Agile initiatives can have a surprisingly short run. At first everything seems rosy, but as soon as the going gets tough, the experiment is history. In "Unintended Consequences -- the Agile death march" I told the sad story of a team demoralized and stricken with "delight withdrawal". It got so bad that team members were resigning. The abandonment of Agile by the organization was the next likely step. But did it need to be so? What might have been done differently to avoid such a messy outcome?...Read More
Notes from the field...
In project management, the phrase "death march" refers to the demoralizing experience people assigned to a doomed project have just prior to and during its death throes. Agile teams generally avoid this type of death march by surfacing risk early and appropriately adjusting course. However, there is another type of death march that Agile teams can experience, and this Agile death march can prove equally if not more damaging to the organization than the type experienced by non-Agile teams...Read More
With sequestration and furloughs a reality and demand for services still high, organizations are dealing with the question of how to do more with less. I submit that how to do more with less may not be the right question. Instead of doing more with less, perhaps the right question is how to do less. In a world of tightening budgets and forced reduction in staff, we don't have the option to do more. Pushing more demand onto a smaller capacity only slows things down. Take, for example, road maintenance on a multi-lane highway that requires shutting down one or more lanes of traffic. The remaining lanes have to take on the amount of traffic that the previous larger number of lanes handled. Inevitably, traffic backs up. It takes longer for each vehicle to reach its destination. The backup happens even though no additional vehicles have been added to the road.
Now, add more vehicles. The backup gets even worse. Little's Law predicts this outcome. The only ways to eliminate the backup are to increase capacity, reduce the amount of time each vehicle spends on the constricted section of the road, or limit the arrival rate of vehicles.
Increasing capacity often requires an increased investment, for example, adding temporary lanes to replace the lanes taken out of service. In this road construction example, reducing the amount of time a vehicle spends on the constricted section of the road has limits constrained by physics and safety. Limiting the arrival rate could be manipulated by offering options, such as a detour around the affected section, or an informational campaign that encourages drivers to avoid the area during peak usage times.
Now, think of your projects as if they were vehicles approaching this construction zone. Though, instead of a construction zone, the projects are entering a delivery process that is constrained by budget cutbacks. Just like there are fewer lanes to support the vehicles in the construction zone, there are fewer people, teams, and infrastructure to support the arriving projects in your delivery system. The reduced capacity also impacts the projects that are already in process. If you don't want to increase cycle time, that is, the time it takes a project to be completed, you must do something. According to Little's Law, there are only 3 options: 1) Increase capacity, 2) Improve flow, or 3)Limit the arrival rate.
Given sequestration, increasing capacity may not be an option.¹ Improving flow can be achieved by adopting Agile practices that speed up the delivery process. This solution is analogous to reducing the amount of time a vehicle spends in the construction zone. If the cycle time increases to an unsatisfactory level despite flow improvements, the only remaining option is to limit the arrival rate of projects.
Which projects to do and which to delay or put off altogether is a portfolio management problem. Little's Law and Pareto are useful techniques for analyzing this problem, but the ultimate goal is to pick which projects generate the greatest return and focus on those. Directing the limited capacity of the organization at a smaller set of high value work is not "doing more with less," but rather doing the right work, at the right time, within capacity constraints, which is, by the way, what we probably should have been doing all along. Sometimes it takes a crisis, like sequestration, to force the issue into action. So, this is an opportunity to do the right thing. Don't waste it.
¹Depending the organization's business model it may be opportunistic to increase capacity at a time when others must cut back, but that is a topic for another day.
"A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away." - Antoine de Saint-Exupéry One of the tricks that makes Agile work is keeping things small. In practice, small may be the "secret sauce" in Agile.
Small releases, small iterations, small teams, small queues, small user stories (the "S" in the "INVEST" acronym) -- Small is good. Small is beautiful.
One of the tricks to keeping things small is Pareto. Also known as the 80/20 rule, the Pareto Principle basically states that 80% of the effect comes from 20% of the cause.
To see how the Pareto Principle applies in Agile, consider a feature. Most of the value of a feature is in the happy path, the default scenario. The happy path is the scenario where everything works as intended with no missteps. The edge cases or exception paths carry different values, but none are likely to trump the happy path -- not by a long shot. Quality specifications inform the value of edge cases, and quality specifications may dictate that some edge cases are essential for a production release. Regardless, the happy path is where most of the value lies. Very likely the 80% value or "effect" is in the happy path.
Product Owners can break a complex user story into multiple smaller stories by separating the happy path and the exception cases into separate user stories with each story representing a unique and distinct path through the feature. The order of these stories in the product backlog would be the happy path first, followed by the next highest value exception path scenario, and so on.
Since product backlogs almost always contain more than one feature, the stories associated with one feature would almost always be interleaved with stories from other features. The Pareto Principle tells us that the value in the subsequent stories after the happy path story starts to fall off at a very rapid rate. The diminishing returns of these exception path stories means that, at some point, the value of the happy path of a "lower" value feature might exceed the value of the next "not yet started" exception path story of a "higher" value feature.
In this way, the Product Owner plays a value optimization game, sequencing the items in the product backlog by comparing exception paths of one story to happy paths of others. As stories are completed or "done," the Product Owner determines readiness for production by considering the appropriate level of quality required for the features to be deployed.
The Macro is in the Micro
The applicability of the Pareto Principle doesn't stop at a user stories and the product backlog. It applies equally well at the product portfolio level. The Pareto Principle shows us how small is beautiful. In truth, less is more.