Balancing Adaptability and Predictability

This content is syndicated from Jim Highsmith by Jim Highsmith. To view the original post in full, click here.

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.

Multi-level, Multi-timeframe

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.

Leave a Reply

Your email address will not be published. Required fields are marked *

9 − two =

There are 101 ways to do anything.
To find the best way, sometimes you need expert help

What People Say

“Kelly revolutionised the way our digital department operated. A true advocate of agile principles, he quickly improved internal communication within our teams and our internal clients by aligning our business and creating a much enhanced sense of transparency in the decisions the business was making. Kelly also introduced a higher sense of empowerment to the development teams...”


“Kelly is an extremely talented and visionary leader. As such he manages to inspire all around him to achieve their best. He is passionate about agile and has a wealth of experience to bring to bear in this area. If you're 'lucky' he might even tell you all about his agile blog. Above all this, Kelly is great fun to work with. He is always relaxed and never gets stressed - and trust me, he had plenty of opportunity here! If you get the chance to work with Kelly, don't pass it up.”


“Kelly and I worked together on a very large project trying to secure a new Insurer client. Kelly had fantastic commercial awareness as well as his technical expertise. Without him I would never had secured this client so I owe a lot to him. He is also a really great guy!”


“Kelly’s a leading program director with the ability to take charge from day one and keep strong momentum at both a program and project level driving prioritisation, resourcing and budgeting agendas. Kelly operates with an easy-going style and possesses a strong facilitation skill set. From my 5 months experience working with Kelly, I would recommend Kelly to program manage large scale, complex, cross company change programs both from a business and IT perspective.”


“Kelly was a great colleague to work with - highly competent, trustworthy and generally a nice bloke.”


“I worked with Kelly on many projects at IPC and I was always impressed with his approach to all of them, always ensuring the most commercially viable route was taken. He is great at managing relationships and it was always a pleasure working with him.”


“Kelly came to the department and has really made a huge impact on how the department communicates, collaborates and generally gets things done. We were already developing in an agile way, but Kelly has brought us even more into alignment with agile and scrum best practices, being eager to share information and willing to work with us to change our processes rather than dictate how things must be done. He is highly knowledgable about agile development (as his active blog proves) but his blog won't show what a friendly and knowledgeable guy he is. I highly recommend Kelly to anyone looking for a CTO or a seminar on agile/scrum practices - you won't be disappointed!”


“I worked with Kelly whilst at Thoughtworks and found him to be a most inspiring individual, his common-sense approach coupled with a deep understanding of Agile and business makes him an invaluable asset to any organisation. I can't recommend Kelly enough.”


“Kelly is an Agile heavy-weight. He came in to assess my multi-million $ Agile development program which wasn’t delivering the right throughput. He interviewed most of the team and made some key recommendations that, when implemented, showed immediate results. I couldn’t ask for more than that except he’s a really nice guy as well.”


“Kelly was engaged as a Program Director on a complex business and technology transformation program for Suncorp Commercial Insurance. Kelly drew on his key capabilities and depth of experience to bring together disparate parties in a harmonised way, ensuring the initiate and concept phases of the program were understood and well formulated. Excellent outcome in a very short time frame. ”


“Kelly was a brilliant CTO and a great support to me in the time we worked together. I owe Kelly a great deal in terms of direction and how to get things done under sometimes difficult circumstances. Thanks Kelly.”



To explore how we can help you, please get in touch