Don’t Let Too Little Planning Tank Your Agile Adoption
One of the most prevalent misconceptions I hear from organizations struggling with agile adoption is about planning. Many organizations turning to agile believe it means avoiding planning—it’s a common stance for those who have never truly experienced being on a highly functioning agile team.
This couldn't be further from the truth. A healthy agile team does just as much (if not more) planning than a team using a traditional, waterfall software development methodology.
This approach is derived from the Agile Manifesto: An agile team values "Responding to change over following a plan," but this doesn’t mean an agile team does no planning. The expectation is that the team will deliver greater value from starting on the well-known requirements than it would from continuing to invest in additional planning.
The value of any learning that results from getting started will have a greater return on investment than the value from continued planning. An agile team expects that once it gets started, the plan that has been developed is likely to change before they are done based on what the team has learned.
Agile planning happens throughout the project. In the absence of this planning, projects are doomed to run over budget and over schedule. What’s worse, the delivered product (if there ever is one) will not accurately meet the customer’s needs or the original project objectives, resulting in project missteps or failure. Additionally, the code generated is likely to be of suspect quality (typically buggy and not easily maintained or extended).
Effective planning takes place before the project starts, and monthly sprint planning ensures the backlog is prioritized and requirements are well understood. When goals are presented to the development team early, it gives them a chance to understand the scope of the project, begin thinking about how they would deliver it, and get initial buy-in. It also gives the product owner an opportunity to refine the requirements before the story is deemed ready for development. This type of planning is important because it allows the team to understand the big picture so that they can think through a high-level application architecture.
It’s important to spend enough time during your sprint kickoff to plan how you will deliver on the stories for each sprint. The team plans out the detailed tasks necessary to deliver on each story. These tasks are then estimated and the team commits to delivering the number of features they believe they can complete during the sprint.
During the sprint, these detailed requirements are used by the developers to design and build software, create end-user documentation, and successfully deploy the software. Sprint planning is also a key component for testers so that they can write well-designed tests, establish acceptance criteria, and, most importantly, outline a test strategy to reduce duplication of effort and ensure tests properly cover all the key functionality.
If you take the time to prepare and continually maintain a product backlog, your project will proceed more predictably, the end product will better address the customer’s needs, and the code produced will be of higher quality—and you will enjoy a more successful agile adoption.
