“Planning is everything. Plans are nothing.” —Field Marshal Helmuth Graf von Moltke
Predictability brings control. Control is what project managers are supposed to do. It’s no surprise that traditional project management practices strive to achieve one thing – predictability.
But can anyone really guarantee predictability?
Software projects, just like any business project, are exposed to macro factors outside anyone’s control. Changes in regulations may increase complexity of key modules manifold. Competitors may introduce a new product that challenges the rules of the game. Requirements that made sense at the beginning of the project may no longer remain feasible or necessary.
The very nature of software development is such that early in a project, a number of variables that control outcome of the project are usually unclear – such as the ROI expectation or the architecture implementation details. The impact of this variability is more significant at the beginning of the project and usually tapers down as the project approaches completion. Steve McConnell demonstrated this pattern using his famous cone of uncertainty.
Ironically, project planning is supposed to be done at the beginning. Or atleast that’s what sequential models like Waterfall recommend.
If the objective of project planning is to ensure that the project achieves what it was meant to accomplish, then something is clearly not right. The key is knowing that the plans are not cast in stone, but rather need to adapt to changing scenarios as things evolve.
Enter Agile Planning
One of the fundamental values of Agile development “Responding to change over following a plan” can be easily misinterpreted into thinking that being Agile means being without plans. Nothing could be further from truth. I wish one could rephrase it to “Responding to change over following a predetermined plan”.
Agile delivery places more emphasis on the plan the verb than plan the noun. Continuous and adaptive planning is the key. As Mike Cohn says in Agile Estimating and Planning, “An agile plan is one that we are not only willing but also eager to change”.
This is not much different from Progressive Elaboration or Rolling Wave Planning (which is a kind of Progressive Elaboration) techniques PMBOK describes.
Plan for the known and adapt to the unknown. Because project planning is not just about deadlines and schedules. It’s about a quest for value. It’s an ongoing attempt to find solutions to questions. Are we building the right thing? As we start the project, the initial focus can be on determining high-level timelines and features. As more clarity emerges about features to be developed, individual features can be planned in detail.
So Are There Any Challenges?
You bet. Agile planning is both easy and difficult. Easy because the iterative approach allows project plans to evolve as the project progresses. Difficult because it’s more dynamic, ongoing, and much more work!
What to Explore
Here are some real-life challenges that Agile Planning may need to address.
1. Translating Product Vision To Iterations
Jumping in too quickly to start the development may turn counterproductive. It’s crucial that the team management and Product Owner together establish a roadmap that keeps the team on the path of achieving targeted objectives. It does take some efforts at the start of the project to articulate the product vision and analyze available requirements. Involving key team members and the Product Owner helps set a clear vision.
2. Knowing You Are Delivering The Right Thing
The Product Owner plays a key role in ensuring project success. Translating business needs into project objectives may seem easy on the surface, but it is a tricky task. The person in this role may need to stay constantly involved with the development team for iteration demos and mid-iteration interactions. The Product Owner represents the business and plays a crucial role in not just validating iteration output but also drives the development of UI designs, use cases, and test cases.
This is a hands-on, high involvement job and can turn daunting especially when done in an onsite-offshore setting. BitWise agile projects delivered from offshore, have a designated Proxy Product Owner who is co-located with the team and usually comes from a testing or a business analysis background. The Proxy Product Owner assists in creating use cases and test cases while maintaining close communication with the real Product Owner.
3. You Can’t Predict Defects
That’s why you need to keep some bandwidth available to fix them. Usually, more bug-fixing bandwidth is recommended for later iterations compared to earlier ones. Historical data, if available, plays a crucial role in deciding how much of bandwidth is really required at different stages.
Continuous testing plays a key role in the success of Agile projects. The team needs to be equipped and prepared to handle the amount of testing necessary for the project. The disastrous launch of healthcare.gov in late 2013 is a good case in point.
An important feature of BitWise agile projects is a dedicated iteration for regression testing, usually towards the end of a milestone or project. It has provided incredible value to customers and ensured adequate attention is paid to defects.
4. Do Iterative Changes Affect Product Design?
Design, like integration and testing, is a continuous activity. The iterative approach provides the luxury to plan a design that’s minimum viable and enhance it from there. Bitwise Agile iterations deliver not only code but also design improvements as deliverables.
Unless you are careful and have invested some upfront effort in setting up a clear roadmap and future-proofing the design, it won’t be long before you start worrying about the rework frequent design changes are causing.
5. Timeboxing Research-Oriented Tasks
Having incomplete tasks at the end of an iteration is not a very uncommon scenario. Especially, if the tasks involve technically complex research-oriented work. Apart from derailing team velocity, such tasks may impact a more important metric – customer satisfaction. The sprint retrospective is an opportunity to brainstorm the causes and consider alternative approaches.
So what are the options? Not too many, really. Either it can be moved to the next iteration if it’s more than halfway through or move it back to the product backlog and reprioritize.
Conclusion
Agile delivery works. Confirmed by a large percentage of teams across domains and organizations who are adopting or have already adopted Agile. An adaptive planning approach and clever handling of challenges are what differentiates a successful Agile project from an unsuccessful one.
Bitwise has consulted a number of clients on delivering Agile projects and helped overcome challenges. Think we can help? Do let us know.
Recommended Content
You Might Also Like
Data Analytics and AI
5 Essential Steps to Assess Your Readiness for Microsoft Fabric Adoption
Learn More
ETL Migration
