Any type of software development methodology such as Agile or LEAN is just that: a methodology. Implementing that into an effective process for a development team in the real world can often be challenging. This article explores four real world challenges that frequently prevent teams from being effective with Agile:
1. Manage the dependencies between the front-end and the backend.
2. UX
3. Details Still Matter
4. Estimates Change. Release Planning is continuous.
Staying just enough ahead of the curve in these 4 areas will allow the development and business teams to focus on quality, maximize velocity, and get code shipped.
Manage the dependencies between the front-end and the backend.
There are no dependencies between user stories in a pure Agile world. This means that front-end work and backend work for a particular feature need to be completed together into one story. However, in the real world of product development this isn’t always so simple when managing separate front-end and backend engineering teams which is often the case. This can quickly slow Sprint velocity where stories are being completed on the front-end but are waiting on updates to the backend.
Communication is critical to identifying these dependencies and understanding how they will factor into the Sprint schedule in order to prevent a major backup of user stories from being accepted. Looking a few Sprints ahead to identify needed backend work will help keep the teams on schedule and limit surprises at the end of a Sprint with low acceptance rates.
UX
UX decisions can happen after a User Story is written, but they should ideally be happening before Sprint Planning. A strong UX team will often challenge the way the Business sees the direction of a story. If the UX team can stay at least two Sprints ahead of development team it will maximize the velocity of engineering by not having to change UX and design mid-Sprint or later. This also allows Sprint planning meetings to stay focused to the task at hand of explaining what development needs to do for each user story, and not derailed by talking through UX questions and design challenges.
Staying ahead will greatly reduce Sprint Planning meeting time and also reduce re-work that needs to be done for stories that are still in need of clarification for design.
Details Still Matter
Agile is not an excuse for laziness with details. It just means that not all details are necessary to work, and understanding that some details will change in time. It’s easy as a project or product manager to write a user story without explaining requirements, pat yourself on the back for not being Waterfall, and call it a day.
However, if the goal of Agile development is efficiency and velocity then both of those goals are going to take a hit before long without the proper detail. The key to this point is the right amount of detail, and when it is needed. An engineering team does not need every test case and acceptance criteria for a user story that is 5 Sprints out even to give it an estimate, but they absolutely need that level of detail before a Sprint Planning meeting for stories that are about to start.
Estimates Change. Release Planning is continuous.
Planning and estimating are amazing tools to creating a roadmap for a release schedule. Regardless, this cannot be a one time process at the beginning of a project or a new release cycle. It is critical to find points throughout the project lifecycle to evaluate the release schedule and story point estimates and make sure they are still aligned to the reality of development.
There are too many variables that change throughout a project which make estimations not fully predictable from the start: increased complexity as requirements become more detailed, added dependencies, scope creep, priority changes from the business, resource turnover, and many more. A project/product manager should work with the development team to re-evaluate estimates every few Sprints and communicate this information to the Business to adjust the Release Plan and priorities as necessary.
Conclusion
Being Agile does not excuse planning. The problem that development teams are attempting to solve with Agile is to not be so rigid with planning that real world change in software cannot occur. Knowing how to plan just enough, and when to do it will make all the difference.
Want to learn more about Agile and LEAN best practices? Visit us in San Francisco this December at the Lean Startup Conference 2013, where we will run a workshop on Using Lean Startup Principles to Add Mobile to Your Enterprise App Portfolio. Is your battleship pointed the right way?
