We all know how to plan. From waterfall, we know how to over plan. But how much planning is necessary if you are using an agile approach? Here’s an idea…try starting the first piece of a project before you have the full plan. Radical thought? Did your heart skip a beat? Here’s why this experiment might change your attitude about planning.
- Skipping a formal plan will speed up your scrum team. Organizations that proceed without a full project plan will deliver value quicker to the business. Let your teams engage on the project and start to learn.  Jump boldly in the water!
- The product will begin to evolve quicker without a formal plan. Typically, any plans need to be reworked after teams engage because of what they learn as they develop. Determine a first step that delivers the most value. Execute against that piece. Determine the next most important piece and execute. Other pieces will begin to fall into place, and your plan will evolve. Change is inevitable!
- When you allow your team to engage quicker, you will have higher customer satisfaction and faster ROI. Even if there is some rework, erring on the side of action is preferable. Focus on the business value in choosing which pieces to start. Delight your customers and stakeholders!
- When developers are involved in the planning, they take ownership of the product. Having architects or leaders do planning before the scrum team causes your developers to miss out on that ownership. In waterfall, we told developers exactly what to do, and they did it. Giving your team a plan in agile may cause the developers to fall into this same pattern. In agile, they should own the work and make suggestions to deliver more value. Do not allow plans to stifle creativity. Let the team own the solution!
- Team morale improves when the team is part of the solution. Since the team is working with the stakeholders and the product daily, they are a valuable source for information. Include them in determining which pieces to start with and how much of a plan is necessary. Then watch their enthusiasm as they engage on the project. Go Team!
Some projects may have more of a need for prior planning (for instance, projects in heavily regulated areas or with high risk that needs mitigating). But for many projects you will reap more benefits from beginning without a plan and letting your plan evolve more naturally. Some rework will be necessary as your team solidifies the solution. Why are we terrified of “rework”? That mindset is a holdover from waterfall! Rework is an acceptable by-product for an agile methodology and is encouraged. Rework means that the functionality or product is evolving. Stress options thinking and making decisions at the last responsible moment to lessen the amount of rework needed as you reap the benefits of allowing the plan to evolve.
What do you think? Do you agree? Any successes to share?
