How do you decide what you're going to do (or drink) first?

How do you decide what you’re going to do (or drink) first?

Deciding which piece of work should be done first is a vexing question of any organization. Every organization finds a set of tools to help sift through the portfolio of possible projects. In organizations without some form of central portfolio control, each department or team may have its own set of criteria to decide which job to do first. Techniques for prioritization that I have seen in action range from ‘the squeaky wheel’ to a highly detailed cost-benefit analysis. One method that I was initially exposed during SAFe training was the weighted shortest job first (WSJF).

WSJF begins with the cost of delay. Cost of delay (CoD) is a method of placing a value on the waste inherent in delay. There are any number of factors that can (and often should) be included in the cost of delay. These include wait times, inventory costs and opportunity costs. Once the CoD has been estimated, the time to complete the work (also known as duration) is used as a weighting mechanism to differentiate between projects.

Donald Reinertsen, in his book The Principles of Product Development Flow: Second Generation Lean Product Development, provided an example that showed that if the cost of delay was the same for two jobs, you should do the shortest job first. One way to conceptualize this is that by doing the shortest job first you would avoid at least some cost of delay and deliver value sooner. Here is an example:

CoD per day                          Time to Complete

Work Item 1                          $100                                          1 Days

Work Item 2                          $100                                          2 Days

Work Item 3                          $100                                          5 Days

Doing the work item 1, then 2 and then 3 (shortest to longest) would mean 0 cost of delay for item one, $100 CoD (1 day X $100 ) for item 2 and $300 CoD (1 day +2 days X $100). A total of $400 in CoD would be incurred. Compare the doing the earliest job first to the doing the work in the opposite order (longest to shortest).

Work Item 3 – Zero CoD Accrued

Work Item 2 – $500 CoD (5 days x $100)

Work Item 1 – $700 CoD (5 days + 2 days x $100)

$1,200 in CoD versus $400 . . . I know which order I would choose.

Obviously things are typically messier with estimates of CoD and time to complete. SAFe uses the size/time to complete attribute as a weighting factor to identify the weighted smallest job (so that it can be done first). The calculation for weighted shortest job first (WSJF) is CoD/Duration. Her is an example:

CoD per day                          Time to Complete             Weight

Work Item 1                          $100                                          25 Days                            4

Work Item 2                          $ 75                                            30 Days                           2.5

Work Item 3                          $600                                          3 days                               200

The order of completion would be work item 3, then 1 and then work item 2. The total CoD accrued would be $2,428.

Prioritization is difficult, and as a result there are any number of techniques to approach prioritization. WSJF allows you to prioritize units of work using the lean concept of cost of delay and duration/time to complete, giving you a consistent economic framework. Consistency and repeatability means that logic and fairness drive which work is done in what order. Without a framework it is often the squeaky wheel that gets the grease, and who knows what is squeaky will deliver the most value.

Are scaled frameworks process-focused, not people-focused.

Are scaled frameworks process-focused, not people-focused.

As noted in the Heavy Weight Championship of Agile, there has been a substantial amount of animated “discussion” about whether there is a need for scaled frameworks.  The three major players in the scaled framework arena, DSDM, DAD and SAFe all combine component Agile, lean, product flow and other techniques to address perceived needs in the overall software development community.  The primary issues are:

  1. Scaled frameworks are not “Agile.” This argument stems from the inclusion of techniques such as large scale release planning and hardening sprints (SAFe), an inception phase (DAD) and classic project management documentation (DSDM) to name a few techniques that draw attention. The argument is correct. These techniques are, strictly speaking, not Agile, however neither are the lean and product flow techniques that have become de rigor in many “Agile” implementations.  Our definition of what is Agile has evolved over time. The twelve principles in the Agile Manifesto provide a core set of values to use as a tool to evaluate whether any addition to our practice is Agile or not.
  2. The scaled frameworks are process-focused rather than people-focused.  One of the greatest successes of the Agile movement has been to refocus the software development process (including development, enhancement and maintenance) on people and communication without losing sight of the fact that software development is a process. This is generally interpreted that teams self-manage and self-organize to meet the demands for the work they are asked to perform.  All three of the major scaled frameworks embrace Scrum as their central team management tool.  What tends to be more explicitly delineated in the scaled frameworks is the role of the larger organization (management) to decide and plan for what will be done in terms of release planning.  I agree with the argument that large organizations are trading nimbleness for additional predictability (with the attendant risk). Processes and the predictability/coordination needs they address are driven because large organizations have so many more moving parts (for example marketing, sales, production, customer service, legal departments and that generally does not scratch the surface) that more free flowing communication is less effective.  This is one of the reasons why large organizations tend to be less nimble, but can tackle huge programs. 

The criticisms are valid, however overly specific to one type or culture of work.  In broader world ranging from small cutting edge firms to large, regulation-bound behemoths, there will be mechanisms needed to effectively deliver value.  We need to interpret those mechanisms through the eyes of the principles in Agile, lean and other methods to ensure we do not have runaway bloat.  What does not go away in any implementation scaled or not scaled is core premise of Agile that the people doing the work are the people who best figure how to approach and organize to get they need to accomplish done.  Teams are best positioned to react to the facts on the ground however they need to do so within the boundaries of business need and organizational culture.