Don’t Lock in Tough Decisions Early

By July 9, 2015Agile, Article

Part 1 of 6 in the Double the Value in Half the Time series based on David Hawks’ presentation from Keep Austin Agile 2015 . Stay tuned for subsequent posts…

Traditional Project Planning

Traditionally we create our plans up front at our Dumbest Point. We take our requirements, get our estimates, set our target and lock it in.

I used to love creating this plan, since I enjoy a tough puzzle. How can I take all the estimated tasks of varying sizes and allocate those efficiently across all my “resources”? I would open up MS Project and start dragging things around, assigning Resource 1 to work on Task 1 for 2.2 days and then pick up Task 2 for around 3.8 days. Meanwhile, Resource 2 would be allocated 70% to one task and 30% to another. Once those dependencies were completed at the end of week 1, then Resource 3 could start their item.

This would continue until the end and I’d have this Eureka moment when I had solved the puzzle. Everyone was perfectly load balanced with my “perfect plan”. I would present it to executive management, who would look at it and say, “Awesome! You guys really must know what you’re doing over there based on the precision of this plan.” You know what I call those plans now? Mythical Certainty. They provide an illusion of accuracy in our estimates and in our understanding of the user’s needs. And do you think my “perfect plan” was open to change? No way!! Any big changes along the way would totally disrupt the my “perfect plan”.

Defer decisions to the last responsible moment - continuous agile planningSo are we creating these plans at our smartest point? No! Not only are we making these plans at our dumbest point, but we tend to lock them in.

Continuous Agile Planning

It is a fallacy in Agile that we don’t plan. The reality is we plan and re-plan continuously. If we are using our empirical process control we should be constantly inspecting and adapting. We progress in a series of Sprints in Scrum, and after each Sprint we will inspect our progress, review what we learned and potentially pivot on our path.

This is done all in an effort to deliver the most value possible given the constraints of time and budget (or, as in most cases, the size of your allocated team).

This is where the third Agile Manifesto value statement comes into play:

“Customer Collaboration over Contract Negotiation”

Our goal is not to just manage to the plan, but to maximize the value delivered. To accomplish this, we need to Accelerate Learning throughout the project and involve customers in the process. If we aren’t reaching a Potentially Shippable Product Increment every Sprint, we won’t accomplish this. The Potentially Shippable Product Increment is the Rosetta Stone that unlocks so much in Agile. If you carry over work from Sprint to Sprint, you can’t pivot. If your Definition of Done does not include testing and bug fixing, then you don’t know if your software works, thus deferring risk.

The third element of an empirical process is transparency and it is critical to accomplish this consistent pivoting. This is where Principle #7 in the Agile Manifesto comes into play:

“Working software is the primary measure of progress”

Only if we truly finish working verified items, will we learn and understand what progress we are making towards the goal. Only then we will gain the required insight to pivot to the best outcome possible. While your teams are getting gains from Agile, getting to done and delivering working product increments is a hard capability to acquire. It’s common for teams to need guidance to reach this next level. Go here if you’re interested in learning more about our supplementary Agile coaching services like agility tune-ups.

Next topic in the Double the Value in Half the Time series: It’s About Requirements Discovery, Not Just Delivery.

Leave a Reply