One of the most vexing issues for executives and managers is balancing the need for both predictability and adaptability in software delivery. While this might seem like an either/or issue, the solutions are really both/and ones. In presentations I often ask the question, “How many of you have been on Agile teams and were asked to be agile, adaptive, flexible—but also asked to conform to the plan?” Mostly I get snickers and mild laughter at the question because most have experienced it.
Ambiguous, uncertain and fast moving environments create paradoxes that cannot be resolved by canned answers. Teams and managers need to understand how to manage these paradoxes by finding ways to do both—to predict and adapt within the same delivery effort. So here are some of my thoughts about riding this paradox.
One of the key ways that Agile teams predict schedule (which is often the most critical attribute for management) is to timebox the effort. While a timebox specifies the schedule for a release of the product, it’s really more about forcing hard trade off decisions than timing per se. Agilists prefer to adjust scope in order to meet time deadlines. This approach has proved very effective and some people refer to this as a release train (as in the train is leaving the station on time and you are either on or not). However, some managers are uncomfortable with scope adjustments, viewing it as an excuse to under-perform—which in some cases has been true. So scope adjustments, as in any complex trade-off situation, must be visible and defensible.
Confusing Plans and Targets
One big problem, in either traditional or Agile projects, is confusing plans and targets—and the level of commitment to each. A target is a goal, usually set by management and usually associated with a date, based on the business situation. The situation could be a regulatory requirement or a manager’s assessment of when a new product needed to be launched. It is not an engineering estimate of the project. A plan incorporates the best engineering estimates that can be made at the time (not very good sometimes in the beginning). The target is basically, “I need it by June,” and the engineering estimate is basically, “given these conditions, we can deliver the product by August.” The discrepancy is the bases for negotiation—less scope, more people, etc. Engineers should not be upset when given targets—they are expressions of a valid business need. Managers should not be upset at engineering estimates—they are expressions of a thoughtful analysis of the work required. Plans are the results of negotiating these two perspectives until common ground is reached.
Traditional project teams often plan an entire project in mind-numbing detail (as in thousands of detail tasks). Agile teams do skeleton planning up front and then continuous planning and re-planning as the project proceeds. With larger and longer projects (which we try to avoid but can’t always), the planning should be broken into Roadmaps (6-18 months), Release (3-6 months), and iterations (2 weeks). Each of these levels should be planned at a different level of precision—Capability (40-90 days or story points), Feature (10-39 days or SP), and Story (2-10 days or SP). Roadmaps should be considered targets and not commitments. Commitments at the Capability level should be general (as in we will deliver functionality that will meet this Capability) not a commitment to detail requirements. At shorter time horizons and greater granularity the greater the commitment level should be.
Value, not Task Planning
Several studies have shown that over 50% of the functionality in software applications is rarely or never used. From a lean perspective, the biggest “waste” factor in software development is low- or no-value features. If we were able to eliminate 15, or 20, or 30 percent of the scope of software projects, we would increase the chances of meeting planned delivery dates. Agile’s biggest contribution to productivity can be all the functionality we don’t produce.
But it’s not just about cutting out, but about emphasizing the right thing—and that thing is value. Product managers should be calculating business value, either relative or monetary, to the feature level so teams can produce the highest value feature early. Then, if scope reductions need to happen later in a project, those eliminated features come from the lower-value list.
Pivots and Adaptations
There is an interesting concept coming out of the Lean Start Up movement called a pivot. A pivot is when a start-up company realizes its business model isn’t working in some significant way, and they therefore change or pivot to a revised model. While the pivot term has seemingly has been over used and over hyped, the concept can be applied to projects. Some project changes are normal adaptations, smaller changes to accommodate the myriad of things that arise during a project. However, occasionally (hopefully not more than once or twice a project), large issues arise that entail a significant change in its value proposition, a major problem with the technology or architecture, or an updated release plan that indicates major schedule problems. At this point, the project should “pivot.” Pivoting is a recognition that at project or product plan won’t work as envisioned. Pivoting should be viewed as adapting to changes or learning new information, not as an opportunity to start the blame game.
Short Time Horizons
One way to ease the predictability/adaptability predicament is to shorten the deployment time horizon. While this strategy is product dependent, many organizations can do much better in this regard. And, I’m not just talking about the software delivery organization. When we practices continuous delivery, for example, and the cycle time for feature delivery is reduced, the business units must be prepared to deploy, use, support and promote the new features on a daily or weekly basis possibly. Trying to predict 3 months in advance is much easier than predicting (actually much more like guessing) 18 months out. Having short time horizons are actually the best way to solve the predictability-adaptability paradox.
False Predictability Requirements
And finally, there are just those times when requirements for predictability are just false, or seemingly ludicrous. I recently had someone say, “We can’t go Agile because our customers need for us to commit to a plan 18 months in advance.” To which I responded with my traditional Agile consultant question, “So how’s that working out for you?” Many times customer requests like this are a product of a long dysfunctional relationship with their software delivery organizations. The results of that dysfunction are manifested in weird ways—like “since we have never delivered according to our plan for the last 5 years, let’s try to predict delivery even further out!” In many situations solving the dysfunctional relationship problems (that Agile delivery often helps to do) solve the predictability-adaptability problem.