We’ve added a Lean Agile Leadership Workshop event in Wellington, New Zealand (It was Auckland at one point, but it moved, sorry) on Feb 28&29. Also, the Australia dates have been changed. The new dates are:
Sydney – Feb 7 & 8 and Melbourne Feb 14 & 15.
Sorry if that caused any confusion.
You can register through Agile University here.
As I’ve noted on this blog before, delivering my two-day Lean|Agile Leadership workshop to managers and executives is one of the most fun things I get to do. Even more importantly, it has a major benefit in preparing leaders, managers and executives to lead, rather than follow, this critical business transformation. After all, no enterprise can be leaner than its executives thinking.
Most of these workshops are delivered at a client’s site. However, I do have two public workshops scheduled in Sydney (February 7&8) and Melbourne (Feb 14&15), Australia in February 2012. You can register for these workshops through Agile University here:
While I was thinking about my then-upcoming presentation entitled Five Keys to Building the Lean Agile Enterprise for Agile 2011, I was contacted by Joe Dager, owner of Business901, about doing a podcast on essentially the same topic. Joe did an excellent job of interviewing me and framing the discussion in pragmatic terms that are directly relevant to most every leader, manager and executive contemplating, or in the midst of, a substantial Lean|Agile enterprise software transformation. A reader just pointed me to the podcast which is posted here. (The title, Lean Agile Software Train Description, is a little different, but the content is even broader than the Agile 2011 presentation.)
This is a pretty far ranging discussion, and on review, I thing it does a fair job of covering a number of critical topics, including:
➵Not Everything is a User Story: Scalable Agile Requirements
➵Think Agile Programs, Not Just Agile Teams: The Agile Release Train and Program Kickstart
➵Enterprise Systems Require Intentional Architecture: Rearchitecting with Flow
➵Portfolio Management Must be Agile Too: Addressing Legacy Mindsets and the Agile PMO
➵Your Enterprise Can Be No Leaner Than the Executives Thinking: Lean Education and The Big Picture
as well as a discussion of lessons learned in a number of larger scale transformations.
My colleague, (and partner in a number of agile rollouts), Alex Yakyma from Kyiv, Ukraine, has been opining on how the Agile Release Train and the Scaled Agile Delivery Model in general, helps drive knowledge acquisition, accumulation, and flow in the agile enterprise. He just put up a new post, Knowledge Flow in the Scaled Agile Delivery Model, which describes Nonaka and Konno’s Socialization, Externalization, Combination, and Internalization (SECI) model for the acquisition of new knowledge. We’ve seen this “ba” (*the Zen of Scrum, see note below) drive teams to higher and higher levels of performance, and we see it in some agile programs (release trains) too.
I think you’ll find the article interesting, but fair warning, there will be some thinking involved. (But that’s usually required for new knowledge acquisition).
*Note: “Ba” is the energy and knowledge acquisition power of agile teams, or as Jeff Sutherland puts it, “BA is the zen of Scrum”. Ba can be described as follows:
Last year, when I was writing Agile Software Requirements, I was researching various strategies (algorithm is too strong a term) for prioritizing user stories, and perhaps more importantly the features of a solution, and even higher on the economic food chain, the portfolio epics that drive the solution roadmap. (That’s where the real economic leverage comes – from the portfolio level.)
I admit that I was never much impressed by what I had read or written on the topic of prioritizing requirements prior (ok, so delighters are better than satisfiers, who can say what is one and what is the other, or which MMF to do first?), so I wanted to take a fresh look.
About that time, I came across Reinersten’s latest book, Principles of Product Development Flow, and I quickly gravitated to his lean, flow-based model for prioritizing work, based on the Cost of Delay, and which he summarizes in a model which he calls Weighted Shortest Job First (WSJF). I also was able to attend one of his workshops, so I had a chance to ask a few relevant questions, which improved my understanding. While Reinersten’s book is not about software per se, the lean economic principles apply extremely well in agile, so prior to writing the book, I started using the WSJF method in various classes and consulting engagements.
So that you don’t have to go through all the laborious history and derivations that I seem to bludgeon readers with, I’ve summarized the model that evolved over time below. (however, if you are serious about software economics, you’ll need to understand the fuller model.) Here’s the synopsis picture from one of my current presentations:
Here’s what we recommend for Cost of Delay for software:
And finally, here’s the spreadsheet I like to use for prioritizing jobs (in our case – epics, features, and stories).
“Simply” you rate each job relative to other jobs on each of the three parameters, divide by the size of the job (which as equivalent to length of the job in most cases) (oops?…your backlog is estimated right?) and come up with a number that rates the job priority (note: because of the way we’ve set up the relative rating system, higher numbers have higher economic priority).
And guess what, while the results often surprise people, it seems to work really well. After a bit, people really get it and then they realize they can use the same model to prioritize work, based on lean economics, at any level of the Big Picture (Scaled Agile Delivery Model). This creates a common basis for economic decision making throughout the enterprise. Potentially, THAT is a pretty big deal.
One advantage of the model is that really-big-important jobs (like architectural and business epics) have to be divided into smaller-pretty-important jobs, in order to make the cut against easier ways of making money (i.e., small, low risk features that your customers are willing to pay for now). Now that’s agile thinking.
Also, a subtlety of the model is that we do NOT have to determine the absolute value of any of these numbers, as that’s a fool’s errand. Rather, we only need to rate the parameters of the job against other jobs from the backlog. After all, what credible agile program or team doesn’t have a robust backlog to choose from?
My colleague and agile ninja, Chad Holdorf has been putting this same model to work as well, and he recently did a video blog post on the topic. You can find it here.
http://www.scaledagiledelivery.com/2011/05/05/how-to-prioritize-your-backlog-using-economics/
You can also find a deeper explanation in ASR (but then of course you’d likely to have to buy a copy.)
Note: I have had some questions about the model, particularly as to whether or not it is overkill for user stories at sprint boundaries. After all, there, the size of the job is about the same, (all stories are sized to fit in an iteration, typically 3-5 points) and the time value of the job may have already been determined by higher-level work prioritization, including dependencies with other teams. If that is the case, the model deprecates to a simpler equation:
* Deprecated WSJF model, assuming story size is about the same and that the stories have reached an iteration boundary based on external factors or other logical sequencing. If that is not the case, use the full model!
which probably looks pretty familiar to many of you.
I’ve blogged and written more about the Agile Release Train topic more than most over the last year or two. Thats because for many enterprises, it is the next big step of agile enterprise maturity because it drives strategic alignment and institutionalizes product development flow.
In Scaling Software Agility, I had a chapter on the topic as well. A few years have passed since I wrote that book, and the thinking and practices around the ART have advanced as well.
In the context of the upcoming book Agile Software Requirements: Lean Requirements Practices for Teams, Programs and the Enterprise, I’ve had the opportunity (and need) to update the description and to integrate it more directly to agile requirements management, the Big Picture and product development flow. I thought it was a good draft chapter to share for a while prior to publication, so I’ve posted it here.
Comments welcome.
I’m happy to report that the final chapters of the agile requirements book are largely converging. It now appears as it might actually be finished someday. In the meantime, for those of you who have been interested in the topic of agile architecture, I’ve completed the next draft of Chapter 21 – Rearchitecting with Flow and posted it here for public review and comment.
I think it provides some innovations that might help larger agile enterprises reason about and implement system-level architecture in a lean and agile manner.
I’d like to thank the architects and enterprise agilists at F-Secure Corporation, including KE Tan, Gabor Gunyho, Santeri Kangas, Ari Inki and James Cooper, for their substantial contribution to this Chapter. Even more importantly, they are putting a variant of this system to work right now so we’ll have more feedback over the next few months However, any errors in thinking, logic, design or description are solely my own.
In the last post, I described a system for estimating features that will be in my upcoming book. This post, prioritizing features, is that post’s evil twin. Together, it should be provide a reasonable strategy to estimate cost and schedule for a feature, and a systematic way to pick which features will deliver the highest value first, based on the cost of delay. For context, you may want to browse the Big Picture category and the Agile Requirements category.
One of the largest challenges that all software teams face is prioritizing requirements for implementation and delivery to the customers. This is certainly a challenge for every agile team at iteration boundaries, and it rises to even greater importance when prioritizing features at the program level. Here, small decisions can have big impacts on implementation cost and timeliness of value delivery.
There are a number of reasons why prioritization is such a hard problem:
To assist us in our efforts, we often attempt to provide a Return on Investment (ROI) per feature, by predicting the likely increase in revenue if a feature is available. Of course, investment in determining ROI is most likely a false science, as no ones crystal ball is an adequate predictor of future revenue, especially when you attempt to allocate revenue on a per-feature basis. This is compounded by the fact that the analyst that does the work is likely to develop a vested, personal interest in seeing that the feature is developed. Plus, any product manager or business analyst worth their salt can probably make a case for a great ROI for their feature – otherwise they wouldn’t have worked on it to begin with.
In agile, however, the challenge of prioritization is immutable – we admit up front that we can’t implement (nor even discover) all potential requirements. After all, we have typically fixed quality, resources and delivery schedule. Therefore, the only variable we have is scope. Effective prioritization becomes a mandatory practice and art; one that must be mastered by every agile team and program.
Of course, prioritizing requirements is not a new problem. A number of authors have described reasonable mechanisms for prioritization. Our favorites include
For those for whom this topic is potentially a determinant of program of success or failure of the program, we refer you also to these bodies of work. While we will take a different approach in this post (and upcoming book), there is certainly no one right way to prioritize and teams will benefit from differing perspectives on this unique problem.
As we alluded to above, we have traditionally prioritized work by trying to understand the relative Return on Investment, which is the relationship between potential return (value) divided by the effort (cost to implement) for a feature. At least the model was simple:
If we could simply establish value and cost – if not in absolute terms, then at least relative to other features – then we have a way to prioritize based on economics. After all, who wouldn’t want to deliver a higher ROI feature before a lower ROI feature? That seemed to make totally intuitive and (apparently) economical common sense.
However, based on more complete economic framework, it turns out that relative ROI (as we’ve too simply defined it above) is not an adequate proxy for prioritizing value delivery. Recently, one of the more thoughtful and rigorous economic views to prioritizing value delivery (sequencing work in flow terms) is Reinertsen’s Principles of Product Development Flow [Reinertsen 2009] that we introduced in an earlier post. These principles describe methods of sequencing work based on the mathematics and underlying economics of lean product development.
We’ll use those principles to describe an enhanced method for prioritizing features. As we do so, we’ll discover a deeply seated flaw in our first assumption – the assumption that a high relative ROI project should naturally have precedence over a lower ROI project.
Instead, what need to understand is the way in which the economics of our program may be dramatically affected by sequence. For example, the potential profit for a particular high ROI feature could be less sensitive to a schedule delay than a lower ROI feature. In this case, the lower ROI feature should be implemented first, followed by the higher ROI feature. This may not make intuitive sense, but we’ll see that it does make economic sense.
Since prioritizing value delivery is the key economic driver for a program, we’ll need a more sophisticated model to produce better returns. To build the model, we’ll make a small detour through some of the fundamentals of queuing theory. After all, as we described in another post, prioritizing value delivery in software development is just a special case of queuing theory. So applying those principles will should create a solid foundation for critical decision-making.
As Reinertsen points out “if you only quantify one thing, quantify the cost of delay.”[2], so we’ll need to be able to estimate the CoD as part of our more economically-grounded approach. (More on that shortly). Fortunately, however, we don’t have to only quantify one thing, and as we have already outlined an estimating strategy, we’ll actually be able to quantify two things, the feature effort estimate, as we have described in the last post, and the Cost of Delay. Together, we should have what we need.
In achieving product development flow, Reinertsen describes three methods for prioritizing work based on the economics of Cost of Delay.
When the cost of delay for two features is equal, doing the Shortest (in our case, smallest) Job First, produces the best economic returns, as is illustrated in the Figure below.
Shortest Job First
Fro
Indeed the impact is dramatic, as doing the smallest job first has economic returns that are many times better than doing the larger job first. So we arrive at our first conclusion:
If two features have the same Cost of Delay, do the smallest feature first.
If the size of the jobs are about the same, then the second approach, High Delay Cost First, illustrates the effect of prioritizing the jobs with the highest cost of delay. Again, the economics are compelling as the figure below illustrates.
High Delay Cost First
Of course this makes intuitive sense in this case as well (not that intuition has always led us to the correct conclusion). For if CoD is a proxy for value, and one feature has more value than another and it’s the same effort, we do it first; we knew that already from our ROI Value/Effort proxy. So we have our second conclusion:
If two features have the same effort, do the job with the highest cost of delay first.
Now that we have seen the impact, we understand that these two conclusions are quite sensible when the size or CoD of two features are comparable. Of course, we are not manufacturing widgets here. The Cost of Delay and implementation effort for different software features is highly variable. Plus, often they have weak or no correlations (i.e., some valuable jobs are easy to do, some are hard); that’s just the way it is with software. In the case where the CoD and effort for a feature are highly variable, then the best economics is achieved when we implement them in order of the Weighted Shortest Job First.
In this case, we calculate the relative priority weighting by dividing the CoD by the size estimate. If the CoD and job sizes vary greatly, then the differential economics can be dramatic, as illustrated in the figure below.
Weighted Shortest Job First
This, then, is our preferred approach for software development:
If two features have different size and CoD, do the weighted shortest feature first.
This seems like a promising decision model for prioritizing features. It is based on solid economics and is quite rational once you understand it. However, we have excluded one small item – how does one go about calculating the cost of delay for a feature? If we aren’t careful, we could fall into the analysis trap we mentioned above – overinvesting in calculating size estimates for features – plus overinvestment in calculating CoD – could lead to too much overhead plus a potential bias by those doing the work. We need something simpler.
We suggest that CoD – so critical to our decision-making criteria – is in turn, an aggregation of three attributes of a feature, each of which can be estimated fairly readily, if compared to other features. They are user value, time value, and information discovery value.
With these three value factors, user value, time value, and information discovery value, we have the final pieces to our prioritization puzzle.
Now, we can integrate all this information into an evaluation spreadsheet that we can use to establish the relative priorities for a feature, based on both effort and CoD. An example is shown in the table below below.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Table 1: Spreadsheet for calculating weighted shortest job first
In our example, it is interesting to note that that Feature B – the job with the highest user value (8) and the highest feature/effort rating (1.3) – is actually the job that has the lowest weight, and therefore should be implemented last, not first. The job that has the lowest feature value (Feature A) actually produces the highest actual return on investment, so long as it is implemented first. So much for our intuition!
Reinertsen points out another subtle implication of WSJF scheduling. Priority should be based on delay cost, which is a global property of the feature, and effort, which is a local property of the team that is implementing the feature. In other words, a job with a lower relative feature value may require little resource from a specific team, and therefore should be implemented ahead of another higher priority feature, if that feature requires more resources for that team. This means that all priorities are inherently local[3].
This occasionally flies in the face of the way we often do things, whereby management sets a global priority for a project, which is to be applied across all teams. In that case, a lower priority task for a high priority project may take precedence over a high priority task for a lower priority feature. And availability of scarce resources doesn’t even enter into the equation. We see now that this approach simply doesn’t make economic sense.
In addition, we note that our model is highly sensitive to the time element – priorities change rapidly as deadlines approach. For example: “implement the new testing protocol in time for the school year buying season” could have a time value of “1-2” on the winter prior to the next school year start, but could easily be a “10” in May of the next year.
One conclusion of the above is that priorities have to be determined locally, and at the last responsible moment. That is the time when we can best assess the cost of delay and the resources available to work on the feature.
Fortunately, in our big picture model, we prioritize features on Release ( or PSI) Planning boundaries. Therefore the cadence we established for our release train will serve us well here, so long as we take the time to reprioritize at each such boundary.
When we do so, we can be confident that our priorities are current – taking into account then-current availability of resources and then-current cost of delay, as well as being based on solid economic fundamentals.
Along with his colleagues, Noriaki Kano, an expert on the field of quality management and customer satisfaction, developed a model for customer satisfaction that challenged many traditional beliefs. Specifically, the Kano model challenges the assumption that customer satisfaction is achieved by balancing investment across the various attributes of a product or service. Rather, customer satisfaction can be optimized by focusing on differential features, those “exciters” and “delighters” that increase customer satisfaction and loyalty beyond that which a proportional investment would otherwise merit. The Kano model is shown in the figure below.
Kano Model of Customer Satisfaction
The model illustrates three types of features
The primary insight from the Kano model is the position and shape of the lower and upper curves.
The shape of the basic curve is telling. Until a feature is simply “present”, the investment is proportional to the result, but satisfaction remains low until a threshold is achieved. Thereafter, however, additional investment produces a less than proportional reward. The center point of this curve gives rise to what is often described as the Minimum Marketable Feature (MMF). In other words, in order for solution to be considered viable, it must contain the requisite set of MMFs. However, enhancing or “gold plating” any MMF will not produce a proportional economic return.
The position and shape of the exciters and delighters curve tells the opposite story. Because these features are unique, compelling and differentiated, even a small investment (the area on the left) still produces high customer interest and potential satisfaction. Additional investment produces still more, and proportionally more investment produces still higher satisfaction. This is where we get the greatest leverage for our investment.
Given that we have already described a full-fledged Weighed-Shortest-Job-First prioritization model, the question arises as to what additional benefit we can derive from Kano’s thinking? There are three strategic takeaways:
First, when competing on features in an existing marketplace, teams should place relatively high user value (and therefore a relatively high cost of delay) on features required to reach minimal parity. This leads us to rule #1:
Differential Value Rule #1 – Invest in MMFs, but never overinvest in a feature that is already commoditized.
Thereafter, the strategic focus should move to placing higher user value on differentiating features – those that will excite and delight the users, those for which competitive solutions have no answer, and those for which an incremental investment produces a nonlinear return. This leads us to rule #2:
Differential Value Rule #2 – Drive innovation by having the courage to invest in exciters.
Finally and most subtly, when we are forced to engage in feature wars with competitors that may already be ahead of us, it may not make sense to put all our investment into MMFs. After all, our competitors will keep investing too; what makes us think we can catch up? Instead, it may be better to slight some narrow category of MMFs and, instead, focus some amount of investment on exciters – even if we have not reached full basic feature parity.
Experience has shown that customers can be relatively patient with developers when they can a) reasonably anticipate the appearance of adequate MMFs and b) see the promise of the differential value of the exciters that the team is bringing forward from the backlog. This leads us to our third and final rule of feature prioritization:
Differential Value Rule #3 – If resources do not allow you to compete with the current rules of the game, play a different game.
In this post we’ve provided a method for prioritizing features based on a weighted Cost of Delay. It’s not so different from prior models, but it delivers superior economic returns, and it includes attributes of estimate size (cost), potential return and adjustments for risk (information discovery). We’ve also described the Kano Model which leads to an appropriate bias for investment in exciters and delighters. It may just be common sense; or perhaps its common sense buttressed by the real, yet subtle, economics of product development flow.
Comments welcome.
[2] Principle of Product Development Flow E3: if you only quantify one thing, quantify the Cost of Delay
[3] Principle of Product Development Flow:F18: Prioritizations are inherently local.
Reference: Reinertsen, Don. The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing. 2010.
In the last post, I described the context and objectives for a kanban system for identifying, analyzing and implementing architectural epics in the agile enterprise. This work is being developed in collaboration with Santeri Kangas and others of F-Secure Corp., who are contributing to the model and applying it in their agile development shop. In this post, we’ll introduce the proposed model.
For additional context for this work in process, architectural epics are first class citizens of the agile enterprise in the Big Picture Series (see below)
And the epics themselves are described in the Lean and Scalable Requirements Model:
In the last post, we described the role of system architects and “intentionally emergent architecture” in enterprise class agile development. We also described four primary business factors that drive new, cross cutting, architectural epics:
In order to assure that we address the development of architectural runway in a lean and agile manner, we proposed using a kanban system. We also described the three primary objectives for such a kanban system:
Of course, we probably wouldn’t have invested this time if we didn’t have any idea how such a system might work, and indeed, we have been developing it for the last few months. And, as readers of this blog already know, I like to express concepts visually first, so the reader doesn’t have to pour through a ton of text just to build their own mental model for what it is, and how it works.
So, here is another big picture graphic that highlights the relevant elements of the proposed system.
The underlying assumption for the kanban system is that epics go through a series of four states, each characterized by different activities on the part of the architecture and development teams and correspondingly increasing levels of investment. They are as follows:
The Funnel state is the “capture” state. In this state all new “big ideas” are welcome. They can come from any source. They need no business case or estimates. Tooling is trivial – a document , spreadsheet or simple list on the wall will typically suffice. Since investment is minor, this state is not WIP limited; all ideas are captured for consideration. Funnel epics are discussed periodically. Based on decision criteria, epics in this state can be a) promoted to the next state, b) left in this state, or c) deleted.
Analysis: Backlog
The Analysis:Backlog state is more meaningful; epics that reach this state warrant further investment of time. These epics are roughly sized (we’ve indicated t-shirt sizes to avoid overinvesting in estimates). Investment is controlled to discussion level, and perhaps some very preliminary and lightweight investigation. The epic may be elaborated to a paragraph or two.
Since the investment is increasing, this state is WIP limited, primarily by the capacity of the architecture team.
Analysis:Backlog epics are discussed periodically. Based on decision criteria, epics in this state can be a) promoted to the next state b) demoted back to Funnel state, or c) deleted.
Epics which are promoted to this next state deserve a more rigorous analysis, and require further investment. An architect is typically assigned as the epic owner. An active collaboration with development is initiated. Design alternatives are explored. Options for internal development and/or outsourcing, including 3rd party solutions acquisition, are considered. The affected development teams may estimate the epic. A lightweight business case, with a go or no-go recommendation, is developed. If 3rd party solutions are evaluated, the recommendation is given in priority order.
This state uses scarce resources, so it is WIP limited based on capacity of the architecture and development teams.
Epics that meet the go criteria are promoted to Implementation; otherwise, they are deleted from the queue.
In this state, the epic is moved to implementation and the primary responsibility for the epic is passed to the development teams. This hand-off is effected when the epic appears in release planning. Architect resources remain available on a “pull” basis. (i.e. the responsibility for implementation rests with the development teams, but the architect assists the teams and shares responsibility until the team has developed an understanding of the work required.
This state is WIP limited by the capacity of the development teams and architect’s.
Promotion from State 3 to state 4 is an important economic decision for the enterprise that can be made only by the appropriate authority, based on the developed business case.
In this and the prior post, we’ve introduced the motivation and the model for an architectural epic kanban system. In follow on posts, we’ll develop the model further.
In this blog, in Scaling Software Agility, and in my forthcoming book on Agile Requirements, I’ve been writing fairly extensively on the implementation of the Agile Release Train (also see whitepaper derived from the book) as a means of achieving both strategic alignment and product development flow in the larger software enterprise. It is hard to overstate the importance of the Agile Release Train in how it helps the enterprise achieve product development flow. I spend a lot of my time helping enterprises achieve the benefits of this model.
Recently, I’ve been reading (and rereading) Don Reinersten’s new book The Principles of Product Development Flow: Second Generation Lean Product Development. This book may be the best book on product development I have read in a decade. I strongly recommend it to anyone who finds my blog or the topic of scaling software agility of interest.
In addition to the depth of content, and its simultaneously light, yet rigorous, (is that really possible?) economic and mathematical treatment of flow, I like the way the book is organized around eight major themes of product development flow. They are:
1. Take an economic view
2. Actively manage queues
3. Understand and exploit variability
4. Reduce batch sizes
5. Apply WIP constraints
6. Control flow under uncertainty – cadence and synchronization
7. Get feedback as fast as possible
8. Decentralize control
For a meaningful discussion of these themes, I refer you directly to Reinertsen’s book.
Perhaps not surprisingly, the Agile Release Train maps pretty directly to Reinertsen’s eight primary themes. Understanding this mapping is the key to understanding the criticality and motivation for the ART itself. So to make it easy for you, I’ll map them in this post:
Product Development Flow Theme 1 – Take an economic view.
The ART’s incremental releases substantially improve the ROI of software development by accelerating the release of value to the customer. This helps capture early market share and drives gross margins by delivering features to the market at the time when the market values them most highly.
Product Development Flow Theme 2. Actively manage queues.
The short, frequent planning cycles of the Agile Release Train actively manage queue lengths:
Team backlogs (queues of waiting stories), (see the mildly controversial post on this topic ) are generally limited to about the amount of work that can be accomplished in a single release increment (Or Potentially Shippable Increment). Planning much beyond that is generally not very productive for the teams, because teams know strategic priorities could change at any release boundary.
Release backlogs (queues of waiting features) are typically limited to those features that can realistically be implemented in the next release or two. Beyond that, product managers understand that they may be over-investing in feature elaboration for features that will never see the light of day.
Portfolio backlogs (queues of waiting epics and future projects) are typically limited to those epics that could likely find their way to release planning in the next six months or so. Too early, or too in-depth investment in business cases for those projects that will not be implemented is a form of waste.
Product Development Flow Theme 3. Understand and exploit variability.
Since a high degree of variability is inherent in software development, frequent re-planning provides the opportunity to adjust and adapt to circumstances as fact patterns change. New, unanticipated opportunities can be exploited by quickly adapting plans; critical paths and bottlenecks become clear and resources can be adjusted to optimize throughout through the bottlenecks and better avoid unanticipated delays.
Product Development Flow Theme 4. Reduce batch sizes.
Large batch sizes create unnecessary variability and cause severe delays in delivery and quality. The ART reduces batch sizes by releasing only those features to the development teams that are prioritized, elaborated sufficiently for development, and are sized to fit within the next release cycle. This avoids overloading the development teams with significant number of longer term, parallel development projects, which may or may not ever see the light of day, and in any case cause multiplexing, overhead, and thrashing. The transport (handoff) batch delay between teams is minimized as well, as face to face planning facilitates high bandwidth communication and instant feedback.
Product Development Flow Theme 5. Apply WIP constraints.
In release planning, teams plan their work and take on only the amount of features that their velocity indicates they can achieve. This forces the input rate (agreed-to, negotiated release objectives) to match capacity (what the teams can do in the release). The current release timebox prevents uncontrolled expansion of work; so the current release does not become a “feature magnet” for new ideas. The global WIP pool, consisting of features and epics in the enterprise backlog, is constrained by the local WIP pools, which reflects the team’s current backlog driven by the current release increment. When WIP is too high, lower value projects either a) never make it into development, or b) are purged during, or just prior to, release planning.
Product Development Flow Theme 6. Control flow under uncertainty – cadence and synchronization.
Planning – The release train planning cadence makes planning predictable, and lowers transaction costs (facilities, overhead, travel.) Planning can be scheduled well in advance, allowing participation by all key stakeholders in most planning events, making face to face information transport reliable and predictable.
Periodic re-planning (resynchronization) allows us to limit variance and misalignment to a single planning interval.
Releasing – The cadence and synchronization of regular, system-wide integration provides high fidelity system tests and objective assessment of project status at regular intervals. Transaction costs are lowered as teams invest in infrastructure necessary for continuous integration, automated testing, and deployment. Since planning is bottom up, (performed by the teams and based on teams actual known velocity) and short term, delivery becomes predictable. Most all that has been planned should be reliably available as scheduled.
Product Development Flow Theme 7. Get feedback as fast as possible.
The fast feedback of the iteration and release cycle allows us to take fast corrective action. Even within the course of a release increment (or PSI), feedback is no more than two weeks (or the iteration length) away. Small incremental releases to customers allow us to track more quickly to their actual, rather than anticipated, needs. Incorrect paths can be abandoned more quickly (at worse, at the next planning cycle).
Product Development Flow Theme 8. Decentralize control.
Release plans are prepared by the teams who are doing the actual implementation, rather than by a planning office or project management function. Commitments to the plans are bottom-up, based on individual’s commitment to their teammates and team-to-team commitments reached during the planning cycle. Once planned, the teams are responsible for execution, albeit subject to appropriate lightweight governance and release management. Agile project management tooling automates routine reporting; management does not have to slow down the teams to assess actual status.
That’s it for this post, though I expect I’ll visit the topic again, as it’s certainly going to be a major theme of the next book. In the meantime, you might want to read Reinertsen’s new book, as it’s available now.
Scaling Software Agility 