tag:blogger.com,1999:blog-214369262024-03-14T18:49:05.126+00:00Improving projectsThe Improving Projects blog from Huge IO (UK & Ireland) is primarily about products, organisations and projects... and how to improve them. As well as musings on agile processes, software engineering in general, and methods like Kanban and Scrum, there's advice here too for users of process planning, execution and improvement tools - and the metrics they can provide. https://uk.huge.ioAndyhttp://www.blogger.com/profile/04231681582044414408noreply@blogger.comBlogger183125tag:blogger.com,1999:blog-21436926.post-78110160958146973662021-01-11T15:10:00.010+00:002021-01-12T10:57:24.336+00:00Breakout sessions that ensure everyone in the meeting meets everyone else<p>Lockdown finds us doing more and more in online meetings, whether it's business, training, parties or families. It also finds us spending inordinate amounts of time on trivail and time-consuming tasks of dubious value. This blog explores exactly such a problem!</p><p>I recently wanted to find a way to divide an online meeting into several breakout sessions, ensuring at the end of them, everyone would have met everyone else. But how many sessions of what size would I need, and how could I put the right people in the right group in each session?</p><p>After a brief internet search which didn't answer my question (I know someone's done this before, and probably written about how to do it, but I didn't find them!) I decided to work it out myself. Here's my attempt for groups of between 4 and 12 - minimising the number of breakout sessions, the number of people that meet people twice, and variation in group size.</p><p></p><div class="separator" style="clear: both; text-align: center;"><a href=" https://docs.google.com/spreadsheets/d/1SSp2FUeL3K9mbNu0hU6D8QhzVK73OKlBef_2sYW8rQU/edit?usp=sharing Number of people Group size (range) Nominal group size Number of sessions Session I Session II Session III Session IV Session IV 4 2 2 3 (1 2) (3 4) (1 3) (2 4) (1 4)( 3 2) 5 2-3 2 3 (1 2) (3 4 5) (1 3) (2 4 5) (1 4 5) ( 3 2) 6 2-3 3 4 (1 2 3) (4 5 6) (1 4) (2 5) (3 6) (1 5) (4 3) (2 6) (1 6) (4 2) (5 3) 7 2-4 3 4 (1 2 3) (4 5 6 7) (1 4 7) (2 5) (3 6) (1 5) (4 3) (7 2 6) (1 6) (4 2) (7 5 3) 8 2-3 3 4 (1 2 3) (4 5 6) (7 8) (1 4 7) (2 5 8) (3 6) (1 5) (4 8 3) (7 2 6) (1 8 6) (4 2) (7 5 3) 9 3 3 4 (1 2 3) (4 5 6) (7 8 9) (1 4 7) (2 5 8) (3 6 9) (1 5 9) (4 8 3) (7 2 6) (1 8 6) (4 2 9) (7 5 3) 10 3-4 3 4 (1 2 3) (4 5 6) (7 8 9 10) (1 4 7) (2 5 8) (3 6 9 10) (1 5 9 10) (4 8 3) (7 2 6) (1 8 6) (4 2 9 10) (7 5 3) 11 3-5 3 4 (1 2 3) (4 5 6 11) (7 8 9 10) (1 4 7) (2 5 8) (3 6 11 9 10) (1 5 9 10) (4 8 3) (7 2 6 11) (1 8 6 11) (4 2 9 10) (7 5 3) 12 4 2 5 (1 2 3 4) (5 6 7 8) (9 10 11 12 ) (1 2 5 6) (7 8 5 6) (1 2 9 10) (1 2 7 8) (5 6 11 12) (3 4 9 10) (1 2 9 10) (7 8 11 12) (3 4 9 10) (1 2 11 12) (9 10 7 8) (5 6 3 4) Number of people Group size (range) Nominal group size Number of sessions Session I Session II Session III Session IV Session IV 4 2 2 3 (1 2) (3 4) (1 3) (2 4) (1 4)( 3 2) 5 2-3 2 3 (1 2) (3 4 5) (1 3) (2 4 5) (1 4 5) ( 3 2) 6 2-3 3 4 (1 2 3) (4 5 6) (1 4) (2 5) (3 6) (1 5) (4 3) (2 6) (1 6) (4 2) (5 3) 7 2-4 3 4 (1 2 3) (4 5 6 7) (1 4 7) (2 5) (3 6) (1 5) (4 3) (7 2 6) (1 6) (4 2) (7 5 3) 8 2-3 3 4 (1 2 3) (4 5 6) (7 8) (1 4 7) (2 5 8) (3 6) (1 5) (4 8 3) (7 2 6) (1 8 6) (4 2) (7 5 3) 9 3 3 4 (1 2 3) (4 5 6) (7 8 9) (1 4 7) (2 5 8) (3 6 9) (1 5 9) (4 8 3) (7 2 6) (1 8 6) (4 2 9) (7 5 3) 10 3-4 3 4 (1 2 3) (4 5 6) (7 8 9 10) (1 4 7) (2 5 8) (3 6 9 10) (1 5 9 10) (4 8 3) (7 2 6) (1 8 6) (4 2 9 10) (7 5 3) 11 3-5 3 4 (1 2 3) (4 5 6 11) (7 8 9 10) (1 4 7) (2 5 8) (3 6 11 9 10) (1 5 9 10) (4 8 3) (7 2 6 11) (1 8 6 11) (4 2 9 10) (7 5 3) 12 4 2 5 (1 2 3 4) (5 6 7 8) (9 10 11 12 ) (1 2 5 6) (7 8 5 6) (1 2 9 10) (1 2 7 8) (5 6 11 12) (3 4 9 10) (1 2 9 10) (7 8 11 12) (3 4 9 10) (1 2 11 12) (9 10 7 8) (5 6 3 4) " style="margin-left: 1em; margin-right: 1em;"><img alt="" data-original-height="549" data-original-width="1827" height="192" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhpYDpVE9vGiIKj55-WArYnZl9j8SRNn4YVC0r1eBFvCD0kN18hxPLyWMvfwk5xAYUBssJzxNE1_Ifq6ou6wQ7Ucd-qLlaENg-WywN9Dh-ob3ied1bDc9gC38DCw5pk37l4sdzs/w640-h192/image.png" width="640" /></a></div><br />Let me know if you're keen to extend this to larger groups.<p></p><p><b>Some further thoughts on approaching this problem</b></p><p>Let's start simply. If I had 4 people, I could easily put them in 2 groups of 2 people. I'll number the people from 1 to 4, so here's my first session...</p><p>Session A: (1,2) (3,4) ... start at 1 and add 1 each time</p><p>Everyone's now met one person. Since they meet 1 person in each session, and there are 3 other people to meet, I need 2 more sessions:</p><p>Session B: (1,3) (2,4) ... start at 1 and then 2, adding 2 <br />Session C: (1,4) (3,2) ... start at 1 and add 3 (mod 4) each time</p><p>It turns out I can do this with any even number of people, put into n groups of 2 people*. After the correct (2n - 1) sessions, they all have met everyone. Here's a solution for 8 people for example, with 7 sessions, each with 4 groups of 2):</p><p>Session A: (1,2) (3,4) (5,6) (7,8) ... start at 1 and add 1 each time<br />Session B: (1,3) (5,7) (2,4) (6.8) ... start at 1 and then 2, adding 2 each time<br />Session C: (1,4) (7.2) (5,8) (3,6) ... start at 1 and add 3 (mod 8) each time <br />Session D: (1,5) (2,6) (3,7) (4,8) ... start at 1,2,3, and 4, adding 4 each time<br />Session E: (1,6) (3,8) (5,2) (7,4) ... start at 1 and add 5 each time<br />Session F: (1,7) (5,3) (2,8) (6,4) ... start at 1 and then 2, adding 6 each time<br />Session G: (1,8) (7,6) (5,4) (3,2) ... start at 1 and add 7 each time</p><p>These get more laborious to work out with larger numbers, but anyway there are too many sessions when there are a lot of people; better to have larger groups with fewer sessions. </p><p>For groups of 3, you need at least 9 people**. 9 people can meet everyone else in 4 sessions with groups of 3 (there are 8 others to meet, and you meet 2 in each session).</p><p>Session A: (1,2,3) (4.5.6) (7,8,9) ... start at 1 and add 1 each time<br />Session B: (1,4,7) (5,8,2) (9,6,3) ... start at 1,5 and 3, adding 3 (mod 9) each time <br />Session C: (1,5,9) (4,8,3) (7,2,6) ... start at 1 and add 4 each time<br />Session D: (1,8,6) (4,2,9) (7,5,3) ... start at 1 and add 7 each time (adding 5 clashes wih group A, adding 6 clashes wih group B)</p><p>The next feasible number with groups of 3 (where nobody meets the same person twice) is 15. That's 5 groups of 3 for 7 sessions.</p><p>The next square number, 16, divided into 4 groups of 4 can be designed so everyone meets everyone else in 5 sessions. These two problems are left as an exercise for the reader! </p><p>(Send me your workings when complete. :-)</p><p><br /></p><p><b>Notes:</b></p><p>* You can design groups of size n where people meet once and only once provided the number of people N is divisible by n, and (N-1) is divisible by (n-1). That is all even numbers for groups of 2, all odd multiples of 3 for groups of 3, etc. (Note: If n is the number in the groups, we need the number of people, N, to be divisible by n so there's an equal number in each group, but in addition we need (N-1) to be divisible by (n-1) so we have a whole number of sessions.</p><p>** It turns out <i>n </i>squared is the minimum meeting size with <i>n</i> people in each breakout group, in order to meet everybody once and only once.</p>Andyhttp://www.blogger.com/profile/04231681582044414408noreply@blogger.com0tag:blogger.com,1999:blog-21436926.post-67285736847197326792019-01-03T10:48:00.001+00:002019-01-03T10:54:03.127+00:00Why do organisations fail to achieve business agility?Recently I was asked to participate in an <a href="http://innoroo.com/blog/2018/12/25/interview-with-andy-carmichael/">Interview Series</a> by Noopur Pathak of Innovation Roots, an Agile consultancy based in Bengaluru and several other cities. One of the questions she asked me was why organisations fail to achieve business agility.<br />
Here's an excerpt from my reply.<br />
<h4>
<b> Do you <i>want </i>to be agile?</b></h4>
There are many more reasons organisation fail to become agile than there are to succeed, but the first question to ask organisations is what they want to achieve. Is business agility one of those things? Because if you are in a very stable situation and you have very stable business, agility isn’t necessarily on the priority list of what must be achieved.<br />
<br />
On the other hand, nearly all organisations – including those in industries we consider most stable, where nothing seems to have changed in decades – face the disruption of new ways of doing business, and innovators entering into their markets. It means everybody must think about the need to change… the need to change fast. Remember: “It’s not the big fish that eat the small ones, it’s the fast that eat the slow!” If your organisation is slow, there is a good chance that your competitors or new entrants into the market will disrupt it and take market share.<br />
<br />
So the first question is, “Is agility an aim for the organisation?” If it isn’t, you won’t achieve it. If you realise that you do need to become agile, there are still many reasons why you may fail.<br />
<h4>
A failure to plan</h4>
For example, you need to plan to become more agile (more able to respond rapidly to changing market conditions), and you need to invest in those plans. If you want to encourage innovation, you need to communicate that goal to staff and show how you will reward it. Traditional command and control approaches to managing business, and fixed long-term goals, won’t work, particularly if disruptors are already entering your market and introducing new ways of working more successfully than you are. You have to think about the way the organisation can empowers its staff, and allow them to think differently, to try new things in a safe-to-fail manner. That allows the organisation to discover different ways of working. Agility comes from the chosen strategy of an organisation, and from its leaders’ ability to communicate and encourage staff to implement that strategy.<br />
<h4>
It's not just IT</h4>
When people say the word “Agile”, they are often only thinking about it in the context of software development. That software is important to business agility is not in question. Software has “eaten the world,” it is the driver for business transformation, it is the foundation of digital solutions. The way you create software, and the way you plan, manage and finance software development is crucial if you want to achieve business agility. However, I encourage leadership teams to consider first why they want to achieve business agility, and what it involves in terms of the changes needed in their organisation. Then they can start planning, not only how it will change software development, but also every other area of the business. Each area, just like the software teams, must invest in new ways of doing business, must try multiple things to see what works; must act before knowing if it will work, learning from failures and exploiting successes. Rather than waiting for the fully developed ideas – the big up-front plans with every component costed and all outcomes forecast, the big implementation and the big-bang delivery – smaller steps and more learning on the journey is essential.<br />
<br />
These are strategies for moving faster than your competitors and ensuring survival in rapidly moving markets. That’s why business agility is important. It answers the existential question of how we survive in this rapidly changing world, where organisations can quickly discover they are no longer fit for the new competitive landscape.<br />
<br />
Back to some of the reasons for failure to achieve business agility:<br />
<ul>
<li>Not wanting it</li>
<li>Wanting, but not planning for it</li>
<li>Planning, but not investing in it</li>
<li>Not seeing through the changes</li>
<li>Not dealing with the negative consequences of innovation in the organisation – not ensuring there is safety in both failed experiments, and successful ones that disrupt existing parts of the business. </li>
</ul>
<h4>
There is no formula</h4>
One other thing. People think there is some magic method or strategy or formula that makes organisations agile. There are principles to learn, but there is no formula. Applying those principles in the unique context of your business, your market and your people – and helping your people to innovate – is where business agility comes from.<br />
<br />
You can read more of this interview at: <a href="http://innoroo.com/blog/2018/12/25/interview-with-andy-carmichael/">innoroo.com/blog/</a>Andyhttp://www.blogger.com/profile/04231681582044414408noreply@blogger.com0tag:blogger.com,1999:blog-21436926.post-67121793807711634732018-06-27T15:48:00.000+01:002018-06-27T15:51:28.963+01:00Webinar July 6th - Essential Kanban: It's all about FLOW!<ul class="event-meta list-inline" style="background-color: white; box-sizing: border-box; font-family: myriad-pro, myriad-pro, myriad, sans-serif; list-style: none; margin: 0px 0px 2rem; padding-left: 0px; text-align: center;">
<li style="box-sizing: border-box; color: #333333; display: inline-block; font-size: 16px; margin-top: 1rem; padding: 0px 10px 0px 0px; text-align: center;"><a href="https://ti.to/hugeio/essential-kanban-webinar-01.ics" style="background-color: transparent; box-sizing: border-box; color: #639dcc; text-decoration-line: none;"><span class="fa fa-calendar" style="box-sizing: border-box; display: inline-block; font-family: "fontawesome"; font-size: inherit; font-stretch: normal; line-height: 1; padding-right: 3px;"></span> </a><span style="color: #639dcc;"><span style="box-sizing: border-box;"><a href="https://ti.to/hugeio/essential-kanban-webinar-01">July 12th, 2018 Online Webinar. London: 1400; New York: 0900; Bangalore: 1830</a></span></span></li>
</ul>
<div class="event-description markdown" style="background-color: white; box-sizing: border-box; color: #333333; font-family: myriad-pro, myriad-pro, myriad, sans-serif; font-size: 18px; line-height: 34px; text-align: center;">
<div style="box-sizing: border-box; line-height: 30px; margin-bottom: 10px;">
<span style="text-align: left;">Customers are always saying "Why is not done yet?" and staff are always saying "We're too busy." But what's the </span><em style="box-sizing: border-box; text-align: left;">real</em><span style="text-align: left;"> problem? Kanban has the key! </span></div>
<h2 style="box-sizing: border-box; line-height: 30px; margin-bottom: 10px;">
<a href="https://ti.to/hugeio/essential-kanban-webinar-01">Sign up Now!</a></h2>
<div style="box-sizing: border-box; line-height: 30px; margin-bottom: 10px; text-align: left;">
Kanban is a way to visualise and manage your team's (and your organisation's) work, and the first crucial insight it brings is that it's the flow of work, not the busy-ness of staff, or the efficiency of each worker, that bring value to your customers and profitability to the business. This half-hour webinar introduces you to the foundational concept of Kanban - FLOW - and it will set you on the road to find out more.</div>
<div style="box-sizing: border-box; line-height: 30px; margin-bottom: 10px;">
<b>Don't miss it!</b></div>
<div style="box-sizing: border-box; line-height: 30px; margin-bottom: 10px;">
<em style="box-sizing: border-box;">Webinar duration: 30 minutes, plus questions and discussion</em></div>
<div style="box-sizing: border-box; line-height: 30px; margin-bottom: 10px; text-align: justify;">
<em style="box-sizing: border-box;"><span style="font-size: 16px; font-style: normal; text-align: start;">This webinar is a great introduction to Kanban for those new to it, but also a great resource for those familiar with the method, and looking for a straightforward and short description of one of its key ideas. Why not invite your colleagues too, perhaps to kick off an informal discussion of how you can use these ideas at work?</span></em></div>
</div>
Andyhttp://www.blogger.com/profile/04231681582044414408noreply@blogger.com0tag:blogger.com,1999:blog-21436926.post-59743287214197962962018-02-28T12:04:00.001+00:002018-03-02T18:37:17.521+00:00Kanban: How to Start; How to Scale<b>How to start...</b><br />
<b><br /></b>
Several years ago I published my <i>shortest possible</i> advice on "<a href="http://xprocess.blogspot.co.uk/2013/05/how-to-adopt-kanban.html">How to start using Kanban</a>". Not being restricted by arbitrary limits like 140 characters, I would express these steps today as:<br />
<div>
<div>
<ol>
<li>See your work as a flow of value to your customer</li>
<li>Start from where you are</li>
<li>Visualize your work, your process and your policies</li>
<li>Adopt validated changes that improve things</li>
</ol>
</div>
</div>
<div>
Note that the first three of these steps do not involve changing what you are currently doing, how you are doing it, who is doing it, or what their role is called. The changes are: to your <i>viewpoint</i> (Kanban is a way of seeing, as much as it is a way of changing); to your <i>approach to change</i> (in an evolutionary way, from where you are); and to the use of <i>visualisation </i>(to make invisible knowledge work visible, as well as the process and policies - like controlling <a href="http://xprocess.blogspot.co.uk/search/label/Work%20in%20progress">WiP</a> - that apply to it).<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjcloLcSFj3ZB4vv330rlyrlrlj1s0gxiuUGnvPnjvkwYFNCAtg8YfmOKk6W5pOWgQFne0KzNpv2H_fde_ArSfKA4_bNYWFM56Ey8w6DQxCcJJx06m3UMI950J1JtKH5_qPI0Kx/s1600/Cartoons_13.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" data-original-height="618" data-original-width="605" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjcloLcSFj3ZB4vv330rlyrlrlj1s0gxiuUGnvPnjvkwYFNCAtg8YfmOKk6W5pOWgQFne0KzNpv2H_fde_ArSfKA4_bNYWFM56Ey8w6DQxCcJJx06m3UMI950J1JtKH5_qPI0Kx/s320/Cartoons_13.jpg" width="312" /></a></div>
The fourth step though, is to start improving things. It's good to see that previous critics of Kanban are recognising the value of these lessons, even where some of a process's previously inviolable "rules" might be breached. Provided we have a clear idea of what makes a product, a process, or an organisation fit for purpose, and provided the changes proposed can be shown to improve things, it's foolish not to change.</div>
<div>
<br /></div>
<div>
Kanban is often caricatured as only being applicable to small teams (say 3-12 people), or to processes with only small work items. In fact, this process of visualising the work and process, and improving the flow of value using Kanban's <a href="http://xprocess.blogspot.co.uk/2013/04/there-are-6-core-practices-of-kanban.html">general practices</a>, is applicable across a wide range of scales, contexts, and organisational maturity.</div>
<div>
<br />
So if you're starting from a few teams using Kanban at the team level (a reasonable place to start by the way), how do you scale to using Kanban across an organisation?</div>
<div>
<br /></div>
<div>
<b>How to scale...</b><br />
<b><br /></b>
We can express the answer to that question with 4 quite similar steps:<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
</div>
<div>
<div>
<ol>
<li>See your organisation as a network of inter-dependent services</li>
<li>Scale out sequentially, service by service</li>
<li>Design each service independently from first principles</li>
<li>Use feedback loops through the management system to achieve balance and improve service delivery to customers</li>
</ol>
</div>
</div>
<div>
Like the first "how-to", this one starts with changing how you see. I've spoken more about this in my sessions on the <a href="http://xprocess.blogspot.co.uk/2018/02/the-kanban-lens-way-to-see.html">Kanban Lens</a>. The way we "see" - our instinctive way of modelling the world around us - has the greatest impact on our interpretation of new situations and ultimately our behaviour. Letting how you see change is a most powerful door into new possibilities.<br />
<br />
Specifically "seeing services" is not instinctive. We're more likely to look at organisations through a "departmental" lens (people with similar functions or roles in the the organisation), or through a "small team" lens (the groups of people that get things done together). What is often missing is how departments and teams fit together to deliver value to the organisation's "customers". Changing to that as your default viewpoint, brings quite different issues into focus. It has a powerful impact.<br />
<br />
Scaling out <i>service by service</i> again may not be management's instinctive approach. If we've found a better process, why not roll it out across the whole business together, in the shortest possible time? The answer to that question lies in Kanban's foundational principles, specifically the <a href="http://anderson.leankanban.com/kanbans-change-management-principles/">change management principles</a>. These can summarised as "start from what you do now... and change in an evolutionary manner, learning and applying the lessons learned as you go." In practice, that's what the most successful organisations have found as they roll out Kanban. It is not slower to move incrementally. You get there faster because you don't generate massive fear and resistance within the organisation, and most importantly you learn as you go, while it's still not too late to apply the lessons.<br />
<br />
If you want to know more about the third step - often referred to as STATIK (<b>s</b>ystems <b>t</b>hinking <b>a</b>pproach <b>t</b>o <b>i</b>ntroducing <b>K</b>anban), we discuss it (albeit briefly) in <i><a href="http://leankanban.com/guide">Essential Kanban Condensed</a>. </i>It's one of the main elements in the KMP 1 training syllabus - see this course from <a href="http://huge.io/">Huge.IO</a> for example, <a href="https://ti.to/hugeio/ksd-uka-2018-05">Kanban System Design</a>.<br />
<br />
Finally the fourth step - using the Kanban Cadences, is the subject of the next blog (as well as the follow-on training . Watch this space.<br />
<br />
<br />
<b style="background-color: white; color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13.2px;">References and Credits</b><br />
<div style="background-color: white; direction: ltr; line-height: 11.88px; margin-bottom: 0pt; margin-left: 0in; margin-top: 10pt; text-indent: 0in; unicode-bidi: embed; word-break: normal;">
<span style="color: #222222; font-family: "stag sans book"; font-size: 9pt; text-indent: 0in;">Anderson, David J. 2016. "</span><span style="background-color: transparent; font-size: 12px;"><span style="color: #222222; font-family: "stag sans book";">Kanban’s Change Management Principles", <i>Lean Kanban</i></span></span><span style="color: #222222; font-family: "stag sans book"; font-size: 9pt; text-indent: 0in;">. </span><span style="background-color: transparent; font-size: 12px;"><span style="color: #888888; font-family: "stag sans book";">http://anderson.leankanban.com/kanbans-change-management-principles/</span></span></div>
<div style="background-color: white; color: #222222; direction: ltr; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13.2px; line-height: 11.88px; margin-bottom: 0pt; margin-left: 0in; margin-top: 10pt; text-indent: 0in; unicode-bidi: embed; word-break: normal;">
<span style="font-family: "stag sans book"; font-size: 9pt; text-indent: 0in;">Anderson, David J., and Andy Carmichael. 2016. </span><span style="font-family: "stag sans book"; font-size: 9pt; font-style: italic; text-indent: 0in;">Essential Kanban Condensed</span><span style="font-family: "stag sans book"; font-size: 9pt; text-indent: 0in;">. Lean Kanban University Press. </span><span style="font-family: "stag sans book"; font-size: 9pt; text-indent: 0in;"><a href="http://leankanban.com/guide" style="color: #888888; text-decoration-line: none;">http://leankanban.com/guide</a></span></div>
<div style="background-color: white; color: #222222; direction: ltr; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13.2px; line-height: 11.88px; margin-bottom: 0pt; margin-left: 0in; margin-top: 10pt; text-indent: 0in; unicode-bidi: embed; word-break: normal;">
<span style="font-family: "stag sans book"; font-size: 9pt; text-indent: 0in;">Carmichael, Andy. 2013. “How to Adopt Kanban”, </span><span style="font-family: "stag sans book"; font-size: 9pt; font-style: italic; text-indent: 0in;">Improving Projects.</span><span style="font-family: "stag sans book"; font-size: 9pt; font-style: italic; text-indent: 0in;"><a href="http://xprocess.blogspot.co.uk/2013/05/how-to-adopt-kanban.html" style="color: #888888; text-decoration-line: none;">http://xprocess.blogspot.co.uk/ 2013/05/how-to-adopt-kanban.html</a></span></div>
<div style="background-color: white; color: #222222; direction: ltr; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13.2px; line-height: 11.88px; margin-bottom: 0pt; margin-left: 0in; margin-top: 10pt; text-indent: 0in; unicode-bidi: embed; word-break: normal;">
<span style="font-family: "stag sans book"; font-size: 9pt;"></span></div>
<div style="background-color: white; direction: ltr; line-height: 11.88px; margin-bottom: 0pt; margin-left: 0in; margin-top: 10pt; text-indent: 0in; unicode-bidi: embed; word-break: normal;">
<span style="color: #222222; font-family: "stag sans book"; font-size: 9pt; text-indent: 0in;">Carmichael, Andy. 2013. “There are 6 general practices of Kanban...”, </span><span style="color: #222222; font-family: "stag sans book"; font-size: 9pt; font-style: italic; text-indent: 0in;">Improving Projects. </span><span style="background-color: transparent; font-size: 12px;"><span style="color: #888888; font-family: "stag sans book";"><i>http://xprocess.blogspot.co.uk/2013/04/there-are-6-core-practices-of-kanban.html</i></span></span></div>
<div style="background-color: white; color: #222222; direction: ltr; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13.2px; line-height: 11.88px; margin-bottom: 0pt; margin-left: 0in; margin-top: 10pt; text-indent: 0in; unicode-bidi: embed; word-break: normal;">
<span style="font-family: "stag sans book"; font-size: 9pt; text-indent: 0in;">“Kanban (development)”. </span><span style="font-family: "stag sans book"; font-size: 9pt; font-style: italic; text-indent: 0in;">Wikipedia</span><span style="font-family: "stag sans book"; font-size: 9pt; text-indent: 0in;">. Retrieved July 7, 2017,</span><span style="font-family: "stag sans book"; font-size: 9pt; text-indent: 0in;"><a href="https://en.wikipedia.org/wiki/Kanban_(development)" style="color: #888888; text-decoration-line: none;">https://en.wikipedia.org/wiki/Kanban_(development)</a></span></div>
<div style="background-color: white; color: #222222; direction: ltr; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13.2px; line-height: 11.88px; margin-bottom: 0pt; margin-left: 0in; margin-top: 10pt; text-indent: 0in; unicode-bidi: embed; word-break: normal;">
<span style="font-family: "stag sans book"; font-size: 9pt;"></span></div>
<div style="background-color: white; color: #222222; direction: ltr; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13.2px; line-height: 11.88px; margin-bottom: 0pt; margin-left: 0in; margin-top: 10pt; text-indent: 0in; unicode-bidi: embed; word-break: normal;">
<br /></div>
</div>
<div style="background-color: white; color: #222222; direction: ltr; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13.2px; line-height: 11.88px; margin-bottom: 0pt; margin-left: 0in; margin-top: 10pt; text-indent: 0in; unicode-bidi: embed; word-break: normal;">
<br /></div>
Andyhttp://www.blogger.com/profile/04231681582044414408noreply@blogger.com0tag:blogger.com,1999:blog-21436926.post-62663232396914844462018-02-26T10:25:00.001+00:002018-02-26T15:46:47.150+00:00The Kanban Lens: a way to seeThe Kanban Lens is a way to see your work. Specifically it asks us to see:<br />
<ul>
<li>work as flow </li>
<li>workflow as knowledge discovery steps</li>
<li>knowledge work as a service</li>
<li>organizations as networks of services</li>
</ul>
I got involved with the Kanban community not very long ago - in 2012. I wanted to understand what the Kanban method was. People were saying “it’s better than this” or “worse than that”. But they weren't telling me what it was! The only detailed explanations came from critics or tool vendors, and to be frank neither of those sources were particularly reliable. I knew about the general practices of Kanban and its principles for change management. I even understood kanban systems, which are used in Kanban, just as they are in manufacturing and delivery systems, to ensure we only start work when our customers actually want it, and we have the capacity finish it.<br />
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; margin-left: 1em; text-align: right;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjyPh_eL8FBjA5wb29rFiQb7wDJWMmJGLhm-NrKH12fQeKLT3JXtulkUrlZr2yorbFI2izjxPKEa5aDio3jzyp46jORHlPviWbD79fxnhOTYIoPUU8TC_sy8zvRzhyphenhyphenpYtjJKC44/s1600/Capture.JPG" imageanchor="1" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" data-original-height="885" data-original-width="1600" height="176" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjyPh_eL8FBjA5wb29rFiQb7wDJWMmJGLhm-NrKH12fQeKLT3JXtulkUrlZr2yorbFI2izjxPKEa5aDio3jzyp46jORHlPviWbD79fxnhOTYIoPUU8TC_sy8zvRzhyphenhyphenpYtjJKC44/s320/Capture.JPG" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;"><a href="https://vimeo.com/244002864#t=15:05"><span style="font-size: x-small;">Video of the "Kanban Lens" lightning talk (7 minutes)</span></a></td></tr>
</tbody></table>
<br />
But that still didn’t explain what the Kanban method was.<br />
<br />
A few years ago Rodrigo Yoshima used an eye-opening phrase in a talk he did at Lean Kanban North America: the “Lean flow paradigm”. It helped me understand that Kanban is not a process, or a recipe, or a framework. It’s how to <i>see</i> work. This is what brings together the many and various parts that make up the Kanban method. In 2013, David Anderson blogged about this, coining the phrase “the Kanban Lens” and recently I’ve been talking to David again about its definition, looking for a simple form of words that captures the Kanban “way of seeing”.<br />
<br />
There are four elements to the Kanban Lens.<br />
<br />
<b>1. See work as flow</b><br />
<br />
Firstly… “See work as flow.” Or more explicitly: See work as a flow “from customer need, to needs met.” This is the starting point for using Kanban. Before you change the organisation, or the process, or the roles and responsibilities, or anyone’s job title, change how you view your work. Seeing work as flow may seem obvious. Except that this is completely against most managers' and most professionals' instincts. It's not how work is traditionally managed. When you look at what people actually do, it's clear; most of us are more concerned about people who are not busy, than work items that are not flowing!<br />
<br />
Change your viewpoint. Don’t view your work as being busy at your skill, or your role. Work has value because, we fulfil customers’ needs. By visualising work and ensuring it's made up of small, distinct items, the flow of work becomes visible. Ensuring each work item is coherent and valued by the customer, means genuine value can be delivered to the customer as each item is delivered.<br />
<br />
That’s how work flows. Workflows... that's the second element of the lens...<br />
<br />
<b>2. See workflow as a sequence of knowledge discovery steps</b><br />
<br />
Workflow as a sequence of knowledge discovery steps is something that often puzzles people. It cuts across how we've traditionally looked at workflow - as hand-offs between individuals or teams. However the columns on a kanban board should not be viewed as representing the teams of people that handle the work. Look through a different lens. The workflow shows the progress of the work item, through different<i> learning activities</i>, until we know enough about each item, to convert the ideas and options into delivered value.<br />
<br />
“Really? How can we expect a linear monotonic process to represent such complex activities?”<br />
<br />
The answer is that we don’t, and it doesn’t. The steps in a Kanban process are states of the item. In each state there’s a dominant means of learning (of knowledge discovery), using people and skills as needed. This is how to build effective, improvable services.<br />
<br />
<b>3. See knowledge work as a service</b><br />
<br />
The third element of the Kanban lens is to “See knowledge work as a service.”<br />
<br />
Again this raises eyebrows. “Isn’t it obvious that knowledge work is a service? Accountants and tax men call it a service. The product is intangible. There is no manufacturing involved.” But that’s not the source of the controversy. Our instinct is to manage what’s visible – the people; rather than what’s invisible – the work being produced. The Kanban Lens asks us to focus on the work, not the workers, and to see that work as a service.<br />
<br />
A service implies the existence of a customer, needing, and ultimately benefiting from, the work.<br />
It implies care on the part of the service provider…<br />
<ul>
<li>to know what makes the service fit for the customer’s purpose, and </li>
<li>to what degree, and when, it can be delivered.</li>
</ul>
Sometimes a service delivers to an internal customer. That’s okay, indeed it’s inevitable in larger contexts. But don’t lose sight of the real customer, nor those that deliver direct to that customer. Our work enables them to fulfil customer needs.<br />
<br />
<b>4, See your organisation as a network of services</b><br />
<br />
Multiple inter-dependent services require organising, and that's where the fourth element of the lens comes in. “See your organisation as a network of services.”<br />
<br />
Network here is a general term. Typically we see<br />
<ul>
<li>chains of services </li>
<li>hierarchies of services, and</li>
<li>inter-connected services </li>
</ul>
We can even see multiple services on a single board, as this one from Wikipedia, which has chains of services… (sequences), hierarchies of services… (decomposed work, with the lower level items handled by different services), and inter-connected services… (where blockers on work items on this board are work in someone else’s service).<br />
<img alt="Sample Kanban Board.png" height="360" src="https://upload.wikimedia.org/wikipedia/commons/c/c2/Sample_Kanban_Board.png" width="640" /><br />
<div style="text-align: center;">
<span style="font-size: xx-small;">[CC BY-SA 4.0 (https://creativecommons.org/licenses/by-sa/4.0)], via Wikimedia Commons]</span></div>
<br />
These networks must be balanced by adjusting the policies and resources to ensure flow and timely delivery. Management cadences for improvement are therefore vital, particularly an Operations Review, which interacts with multiple services.<br />
<br />
Scaling Kanban depends on this first step of seeing the organisation differently… as a network of services. The "org. chart" is no help for this. But when people see the services, and their customers, they can<br />
<ul>
<li>self-organise to the work</li>
<li>cut the waste of siloed thinking and redundant activities, and</li>
<li>generate improvements from within… across the organisation.</li>
</ul>
This is what “Whole Organisation Kanban” means. It’s all a part of looking at work differently, using the Kanban Lens to...<br />
<ol>
<li>See work as flow (from customer need, to needs met), </li>
<li>See workflow as a sequence of knowledge discovery steps</li>
<li>See knowledge work as a service</li>
<li>See your organisation as a network of services</li>
</ol>
That’s the Kanban Lens!<br />
<br />
<b><br /></b>
<b>References and Credits</b><br />
<div style="direction: ltr; line-height: 90%; margin-bottom: 0pt; margin-left: 0in; margin-top: 10pt; text-indent: 0in; unicode-bidi: embed; word-break: normal;">
<span style="font-family: "stag sans book"; font-size: 9pt;">Anderson, David J. 2011 “Understanding
the Process of Knowledge Discovery”. DJAA blog</span><span style="font-family: "stag sans book"; font-size: 9pt; font-weight: bold;">: </span><span style="font-family: "stag sans book"; font-size: 9pt;"><a href="http://www.djaa.com/understanding-process-knowledge-discovery">http://www.djaa.
com/understanding-process-knowledge-discovery</a></span><span style="font-family: "stag sans book"; font-size: 9pt;"> </span></div>
<div style="direction: ltr; line-height: 90%; margin-bottom: 0pt; margin-left: 0in; margin-top: 10pt; text-indent: 0in; unicode-bidi: embed; word-break: normal;">
<span style="font-family: "stag sans book"; font-size: 9pt;">Anderson, David J. 2013 “The Kanban
Lens”. DJAA blog</span><span style="font-family: "stag sans book"; font-size: 9pt; font-weight: bold;">:
</span><span style="font-family: "stag sans book"; font-size: 9pt;"><a href="http://www.djaa.com/kanban-lens">http://www.djaa.com/kanban-lens</a></span><span style="font-family: "stag sans book"; font-size: 9pt;"> </span></div>
<div style="direction: ltr; line-height: 90%; margin-bottom: 0pt; margin-left: 0in; margin-top: 10pt; text-indent: 0in; unicode-bidi: embed; word-break: normal;">
<span style="font-family: "stag sans book"; font-size: 9pt;">Anderson, David J., and Andy Carmichael.
2016. </span><span style="font-family: "stag sans book"; font-size: 9pt; font-style: italic;">Essential
Kanban Condensed</span><span style="font-family: "stag sans book"; font-size: 9pt;">.
Lean Kanban University Press. </span><span style="font-family: "stag sans book"; font-size: 9pt;"><a href="http://leankanban.com/guide">http://leankanban.com/guide</a></span><span style="font-family: "stag sans book"; font-size: 9pt;"> </span></div>
<div style="direction: ltr; line-height: 90%; margin-bottom: 0pt; margin-left: 0in; margin-top: 10pt; text-indent: 0in; unicode-bidi: embed; word-break: normal;">
<span style="font-family: "stag sans book"; font-size: 9pt; text-indent: 0in;">Carmichael, Andy. 2013. “How to Adopt
Kanban”, </span><span style="font-family: "stag sans book"; font-size: 9pt; font-style: italic; text-indent: 0in;">Improving
Projects. </span><span style="font-family: "stag sans book"; font-size: 9pt; font-style: italic; text-indent: 0in;"><a href="http://xprocess.blogspot.co.uk/2013/05/how-to-adopt-kanban.html">http://xprocess.blogspot.co.uk/
2013/05/how-to-adopt-kanban.html</a></span></div>
<div style="direction: ltr; line-height: 90%; margin-bottom: 0pt; margin-left: 0in; margin-top: 10pt; text-indent: 0in; unicode-bidi: embed; word-break: normal;">
<span style="font-family: "stag sans book"; font-size: 9pt;">Carmichael, Andy. 2017. "Sample
Kanban Board“, CC BY-SA 4.0 via </span><span style="font-family: "stag sans book"; font-size: 9pt; font-style: italic;">Wikimedia Commons. </span><span style="font-family: "stag sans book"; font-size: 9pt;"><a href="https://commons.wikimedia.org/wiki/File:Sample_Kanban_Board.png">https://commons.wikimedia.org/
wiki/File%3ASample_Kanban_Board.png</a></span><span style="font-family: "stag sans book"; font-size: 9pt;"> </span></div>
<div style="direction: ltr; line-height: 90%; margin-bottom: 0pt; margin-left: 0in; margin-top: 10pt; text-indent: 0in; unicode-bidi: embed; word-break: normal;">
<span style="font-family: "stag sans book"; font-size: 9pt;">Ebbesen</span><span style="font-family: "stag sans book"; font-size: 9pt;">, Bill. “Lenses” Photo. Transferred from </span><span style="font-family: "stag sans book"; font-size: 9pt;">en.wikipedia</span><span style="font-family: "stag sans book"; font-size: 9pt;">, CC BY 3.0, </span><span style="font-family: "stag sans book"; font-size: 9pt;"><a href="https://commons.wikimedia.org/w/index.php?curid=11430342">https://commons.wikimedia.org/
w/</a></span><span style="font-family: "stag sans book"; font-size: 9pt;"><a href="https://commons.wikimedia.org/w/index.php?curid=11430342">index.php?curid</a></span><span style="font-family: "stag sans book"; font-size: 9pt;"><a href="https://commons.wikimedia.org/w/index.php?curid=11430342">=11430342</a></span><span style="font-family: "stag sans book"; font-size: 9pt;"> </span></div>
<div style="direction: ltr; line-height: 90%; margin-bottom: 0pt; margin-left: 0in; margin-top: 10pt; text-indent: 0in; unicode-bidi: embed; word-break: normal;">
<span style="font-family: "stag sans book"; font-size: 9pt;">“Kanban (development)”. </span><span style="font-family: "stag sans book"; font-size: 9pt; font-style: italic;">Wikipedia</span><span style="font-family: "stag sans book"; font-size: 9pt;">. Retrieved July 7, 2017, </span><span style="font-family: "stag sans book"; font-size: 9pt;"><a href="https://en.wikipedia.org/wiki/Kanban_(development)">https://en.wikipedia.org/wiki/Kanban_(develop
</a></span><span style="font-family: "stag sans book"; font-size: 9pt;"><a href="https://en.wikipedia.org/wiki/Kanban_(development)">ment</a></span><span style="font-family: "stag sans book"; font-size: 9pt;"><a href="https://en.wikipedia.org/wiki/Kanban_(development)">)</a></span><span style="font-family: "stag sans book"; font-size: 9pt;"> </span></div>
<div style="direction: ltr; line-height: 90%; margin-bottom: 0pt; margin-left: 0in; margin-top: 10pt; text-indent: 0in; unicode-bidi: embed; word-break: normal;">
<span style="font-family: "stag sans book"; font-size: 9pt;">Kennedy, Michael. 2012. “Set-Based
Decision Making”, </span><span style="font-family: "stag sans book"; font-size: 9pt; font-style: italic;">Lean
Software and Systems Conference</span><span style="font-family: "stag sans book"; font-size: 9pt;">,
Boston, MA. Video: </span><span style="font-family: "stag sans book"; font-size: 9pt;"><a href="https://vimeo.com/42785298">https://vimeo.com/42785298</a></span><span style="font-family: "stag sans book"; font-size: 9pt;"> </span></div>
<div style="direction: ltr; line-height: 90%; margin-bottom: 0pt; margin-left: 0in; margin-top: 10pt; text-indent: 0in; unicode-bidi: embed; word-break: normal;">
<span style="font-family: "stag sans book"; font-size: 9pt;">USDA, “Large format camera”
Photo. </span><span style="font-family: "stag sans book"; font-size: 9pt; font-style: italic;">PD-</span><span style="font-family: "stag sans book"; font-size: 9pt; font-style: italic;">USGov</span><span style="font-family: "stag sans book"; font-size: 9pt; font-style: italic;">-USDA-ARS. </span><span style="font-family: "stag sans book"; font-size: 9pt;"><a href="https://commons.wikimedia.org/wiki/File:Large_format_camera_lens.jpg">https://commons.wikimedia.org/wiki/File%3A
Large_format_camera_lens.jpg</a></span><br />
<span style="color: black; font-family: "stag sans book"; font-size: 9pt; text-indent: 0in;"><br /></span><span style="color: black; font-family: "stag sans book"; font-size: 9pt; text-indent: 0in;">Yoshima, </span><span style="font-family: "stag sans book"; font-size: 12px; text-indent: 0in;">Rodrigo. 2013. "Management and Change - Avoiding the Rocks," <i>Lean Kanban North America, </i></span><span style="text-indent: 0in;"><span style="font-family: "stag sans book";"><span style="font-size: 12px;"><a href="https://www.slideshare.net/rodrigoy/management-and-change-avoidin">https://www.slideshare.net/rodrigoy/management-and-change-avoidin</a>.</span></span></span><br />
<span style="color: black; font-family: "stag sans book"; font-size: 9pt; text-indent: 0in;"><br /></span>
<span style="color: black; font-family: "stag sans book"; font-size: 9pt; text-indent: 0in;">Zheglov</span><span style="color: black; font-family: "stag sans book"; font-size: 9pt; text-indent: 0in;">, Alexei. 2014. “Beyond VSM:
Understanding and mapping your process of knowledge discovery”, </span><span style="color: black; font-family: "stag sans book"; font-size: 9pt; font-style: italic; text-indent: 0in;">Lean Kanban Central Europe. </span><span style="color: black; font-family: "stag sans book"; font-size: 9pt; text-indent: 0in;">Slides</span><span style="color: black; font-family: "stag sans book"; font-size: 9pt; font-style: italic; text-indent: 0in;">: </span><span style="color: black; font-family: "stag sans book"; font-size: 9pt; text-indent: 0in;"><a href="https://goo.gl/ay6P7U">https://goo.gl/ay6P7U</a></span><span style="color: black; font-family: "stag sans book"; font-size: 9pt; text-indent: 0in;">, Video:</span><span style="color: black; font-family: "stag sans book"; font-size: 9pt; font-style: italic; text-indent: 0in;"> </span><span style="color: black; font-family: "stag sans book"; font-size: 9pt; text-indent: 0in;"><a href="https://vimeo.com/114542264">https://vimeo.com/
114542264</a></span><span style="color: black; font-family: "stag sans book"; font-size: 9pt; text-indent: 0in;"><span style="mso-spacerun: yes;"> </span></span></div>
Andyhttp://www.blogger.com/profile/04231681582044414408noreply@blogger.com0tag:blogger.com,1999:blog-21436926.post-52813660978879368052017-05-12T11:26:00.001+01:002018-07-30T09:32:00.642+01:00Time is an Asset - Delay is a CostCost of Delay is a vital concept for management teams to understand and use. It enables better decision-making concerning investments and cost-saving, and is the basis of a coherent economic framework for considering the trade-offs management are responsible for, when deciding for example, whether to focus on reducing cost, or on investments that might reduce costs or increase value in the future.<br />
<br />
After over a year of blogging and conference presentations on the topic - much of which has focused on the technical rather than practical explanations - I want to draw these to a close here with some straightforward summaries for managers of agile teams. While I think most managers will benefit from looking more deeply at <i>why</i> this advice applies (and its limits based on the assumptions underlying it), I'm also clear that a summary of what to do is the most helpful.<br />
<br />
My thinking has evolved over the year, since the preparation and publication of the Kanban guide to Kanban - <i>Essential Kanban Condensed </i>(<a href="http://leankanban.com/guide">downloadable here</a>). I started this series of blogs in April 2016 to provide more details on the subject than was possible to include in the condensed guide, and since that time I've had the good fortune to discuss Cost of Delay in some depth with some key thinkers on the subject. For this I'm particularly grateful to Don Reinertsen [1,8], David Anderson, Joshua Arnold [4,7], Chris Matts and Dave Snowden [9], who have taken the time at various points this year to teach, cajole, contradict or endorse various things that I was saying. While it is certainly not possible to reconcile all the thoughts and published works of the authors who have used and modified Don Reinertsen's original work on the subject - it is now at least possible to summarise my own (interim) conclusions!<br />
<div>
<br /></div>
Firstly here is the list and links to each of the previous articles:<br />
<br />
<span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.2px; line-height: 18.48px;">Part 1: </span><i style="background-color: white; color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13.2px; line-height: 18.48px;"><a href="http://xprocess.blogspot.co.uk/2016/04/understanding-cost-of-delay-and-its-use.html" style="color: #888888; text-decoration: none;">Understanding Cost of Delay and its Use in Kanban</a></i><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.2px; line-height: 18.48px;"><br />Part 2: </span><a href="http://xprocess.blogspot.co.uk/2016/04/cost-of-delay-profiles.html" style="background-color: white; color: #888888; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13.2px; font-style: italic; line-height: 18.48px; text-decoration: none;">Delay Cost and Urgency Profiles</a><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.2px; line-height: 18.48px;"><br />Part 3: </span><i style="background-color: white; color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13.2px; line-height: 18.48px;"><a href="http://xprocess.blogspot.co.uk/2016/04/how-to-calculate-wsjf.html" style="color: #888888; text-decoration: none;">How to Calculate WSJF</a></i><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.2px; line-height: 18.48px;"><br />Part 4: </span><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.2px;"><span style="font-size: 13.2px; line-height: 18.48px;"><i><a href="http://xprocess.blogspot.co.uk/2016/04/wsjf-should-you-divide-by-lead-time-or.html">WSJF - Should you divide by Lead Time or Size?</a></i></span></span><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.2px; line-height: 18.48px;"><br />Part 5: <i><a href="http://xprocess.blogspot.co.uk/2017/01/qualitative-formulae-for-wsjf.html">A "Qualitative" Formula for WSJF?</a></i></span><br />
<span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.2px; line-height: 18.48px;">Part 6: <i>Time is an Asset - Delay is a Cost</i></span><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.2px;"><span style="font-size: 13.2px; line-height: 18.48px;"><i> </i></span></span><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.2px; line-height: 18.48px;">(this article)</span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><br /></span>
<span style="font-family: "arial" , "helvetica" , sans-serif;">In this article I look first at some key terms we have used. I then ask, and hopefully answer, "why is Cost of Delay important?"; "can Cost of Delay be quantified?"; "when could we use WSJF?"; and finally "what next?".</span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><br /></span>
<span style="font-family: "arial" , "helvetica" , sans-serif;"><b>Terminology</b></span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><br /></span>
<span style="font-family: "arial" , "helvetica" , sans-serif;">Three useful terms...</span><span style="background-color: white; font-family: "arial" , "helvetica" , sans-serif;">Unfortunately there is not unanimity on terminology but these ones are important. The first 2 terms below follow Don Reinertsen's work. The third, a term Joshua Arnold used when correcting the dimensionality of SAFe's use of Cost of Delay, was discussed in the </span><a href="http://xprocess.blogspot.co.uk/2017/01/qualitative-formulae-for-wsjf.html" style="font-family: arial, helvetica, sans-serif;">previous blog</a><span style="background-color: white; font-family: "arial" , "helvetica" , sans-serif;"> [10]. (Other terms are introduced in the previous blogs and are available in the glossary of </span><i style="font-family: arial, helvetica, sans-serif;">Essential Kanban Condensed.)</i><br />
<span style="background-color: white; font-family: "arial" , "helvetica" , sans-serif;"><br /></span>
<span style="background-color: white;"><b><span style="font-family: "arial" , "helvetica" , sans-serif;">Cost of Delay</span></b><span style="font-family: "arial" , "helvetica" , sans-serif;"> </span><i><span style="font-family: "arial" , "helvetica" , sans-serif;">(CoD)</span></i><span style="font-family: "arial" , "helvetica" , sans-serif;"> - the rate of decay of value per period of delay. Units for example could be dollars per week. Due to the confusion possible with the next term in this list, I frequently use </span><i><span style="font-family: "arial" , "helvetica" , sans-serif;">Urgency (U) </span></i><span style="font-family: "arial" , "helvetica" , sans-serif;">as a synonym for CoD.</span></span><br />
<span style="background-color: white; font-family: "arial" , "helvetica" , sans-serif;"><br /></span>
<span style="background-color: white;"><b><span style="font-family: "arial" , "helvetica" , sans-serif;">Delay Cost </span></b><span style="font-family: "arial" , "helvetica" , sans-serif;">- the total loss of value due to a delay of known duration. For example, "The release was delayed by 7 weeks, which resulted in a Delay Cost of $150,000".</span></span><br />
<span style="background-color: white; font-family: "arial" , "helvetica" , sans-serif;"><br /></span>
<span style="background-color: white;"><b><span style="font-family: "arial" , "helvetica" , sans-serif;">Time Criticality </span></b><span style="font-family: "arial" , "helvetica" , sans-serif;">- a relative measure of how quickly all the value of an item would be lost. Units are the reciprocal of time. Usually this is used as an informal and relative term. It is useful though to compare the concepts of Time Criticality (which is independent of value) with CoD/Urgency, which quantifies value lost per time. For example eating the lettuce approaching its use-by date in the fridge may have the same Time Criticality, but very different Urgency, compared to paying the final demand on the mortgage on the house!</span></span><br />
<span style="background-color: white; font-family: "arial" , "helvetica" , sans-serif;"><br /></span>
<span style="background-color: white; font-family: "arial" , "helvetica" , sans-serif;"><i>Three useful graphs:</i></span><br />
<span style="background-color: white; font-family: "arial" , "helvetica" , sans-serif;"><br /></span>
<span style="background-color: white;"><b><span style="font-family: "arial" , "helvetica" , sans-serif;">Benefit Profiles </span></b><span style="font-family: "arial" , "helvetica" , sans-serif;">- these show the benefit accrual rate expected from a defined piece of work, plotted against date, for example net pre-tax profits expected per week. There is not unanimity concerning this term. David Anderson frequently refers to these plots as "adoption curves" since for product releases the benefit accrual rate follows the adoption of the product by customers. Joshua Arnold often calls these graphs "urgency profiles", which unfortunately clashes with the definition below. (Since the graphs do not actually reveal urgency - this can only be determined by comparing one benefit profile with a subsequent one incorporating a delay - I would discourage this usage.)</span></span><br />
<span style="background-color: white; font-family: "arial" , "helvetica" , sans-serif;"><br /></span>
<span style="background-color: white;"><b><span style="font-family: "arial" , "helvetica" , sans-serif;">Delay Cost Profiles </span></b><span style="font-family: "arial" , "helvetica" , sans-serif;">- these are plots of delay cost against the delay (or release date, if you prefer). The gradient (first derivative) of these curves shows the CoD or Urgency.</span></span><br />
<span style="background-color: white; font-family: "arial" , "helvetica" , sans-serif;"><br /></span>
<span style="background-color: white;"><b><span style="font-family: "arial" , "helvetica" , sans-serif;">Urgency (or CoD) Profiles </span></b><span style="font-family: "arial" , "helvetica" , sans-serif;">- these plots should how the Cost of Delay is expected to vary over time. Of particular importance is: where there is a spike in CoD (as for example occurs if there is an external deadline); or where there is a continuing change in CoD (as for example occurs when there is expected loss of market share as well as loss of earning period due to the delay); or where step changes occur (as happens at the start and end of expected earning periods).</span></span><br />
<span style="background-color: white;"><span style="font-family: "arial" , "helvetica" , sans-serif;"><br /></span></span>
<span style="background-color: white; font-family: "arial";">See the <a href="http://xprocess.blogspot.co.uk/2016/04/understanding-cost-of-delay-and-its-use.html">first blog</a> in this series for examples of these three types of </span><span style="font-family: "arial";">graph.</span><br />
<span style="font-family: "arial";"><br /></span>
<span style="font-family: "arial";"><b>Why is Cost of Delay Important?</b></span><br />
<br />
<span style="font-family: "arial";">Traditional business cases for new work use estimates of cost and benefit to derive Return on Investment (yield) and a pay-back schedule (duration). However the rate at which value is lost due to delays is not taken into account. As a result we live with the consequences: arbitrary cost cutting by activity type (such as travel bans and contractor “holidays”), a failure to invest to reduce lead time, and an inability to trade-off cost for time. It also means the choice of initiatives undertaken, and the order they are implemented when they cannot or should not be carried out in parallel, is poorly informed. These discussions need accountants and software managers to share vocabulary (and goals)… and ultimately to evolve policies that improve outcomes. Cost of Delay needs to become part of the every day discussions of management.</span><br />
<span style="font-family: "arial";"><br /></span>
<span style="font-family: "arial";"><b>Can Cost of Delay be Quantified?</b></span><br />
<br />
<span style="font-family: "arial";">My short answer to this is "yes, but it cannot be measured" (apologies to Don Hubbard, who would correct the definition of "measured" that I'm using here and say yes it can!). The point is that Cost of Delay is the difference between: something that cannot be measured until after the project has finished (life-time benefits for the work); and something that cannot be measured at all since it relates to something that will never occur (life-time benefits of the work if it had been released on a different date). Since we are estimating CoD it is worth having this in mind - not to prevent its use but to realise its limitations. Even after the fact we will not have a definitive answer about whether it was right.</span><br />
<span style="font-family: "arial";"><br /></span>
<span style="font-family: "arial";">However, the estimates of CoD do not have to be perfect, they just have to be better than the alternative. That is why it is useful. The alternatives are very often even poorer quantifications or merely vague assertions.</span><br />
<span style="font-family: "arial";"><br /></span>
<span style="font-family: "arial";">One further word of caution. Don Reinertsen applied CoD to sizeable initiatives such as new product launches and significant projects. Applying the same technique (Weighted Shortest Job First, or WSJF) to small items such as "epics" or even user stories may be a stretch. The uncertainties involved in estimating value and the rate of loss of value, when considering the life-time benefits of these small items, are likely to result in inaccuracies that invalidate the results.</span><br />
<br />
<div>
<span style="background-color: white; color: #222222; font-family: "arial" , "helvetica" , sans-serif;"><b>So when could we use WSJF</b></span></div>
<div>
<b><span style="background-color: white; color: #222222;"><span style="font-family: "arial" , "helvetica" , sans-serif;"></span><br /></span></b></div>
<div>
<span style="background-color: white; color: #222222; font-family: "arial" , "helvetica" , sans-serif;">If you have read the preceding articles to this blog carefully, you will have noted a number of key assumptions that relate to the validity of the WSJF formula (Cost of Delay Divided by Duration, or CD3). Some of these make WSJF inapplicable for some processes. An example might be where, by continual monitoring of expected delivery dates against the delay cost profile, we can readily and dynamically reorder work schedules to preserve maximum value-delivery. Balancing the right types of work and managing risk by monitoring "last responsible moments" is a way of using CoD without using the WSJF formula, which does not account for variable CoD. Other aspects (such as difficulty in predicting value realization) make the technique inapplicable at smaller scales (for example small work items).</span></div>
<div>
<span style="background-color: white; color: #222222;"><span style="font-family: "arial" , "helvetica" , sans-serif;"></span><br /></span></div>
<div>
<span style="background-color: white; color: #222222; font-family: "arial" , "helvetica" , sans-serif;">Another aspect which affects the applicability of WSJF, is the nature of the domain where we are seeking to order work. Chris Matts has certainly influenced my thinking in this area. Referencing Dave Snowden's Cynefin model [11], Chris points out that in "complex" domains results are not predictable or plannable. Safe-to-fail experiments lead to better outcomes than pre-planned actions (though not necessarily the "best" outcome, which is unknowable in such domains). So rather than preceding delivery with long periods of analysis and estimation, it is better to deliver smaller items and then choose subsequent items based on customer outcomes. This is an important observation, and coincides of course with many other ways of looking at the problem. Reducing the size of value-bearing work items, and reducing the lead times, so that feedback and response can happen quickly, is the right way to proceed in such domains. </span><span style="background-color: white; color: #222222; font-family: "arial" , "helvetica" , sans-serif;">To summarise this advice with regards WSJF - don't use it in complex (or unplannable) domains! This is not just applicable to WSJF of course. If you are doing lots of up front planning any way, maybe your domain is not "complex" in this sense - or maybe you should question other practices as well!</span></div>
<div>
<span style="background-color: white; color: #222222;"><span style="font-family: "arial" , "helvetica" , sans-serif;"></span><br /></span></div>
<div>
<span style="background-color: white; color: #222222; font-family: "arial" , "helvetica" , sans-serif;">So when <i>can</i> we use WSJF? Well not all domains are "unplannable", even domains where continuous feedback and adjustment are required. Not all work items are so small that estimating value and the decay of value is futile or too time-consuming. The most obvious place to look is where Don Reinertsen originally proposed the technique. For sequencing larger plannable items, which due to resource constraints or other reasons, follow each other in sequence. Not only is the WSJF formula useful in such discussions, it provides a means to discuss and manage portfolios of work using financial criteria that our accountants can understand and validate. We need accountants to be involved in this discussion, not least because it the surest way to move management decision making in the direction of greater business agility.</span></div>
<div>
<span style="background-color: white; color: #222222;"><span style="font-family: "arial" , "helvetica" , sans-serif;"></span><br /></span></div>
<div>
<span style="background-color: white; color: #222222; font-family: "arial" , "helvetica" , sans-serif;"><b>Where next?</b></span></div>
<div>
<b><span style="background-color: white; color: #222222;"><span style="font-family: "arial" , "helvetica" , sans-serif;"></span><br /></span></b></div>
<div>
<span style="background-color: white; color: #222222; font-family: "arial" , "helvetica" , sans-serif;">WSJF of course is only one aspect of the application of Cost of Delay. The wider use of Cost of Delay in business, including the involvement of accountants in developing sound ways to apply its quantification, will in the end result in better business decisions and improved value delivery. While the minutiae of formulae and assumption validity, and the difficulty of estimating value-delivery and its decay, are certainly roadblocks in improving our understanding and good business practice in this area, the stakes are too high not to persevere towards robust solutions. </span></div>
<div>
<span style="background-color: white; color: #222222;"><span style="font-family: "arial" , "helvetica" , sans-serif;"></span><br /></span></div>
<div>
<span style="background-color: white; color: #222222; font-family: "arial" , "helvetica" , sans-serif;">If <i>you</i> have persevered through the machinations of this series of blogs, I thank you - and look forward to hearing your feedback and experience reports. The next generation of managers needs clearer explanations of these concepts so they become as well understood as pre-tax profits and balance sheets in driving correct business actions. Accountants and agile managers need to join together to develop the mechanisms and standards that will augment current accounting practice and produce the environment for better business decision making.</span><span style="background-color: white; color: #222222; font-size: 13.2px; line-height: 18.48px;"><br /></span><br />
<span style="background-color: white; color: #222222; font-family: "arial" , "helvetica" , sans-serif;"><br /></span>
<b>References</b><br />
<b><br /></b>[1] Donald G. Reinertsen. <i>The Principles of Product Development Flow</i>, (United States: Celeritas Publishing. 2009)<br />
<br />
[2] David J. Anderson and Andy Carmichael, <i><a href="http://leankanban.com/guide">Essential Kanban Condensed</a></i>. (United States: Lean Kanban University Press. 2016)<br />
<br />
[3] David J. Anderson. <i>Kanban: Successful Evolutionary Change for Your Technology Business</i> (United States: Blue Hole Press, 2010)<br />
<br />
[4] Joshua Arnold and Özlem Yüce. “Using Cost of Delay: Experience Report – Maersk Line.” <i><a href="http://blackswanfarming.com/experience-report-maersk-line/">Black Swan Farming</a></i>. (2013)<br />
<br />
[5] Preston G. Smith and Donald G. Reinertsen. <i>Developing Products in Half the Time</i>. (United States: John Wiley and Sons. 1998)<br />
<br />
[6] Ian Carroll. “No Correlation Between Estimated Size and Actual Time Taken.” <a href="https://iancarroll.com/2016/04/18/no-correlation-between-estimated-size-and-actual-time-taken/"><i>IanCarroll.com</i></a>. (2016)<br />
<span style="background-color: white; color: #222222; font-family: "arial" , "helvetica" , sans-serif;"></span><br />
[7] Joshua Arnold. "Qualitative Cost of Delay." <i><a href="http://blackswanfarming.com/qualitative-cost-delay/">Black Swan Farming</a></i>. (2016)<br />
<br />
[8] Donald G. Reinertsen, David J. Anderson and Andy Carmichael. Meeting Minute. (September, 2016)<br />
<br />
[9] Kanban Leadership Retreat Dubai, www.leankanban.com (2017)<br />
<br />
[10] Magennis, Troy. 2016. Better Backlog Prioritization (from random to lifetime cost of delay). <a href="https://github.com/FocusedObjective/FocusedObjective.Resources/raw/master/Canvas%20and%20Forms/Better%20Backlog%20Prioritization.pdf">https://github.com/FocusedObjective/FocusedObjective.Resources/raw/master/Canvas%20and%20Forms/Better%20Backlog%20Prioritization.pdf</a><br />
<br />
[11] Greg Brougham. <i>The Cynefin Mini-Book: An Introduction to Complexity and the Cynefin Framework</i>, C4Media for InfoQ. (2015)<br />
<div>
<br /></div>
<br />
<br /></div>
Andyhttp://www.blogger.com/profile/04231681582044414408noreply@blogger.com0tag:blogger.com,1999:blog-21436926.post-16006726328525075852017-01-05T08:18:00.000+00:002017-05-12T11:39:48.611+01:00A "Qualitative" Formula for WSJF?In this series of blogs we have been examining the use of Cost of Delay as a way of understanding ordering work - either from a quantitative approach using estimates for value, urgency, duration and/or size, or from a qualitative approach, such as the use of Delay Cost Profiles [1], Risk Profiles [2,3] or Value Size matrices [4]. The SAFe definition of WSJF is something of a hybrid, since it uses a formula, but a formula that has only "qualitative" value at best. Here is their definition [5]:<br />
<br />
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiNbj2LyHV92YrZHk9suZSol2n4EI-njVF0vmKvVu8g34oFUYOeiBDzibq4Rim0WAgcjROfXltmLKEbl3cFhdOuBcLx2zTgdDoQ3H6PT96mZLf-MTyWrZDdqPNBQEkrOfYhrcft/s1600/SAFeCapture.JPG" imageanchor="1" style="clear: left; display: inline !important; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="45" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiNbj2LyHV92YrZHk9suZSol2n4EI-njVF0vmKvVu8g34oFUYOeiBDzibq4Rim0WAgcjROfXltmLKEbl3cFhdOuBcLx2zTgdDoQ3H6PT96mZLf-MTyWrZDdqPNBQEkrOfYhrcft/s400/SAFeCapture.JPG" width="400" /></a><br />
<br />
The 4 terms are determined by Planning Poker estimation using a Fibonacci scale (usually 1 to 20). The work items are ordered according to the formula following an estimation workshop. While this formula cannot provide a true quantitative analysis for ordering items to maximise value, some consultants using it have said that is a useful technique for the discussion it engenders among stakeholders. Once the numbers have been generated the items ordered, re-ordering to a better order is straightforward because of all the discussion that has preceded this point. Needless to say, I strongly disagree with this. While the discussion is necessary for a quantitative or qualitative approach, creating a spurious anchor from numbers which <i>cannot </i>be meaningful will lead to cognitive bias rather than better ordering.<br />
<br />
Why can't the above formula provide meaningful answers? For 2 reasons:<br />
<ol>
<li>Dimensionally the formula is inconsistent</li>
<li>The terms are not estimated on a proportional scale</li>
</ol>
These problems were addressed in Joshua Arnold's proposed modification to the formula [4] which rearranged the terms as follows:<br />
<br />
<i>"WSJF" = Time Criticality x (User-Business Value + Risk Reduction | Opportunity Enablement) / Size</i><br />
<div>
<br /></div>
<b>Dimensionality </b>is addressed, subject to the following assumptions:<br />
<ol>
<li><i>Time Criticality, </i><i><span style="font-family: "times" , "times new roman" , serif;">τ</span>,</i> has units of the reciprocal of time (e.g. days<sup>-1</sup>). In other words an option expiring in 2 months would have double the <i><span style="font-family: "times" , "times new roman" , serif;">τ</span></i> of one expiring in 4 months.</li>
<li><i>User-Business Value</i> and <i>Risk Reduction | Opportunity Enablement </i>are measured in consistent units, possibly using a weighting factor to translate the intangible values to the units of the tangible values</li>
<li><i>Size </i>is proportional to the blocking time caused by implementing the item. This term may in such a case be used as a proxy for duration measured in units of time. This issue has been addressed in this series here: <a href="http://xprocess.blogspot.co.uk/2016/04/wsjf-should-you-divide-by-lead-time-or.html">WSJF - Should you divide by Lead Time or Size?</a> which also identifies additional assumptions required for this to be true.</li>
<li><i>WSJF </i>itself is used consistently with its intended dimensions, which are value/time<sup>2</sup></li>
</ol>
<b>Proportionality </b>must also be addressed. The scale used in estimating must be <i>proportional </i>(including 0 and not limiting maximum range) not just <i>ordinal</i> as would occur if the items with minimum and maximum value are set at say 1 and 20 respectively. The use of a weighting term to ensure the tangible and intangible business value terms are appropriately scaled relative to each other which is also required for proportionality.<br />
<br />
The modified SAFe formula suggests a more general expression for WSJF using the weighting factors for a set of "business value types", <i>v</i>, and "exchange rates" that convert the values to a common "currency" of value:<br />
<br />
<i>WSJF = <span style="font-family: "times" , "times new roman" , serif;">τ</span>Σ(v<sub>n</sub> X<sub>n</sub>) / D</i><br />
<i><br /></i>
<i><span style="font-family: "times" , "times new roman" , serif;">τ</span></i> (tau) is time criticality, <i>v<sub>n</sub></i> is the nth business value, <i>X<sub>n</sub></i> is the exchange rate for this business value type, D is duration, for which Size may be a proxy subject to the assumptions discussed above.<br />
<!--[if gte msEquation 12]><m:oMathPara><m:oMath><i
style='mso-bidi-font-style:normal'><span style='font-size:11.0pt;line-height:
107%;font-family:"Cambria Math",serif;mso-fareast-font-family:Calibri;
mso-fareast-theme-font:minor-latin;mso-bidi-font-family:"Times New Roman";
mso-bidi-theme-font:minor-bidi;mso-ansi-language:EN-GB;mso-fareast-language:
EN-US;mso-bidi-language:AR-SA'><m:r>τ</m:r></span></i></m:oMath></m:oMathPara><![endif]--><!--[if !msEquation]--><!--[endif]--><br />
This blog has not addressed the issue of when quantitative or qualitative approaches should be used. As well as having formulae that are coherent, the work of estimating to provide numbers for the formulae must be worthwhile and comprehensible to the business doing such estimation. In many cases it is not - for example where the domain or context in inherently "non-plannable". The concept of cost of delay is still important, but we should for different techniques for ordering work. Further discussion of this must wait for the next article in the series.<br />
<br />
<b>Previous blogs:</b><br />
<b><br /></b>
<br />
<span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.2px; line-height: 18.48px;">Part 1: <i style="background-color: white; color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13.2px; line-height: 18.48px;"><a href="http://xprocess.blogspot.co.uk/2016/04/understanding-cost-of-delay-and-its-use.html" style="color: #888888; text-decoration: none;">Understanding Cost of Delay and its Use in Kanban</a> </i><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.2px; line-height: 18.48px;"><br />Part 2: </span><a href="http://xprocess.blogspot.co.uk/2016/04/cost-of-delay-profiles.html" style="background-color: white; color: #888888; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13.2px; font-style: italic; line-height: 18.48px; text-decoration: none;">Delay Cost and Urgency Profiles</a><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.2px; line-height: 18.48px;"><br />Part 3: </span><i style="background-color: white; color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13.2px; line-height: 18.48px;"><a href="http://xprocess.blogspot.co.uk/2016/04/how-to-calculate-wsjf.html" style="color: #888888; text-decoration: none;">How to Calculate WSJF</a></i><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.2px; line-height: 18.48px;"><br />Part 4: </span><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.2px;"><span style="font-size: 13.2px; line-height: 18.48px;"><i><a href="http://xprocess.blogspot.co.uk/2016/04/wsjf-should-you-divide-by-lead-time-or.html"><span style="color: #2288bb;">WSJF - Should you divide by Lead Time or Size?</span></a></i></span></span><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.2px; line-height: 18.48px;"><br />Part 5: <a href="http://xprocess.blogspot.co.uk/2017/01/qualitative-formulae-for-wsjf.html"><span style="color: #2288bb;"><i>A "Qualitative" Formula for WSJF?</i></span></a><i> </i><i>(this article)</i><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.2px; line-height: 18.48px;"></span></span><br />
<span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.2px; line-height: 18.48px;">Part 6: <i><a href="http://xprocess.blogspot.co.uk/2017/05/time-is-asset-delay-is-cost.html">Time is an Asset - Delay is a Cost</a></i></span></span><br />
<b>References</b><br />
<br />
[1] David J. Anderson and Andy Carmichael, <a href="http://leankanban.com/guide" style="color: #888888; text-decoration: none;">Essential Kanban Condensed</a>. (United States: Lean Kanban University Press. 2016)<br />
[2] Anderson, David. 2015. ESP: Scaling the benefits of Kanban. Slides 45-49. April 23. http://www.slideshare.net/agilemanager/enterprise-services-planning-scaling-the-benefits-of-kanban (January 5, 2017).<br />
[3] Sharvari, Sawant. 2016. "SwiftKanban help - risk module.". http://help.swiftkanban.com/getting-started/projects/metrics/esp-analytics/risk-management.html(January 5, 2017).<br />
[4] Magennis, Troy. 2016. Better Backlog Prioritization (from random to lifetime cost of delay). https://github.com/FocusedObjective/FocusedObjective.Resources/raw/master/Canvas%20and%20Forms/Better%20Backlog%20Prioritization.pdf<br />
[5] Agile, Scaled. 2016. "WSJF – scaled agile framework.". http://www.scaledagileframework.com/ wsjf/ (January 5, 2017).<br />
<br />Andyhttp://www.blogger.com/profile/04231681582044414408noreply@blogger.com0tag:blogger.com,1999:blog-21436926.post-24427376472146358852016-04-29T16:52:00.001+01:002017-05-12T11:38:35.067+01:00WSJF - Should you divide by Lead Time or Size?<h3 style="background-color: white; color: #222222; font-family: arial, tahoma, helvetica, freesans, sans-serif; margin: 0px; position: relative;">
Understanding Cost of Delay (Part 4): WSJF - the "divisor"</h3>
<div style="background-color: white;">
<div style="color: #222222; font-family: arial, tahoma, helvetica, freesans, sans-serif; font-size: 13.2px; line-height: 18.48px;">
<br /></div>
</div>
This article is the fourth in a series of blogs on <b>Cost of Delay</b> (CoD) and <b>Weighted Shortest Job First</b> (WSJF).<br />
<i><br /></i>
<i>Note: terms in boldface are defined in the Glossary of </i><a href="http://leankanban.com/guide">Essential Kanban Condensed</a> <i>which is available </i><a href="http://leankanban.com/guide">here</a>. To get the background to this piece check out these previous posts:<br />
<blockquote class="tr_bq">
<span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.2px; line-height: 18.48px;">Part 1: <i style="background-color: white; color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13.2px; line-height: 18.48px;"><a href="http://xprocess.blogspot.co.uk/2016/04/understanding-cost-of-delay-and-its-use.html" style="color: #888888; text-decoration: none;">Understanding Cost of Delay and its Use in Kanban</a></i><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.2px; line-height: 18.48px;"><br />Part 2: </span><a href="http://xprocess.blogspot.co.uk/2016/04/cost-of-delay-profiles.html" style="background-color: white; color: #888888; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13.2px; font-style: italic; line-height: 18.48px; text-decoration: none;">Delay Cost and Urgency Profiles</a><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.2px; line-height: 18.48px;"><br />Part 3: </span><i style="background-color: white; color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13.2px; line-height: 18.48px;"><a href="http://xprocess.blogspot.co.uk/2016/04/how-to-calculate-wsjf.html" style="color: #888888; text-decoration: none;">How to Calculate WSJF</a></i><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.2px; line-height: 18.48px;"><br />Part 4: </span><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.2px;"><span style="font-size: 13.2px; line-height: 18.48px;"><a href="http://xprocess.blogspot.co.uk/2016/04/wsjf-should-you-divide-by-lead-time-or.html"><span style="color: #2288bb;"><i>WSJF - Should you divide by Lead Time or Size?</i></span></a><i> (this article)</i></span></span><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.2px; line-height: 18.48px;"><br />Part 5: <i><a href="http://xprocess.blogspot.co.uk/2017/01/qualitative-formulae-for-wsjf.html"><span style="color: #2288bb;">A "Qualitative" Formula for WSJF?</span></a></i></span><br />
<span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.2px; line-height: 18.48px;">Part 6: <i><a href="http://xprocess.blogspot.co.uk/2017/05/time-is-asset-delay-is-cost.html">Time is an Asset - Delay is a Cost</a></i></span></span></blockquote>
<span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.2px; line-height: 18.48px;">In Part 3 we established why the factor used for prioritising <b>work items</b> is <b>urgency </b>divided by the development delay (<i>U/D</i>). The item to be done first should have the highest value for this term (sometimes referred to as the "<i>wisjif" </i>or <i>CD3</i>). Urgency is the rate of decay of the business value (the Delay Cost per week) and we must estimate both the business value and Delay Cost Profile to derive this. In this post however we focus on the other variable. What is the appropriate value to use for <i>D</i>?</span><br />
<span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.2px; line-height: 18.48px;"><br /></span>
<span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.2px; line-height: 18.48px;">OK I'm going to tell you my conclusion before looking at why. It's a surprising conclusion (at least for me). My conclusion is that you should use "size", or a proxy for size like the estimated number of "user stories" in the work item, rather that the period of time before the item is released (Customer Lead Time). Mmm... if that's surprising to you (or if you've no idea why it might be surprising) read on!</span><br />
<span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.2px; line-height: 18.48px;"><b><br /></b></span>
<span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.2px; line-height: 18.48px;"><b>Why use "size" rather than Customer Lead Time in WSJF?</b></span><br />
<span style="color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif;"><span style="font-size: 13.2px; line-height: 18.48px;"><br /></span></span>
<span style="color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif;"><span style="font-size: 13.2px; line-height: 18.48px;">To me the "first-glance" obvious answer to the question "What is D?" is </span></span><b style="color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13.2px; line-height: 18.48px;">Customer Lead Time</b><span style="color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif;"><span style="font-size: 13.2px; line-height: 18.48px;">. The business value is not realised until the item is delivered and "live". So the delay we are talking about is the time from the decision to implement (known as the </span></span><b style="color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13.2px; line-height: 18.48px;">commitment point</b><span style="color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif;"><span style="font-size: 13.2px; line-height: 18.48px;"> in Kanban) to the release date; in other words, the Customer Lead Time. Some people have suggested that an estimate of the "size" of the item in some units (such as number of stories or story points) is an effective proxy for Lead Time. In fact it is a very poor proxy for this. (See for example </span></span><a href="https://iancarroll.com/2016/04/18/no-correlation-between-estimated-size-and-actual-time-taken/" style="color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13.2px; line-height: 18.48px;"><i>Ian Carroll's blog</i></a><span style="color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif;"><span style="font-size: 13.2px; line-height: 18.48px;"> <a href="http://xprocess.blogspot.co.uk/2016/04/understanding-cost-of-delay-and-its-use.html#ref6" id="cite6">[6]</a> looking at correlation between size and Lead Time. The correlation is very weak, possibly non-existent.) The reason for this is low </span></span><b style="color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13.2px; line-height: 18.48px;">Flow Efficiency</b><span style="color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif;"><span style="font-size: 13.2px; line-height: 18.48px;"> - the ratio of time working on an item to elapsed time. If Flow Efficiency is in single figures (typical for many teams) it is not surprising that size does not correlate well with Lead Time. Therefore we can't use size as a proxy for Lead Time. So why did I conclude that size is the correct divisor for </span></span><i style="color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13.2px; line-height: 18.48px;">wisjif</i><span style="color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif;"><span style="font-size: 13.2px; line-height: 18.48px;">?</span></span><br />
<span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.2px; line-height: 18.48px;"><br /></span>
<span style="color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif;"><span style="background-color: white; font-size: 13.2px; line-height: 18.48px;">Let's go back to the derivation of WSJF in the previous article (</span></span><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.2px; line-height: 18.48px;"><a href="http://xprocess.blogspot.co.uk/2016/04/how-to-calculate-wsjf.html" style="color: #888888; font-style: italic; text-decoration: none;">How to Calculate WSJF</a>). The assumptions we used were that: the urgency was constant over the period of interest; and </span><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.2px; line-height: 18.48px;">importantly,</span><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.2px; line-height: 18.48px;"> </span><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.2px; line-height: 18.48px;">that the team's WiP limit was 1. Basically we assumed the second feature had to wait until the first feature had been delivered before we started on the next feature. In these circumstances the delay, is equal to Customer Lead Time - both for the wait until benefit occurs and for how long the previous item holds up the product team before it can start the next item. In reality these are two different wait times - provided that the WiP limit is allowed to be greater than one. The delay before benefit occurs is still the Customer Lead Time (let's call this </span><i style="color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13.2px; line-height: 18.48px;">T</i><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.2px; line-height: 18.48px;">), but the team is held up by less that the Customer Lead Time - they can work on another work item while the first item is held up by a blocker or waiting for release. This is a much more realistic assumption than WiP=1 provided what we are talking about is a product feature, not a project.</span><br />
<span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.2px; line-height: 18.48px;"><br /></span>
<span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; line-height: 18.48px;"><span style="font-size: 13.2px;">This change in assumption changes the equation for the value realised by implementing item 1 followed by item 2. In the previous article we found this to be:</span></span><br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgHg6Gs2_i1-kjdMu9LYACIZVmEGm5DCXhe_4s-FbQQdkEdU-s7efkW9Gkt6dYsY9Vi34bIwuPy0l_Oolv5OCQmUKMkalKdJbJm-68vjmhDvwnGAJUQkIfUJ7J-OJOCNg86yaRq/s1600/Capture.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="33" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgHg6Gs2_i1-kjdMu9LYACIZVmEGm5DCXhe_4s-FbQQdkEdU-s7efkW9Gkt6dYsY9Vi34bIwuPy0l_Oolv5OCQmUKMkalKdJbJm-68vjmhDvwnGAJUQkIfUJ7J-OJOCNg86yaRq/s320/Capture.JPG" width="320" /></a></div>
<span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; line-height: 18.48px;"><span style="font-size: 13.2px;"><br /></span></span>
<span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; line-height: 18.48px;"><span style="font-size: 13.2px;">Now we are considering that the time during which the team is held up, is a different and shorter time than the time before the value is realised. Let's say the teams working on this product have capacity to deliver "stories" at an average rate of </span><i style="font-size: 13.2px;">C </i><span style="font-size: 13.2px;">stories per week. and that the estimated number of stories in the two work items are </span><i><span style="font-size: 13.2px;">s</span><span style="font-size: xx-small;">1 </span></i></span><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.2px; line-height: 18.48px;">and</span><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.2px; line-height: 18.48px;"> </span><i style="color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; line-height: 18.48px;"><span style="font-size: 13.2px;">s</span><span style="font-size: xx-small;">2</span></i><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.2px; line-height: 18.48px;">. </span><br />
<span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.2px; line-height: 18.48px;"><br /></span>
<span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.2px; line-height: 18.48px;">So the amount of time that the second item is held up by the first item is </span><i style="color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; line-height: 18.48px;"><span style="font-size: 13.2px;">s</span><span style="font-size: xx-small;">1</span></i><i style="color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13.2px; line-height: 18.48px;">/C</i><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.2px; line-height: 18.48px;">. The rest of the Customer Lead Time, <i>T</i>, is waiting time - let's call that <i>w</i>. So...</span><br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgcKOS4fhbNn7E5cJu3jSctGDsHaaKfdORRZqNOY8WjEfc3oS0fm-4CuZNdIijAVCDYBQJt1Y8mNsY5VDqQZHJfc0smQLiI7Qkhp5dAQMmZbUrgjHxF-EiQHYnLJMT0SCzDJf-7/s1600/Capture.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="75" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgcKOS4fhbNn7E5cJu3jSctGDsHaaKfdORRZqNOY8WjEfc3oS0fm-4CuZNdIijAVCDYBQJt1Y8mNsY5VDqQZHJfc0smQLiI7Qkhp5dAQMmZbUrgjHxF-EiQHYnLJMT0SCzDJf-7/s200/Capture.JPG" width="200" /></a></div>
<div class="separator" style="clear: both; text-align: left;">
<span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.2px; line-height: 18.48px;">The value realised from item 1 followed by item 2 is now seen to be:</span></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgui-PrKGG9Da3W3VD8ZuqZ08VG2YK80DUa8IhV8yMjYjq78aIqZEVcQsbsZ0pHCTR4BeN6-_RZXCNPCEikvj4hVVdlFyx9p9_sgyOXLBs3pEy5P0AEc3PKsSZBd-sH9enbRrcL/s1600/Capture.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="43" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgui-PrKGG9Da3W3VD8ZuqZ08VG2YK80DUa8IhV8yMjYjq78aIqZEVcQsbsZ0pHCTR4BeN6-_RZXCNPCEikvj4hVVdlFyx9p9_sgyOXLBs3pEy5P0AEc3PKsSZBd-sH9enbRrcL/s320/Capture.JPG" width="320" /></a></div>
<div class="separator" style="clear: both; text-align: left;">
<span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.2px; line-height: 18.48px;">Again subtracting this same formula with the order of the items reversed (and seeing most of the terms cancel out), gives us the difference in value between the alternative orderings, as:</span></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgY0dMCyVzKW3xRcL1tyioI9LOZDAILHV86ysccQLC4iyAadUwiPkHdbdrtOmGgT4Uppdp7W4AqGK8UBrc6rfd-8rs1jVbHabsxCsl-hbcR8j_mt0jKh8VKC5rl1GBKEAKkVup9/s1600/Capture.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="91" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgY0dMCyVzKW3xRcL1tyioI9LOZDAILHV86ysccQLC4iyAadUwiPkHdbdrtOmGgT4Uppdp7W4AqGK8UBrc6rfd-8rs1jVbHabsxCsl-hbcR8j_mt0jKh8VKC5rl1GBKEAKkVup9/s200/Capture.JPG" width="200" /></a></div>
<div class="separator" style="clear: both; text-align: left;">
<span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.2px; line-height: 18.48px;">We can see from this formula that it is the term urgency divided by <i>size</i> for the 2 items (<i>U/s</i>) that determines which order is best. We do not need estimates of lead times for the items to find the optimum order for the work items.</span></div>
<div class="separator" style="clear: both; text-align: left;">
<span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.2px; line-height: 18.48px;"><br /></span></div>
<div class="separator" style="clear: both; text-align: left;">
<span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.2px; line-height: 18.48px;"><i>See important note on assumptions below.</i></span></div>
<div style="clear: both; text-align: left;">
<span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.2px; line-height: 18.48px;"><b><br /></b></span></div>
<div style="clear: both; text-align: left;">
<span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.2px; line-height: 18.48px;"><b>What if the "urgency" is not a constant?</b></span></div>
<div style="clear: both; text-align: left;">
<span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.2px; line-height: 18.48px;"><br /></span></div>
<div class="separator" style="clear: both; text-align: left;">
<span style="background-color: white;"><span style="color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif;"><span style="font-size: 13.2px; line-height: 18.48px;">What about the other important assumption in the simple WSJF formula - that the Urgency (Delay Cost per week) is a constant? In general, Urgency is <i>not</i> constant for work items over the whole period that there is still value in implementing them. However this does not matter <i>if </i>the Urgency is constant during the period that the competing items to be ordered will be implemented. In this case we can just go ahead and use the formula. </span></span></span></div>
<div class="separator" style="clear: both; text-align: left;">
<span style="background-color: white;"><span style="color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif;"><span style="font-size: 13.2px; line-height: 18.48px;"><br /></span></span></span></div>
<div class="separator" style="clear: both; text-align: left;">
<span style="background-color: white;"><span style="color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif;"><span style="font-size: 13.2px; line-height: 18.48px;">For "Fixed Date" items the formula is not appropriate. The determinant for <i>when </i>Fixed Date items should be started is the "last responsible moment", taking into account uncertainty in Customer Lead Time, and the degree of risk that is acceptable to the customer. The determinant for <i>whether</i> Fixed Date items should be started is the <i>total </i>value of the item, compared with the <i>loss of value</i> that occurs by delaying the next highest item to be prioritised. Usually we can just start Expedite items immediately and Fixed Date items before the last responsible moment without the need for estimation or calculation, making WSJF important only for the ordering of Standard items. </span></span></span></div>
<div class="separator" style="clear: both; text-align: left;">
<span style="background-color: white;"><span style="color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif;"><span style="font-size: 13.2px; line-height: 18.48px;"><br /></span></span></span></div>
<div class="separator" style="clear: both; text-align: left;">
<span style="background-color: white;"><span style="color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif;"><span style="font-size: 13.2px; line-height: 18.48px;">Intangible items would not be selected at all if we only applied the WSJF formula, since their immediate urgency is low. Nevertheless it is helpful to always include some Intangible items in the schedule for flexibility (if customer SLAa are threatened), and for preparation for future events. Policies around the use of Intangible items can be tuned to the business context and strategy.</span></span></span></div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
<span style="background-color: white;"><span style="color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif;"><span style="font-size: 13.2px; line-height: 18.48px;"><span style="font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.2px; line-height: 18.48px;">In the next blog in this series we will consider some conclusions from this analysis of Cost of Delay and WSJF. Why is it important? When is it applicable? What to do when it is not applicable or not calculable?</span></span></span></span></div>
<div class="separator" style="clear: both; text-align: left;">
<span style="background-color: white;"><span style="color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif;"><span style="font-size: 13.2px; line-height: 18.48px;"><br /></span></span></span></div>
<div class="separator" style="clear: both; text-align: left;">
<span style="background-color: white;"><span style="color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif;"><span style="font-size: 13.2px; line-height: 18.48px;"><u style="font-weight: bold;">Important Note on Assumptions</u> <i>(continuous delivery or batch)</i></span></span></span></div>
<div class="separator" style="clear: both; text-align: left;">
<span style="background-color: white;"><span style="color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif;"><span style="font-size: 13.2px; line-height: 18.48px;"><i><br /></i></span></span></span></div>
<div class="separator" style="clear: both; text-align: left;">
<span style="background-color: white;"><span style="color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif;"><span style="font-size: 13.2px; line-height: 18.48px;">The algebra above assumes that the waiting time part of the delay</span></span></span><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.2px; line-height: 18.48px;"> </span><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.2px; line-height: 18.48px;">(w)</span><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.2px; line-height: 18.48px;"> does not vary for a given work item, regardless of whether it is implemented before or after another item. This is probably a reasonable assumption if these are "features" which are released as soon as they are completed, in some kind of continuous delivery process. If a batch delivery process is used (e.g. a release every 2 months), the delay is identical for features in the same batch. It would be wasteful to use WSJF for features within the same batch. The issue is which batch the feature is put in and this analysis probably needs to be more sophisticated (or simply qualitative rather than quantitative - see for example <a href="http://xprocess.blogspot.co.uk/2016/04/understanding-cost-of-delay-and-its-use.html#ref7" id="cite7">[7]</a>) - to ensure items are in the right batch.</span></div>
<div class="separator" style="clear: both; text-align: left;">
<span style="background-color: white;"><span style="color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif;"><span style="font-size: 13.2px; line-height: 18.48px;"><b><br style="font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13.2px; line-height: 18.48px;" /></b><i><b>Read part 5:</b></i><b> </b><a href="http://xprocess.blogspot.co.uk/2017/01/qualitative-formulae-for-wsjf.html"><span style="color: #2288bb;"><i>A "Qualitative" Formula for WSJF?</i></span></a><br style="font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13.2px; line-height: 18.48px;" /><br style="font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13.2px; line-height: 18.48px;" /><b style="font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13.2px; line-height: 18.48px;"><i>Back to part 1: </i></b><a href="http://xprocess.blogspot.co.uk/2016/04/understanding-cost-of-delay-and-its-use.html" style="color: #888888; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13.2px; line-height: 18.48px; text-decoration: none;"><i>Understanding Cost of Delay and its Use in Kanban</i></a></span></span></span></div>
Andyhttp://www.blogger.com/profile/04231681582044414408noreply@blogger.com0tag:blogger.com,1999:blog-21436926.post-91978811058417121092016-04-27T14:35:00.004+01:002017-01-02T15:18:27.812+00:00How to calculate WSJF<h3 style="background-color: white; color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; margin: 0px; position: relative;">
Understanding Cost of Delay (Part 3): Calculating WSJF</h3>
<div style="background-color: white;">
<div style="color: #222222; font-family: arial, tahoma, helvetica, freesans, sans-serif; font-size: 13.2px; line-height: 18.48px;">
<br /></div>
<div style="color: #222222; font-family: arial, tahoma, helvetica, freesans, sans-serif; font-size: 13.2px; line-height: 18.48px;">
In <a href="http://xprocess.blogspot.co.uk/2016/04/understanding-cost-of-delay-and-its-use.html" style="color: #888888; text-decoration: none;">part one</a> of this series of blogs on <i style="color: #888888; text-decoration: none;"><a href="http://xprocess.blogspot.co.uk/2016/04/understanding-cost-of-delay-and-its-use.html" style="color: #888888; text-decoration: none;">Understanding Cost of Delay and its Use in Kanban</a></i>, we considered the meaning and difference between <b>Delay Cost</b> and <span style="font-size: 13.2px; line-height: 18.48px;"><b>Urgency</b> (or </span><span style="font-size: 13.2px; line-height: 18.48px;"><b>Cost of Delay</b>). In part two we looked at different</span><b style="font-size: 13.2px; line-height: 18.48px;"> </b><i style="font-size: 13.2px; line-height: 18.48px;"><a href="http://xprocess.blogspot.co.uk/2016/04/cost-of-delay-profiles.html" style="color: #888888; text-decoration: none;">Delay Cost and Urgency Profiles</a> </i><span style="font-size: 13.2px; line-height: 18.48px;">and the archetypes defined in Kanban for classifying work items by these profiles. Now we look at the prioritisation/ordering technique know as <i>Weighted Shortest Job First </i>(WSJF): the formula, the assumptions behind it and how the formula arises. WSJF brings the primacy of time into decision making about which item to implement and when.</span></div>
<div style="color: #222222; font-family: arial, tahoma, helvetica, freesans, sans-serif; font-size: 13.2px; line-height: 18.48px;">
<span style="font-size: 13.2px; line-height: 18.48px;"><br /></span></div>
<div style="color: #222222; font-family: arial, tahoma, helvetica, freesans, sans-serif; font-size: 13.2px; line-height: 18.48px;">
Consider a product development team. They have many ideas for what to add or change in the product, and for improving the way they work. The question is, which of these many useful things should be done first. It turns out the that the total business value of a proposal is not the the deciding factor in maximising the business value a team can deliver in a given period; nor is it urgency of the proposal (the Delay Cost per unit of time). The deciding factor is the urgency divided by duration of implementation, a term sometimes referred to as the WSJF <span style="font-size: 13.2px; line-height: 18.48px;">(or "wisjif") of the item.</span></div>
<div style="color: #222222; font-family: arial, tahoma, helvetica, freesans, sans-serif; font-size: 13.2px; line-height: 18.48px;">
<span style="font-size: 13.2px; line-height: 18.48px;"><br /></span></div>
<span style="color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif;"><span style="font-size: 13.2px; line-height: 18.48px;">To see why let's consider 2 work items with a total cumulative value of <i>V, </i>a duration of <i>D,</i> and an urgency of <i>U.</i> Suffices will indicate which of the 2 work items is being referred to. Assuming the WiP limit in our team is 1 (so the team does only 1 feature at a time), and assuming the urgency, U, is a constant over the period of interest, the estimated value realized by the 2 features will be:</span></span><br />
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: left; margin-right: 1em; text-align: left;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjPsBJIwg_3DLPSJs4-JVpBN0FLGym1LnvLmfJKyQqBBzCm5AUGCZr8PjSQCD-NFnpGhlz42nny8_aeOMgJAGTCIVv5r4sQGi8GBSvaVl3rmTJqFLCE7h71D2eI177QR-wnNsPw/s1600/Capture.JPG" imageanchor="1" style="clear: left; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" height="32" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjPsBJIwg_3DLPSJs4-JVpBN0FLGym1LnvLmfJKyQqBBzCm5AUGCZr8PjSQCD-NFnpGhlz42nny8_aeOMgJAGTCIVv5r4sQGi8GBSvaVl3rmTJqFLCE7h71D2eI177QR-wnNsPw/s320/Capture.JPG" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Total value arising from implementing Item 1 followed by Item 2<br />
For more information see <i><a href="http://leankanban.com/guide">Essential Kanban Condensed</a></i></td></tr>
</tbody></table>
<span style="color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif;"><span style="font-size: 13.2px; line-height: 18.48px;">This is the net present value of the two items less each item's delay cost. In the case of the first item, the delay is just its own duration, but in the case of the second item, it must wait for the first item as well. </span></span><span style="color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.2px; line-height: 18.48px;">If we want to know whether it is better to do item 1 first or item 2,</span><span style="color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.2px; line-height: 18.48px;"> we need to know which has the higher urgency (Delay Cost per time period). </span><span style="color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.2px; line-height: 18.48px;">We can visualise the delay cost like this... it is the total area in these graphs.</span><br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: left; margin-right: 1em; text-align: left;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgN2fL7iirOjb86PbUyYL8Ou3McUmHD-mXN-h3f__iAV9-LMtefM4smjQzlDR3dVhpIqOikv0vy4cTZd6-OJPkC01DM9WlK2tBE9VJOYnPzUbM6O5aS7qd4UE3yK_jAnjwZlz_W/s1600/Capture.JPG" imageanchor="1" style="clear: left; display: inline; margin-bottom: 1em; margin-left: auto; margin-right: auto; text-align: center;"><img border="0" height="132" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgN2fL7iirOjb86PbUyYL8Ou3McUmHD-mXN-h3f__iAV9-LMtefM4smjQzlDR3dVhpIqOikv0vy4cTZd6-OJPkC01DM9WlK2tBE9VJOYnPzUbM6O5aS7qd4UE3yK_jAnjwZlz_W/s200/Capture.JPG" width="200" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Feature 1 then Feature 2<br />
<br /></td></tr>
</tbody></table>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; margin-left: 1em; text-align: right;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgD6FenBjis406-6pkrU8B8Kk7GMyfojDnjHolFhTBmEnmvFLEIbt-GBVnvGoPWixM3Q16GpYxO2ZCDfamsWZ30cWVjhBs3uSn6qx7GX9ce_qFKncCoTnEFnE36HVnVAnH5LHet/s1600/Capture1.JPG" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="134" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgD6FenBjis406-6pkrU8B8Kk7GMyfojDnjHolFhTBmEnmvFLEIbt-GBVnvGoPWixM3Q16GpYxO2ZCDfamsWZ30cWVjhBs3uSn6qx7GX9ce_qFKncCoTnEFnE36HVnVAnH5LHet/s200/Capture1.JPG" width="200" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Feature 2 then Feature 1</td></tr>
</tbody></table>
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<span style="color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.2px; line-height: 18.48px;">Switching the terms over in the formula above, and subtracting, gives us the difference in value realised by changing the order. Most of the terms cancel out, but we are left with the following, for the addition benefit (cost if negative) of doing item 1 before item 2.</span><br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh2qgr2EusataXVYdRySPrBO7AFbRigdh3PFmSXG9tIYyD2ByBKupoSz66cWR1ApslHq-kY3QVlPx6QHfaJ2qXKNo0zeYic6HP8E5xO8QVXHN4epzDmsxF0mkrtm5QuZmTXePNQ/s1600/Capture1.JPG" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="92" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh2qgr2EusataXVYdRySPrBO7AFbRigdh3PFmSXG9tIYyD2ByBKupoSz66cWR1ApslHq-kY3QVlPx6QHfaJ2qXKNo0zeYic6HP8E5xO8QVXHN4epzDmsxF0mkrtm5QuZmTXePNQ/s200/Capture1.JPG" width="200" /></a></div>
<span style="color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif;"><span style="font-size: 13.2px; line-height: 18.48px;">This gives us the basis of WSJF. To maximise business value delivered by the team, we should prioritise the items which have a highest value for urgency divided by duration. The "<i>wisjif</i>" term may thus be expressed as:</span></span><br />
<span style="color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif;"><span style="font-size: 13.2px; line-height: 18.48px;"><br /></span></span>
<span style="color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif;"><span style="font-size: 13.2px; line-height: 18.48px;"><b><i>WSJF = U / D</i></b></span></span><br />
<span style="color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif;"><span style="font-size: 13.2px; line-height: 18.48px;"><br /></span></span>
<span style="color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif;"><span style="font-size: 13.2px; line-height: 18.48px;">In the next article in this series we will look at whether the duration used in this formula should be Customer Lead Time, System Lead Time or something else. we will also consider the assumptions behind the WSJF formula. This will lead us to suggest how the formulae can be used in practice, in conjunction with delay cost profiles for different categories of items.</span></span><br />
<span style="color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif;"><span style="font-size: 13.2px; line-height: 18.48px;"><br style="font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13.2px; line-height: 18.48px;" /><b style="font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13.2px; line-height: 18.48px;"><i>Read part 4 now:</i> </b><i style="font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13.2px; line-height: 18.48px;"><a href="http://xprocess.blogspot.co.uk/2016/04/wsjf-should-you-divide-by-lead-time-or.html" style="color: #888888; text-decoration: none;">WSJF - Should you divide by Lead Time or by Size?</a></i><br style="font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13.2px; line-height: 18.48px;" /><br style="font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13.2px; line-height: 18.48px;" /><b style="font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13.2px; line-height: 18.48px;"><i>Back to part 1: </i></b><a href="http://xprocess.blogspot.co.uk/2016/04/understanding-cost-of-delay-and-its-use.html" style="color: #888888; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13.2px; line-height: 18.48px; text-decoration: none;"><i>Understanding Cost of Delay and its Use in Kanban</i></a></span></span><br />
<div class="MsoEndnoteText">
<!--[if gte msEquation 12]><m:oMathPara><m:oMath><m:sSub><m:sSubPr><span
style='font-family:"Cambria Math",serif;mso-ascii-font-family:"Cambria Math";
mso-hansi-font-family:"Cambria Math";font-style:italic;mso-bidi-font-style:
normal'><m:ctrlPr></m:ctrlPr></span></m:sSubPr><m:e><i style='mso-bidi-font-style:
normal'><span lang=EN-US style='font-family:"Cambria Math",serif'><m:r>V</m:r></span></i></m:e><m:sub><i
style='mso-bidi-font-style:normal'><span lang=EN-US style='font-family:
"Cambria Math",serif'><m:r>1</m:r></span></i></m:sub></m:sSub><i
style='mso-bidi-font-style:normal'><span lang=EN-US style='font-family:"Cambria Math",serif'><m:r>+</m:r></span></i><m:sSub><m:sSubPr><span
style='font-family:"Cambria Math",serif;mso-ascii-font-family:"Cambria Math";
mso-hansi-font-family:"Cambria Math";font-style:italic;mso-bidi-font-style:
normal'><m:ctrlPr></m:ctrlPr></span></m:sSubPr><m:e><i style='mso-bidi-font-style:
normal'><span lang=EN-US style='font-family:"Cambria Math",serif'><m:r>V</m:r></span></i></m:e><m:sub><i
style='mso-bidi-font-style:normal'><span lang=EN-US style='font-family:
"Cambria Math",serif'><m:r>2</m:r></span></i></m:sub></m:sSub><i
style='mso-bidi-font-style:normal'><span lang=EN-US style='font-family:"Cambria Math",serif'><m:r>-</m:r><m:r>
</m:r></span></i><m:sSub><m:sSubPr><span style='font-family:"Cambria Math",serif;
mso-ascii-font-family:"Cambria Math";mso-hansi-font-family:"Cambria Math";
font-style:italic;mso-bidi-font-style:normal'><m:ctrlPr></m:ctrlPr></span></m:sSubPr><m:e><i
style='mso-bidi-font-style:normal'><span lang=EN-US style='font-family:
"Cambria Math",serif'><m:r>U</m:r></span></i></m:e><m:sub><i
style='mso-bidi-font-style:normal'><span lang=EN-US style='font-family:
"Cambria Math",serif'><m:r>1</m:r></span></i></m:sub></m:sSub><m:sSub><m:sSubPr><span
style='font-family:"Cambria Math",serif;mso-ascii-font-family:"Cambria Math";
mso-hansi-font-family:"Cambria Math";font-style:italic;mso-bidi-font-style:
normal'><m:ctrlPr></m:ctrlPr></span></m:sSubPr><m:e><i style='mso-bidi-font-style:
normal'><span lang=EN-US style='font-family:"Cambria Math",serif'><m:r>D</m:r></span></i></m:e><m:sub><i
style='mso-bidi-font-style:normal'><span lang=EN-US style='font-family:
"Cambria Math",serif'><m:r>1</m:r></span></i></m:sub></m:sSub><i
style='mso-bidi-font-style:normal'><span lang=EN-US style='font-family:"Cambria Math",serif'><m:r>-</m:r><m:r>
</m:r></span></i><m:sSub><m:sSubPr><span style='font-family:"Cambria Math",serif;
mso-ascii-font-family:"Cambria Math";mso-hansi-font-family:"Cambria Math";
font-style:italic;mso-bidi-font-style:normal'><m:ctrlPr></m:ctrlPr></span></m:sSubPr><m:e><i
style='mso-bidi-font-style:normal'><span lang=EN-US style='font-family:
"Cambria Math",serif'><m:r>U</m:r></span></i></m:e><m:sub><i
style='mso-bidi-font-style:normal'><span lang=EN-US style='font-family:
"Cambria Math",serif'><m:r>2</m:r></span></i></m:sub></m:sSub><i
style='mso-bidi-font-style:normal'><span lang=EN-US style='font-family:"Cambria Math",serif'><m:r>(</m:r></span></i><m:sSub><m:sSubPr><span
style='font-family:"Cambria Math",serif;mso-ascii-font-family:"Cambria Math";
mso-hansi-font-family:"Cambria Math";font-style:italic;mso-bidi-font-style:
normal'><m:ctrlPr></m:ctrlPr></span></m:sSubPr><m:e><i style='mso-bidi-font-style:
normal'><span lang=EN-US style='font-family:"Cambria Math",serif'><m:r>D</m:r></span></i></m:e><m:sub><i
style='mso-bidi-font-style:normal'><span lang=EN-US style='font-family:
"Cambria Math",serif'><m:r>1</m:r></span></i></m:sub></m:sSub><i
style='mso-bidi-font-style:normal'><span lang=EN-US style='font-family:"Cambria Math",serif'><m:r>+</m:r></span></i><m:sSub><m:sSubPr><span
style='font-family:"Cambria Math",serif;mso-ascii-font-family:"Cambria Math";
mso-hansi-font-family:"Cambria Math";font-style:italic;mso-bidi-font-style:
normal'><m:ctrlPr></m:ctrlPr></span></m:sSubPr><m:e><i style='mso-bidi-font-style:
normal'><span lang=EN-US style='font-family:"Cambria Math",serif'><m:r>D</m:r></span></i></m:e><m:sub><i
style='mso-bidi-font-style:normal'><span lang=EN-US style='font-family:
"Cambria Math",serif'><m:r>2</m:r></span></i></m:sub></m:sSub><i
style='mso-bidi-font-style:normal'><span lang=EN-US style='font-family:"Cambria Math",serif'><m:r>)</m:r></span></i></m:oMath></m:oMathPara><![endif]--><!--[if !msEquation]--><span style="font-family: "calibri" , sans-serif; font-size: 11.0pt; line-height: 107%;"><v:shapetype coordsize="21600,21600" filled="f" id="_x0000_t75" o:preferrelative="t" o:spt="75" path="m@4@5l@4@11@9@11@9@5xe" stroked="f">
<v:stroke joinstyle="miter">
<v:formulas>
<v:f eqn="if lineDrawn pixelLineWidth 0">
<v:f eqn="sum @0 1 0">
<v:f eqn="sum 0 0 @1">
<v:f eqn="prod @2 1 2">
<v:f eqn="prod @3 21600 pixelWidth">
<v:f eqn="prod @3 21600 pixelHeight">
<v:f eqn="sum @0 0 1">
<v:f eqn="prod @6 1 2">
<v:f eqn="prod @7 21600 pixelWidth">
<v:f eqn="sum @8 21600 0">
<v:f eqn="prod @7 21600 pixelHeight">
<v:f eqn="sum @10 21600 0">
</v:f></v:f></v:f></v:f></v:f></v:f></v:f></v:f></v:f></v:f></v:f></v:f></v:formulas>
<v:path gradientshapeok="t" o:connecttype="rect" o:extrusionok="f">
<o:lock aspectratio="t" v:ext="edit">
</o:lock></v:path></v:stroke></v:shapetype><v:shape id="_x0000_i1025" style="height: 18.9pt; width: 146.7pt;" type="#_x0000_t75">
<v:imagedata chromakey="white" o:title="" src="file:///C:/Users/Andy/AppData/Local/Temp/msohtmlclip1/01/clip_image001.png">
</v:imagedata></v:shape></span><!--[endif]--><span lang="EN-US"><o:p></o:p></span></div>
<div class="MsoEndnoteText">
<!--[if gte msEquation 12]><m:oMathPara><m:oMath><m:sSub><m:sSubPr><span
style='font-family:"Cambria Math",serif;mso-ascii-font-family:"Cambria Math";
mso-hansi-font-family:"Cambria Math";font-style:italic;mso-bidi-font-style:
normal'><m:ctrlPr></m:ctrlPr></span></m:sSubPr><m:e><i style='mso-bidi-font-style:
normal'><span lang=EN-US style='font-family:"Cambria Math",serif'><m:r>V</m:r></span></i></m:e><m:sub><i
style='mso-bidi-font-style:normal'><span lang=EN-US style='font-family:
"Cambria Math",serif'><m:r>1</m:r></span></i></m:sub></m:sSub><i
style='mso-bidi-font-style:normal'><span lang=EN-US style='font-family:"Cambria Math",serif'><m:r>+</m:r></span></i><m:sSub><m:sSubPr><span
style='font-family:"Cambria Math",serif;mso-ascii-font-family:"Cambria Math";
mso-hansi-font-family:"Cambria Math";font-style:italic;mso-bidi-font-style:
normal'><m:ctrlPr></m:ctrlPr></span></m:sSubPr><m:e><i style='mso-bidi-font-style:
normal'><span lang=EN-US style='font-family:"Cambria Math",serif'><m:r>V</m:r></span></i></m:e><m:sub><i
style='mso-bidi-font-style:normal'><span lang=EN-US style='font-family:
"Cambria Math",serif'><m:r>2</m:r></span></i></m:sub></m:sSub><i
style='mso-bidi-font-style:normal'><span lang=EN-US style='font-family:"Cambria Math",serif'><m:r>-</m:r><m:r>
</m:r></span></i><m:sSub><m:sSubPr><span style='font-family:"Cambria Math",serif;
mso-ascii-font-family:"Cambria Math";mso-hansi-font-family:"Cambria Math";
font-style:italic;mso-bidi-font-style:normal'><m:ctrlPr></m:ctrlPr></span></m:sSubPr><m:e><i
style='mso-bidi-font-style:normal'><span lang=EN-US style='font-family:
"Cambria Math",serif'><m:r>U</m:r></span></i></m:e><m:sub><i
style='mso-bidi-font-style:normal'><span lang=EN-US style='font-family:
"Cambria Math",serif'><m:r>1</m:r></span></i></m:sub></m:sSub><m:sSub><m:sSubPr><span
style='font-family:"Cambria Math",serif;mso-ascii-font-family:"Cambria Math";
mso-hansi-font-family:"Cambria Math";font-style:italic;mso-bidi-font-style:
normal'><m:ctrlPr></m:ctrlPr></span></m:sSubPr><m:e><i style='mso-bidi-font-style:
normal'><span lang=EN-US style='font-family:"Cambria Math",serif'><m:r>D</m:r></span></i></m:e><m:sub><i
style='mso-bidi-font-style:normal'><span lang=EN-US style='font-family:
"Cambria Math",serif'><m:r>1</m:r></span></i></m:sub></m:sSub><i
style='mso-bidi-font-style:normal'><span lang=EN-US style='font-family:"Cambria Math",serif'><m:r>-</m:r><m:r>
</m:r></span></i><m:sSub><m:sSubPr><span style='font-family:"Cambria Math",serif;
mso-ascii-font-family:"Cambria Math";mso-hansi-font-family:"Cambria Math";
font-style:italic;mso-bidi-font-style:normal'><m:ctrlPr></m:ctrlPr></span></m:sSubPr><m:e><i
style='mso-bidi-font-style:normal'><span lang=EN-US style='font-family:
"Cambria Math",serif'><m:r>U</m:r></span></i></m:e><m:sub><i
style='mso-bidi-font-style:normal'><span lang=EN-US style='font-family:
"Cambria Math",serif'><m:r>2</m:r></span></i></m:sub></m:sSub><i
style='mso-bidi-font-style:normal'><span lang=EN-US style='font-family:"Cambria Math",serif'><m:r>(</m:r></span></i><m:sSub><m:sSubPr><span
style='font-family:"Cambria Math",serif;mso-ascii-font-family:"Cambria Math";
mso-hansi-font-family:"Cambria Math";font-style:italic;mso-bidi-font-style:
normal'><m:ctrlPr></m:ctrlPr></span></m:sSubPr><m:e><i style='mso-bidi-font-style:
normal'><span lang=EN-US style='font-family:"Cambria Math",serif'><m:r>D</m:r></span></i></m:e><m:sub><i
style='mso-bidi-font-style:normal'><span lang=EN-US style='font-family:
"Cambria Math",serif'><m:r>1</m:r></span></i></m:sub></m:sSub><i
style='mso-bidi-font-style:normal'><span lang=EN-US style='font-family:"Cambria Math",serif'><m:r>+</m:r></span></i><m:sSub><m:sSubPr><span
style='font-family:"Cambria Math",serif;mso-ascii-font-family:"Cambria Math";
mso-hansi-font-family:"Cambria Math";font-style:italic;mso-bidi-font-style:
normal'><m:ctrlPr></m:ctrlPr></span></m:sSubPr><m:e><i style='mso-bidi-font-style:
normal'><span lang=EN-US style='font-family:"Cambria Math",serif'><m:r>D</m:r></span></i></m:e><m:sub><i
style='mso-bidi-font-style:normal'><span lang=EN-US style='font-family:
"Cambria Math",serif'><m:r>2</m:r></span></i></m:sub></m:sSub><i
style='mso-bidi-font-style:normal'><span lang=EN-US style='font-family:"Cambria Math",serif'><m:r>)</m:r></span></i></m:oMath></m:oMathPara><![endif]--><!--[if !msEquation]--><span style="font-family: "calibri" , sans-serif; font-size: 11.0pt; line-height: 107%;"><v:shapetype coordsize="21600,21600" filled="f" id="_x0000_t75" o:preferrelative="t" o:spt="75" path="m@4@5l@4@11@9@11@9@5xe" stroked="f">
<v:stroke joinstyle="miter">
<v:formulas>
<v:f eqn="if lineDrawn pixelLineWidth 0">
<v:f eqn="sum @0 1 0">
<v:f eqn="sum 0 0 @1">
<v:f eqn="prod @2 1 2">
<v:f eqn="prod @3 21600 pixelWidth">
<v:f eqn="prod @3 21600 pixelHeight">
<v:f eqn="sum @0 0 1">
<v:f eqn="prod @6 1 2">
<v:f eqn="prod @7 21600 pixelWidth">
<v:f eqn="sum @8 21600 0">
<v:f eqn="prod @7 21600 pixelHeight">
<v:f eqn="sum @10 21600 0">
</v:f></v:f></v:f></v:f></v:f></v:f></v:f></v:f></v:f></v:f></v:f></v:f></v:formulas>
<v:path gradientshapeok="t" o:connecttype="rect" o:extrusionok="f">
<o:lock aspectratio="t" v:ext="edit">
</o:lock></v:path></v:stroke></v:shapetype><v:shape id="_x0000_i1025" style="height: 18.9pt; width: 146.7pt;" type="#_x0000_t75">
<v:imagedata chromakey="white" o:title="" src="file:///C:/Users/Andy/AppData/Local/Temp/msohtmlclip1/01/clip_image001.png">
</v:imagedata></v:shape></span><!--[endif]--><span lang="EN-US"><o:p></o:p></span></div>
</div>
Andyhttp://www.blogger.com/profile/04231681582044414408noreply@blogger.com0tag:blogger.com,1999:blog-21436926.post-69867136908729888652016-04-25T17:55:00.001+01:002016-07-11T22:52:54.973+01:00Delay Cost and Urgency Profiles<h3>
Understanding Cost of Delay (Part 2): Delay Cost and Urgency Profiles</h3>
<div>
In <a href="http://xprocess.blogspot.co.uk/2016/04/understanding-cost-of-delay-and-its-use.html">part one</a> of this series of blogs on <a href="http://xprocess.blogspot.co.uk/2016/04/understanding-cost-of-delay-and-its-use.html">Understanding Cost of Delay and its Use in Kanban</a> we explored how - from understanding the business benefit that is likely to occur following the decision to implement a proposal now or later - we can derive </div>
<div>
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; margin-left: 1em; text-align: right;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhxK7cSZrsznrdVd1hhAERGVdySq32HW72UZcJ_q7yDMe51ENejZjd4c5juEQMwvsdJbyrYZqZjWAiiYPFXehUD3vzvXPCTR8Kipawi739_3W9Un6fVgoy0MOH5Shcm_DyzJm8D/s1600/Capture.JPG" imageanchor="1" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhxK7cSZrsznrdVd1hhAERGVdySq32HW72UZcJ_q7yDMe51ENejZjd4c5juEQMwvsdJbyrYZqZjWAiiYPFXehUD3vzvXPCTR8Kipawi739_3W9Un6fVgoy0MOH5Shcm_DyzJm8D/s320/Capture.JPG" width="181" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;"><div style="font-size: 12.8px;">
Value Flow, Cumulative Value, Delay Cost<br />
and Urgency <span style="font-size: 12.8px;">for </span><b style="font-size: 12.8px;">time-sensitive feature</b></div>
<div style="font-size: 12.8px;">
<i>(click on image for more detail)</i></div>
</td></tr>
</tbody></table>
<ol>
<li>the value flow (net benefits, positive and negative) each week through the useful life of the proposal, for a given release date</li>
<li>the change in cumulative value (<a href="https://en.wikipedia.org/wiki/Net_present_value"><b>Net Present Value</b></a>, NPV, or life-time profits) as a function of time, for a given release date</li>
<li>the <b>Delay Cost</b> Profile - how much business value is lost as a function of the delay </li>
<li>the <b>Urgency</b> Profile (the <i>rate </i>at which value is lost as a function of the delay)</li>
</ol>
<ul>
</ul>
<div>
<b>Note: </b>The terms <b>Cost of Delay</b> (<b>CoD</b>), <b>Class of Service</b>, <b>Delay Cost</b>, <b>Lead Time</b>, <b>NPV</b>, <b>work item </b>and <b>Urgency</b>, as well as over 60 commonly used terms in Kanban and Lean are defined in the Kanban Glossary in <i><a href="http://leankanban.com/guide">Essential Kanban Condensed</a></i> [2] (currently available as a free download).</div>
</div>
<div>
<br /></div>
<div>
For the type of work item that was considered in part 1 (a product feature in a time-limited competitive market), the four curves are shown above: value flow, cumulative value, delay cost (as a function of the delay), and urgency (as a function of the delay).</div>
<div>
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div>
This feature shows a diminishing rate of cost of delay (urgency), due to the twin effects of a reduced peak in earnings and reduced period of earning, the longer the feature is delayed.<br />
<br />
What if we were examining a different type of work item which was estimated to save a certain amount of work each week, work which is currently being contracted out to external staff? In other words the same savings would occur every week for the foreseeable life of the product. Here is an estimated projection for the 4 curves in this case ...<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjs2X02h97Q4Xv0NM6QRHarjHsKZb4ZC5B0BD4fO3te24v-_3-U9Snpmt7EluMyhXLwGZ9RNPelr7evkNfYTYl_hW-0NDxR_hLlZJrtZH0BWvG9rO7a6NJUTf5-8FWWD9faeayx/s1600/Capture.JPG" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="80" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjs2X02h97Q4Xv0NM6QRHarjHsKZb4ZC5B0BD4fO3te24v-_3-U9Snpmt7EluMyhXLwGZ9RNPelr7evkNfYTYl_hW-0NDxR_hLlZJrtZH0BWvG9rO7a6NJUTf5-8FWWD9faeayx/s400/Capture.JPG" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;"><div style="font-size: 12.8px;">
Value Flow, Cumulative Value, Delay Cost and Urgency</div>
<div style="font-size: 12.8px;">
for a feature providing <b>constant benefit </b>for a period of time</div>
</td></tr>
</tbody></table>
In this case the cumulative NPV is more or less a straight line (bending downwards slightly due to the present value discount), and it results in a CoD profile which is also more or less a straight line with the same gradient (bending upwards slightly). Straight line CoD profiles result in constant urgency which we can see (approximately) in the final graph in the series.<br />
<br />
Different again - what about an item that would save a penalty fine from a regulator if a certain issue is not addressed by a fixed date? Here are the curves ...<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhO-7hbk4bhuAZ3-Y3nB-dSGncrt6s_XUDvQluQGJJefA__26sMii6xjIVZk7uslgFcspYw_mMOA7tD9N8Vo747dqRXGjKhZeV-ZnhMnki6puCa_TmZetry8kUtU8cHIGC4z54F/s1600/CoD+case3.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="77" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhO-7hbk4bhuAZ3-Y3nB-dSGncrt6s_XUDvQluQGJJefA__26sMii6xjIVZk7uslgFcspYw_mMOA7tD9N8Vo747dqRXGjKhZeV-ZnhMnki6puCa_TmZetry8kUtU8cHIGC4z54F/s400/CoD+case3.jpg" width="400" /></a></div>
<div style="font-size: 12.8px; text-align: center;">
Cash Flow, Cumulative NPV, Cost of Delay and Urgency</div>
<div style="font-size: 12.8px; text-align: center;">
for a feature providing <b>step-function in benefit</b> at a <b>fixed date</b></div>
<br />
This work item displays a sudden step-function in cumulative NPV at the point the fine would be applied, and a similar step-function in the CoD about 10 weeks before the date of the fine, since development Lead Time is estimated to be 10 weeks. The urgency profile is a spike - no urgency up to the "last responsible moment" when work must start, and no urgency after this point since you would then have passed the "first irresponsible moment"; there is no avoiding the fine after that point! In reality the CoD and Urgency profiles should be smoother since there is uncertainty in the estimate, and leaving it to the last moment increases the risk of incurring higher costs in order to hit the date, or indeed of missing the date due to unforeseen circumstances.<br />
<br />
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; text-align: right;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhT2OAw6mGcoJqFC-1onsaV6AzDV0u22aUM6hQIftcr0ebJOiWkHDeebyagQI96yAM5y-OYI3YLScOs9ODElwxEnQdSXjtIqFtAMWKBSBYwk1OR-znaS0iwQ22Fbp4DrYXmVaQ5/s1600/Capture.JPG" imageanchor="1" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" height="400" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhT2OAw6mGcoJqFC-1onsaV6AzDV0u22aUM6hQIftcr0ebJOiWkHDeebyagQI96yAM5y-OYI3YLScOs9ODElwxEnQdSXjtIqFtAMWKBSBYwk1OR-znaS0iwQ22Fbp4DrYXmVaQ5/s400/Capture.JPG" width="222" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;"><div style="font-size: 12.8px;">
Value Flow, Cumulative Value, Delay Cost <br />
and Urgency <span style="font-size: 12.8px;">for a feature providing </span><b style="font-size: 12.8px;">constant <br />benefit</b><span style="font-size: 12.8px;"> for a period beginning at a</span><span style="font-size: 12.8px;"> </span><b style="font-size: 12.8px;">fixed date</b></div>
</td></tr>
</tbody></table>
Finally consider the case where the savings of staff (similar to the second scenario above) would not start until a fixed date. See graphs to the right.<br />
<br />
We can see this case effectively combines the previous two, with a period of low or negative Delay Cost, followed by approximately linear Delay Cost up to the end of the opportunity.<br />
<br />
We have taken some time here to look at the 4 curves (Value Flow, Cumulative Value, Cost of Delay and Urgency) for these 4 different types of feature because it is easy to confuse between them. In the case of the "constant benefit" item, the Cumulative Value and Delay Cost look almost identical, with the same units on both axes. This has caused some confusion and some inaccurate statements about the use of cost of delay. Take care!<br />
<br />
One of the observations to make about the graphs shown so far is that to estimate and derive them accurately for real features is difficult and error-prone. While this is true, one should not conclude from it that we should therefore estimate a completely different entity, which is easier but not well correlated with the scheduling decisions we wish to make! (Sadly, you may also come across some advice like that.)<br />
<br />
However it does suggest that looking at archetype profiles for different types of work item may be helpful. Picking from a menu of profiles, based on the type of feature proposed e.g. diffentiator in a competitive market, cost-saver in a monopoly market, fixed date cost-saver, and so on, is much simpler than trying to derive these curves from scratch. Some tools for Kanban are already offering such features. The profile can be combined with order of magnitude estimates of value and urgency (e.g. using a series such as 1, 2, 5,10, 20, 50, 100, 200, 500, 1000, etc.).<br />
<br />
Kanban <a href="http://xprocess.blogspot.co.uk/2016/04/understanding-cost-of-delay-and-its-use.html#ref3">[3]</a> defines 4 archetypes with different Delay Cost Profiles which are typically used to differentiate Classes of Service. <i style="background-color: white; color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13.2px; line-height: 18.48px;"><a href="http://blackswanfarming.com/experience-report-maersk-line/" style="color: #888888; text-decoration: none;">Black Swan Farming</a> </i><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.2px; line-height: 18.48px;"><a href="http://xprocess.blogspot.co.uk/2016/04/understanding-cost-of-delay-and-its-use.html#ref4">[4]</a></span> also suggests some typical profiles. The Kanban archetypes do not correspond exactly to the types of feature discussed above, though there is some overlap.<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhbw9_eHgpoChT_NJHcO9na53IdXK-pOYk2jcXFwBJPp4HPyQObrrjbrpkiiNMft1fiizyc7Yf23NfbrMzf9Q3BDXj58S8zA2OIpFdLY7f4bXIv69J7TWRRSAIJfMGmK18m8qLT/s1600/Capture.JPG" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="77" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhbw9_eHgpoChT_NJHcO9na53IdXK-pOYk2jcXFwBJPp4HPyQObrrjbrpkiiNMft1fiizyc7Yf23NfbrMzf9Q3BDXj58S8zA2OIpFdLY7f4bXIv69J7TWRRSAIJfMGmK18m8qLT/s400/Capture.JPG" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;"><span style="font-size: 12.8px;">Kanban's Delay Cost Archetypes, from </span><i style="font-size: 12.8px;"><a href="http://leankanban.com/guide">Essential Kanban Condensed</a></i></td></tr>
</tbody></table>
<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: left;">
The archetypes show 4 Delay Cost Profiles:</div>
<div class="separator" style="clear: both; text-align: left;">
</div>
<ol>
<li><b>Expedite </b>items have very high urgency (high CoD) and there is no end in sight to the cost - if you wait, the losses don't come to an end. It's a straightforward decision - do it now! </li>
<li>The <b>Fixed Date</b> items also have high impact but only if you miss the deadline. The scheduling imperative here is to make sure you start before the last responsible moment and deliver before the deadline. </li>
<li>The <b>Standard </b>profile is approximately linear to start with and tails off or cuts off as the opportunity loses value. Standard items should therefore be done as soon as possible and scheduled relative to each other according to the degree of urgency and the item's size (see later <a href="http://xprocess.blogspot.co.uk/2016/04/how-to-calculate-wsjf.html">discussion of WSJF</a>). </li>
<li>Finally, <b>Intangible </b>items have an apparently low urgency. One might ask why do them? Two reasons. The intangible profile does indicate a rise in urgency - possibly a steep rise - will happen in the future. It is useful to make some progress on these items even though the impact in the short term is likely to be low. In addition having some items in the schedule which are "interruptible" makes the system more resilient in the event of expedite items having to be handled, or events which threaten the service level agreement for standard items.</li>
</ol>
<div>
So how might a workshop gather the quantified information that we need for scheduling the work item options based on cost of delay, particularly if we do not currently have a menu of items to pick from. Here's a generalised profile of cost of delay and urgency that (roughly) covers all the profiles we have discussed within the precision we could reasonably expect from the workshop.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEieGALZsWQnMIBYn9muyPPGItdZYpj01ncENJcrQqIzqWtT5lpYZQD9O1e7U8CXuqAax8N9Dr2jj5n7BHomvMwIjQm0vxS9CRfKFNpoiokx8agoolUCbXd5GwzL9fKtSNVPEA_-/s1600/Capture.JPG" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="166" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEieGALZsWQnMIBYn9muyPPGItdZYpj01ncENJcrQqIzqWtT5lpYZQD9O1e7U8CXuqAax8N9Dr2jj5n7BHomvMwIjQm0vxS9CRfKFNpoiokx8agoolUCbXd5GwzL9fKtSNVPEA_-/s320/Capture.JPG" width="320" /></a></div>
Using this profile we can ask for 3 parameters that give enough detail for us to schedule the items. There are 2 dates (t<span style="font-size: xx-small;">1</span> and t<span style="font-size: xx-small;">2</span>) and the slope of the CoD line (or urgency). Before t<span style="font-size: xx-small;">1</span> there is low or zero CoD - it's the "CoD low until date" (CLUD). After t<span style="font-size: xx-small;">2</span> there is also low or zero CoD - it's the "CoD low after date" (CLAD).</div>
<div>
<br /></div>
Armed with this information about delay cost and urgency profiles, we can now move forward to consider the WSJF method itself. To use it we need information about the urgency, the urgency profile and the duration taken by implementation of the work item.<br />
<br />
This is considered in the next blog in this series.<br />
<br />
<b style="background-color: white; color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13.2px; line-height: 18.48px;"><i>Read part 3 now:</i> </b><i><a href="http://xprocess.blogspot.co.uk/2016/04/how-to-calculate-wsjf.html">How to calculate WSJF</a></i><br />
<br />
<b><i>Back to part 1: </i></b><a href="http://xprocess.blogspot.co.uk/2016/04/understanding-cost-of-delay-and-its-use.html"><i>Understanding Cost of Delay and its Use in Kanban</i></a></div>
Andyhttp://www.blogger.com/profile/04231681582044414408noreply@blogger.com0tag:blogger.com,1999:blog-21436926.post-44491060050962319142016-04-15T13:41:00.000+01:002017-05-12T11:48:48.896+01:00Understanding Cost of Delay and its Use in KanbanCost of Delay (CoD) is a vital concept to understand in product development. It should be a <i>guide</i> to the ordering of work items, even if - as is often the case - estimating it quantitatively may be difficult or even impossible. Analysing Cost of Delay (even if done qualitatively) is important because it focuses on the business value of work items and how that value changes over time. An understanding of Cost of Delay is essential if you want to <i>maximise </i>the flow of value to your customers.<br />
<br />
Don Reinertsen in his book <i>Flow </i><a href="https://www.blogger.com/blogger.g?blogID=21436926#ref1" id="cite1">[1]</a> has shown that, if you want to deliver the maximum business value with a given size team, you give the highest priority, not to the most valuable work items in your "pool of ideas," not even to the most <i>urgent </i>items (those whose business value decays at the fastest rate), nor to your smallest items. Rather you should prioritise those items with the highest value of <b>urgency </b>(or CoD) divided by the time taken to implement them. Reinertsen called this approach <b>Weighted Shortest Job First</b> or WSJF (sometimes pronounced <i>wizjiff!</i>). WSJF is a variation of the <a href="https://en.wikipedia.org/wiki/Shortest_job_next">Shortest Job First</a> scheduling algorithm used in computer operating systems. By adding urgency as a weighting, both time <i>and </i>value contribute to the decision-making.<br />
<br />
In this series of articles, of which this is the first, we return to the topic of Cost of Delay (previously addressed 3 years ago in <a href="http://xprocess.blogspot.co.uk/2013/04/selecting-backlog-items-by-cost-of-delay.html"><i>Selecting Backlog Items By Cost of Delay</i></a>), and how CoD can be applied in Kanban. I'll explain the terminology used in the recently published book <i><a href="http://leankanban.com/guide">Essential Kanban Condensed</a></i> <a href="https://www.blogger.com/blogger.g?blogID=21436926#ref2" id="cite2">[2]</a> - including why this differs slightly from that used by some other authors - and how you can apply this knowledge in Kanban, potentially combining it with the use of <b>Classes of Service</b>. In particular we will look at the simple mathematics applied in WSJF and the assumptions that make it valid or invalid in different circumstances.<br />
<br />
Here are the links to the articles in this series:<br />
<i><br /></i>
Part 1: <i>Understanding Cost of Delay and its Use in Kanban </i>(this article)<br />
Part 2: <a href="http://xprocess.blogspot.co.uk/2016/04/cost-of-delay-profiles.html" style="font-style: italic;">Delay Cost and Urgency Profiles</a><br />
Part 3: <i><a href="http://xprocess.blogspot.co.uk/2016/04/how-to-calculate-wsjf.html">How to Calculate WSJF</a></i><br />
Part 4: <i><a href="http://xprocess.blogspot.co.uk/2016/04/wsjf-should-you-divide-by-lead-time-or.html">WSJF - Should you divide by Lead Time or by "Size"?</a></i><br />
Part 5: Others may follow...<br />
<ol>
</ol>
Let's start with some definitions, by looking at a particular work item, a proposal for a new feature in a software product. Let's assume that we've already carried out some analysis of this feature and the competitive market in which the product operates. As a result we can forecast the value flow - in this case the net profit each week - that will result from the implementation and exploitation of the feature.<br />
<br />
Here's what the weekly business benefit graph looks like...<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhcmAg995kJVB9tz_2tLXJk96fKoHkGh2QPxzmloY9847KitKC_mCvIwc9TJ8wM7T9F7ahXEdiLuNzYj9ExPgE39WFVOEpsaYhUrHzwc2wGig8cuTufaffAMb4VyDRcwh9tDfWD/s1600/Capture.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="181" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhcmAg995kJVB9tz_2tLXJk96fKoHkGh2QPxzmloY9847KitKC_mCvIwc9TJ8wM7T9F7ahXEdiLuNzYj9ExPgE39WFVOEpsaYhUrHzwc2wGig8cuTufaffAMb4VyDRcwh9tDfWD/s320/Capture.JPG" width="320" /></a></div>
<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
To know what the Cost of Delay is for this feature we need to estimate what the business benefits would be if we delayed starting this work and instead started in say 10 weeks or 20 weeks time. Here's a comparison of these 3 different cash flows, with no delay, 10 weeks delay and 20 weeks delay.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEib6h6AZeWV-gqMNwdCycbLDNpPZO8wLzsUqajwJgFbCZwg-YUVXJuxuDlxlssvrf0TbUBTK7atB_4MowjiWfst5SQE8MH-nP_JepyXuzfYkqnLwTRwLxtioPDdvk77jZVzQOAH/s1600/Capture.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="199" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEib6h6AZeWV-gqMNwdCycbLDNpPZO8wLzsUqajwJgFbCZwg-YUVXJuxuDlxlssvrf0TbUBTK7atB_4MowjiWfst5SQE8MH-nP_JepyXuzfYkqnLwTRwLxtioPDdvk77jZVzQOAH/s320/Capture.JPG" width="320" /></a></div>
<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
The analysis seems to be forecasting that not only will the peak revenue be lower by entering the market later, the time period for exploiting the feature profitably is also shorter. To see the effect of this on the overall value of the feature (calculated as a <b>net present value </b>or alternatively total life-time profits), it is useful to plot a cumulative value graph, see below...<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgM27iPE9gH4qPpQYh7PGrhc7_FY2Z2idtcRRXCEsVM4kEG4JIecgYAb1fomms2Vd5KgjtPxCgqfCfhOaOhk9k8qmCstwZNg3pHsBqev8pm2hEASmNKYvBciR3WcKV7A7Xt2Kqg/s1600/Capture.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="188" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgM27iPE9gH4qPpQYh7PGrhc7_FY2Z2idtcRRXCEsVM4kEG4JIecgYAb1fomms2Vd5KgjtPxCgqfCfhOaOhk9k8qmCstwZNg3pHsBqev8pm2hEASmNKYvBciR3WcKV7A7Xt2Kqg/s320/Capture.JPG" width="320" /></a></div>
<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
Now we can see what the value of this feature is if it is implemented without delay - about $420K. We can also see the loss of value - the Delay Cost - for a 10-week and a 20-week delay.<br />
<br />
The next step is to plot the Delay Cost against the length of the delay. This graph is referred to as the Delay Cost Profile. There are a number of archetypes that different authors have identified <a href="https://www.blogger.com/blogger.g?blogID=21436926#ref3" id="cite3">[3, 4]</a> that can help us identify the likely profile in given scenarios. We'll look at these in more detail in <a href="http://xprocess.blogspot.co.uk/2016/04/cost-of-delay-profiles.html">Part 2</a> of this series. Here's the Delay Cost Profile for our feature:<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj_lhjL2j6jnxRDlPHmJrrHDuBz9qDXu2vjDfS9apl5Yx13upr6X31phS0Mwtm86LQ40Z-3QxUuHGaHtInqFxlWk0K5HNQ5Zyw-pgq8lga7XXv1JPLiFSuwBiXMOgtP8VxyQJxu/s1600/Capture.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="189" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj_lhjL2j6jnxRDlPHmJrrHDuBz9qDXu2vjDfS9apl5Yx13upr6X31phS0Mwtm86LQ40Z-3QxUuHGaHtInqFxlWk0K5HNQ5Zyw-pgq8lga7XXv1JPLiFSuwBiXMOgtP8VxyQJxu/s320/Capture.JPG" width="320" /></a></div>
This shows our feature is losing value most rapidly right now! As value is lost so the <i>rate</i> at which value is lost is also diminishing. At a certain point the projected profit from the feature becomes less than the development cost so there is no value in implementing the feature and no further Delay Cost.<br />
<br />
We refer the rate at which value is lost as <b>Urgency </b>or <b>Cost of Delay </b>(the first derivative of Delay Cost). It is important when reviewing materials on CoD - particularly when looking at graphs plotted against time - to clarify whether the term referred to is Delay Cost measured in currency (e.g. $) or Urgency/Cost of Delay (measured in currency per length of delay, e.g. $ per week). It is unfortunate that the 2 terms commonly used here - Delay Cost ($) and Cost of Delay ($ per week) - are so close in natural meaning (translators have nightmares!). For this reason the Kanban glossary suggests an alternative term for the rate at which value and Delay Cost changes - Urgency.<br />
<br />
When Urgency is plotted against the date of availability (or the length of delay, if starting from a reference date), the graph is referred to as the Urgency Profile.<br />
<br />
Here is the plot of the Urgency Profile for our example:<br />
<br />
<div class="separator" style="clear: both; text-align: left;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjBrndy2GpM7RZTxzZvybkOpopivoFbwAJGyAsAc59ot8v91q0PY4NhK65hXd1ujP-pn_umrb8gcV3i9YALihyQhmY6DPoMDayuBpVHZYXhrpWBh6ztYhtz334cSNJ4_BwgzzUU/s1600/Capture.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="187" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjBrndy2GpM7RZTxzZvybkOpopivoFbwAJGyAsAc59ot8v91q0PY4NhK65hXd1ujP-pn_umrb8gcV3i9YALihyQhmY6DPoMDayuBpVHZYXhrpWBh6ztYhtz334cSNJ4_BwgzzUU/s320/Capture.JPG" width="320" /></a></div>
<br />
We can see from this graph that Urgency is diminishing in this case, as the market opportunity is also disappearing. Reinertsen and Preston Smith <a href="https://www.blogger.com/blogger.g?blogID=21436926#ref5" id="cite5">[5]</a> noted that the <i>sense of urgency</i> in organisations often runs in the opposite direction to the market opportunity - they named it the <b>Urgency Paradox</b>, the "cruel tendency" for this <i>sense </i>of urgency in product development to be highest when the <i>real</i> urgency, as reflected by market opportunity, is lowest and <i>vice versa</i>.<br />
<br />
We will see in future articles in this series how different kinds of work item have different Delay Cost and Urgency profiles, and how we can use this with WSJF to help the scheduling of work to maximise the delivery of business value. We'll also examine the degree to which a quantified approach (using numerical estimates of business value and its rate of decay) can be used in practice, and whether alternative approaches such as the use of profile archetypes with scaling factors can be as or more effective.<br />
<blockquote class="tr_bq">
<b>Note: </b>This article has been updated since its first publication to be consistent with the latest version of the glossary in <i>Essential Kanban Condensed </i>[2].</blockquote>
<br />
<b><i>Now read part 2:</i> </b><i><a href="http://xprocess.blogspot.co.uk/2016/04/cost-of-delay-profiles.html">Delay Cost and Urgency Profiles</a></i><br />
<i><br /></i>
<i>The Cost of Delay Series:</i><br />
<i><br /></i>
<span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.2px; line-height: 18.48px;">Part 1: </span><i style="background-color: white; color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13.2px; line-height: 18.48px;"><a href="http://xprocess.blogspot.co.uk/2016/04/understanding-cost-of-delay-and-its-use.html" style="color: #888888; text-decoration: none;">Understanding Cost of Delay and its Use in Kanban</a> (this article)</i><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.2px; line-height: 18.48px;"><br />Part 2: </span><a href="http://xprocess.blogspot.co.uk/2016/04/cost-of-delay-profiles.html" style="background-color: white; color: #888888; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13.2px; font-style: italic; line-height: 18.48px; text-decoration: none;">Delay Cost and Urgency Profiles</a><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.2px; line-height: 18.48px;"><br />Part 3: </span><i style="background-color: white; color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13.2px; line-height: 18.48px;"><a href="http://xprocess.blogspot.co.uk/2016/04/how-to-calculate-wsjf.html" style="color: #888888; text-decoration: none;">How to Calculate WSJF</a></i><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.2px; line-height: 18.48px;"><br />Part 4: </span><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.2px;"><span style="font-size: 13.2px; line-height: 18.48px;"><i><a href="http://xprocess.blogspot.co.uk/2016/04/wsjf-should-you-divide-by-lead-time-or.html"><span style="color: #2288bb;">WSJF - Should you divide by Lead Time or Size?</span></a></i></span></span><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.2px; line-height: 18.48px;"><br />Part 5: <i><a href="http://xprocess.blogspot.co.uk/2017/01/qualitative-formulae-for-wsjf.html"><span style="color: #2288bb;">A "Qualitative" Formula for WSJF?</span></a></i></span><br />
<span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.2px; line-height: 18.48px;">Part 6: <i><a href="http://xprocess.blogspot.co.uk/2017/05/time-is-asset-delay-is-cost.html">Time is an Asset - Delay is a Cost</a></i></span><br />
<br />
<b>References</b><br />
<b><br /></b>
<a href="https://www.blogger.com/blogger.g?blogID=21436926#cite1" id="ref1">[1]</a> Donald G. Reinertsen. <i>The Principles of Product Development Flow</i>, (United States: Celeritas Publishing. 2009)<br />
<br />
<a href="https://www.blogger.com/blogger.g?blogID=21436926#cite2" id="ref2">[2]</a> David J. Anderson and Andy Carmichael, <i><a href="http://leankanban.com/guide">Essential Kanban Condensed</a></i>. (United States: Lean Kanban University Press. 2016)<br />
<br />
<a href="https://www.blogger.com/blogger.g?blogID=21436926#cite3" id="ref3">[3]</a> David J. Anderson. <i>Kanban: Successful Evolutionary Change for Your Technology Business</i> (United States: Blue Hole Press, 2010)<br />
<br />
<a href="https://www.blogger.com/blogger.g?blogID=21436926#cite3" id="ref4">[4]</a> Joshua Arnold and Özlem Yüce. “Using Cost of Delay: Experience Report – Maersk Line.” <i><a href="http://blackswanfarming.com/experience-report-maersk-line/">Black Swan Farming</a></i>. (2013)<br />
<br />
<a href="https://www.blogger.com/blogger.g?blogID=21436926#cite5" id="ref5">[5]</a> Preston G. Smith and Donald G. Reinertsen. <i>Developing Products in Half the Time</i>. (United States: John Wiley and Sons. 1998)<br />
<br />
<a href="http://xprocess.blogspot.co.uk/2016/04/wsjf-should-you-divide-by-lead-time-or.html#cite6" id="ref6">[6]</a> Ian Carroll. “No Correlation Between Estimated Size and Actual Time Taken.” <a href="https://iancarroll.com/2016/04/18/no-correlation-between-estimated-size-and-actual-time-taken/"><i>IanCarroll.com</i></a>. (2016)<br />
<br />
<a href="http://xprocess.blogspot.co.uk/2016/04/wsjf-should-you-divide-by-lead-time-or.html#cite7" id="ref7">[7]</a> Joshua Arnold. "Qualitative Cost of Delay." <i><a href="http://blackswanfarming.com/qualitative-cost-delay/">Black Swan Farming</a></i>. (2016)Andyhttp://www.blogger.com/profile/04231681582044414408noreply@blogger.com0tag:blogger.com,1999:blog-21436926.post-11679687149006882862016-03-17T09:32:00.002+00:002016-04-15T18:14:27.426+01:00Kanban's Survivability Agenda and Antifragility<span style="background-color: white; color: #3f3f3f; font-family: "helvetica neue" , "helvetica" , "arial" , , "roboto"; font-size: 13px; line-height: 16.25px;">A conversation on the <a href="https://groups.yahoo.com/neo/groups/kanbandev/info"><b>kanbandev</b> </a>online forum has triggered this post. The discussion concerns how evolutionary change is applied, particularly when the <b><a href="https://en.wikipedia.org/wiki/Fitness_landscape">fitness landscape</a></b> is changing to such a degree that large rather than small steps are needed to survive in the new competitive environment. It got me thinking that </span><span style="background-color: white; color: #3f3f3f; font-family: "helvetica neue" , "helvetica" , "arial" , , "roboto"; font-size: 13px; line-height: 16.25px;">we must consider evolutionary change on more than one level if we want to address what the Kanban Method calls its <a href="https://www.linkedin.com/pulse/survivability-kanbans-purple-cow-david-anderson"><b>Survivability Agenda</b></a>.</span><br />
<div style="background-color: white; color: #3f3f3f; font-family: 'Helvetica Neue', Helvetica, Arial, san-serif, Roboto; font-size: 13px; line-height: 16.25px; margin: 0px; padding: 0px;">
<br /></div>
<div id="yui_3_15_0_1_1458202176278_2653" style="background-color: white; color: #3f3f3f; font-family: 'Helvetica Neue', Helvetica, Arial, san-serif, Roboto; font-size: 13px; line-height: 16.25px; margin: 0px; padding: 0px;">
<a href="https://t2.gstatic.com/images?q=tbn:ANd9GcTFZnUuQtkEsiCu2CVPAaOtXcSLO8VSYJ9zUmAQ2H0KotdzD9wt" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://t2.gstatic.com/images?q=tbn:ANd9GcTFZnUuQtkEsiCu2CVPAaOtXcSLO8VSYJ9zUmAQ2H0KotdzD9wt" height="200" width="133" /></a>The first mystery to consider is how evolution jumps across valleys in the fitness landscape. Seems to me there are 3 possibilities. You could make large leaps in what you think are promising directions. Doesn't sound a great idea because you're doing reasonably well as you are (different if you know you face an imminent existential threat, but it has the same likely outcome). You could wait for the peak you're climbing to decline in the fitness landscape, to the stage when small steps will move you off it. That's probably going to be too late. Or you rely on diversity. Your peak may be declining and you may - if trends continue - be doomed, but others are in better spaces and they will grow.</div>
<div id="yui_3_15_0_1_1458202176278_2653" style="background-color: white; color: #3f3f3f; font-family: 'Helvetica Neue', Helvetica, Arial, san-serif, Roboto; font-size: 13px; line-height: 16.25px; margin: 0px; padding: 0px;">
<br /></div>
<div id="yui_3_15_0_1_1458202176278_2640" style="background-color: white; color: #3f3f3f; font-family: 'Helvetica Neue', Helvetica, Arial, san-serif, Roboto; font-size: 13px; line-height: 16.25px; margin: 0px; padding: 0px;">
The final option sounds like disaster. But I think it is the way evolution works. Processes and technologies evolve much faster than biological organisms (see Eric Beinhocker's <i><a href="https://www.google.co.uk/imgres?imgurl=http://t2.gstatic.com/images%3Fq%3Dtbn:ANd9GcTFZnUuQtkEsiCu2CVPAaOtXcSLO8VSYJ9zUmAQ2H0KotdzD9wt&imgrefurl=http://books.google.com/books/about/The_Origin_of_Wealth.html%3Fid%3DeUoolrxSFy0C%26source%3Dkp_cover&h=691&w=460&tbnid=Im0ESO3FsqN4QM:&tbnh=160&tbnw=106&docid=CkQ_9Rjf04b_6M&itg=1&usg=__mkSAc1JO_WjDWlDF2i8TPECL0gE=">Origin of Wealth</a> </i>for more discussion of this) because the cycles of copying with differences, selection, amplification/damping are much shorter. Not only that, they are accelerating, which is what is now so threatening to large organisations. Does this mean large organizations must sit back and let the inevitable happen? Of course not. The key is to have multiple fragile parts, so the organization itself is more antifragile.</div>
<div style="background-color: white; color: #3f3f3f; font-family: 'Helvetica Neue', Helvetica, Arial, san-serif, Roboto; font-size: 13px; line-height: 16.25px; margin: 0px; padding: 0px;">
<br /></div>
<div style="background-color: white; color: #3f3f3f; font-family: 'Helvetica Neue', Helvetica, Arial, san-serif, Roboto; font-size: 13px; line-height: 16.25px; margin: 0px; padding: 0px;">
<a href="https://blogger.googleusercontent.com/img/proxy/AVvXsEhrNtVJ0NjrDbYwojCWac-d-TjVhEBgufJs6pBw_TAvsGzCyUjbHSr6gxCD90oVC4aXT1fJC0qm7eon5Ib9EdkpDx4VLbIC5uMac9X5FyorDa6CF4YBfJdNNyj2vUpOj0_wUoQ14KrL3IHa2MrpbfiqlTuUImDoatEcFhzyUnHSCPtxCKWi8xA_=" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" src="http://ecx.images-amazon.com/images/I/51ac-Gfrl-L._SX323_BO1,204,203,200_.jpg" height="200" style="background-color: transparent;" width="130" /></a>In <i>Antifragility </i>N N Taleb discusses how hierarchies can gain antifragility by allowing fragility within them. And also how natural antifragility can be irresponsibly eroded, if higher structures in the hierarchies (like governments) absorb the fragility of structures within them (like banks). Back to the Dinosaurs - they were antifragile as a species (genus? - I don't know; biologists please excuse) to most changes in the fitness landscape less than massive climate change. But since that was the limit of their antifragility they died out. But the higher level in the hierarchy (life on earth) survived (just) because there were some funny rat-like creatures running around scratching a living beneath the dinosaurs feet. They found themselves in the foothills of some pretty small peaks of the fitness landscape, and made the most of it.</div>
<div style="background-color: white; color: #3f3f3f; font-family: 'Helvetica Neue', Helvetica, Arial, san-serif, Roboto; font-size: 13px; line-height: 16.25px; margin: 0px; padding: 0px;">
<br /></div>
<div id="yui_3_15_0_1_1458202176278_2661" style="background-color: white; color: #3f3f3f; font-family: 'Helvetica Neue', Helvetica, Arial, san-serif, Roboto; font-size: 13px; line-height: 16.25px; margin: 0px; padding: 0px;">
So the levels in the hierarchy of Kanban (e.g. Personal, Team, Product, Portfolio) and its stress on the exploitation of real options, are keys to its "Survivability Agenda".* Portfolio management is key. It is where antifragility of the organisation can be built or lost. Portfolio Management must decide what level of investment different products and product ideas receive, and for how long before the return must be tangible. In a stable fitness landscape they might consider that the one successful product they have, should receive all the investment. This builds a monoculture which is vulnerable to shifts in the landscape. Keeping options has a cost but preserves the antifragility at the higher scale. Diversity <i>within </i>the organization and a culture which encourages innovation, learning and experimenting will build greater survivability. Note that in part this is because it tolerates and encourages more fragile technologies and processes within it. They are limited in their ability to survive - indeed they need to maintain the differences from more successful instances, precisely so that diversity is preserved. Eric Bienhocker has an excellent account of Microsoft's use of options when developing Windows. They also had teams investing in OS/2, Apple and Unix. Clearly it would not have been helpful if the Unix team say, thought the OS/2 option was better and started working on that instead of Unix.</div>
<div style="background-color: white; color: #3f3f3f; font-family: 'Helvetica Neue', Helvetica, Arial, san-serif, Roboto; font-size: 13px; line-height: 16.25px; margin: 0px; padding: 0px;">
<br /></div>
<div id="yui_3_15_0_1_1458202176278_2663" style="background-color: white; color: #3f3f3f; font-family: 'Helvetica Neue', Helvetica, Arial, san-serif, Roboto; font-size: 13px; line-height: 16.25px; margin: 0px; padding: 0px;">
In summary, I don't think Kanban provides any magic bullets here. Hopefully it exposes the issues in building resilient or antifragile organisations but it is down to the strategists, managers and leaders within these organisations as to how the tools and insights might be applied. Different groups make different choices. There is no recipe. That in my opinion why it remains one of the most interesting and important methods around.</div>
<div id="yui_3_15_0_1_1458202176278_2663" style="background-color: white; color: #3f3f3f; font-family: 'Helvetica Neue', Helvetica, Arial, san-serif, Roboto; font-size: 13px; line-height: 16.25px; margin: 0px; padding: 0px;">
<br /></div>
<div id="yui_3_15_0_1_1458202176278_2663" style="background-color: white; color: #3f3f3f; font-family: 'Helvetica Neue', Helvetica, Arial, san-serif, Roboto; font-size: 13px; line-height: 16.25px; margin: 0px; padding: 0px;">
* https://www.linkedin.com/pulse/survivability-kanbans-purple-cow-david-anderson</div>
<div>
<br /></div>
<!-- Blogger automated replacement: "https://images-blogger-opensocial.googleusercontent.com/gadgets/proxy?url=http%3A%2F%2Ft2.gstatic.com%2Fimages%3Fq%3Dtbn%3AANd9GcTFZnUuQtkEsiCu2CVPAaOtXcSLO8VSYJ9zUmAQ2H0KotdzD9wt&container=blogger&gadget=a&rewriteMime=image%2F*" with "https://t2.gstatic.com/images?q=tbn:ANd9GcTFZnUuQtkEsiCu2CVPAaOtXcSLO8VSYJ9zUmAQ2H0KotdzD9wt" --><!-- Blogger automated replacement: "https://images-blogger-opensocial.googleusercontent.com/gadgets/proxy?url=http%3A%2F%2Fecx.images-amazon.com%2Fimages%2FI%2F51ac-Gfrl-L._SX323_BO1%2C204%2C203%2C200_.jpg&container=blogger&gadget=a&rewriteMime=image%2F*" with "https://blogger.googleusercontent.com/img/proxy/AVvXsEhrNtVJ0NjrDbYwojCWac-d-TjVhEBgufJs6pBw_TAvsGzCyUjbHSr6gxCD90oVC4aXT1fJC0qm7eon5Ib9EdkpDx4VLbIC5uMac9X5FyorDa6CF4YBfJdNNyj2vUpOj0_wUoQ14KrL3IHa2MrpbfiqlTuUImDoatEcFhzyUnHSCPtxCKWi8xA_=" -->Andyhttp://www.blogger.com/profile/04231681582044414408noreply@blogger.com0tag:blogger.com,1999:blog-21436926.post-71273899078750457292015-08-05T14:36:00.003+01:002015-09-12T11:47:26.465+01:00What is Flow Debt?<a class="g-profile" href="https://plus.google.com/115697407714646375151" target="_blank">+Daniel Vacanti</a>'s excellent treatise on <i>Actionable Agile Metrics </i><span style="font-family: Courier New, Courier, monospace; font-size: x-small;">[vaca]</span> introduces a term that may be unfamiliar, even to those with an interest and experience in managing flow systems. The term is Flow Debt - for a definition and explanation read on.<br />
<br />
My own particular interest in flow systems is the management of agile software development teams, usually using some variant of Scrum and/or Kanban, and other agile practices such as test-driven (or automated-test intensive) build-test-deploy processes. However the discussion is relevant in many other domains, such as one I've recently been involved in discussing, the flow of patients through diagnosis, treatment and convalescence in healthcare systems.<br />
<br />
In managing these systems we need ways to look at the mass of data that emerges from them to focus on the useful information rather than the noise; information in particular that indicates when intervention is appropriate to improve flow, and when the attempt would be as futile as trying to smooth the waves on an ocean. Flow systems in knowledge work contain variability. That variability, within certain bounds (much wider bounds than in manufacturing for example), is desirable to allow innovation, responsiveness and minimising wasteful planning activities.<br />
<br />
In this context Flow Debt is a measure that provides a view of what is happening <i>inside </i>our system. This is in contrast with other important measures such as Throughput (Th) and the time an item stays in the process (I call this "Time in Process", TiP <span style="font-family: Courier New, Courier, monospace; font-size: x-small;">[macc]</span>, though <a href="http://xprocess.blogspot.co.uk/2013/07/whats-difference-between-cycle-time-and.html">other terms</a> may be used). These measures provide information only after items have left the system, which may be too late to avoid problems accumulating.<br />
<br />
Having Flow Debt roughly translates as: <b>delivering more quickly now at the cost of slower times later</b>. It is calculated by comparing the <i>time since the number of arrivals into the systems was equal to the current number of deliveries</i> with the <i>average time in the process </i>for the most recent deliveries. It is easiest to visualise this on a Cumulative Flow Diagram.<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh1GKvA29U2CoxT8mnN_fIbCxbrUY_-IoeNGYFqS7aeE5_6A1iN-LGOpBAQRY17KeJYrund8YpRl_y77imyKDSYJ93q_Yio4NauYBh2ERmps2v6y3aL9tenCe2rfhnZ1P6xoZiP/s1600/cfd.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="171" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh1GKvA29U2CoxT8mnN_fIbCxbrUY_-IoeNGYFqS7aeE5_6A1iN-LGOpBAQRY17KeJYrund8YpRl_y77imyKDSYJ93q_Yio4NauYBh2ERmps2v6y3aL9tenCe2rfhnZ1P6xoZiP/s400/cfd.JPG" width="400" /></a></div>
<div class="separator" style="clear: both; text-align: left;">
At the point highlighted in the the diagram it is a little over 2 weeks since the cumulative number of items entering the system equalled the cumulative number of deliveries on that date. If the items were delivered in the precise order they arrived, and if all the items were delivered (neither assumption is true!), then we would be able to say that the time the last item spent in the process was also a little over 2 weeks. Furthermore if arrivals and deliveries were smooth over the period, the Average Time in Process for the items would also be this same time.</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
What was the actual Average Time in Process though? Well you can't read this off the diagram. You have to look at the average TiP for the items delivered in the recent period. Each one has a known TiP, so take the average of them. Exactly how long the period you select for this average is up to you - a day or a week seems reasonable. The shorter the period you take the more noise there will be in the signal. Take too long a period though and there is insufficient time to act on the information. </div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
With this information we can calculate Flow Debt<i> </i>using Dan's method<span style="font-family: Courier New, Courier, monospace; font-size: x-small;">[vaca]</span>:</div>
<blockquote class="tr_bq" style="clear: both; text-align: left;">
<b>Flow Debt = (Time since number of arrivals equalled deliveries) - Average TiP</b></blockquote>
<div class="separator" style="clear: both; text-align: left;">
If you plot this quantity for the data above you get a graph like this. Note I've reversed the sign on this graph to show Flow <i>Debt </i>as negative.</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhW0mkBLhbms2SoySMawBlLq4WfVKTCZbONV3h5LFCEfyE9LTojnUAMotggPcbWXu70L2VM7sBSZJdzEK6qW_2y_t4SqHPT3KBHkZ_PgRewXdJ4XUZ0YLvs_L6Z4Q6KFQVgkOZd/s1600/flowDebt2.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="132" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhW0mkBLhbms2SoySMawBlLq4WfVKTCZbONV3h5LFCEfyE9LTojnUAMotggPcbWXu70L2VM7sBSZJdzEK6qW_2y_t4SqHPT3KBHkZ_PgRewXdJ4XUZ0YLvs_L6Z4Q6KFQVgkOZd/s400/flowDebt2.JPG" width="400" /></a></div>
<div class="separator" style="clear: both; text-align: left;">
The plot of Flow Debt in this case is quite normal showing a fluctuation around zero and maxima and minima of around the value of the average TiP for the whole period. If you plotted the same data with a monthly average, most of this fluctuation would disappear. I certainly wouldn't want managers rushing down to this team to radically change their process!</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
There is one point highlighted which is interesting, where the Flow Debt goes from highest debt to highest credit in a few days. What do you think is going on here? Well, if you go back to the informal definition of Flow Debt (delivering more quickly now at the cost of slower times later), we should surmise that before this point the delivered items had been in the process for only a short time. Those delivered at or after this point had a longer time in the process. That's exactly what happened, as the Control Chart below shows.</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgg3R5y0Jzk4AGG0em2Xue-P8rDaIr8VjNd31xfiXh2o739kCvc0noBgPATFKxBXmHeS6NLULhs5Vf6J9iY8pPk-LQT_eTiM9zjdO7R9CMoyVWoXSnXh4uXynTdp6kl5aFzM2lx/s1600/control.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="213" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgg3R5y0Jzk4AGG0em2Xue-P8rDaIr8VjNd31xfiXh2o739kCvc0noBgPATFKxBXmHeS6NLULhs5Vf6J9iY8pPk-LQT_eTiM9zjdO7R9CMoyVWoXSnXh4uXynTdp6kl5aFzM2lx/s400/control.JPG" width="400" /></a></div>
<div class="separator" style="clear: both; text-align: left;">
Another useful indicator here is the "average age" of the work in progress. Here is the plot of that and you can see the significant drop in this metric at the same point.</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgsjhoXyx_lOA2bD7dhGc7U5hk6p-KBkG5zJ44dQ6Ed3Ht3Uqw12gm3G-FxOa9o7DVK9aAjNMqjor71Z1b0M7-QyQT00ulGkLje_YifPKEy2CSOeJtsclvSHftV73oqsRNIwfkh/s1600/aawip.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="112" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgsjhoXyx_lOA2bD7dhGc7U5hk6p-KBkG5zJ44dQ6Ed3Ht3Uqw12gm3G-FxOa9o7DVK9aAjNMqjor71Z1b0M7-QyQT00ulGkLje_YifPKEy2CSOeJtsclvSHftV73oqsRNIwfkh/s400/aawip.JPG" width="400" /></a></div>
<div class="separator" style="clear: both; text-align: left;">
Just by way of balance let's look at another data set of a team delivering software much less frequently, where their work in progress is increasing over the process, and where the items are not being delivered in age order. All these factors are likely to effect the efficiency and predictability of the flow system... and this is borne out by their plot of Flow Debt.</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhOMIE2OW4pjM8ng2gYN-oAK64T40PN_nUGTAjh0-xAAk8iAsnWLELJTUtOSCZa9-ZvW042FAw-9mQkz9WVa3fJAhsIGb6x_ZXLBJf9rZV6bKq8Hv-qQwTmBD5fhP4_aaISy5tR/s1600/flowDebt3.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="146" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhOMIE2OW4pjM8ng2gYN-oAK64T40PN_nUGTAjh0-xAAk8iAsnWLELJTUtOSCZa9-ZvW042FAw-9mQkz9WVa3fJAhsIGb6x_ZXLBJf9rZV6bKq8Hv-qQwTmBD5fhP4_aaISy5tR/s400/flowDebt3.JPG" width="400" /></a></div>
<div class="separator" style="clear: both; text-align: left;">
Seeing a plot like this is a indication to management (and flow management specialists in particular) to take a much closer look at the process being used here.</div>
<div class="separator" style="clear: both; text-align: left;">
<span style="background-color: white; color: #222222; font-family: Arial, Helvetica, sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;"><i><u><b><br /></b></u></i></span></div>
<div class="separator" style="clear: both; text-align: left;">
<span style="background-color: white; color: #222222; font-family: Arial, Helvetica, sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;"><i><u><b>References</b></u></i></span></div>
<ul style="background-color: white; color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px; margin: 0.5em 0px; padding: 0px 2.5em;">
<li style="margin: 0px 0px 0.25em; padding: 0px;"><span style="font-family: 'Courier New', Courier, monospace; font-size: 13.1999998092651px; line-height: 18.4799995422363px;">[</span><span style="font-family: 'Courier New', Courier, monospace; font-size: 13.1999998092651px; line-height: 18.4799995422363px;">macc] </span><span style="font-size: 13.1999998092651px; line-height: 18.4799995422363px;">Maccherone, Larry.<i> <a href="http://maccherone.com/publications/LSSC2012-IntroducingtheTimeInStateInSITeChart.pdf" style="color: #888888; text-decoration: none;">Introducing the Time In State InSITe Chart</a></i>. LSSC. (2012)</span></li>
<li style="margin: 0px 0px 0.25em; padding: 0px;"><span style="font-family: 'Courier New', Courier, monospace; font-size: 13.1999998092651px; line-height: 18.4799995422363px;">[vaca] </span><span style="font-size: 13.1999998092651px; line-height: 18.4799995422363px;">Vacanti, Daniel S. <i>Actionable Agile Metrics for Predictability: An Introduction</i>,<i> </i>LeanPub. (2015)</span></li>
</ul>
Andyhttp://www.blogger.com/profile/04231681582044414408noreply@blogger.com0tag:blogger.com,1999:blog-21436926.post-11851555485175207322015-07-29T17:54:00.000+01:002015-09-12T13:58:18.788+01:00Beyond Control Charts and Cumulative Flow Diagrams<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhc90m7EeGP-gPpF8n32yse4hn3qSUsWtLPWLDXf-F1pXqO1llfJHBN5kcIMlq9txKWMxng-tKq2cYppsp0p3QU7ME0x7VEOda5Hqo6BZFZ24KZ3Sg8H_fxQADiq9qHiboUUG_-/s1600/metrics.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="640" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhc90m7EeGP-gPpF8n32yse4hn3qSUsWtLPWLDXf-F1pXqO1llfJHBN5kcIMlq9txKWMxng-tKq2cYppsp0p3QU7ME0x7VEOda5Hqo6BZFZ24KZ3Sg8H_fxQADiq9qHiboUUG_-/s640/metrics.jpg" width="205" /></a></div>
Control Charts (CCs) and Cumulative Flow Diagrams (CFDs) are powerful ways to display information about a flow system, such as a Scrum or Kanban development process. Unfortunately the very fact that the charts display so <i>much </i>information means that it is often difficult to extract <i>specific </i>information from them. That is why it's useful to also plot some of the key attributes of the systems on their own - this allows us to look at these aspects specifically, alongside the rawer view of the data that you get from CCs and CFDs.<br />
<br />
The graphic on the right shows a number of diagrams all of which were derived from very simple data about each item that flowed through this system:<br />
<ul>
<li><b>when it arrived</b> into the system; </li>
<li><b>when it departed</b> the system; and</li>
<li><b>whether the item was "delivered"</b> or "discarded".</li>
</ul>
<blockquote class="tr_bq">
<span style="font-size: x-small;"><b>Note: </b>I use the term "discard" here as a general term to include an exit from the system at any point in the system and for any reason. It includes aborting/abandoning the item after <i>commitment</i>, as well as postponing the item by moving it back to a part of the process upstream from the system under study. For the definition of this and other terms used here please see this <a href="http://xprocess.blogspot.co.uk/2015/05/glossary-proposal.html">Glossary</a>.</span></blockquote>
<div>
The first diagrams in the graphic is the Control Chart - actually this is simply a scatter plot of the <i>time each item stays in the system</i> under study. I refer to this as "Time in Process - TiP - or alternatively "Time in _______" where the blank stands for whatever the process or part of the process is under study. For example it could be the Time in Preparation, Time in Development, Time in Acceptance, etc. The scatter plot highlights (in orange) the items which were not "delivered".</div>
<div>
<br /></div>
<div>
Below it is the CFD. Unlike some very stripy versions, this one has only 3 bands (as limited by the input data), corresponding to arrivals, all departures (including discards), and deliveries.</div>
<div>
<br /></div>
<div>
The remaining diagrams all highlight one or more aspects of the same data. Firstly the terms from Little's Law:</div>
<div>
<ol>
<li><b>Average Delivery Rate</b>. This is measured in <i>items per week</i>, and the average is taken over 1 week. Note this only shows actually <i>delivered </i>items. Alternatively a plot of "Throughput" could have been used which includes all items that have passed through the system.</li>
<li><b>Average Time in Process (TiP)</b>. This is measured in <i>weeks</i> and again the average is taken over 1 week.</li>
<li><b>Average Work in Progress (WiP)</b>. This is measured in <i>number of items</i>, again averaged over one week. Care must be taken when calculating average WiP for a day, particularly on days when an item arrives in or departs from the system, to ensure that it is consistent with the calculations of average TiP.</li>
</ol>
In addition to these standard quantities from Little's Law a number of flow balance metrics are shown. These are:</div>
<div>
<ol start="4">
<li><b>Net Flow</b>. Simply the difference between the number arriving and departing over the previous <i>week</i>.</li>
<li><b>Delivery Bias</b>. This is a measure of the degree to which Delivery Rate is higher or lower than would be predicted by Little's Law for the given period (1 week in this case). If it is non-zero it indicates away from stability. Further discussion of this quantity is found <a href="http://xprocess.blogspot.co.uk/2015/07/littles-inequality.html">here</a>.</li>
<li><b>Flow Debt/Credit</b>. This is a measure of the degree to which the average TiP varies from that predicted by the CFD. This also indicates a degree of instability if it varies significantly from zero. See Dan Vacanti's book <i>[vaca]</i> for further discussion.</li>
<li><b>Age of WiP Indicator</b>. This compares the average age of the WiP with half the average Tip. It is another indicator of imbalance.</li>
</ol>
<div>
Recently I have been discussing these four quantities with colleagues and with Troy Magennis and Dan Vacanti as they show promise for predicting significant changes in the TiP, a very important aspect of the effectiveness of the system.</div>
</div>
<div>
<br /></div>
<div>
A spreadsheet containing the means to generate these diagrams from your data will shortly be made available from gitHub. Watch this space!</div>
<div>
<br /></div>
<div>
<b style="background-color: white; color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;">References</b><br />
<ul style="background-color: white; color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px; margin: 0.5em 0px; padding: 0px 2.5em;">
<li style="margin: 0px 0px 0.25em; padding: 0px;"><span style="font-family: 'Courier New', Courier, monospace; font-size: 13.1999998092651px; line-height: 18.4799995422363px;">[vaca]</span><span style="font-size: 13.1999998092651px; line-height: 18.4799995422363px;"> Vacanti, Daniel S. "Actionable Agile Metrics for Predictability: An Introduction". LeanPub. (2015)</span></li>
</ul>
</div>
Andyhttp://www.blogger.com/profile/04231681582044414408noreply@blogger.com0tag:blogger.com,1999:blog-21436926.post-42795135656799622442015-07-17T12:40:00.001+01:002015-07-17T15:14:30.673+01:00Postscript on Throughput and Delivery RateMost people use <b>Throughput </b>and <b>Delivery Rate</b> in Kanban systems as synonyms - including myself up to this point. I've changed my view however.<br />
<br />
The canonical form of Little's Law in Kanban is as follows:<br />
<blockquote class="tr_bq">
<span style="background-color: white; color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;"><span style="font-family: Arial, Helvetica, sans-serif;"><span style="font-weight: bold; text-decoration: overline;">Delivery Rate</span><b> = </b><span style="font-weight: bold; text-decoration: overline;">WiP</span><b> / </b><span style="text-decoration: overline;"><b>Lead Time</b></span></span></span><i> [ande]</i> </blockquote>
even though these days I more frequently express it this way:<br />
<blockquote class="tr_bq">
<b style="background-color: white; color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;"><span style="font-family: Arial, Helvetica, sans-serif;"><span style="text-decoration: overline;">Throughput</span> = <span style="text-decoration: overline;">WiP</span> / <span style="text-decoration: overline;">TiP</span></span></b> </blockquote>
Surely these two ways of writing the equation are entirely equivalent aren't they? Well maybe not.<br />
<blockquote class="tr_bq">
<span style="font-size: x-small;"><b>Note: </b>All these terms are defined in my <i style="font-weight: bold;"><a href="http://xprocess.blogspot.co.uk/2015/05/glossary-proposal.html">Glossary Proposal</a></i> (which has recently been updated to include the definition of Throughput). Feedback, comments and references to publications using the terms defined are welcomed and encouraged.</span></blockquote>
Throughput is the term <a class="g-profile" href="https://plus.google.com/115697407714646375151" target="_blank">+Daniel Vacanti</a> uses (among many others), particularly in his excellent new book <i>Actionable Agile Metrics [vaca]</i>, and it got me thinking about one of the problems with using Delivery Rate: what about the items which are <i>not </i>delivered but are discarded? If there are a significant number of these Little's Law as expressed in the first equation will not apply, unless we exclude discarded items from calculations of the historical averages for WiP and TiP. All very well except the WiP limits - a crucial control for Kanban systems necessarily contain items that may be discarded in the future.<br />
<br />
Without trying to solve this problem, but rather clarify the terminology we use to describe it, I think it is useful to have differing definitions for the 2 terms:<br />
<blockquote class="tr_bq">
<b>Delivery Rate</b> is the rate at which work items exit the system in a "complete" state (i.e. just <i>delivered</i> items)</blockquote>
<blockquote>
<b>Throughput </b>is the rate at which work items exit the system whether discarded (this includes those which move <i>back</i> in the process to a state prior to the system under consideration) or completed (i.e. both <i>delivered </i>and <i>discarded</i> items)</blockquote>
Let me know if you find this distinction useful. Your feedback is essential in honing the <i style="font-weight: bold;"><a href="http://xprocess.blogspot.co.uk/2015/05/glossary-proposal.html">Glossary Proposal</a></i> to one that everyone finds helpful and acceptable.<br />
<br />
<h3>
<b style="background-color: white; color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;">References</b></h3>
<ul style="background-color: white; color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px; margin: 0.5em 0px; padding: 0px 2.5em;">
<li style="margin: 0px 0px 0.25em; padding: 0px;"><span style="font-family: Arial, Helvetica, sans-serif;"><span style="font-family: 'Courier New', Courier, monospace; font-size: 13.1999998092651px; line-height: 18.4799995422363px;">[ande] </span></span><span style="font-size: 13.1999998092651px; line-height: 18.4799995422363px;"><span style="font-size: 13.1999998092651px; line-height: 18.4799995422363px;">Anderson, <span style="font-size: 13.1999998092651px; line-height: 18.4799995422363px;">David J.</span> </span><i>Kanban</i>, Blue Hole Press. (2010)</span></li>
<li style="margin: 0px 0px 0.25em; padding: 0px;"><span style="font-family: 'Courier New', Courier, monospace; font-size: 13.1999998092651px; line-height: 18.4799995422363px;">[vaca]</span><span style="font-size: 13.1999998092651px; line-height: 18.4799995422363px;"> Vacanti, Daniel S. "Actionable Agile Metrics for Predictability: An Introduction". LeanPub. (2015)</span></li>
</ul>
Andyhttp://www.blogger.com/profile/04231681582044414408noreply@blogger.com0tag:blogger.com,1999:blog-21436926.post-5761638270481488272015-07-16T16:32:00.002+01:002015-08-04T12:38:19.438+01:00Little's InequalityThe interesting thing about Little's Law, in spite of its very general applicability, and in certain cases mathematical certainty, there are many cases when it simply does not hold true. In those cases it's not so much Little's <i>Law</i> as Little's <i>Inequality</i>. Could the fact that specific instances of data do not follow Little's Law actually give us useful information about our Kanban and Scrum systems and point to the right kind of interventions to manage and improve their flow? That's what this blog is about.<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgOEKYGWJvCrLehAWYh4W3dt_zVNPa0x2T52mvj4tOGlbfWGuqEREX9zNWNWtr9vnqbOyBeu-ZeQ-0s1PgzYCHM0i2tqQYVujUUVGA8veR9zSLdoEZON-JSRvLbxoFyXDykBui-/s1600/LittlesInequality.JPG" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="400" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgOEKYGWJvCrLehAWYh4W3dt_zVNPa0x2T52mvj4tOGlbfWGuqEREX9zNWNWtr9vnqbOyBeu-ZeQ-0s1PgzYCHM0i2tqQYVujUUVGA8veR9zSLdoEZON-JSRvLbxoFyXDykBui-/s400/LittlesInequality.JPG" width="368" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;"><b style="font-size: 12.8000001907349px;">Flow Metrics for a Kanban System over time<br />(WiP, TiP, DR, <i>Delivery Bias</i>, Net Flow)</b></td></tr>
</tbody></table>
<div class="separator" style="clear: both; text-align: center;">
</div>
<br />
In 1961 John Little published his proof of this general queuing theory equation [<span style="font-family: Courier New, Courier, monospace;">litt</span>]:<br />
<blockquote class="tr_bq">
<b><span style="font-family: Arial, sans-serif; font-size: 11pt; line-height: 107%;">L=</span><span style="font-family: Arial, sans-serif; font-size: 11pt; line-height: 107%;">λ</span><span style="font-family: Arial, sans-serif; font-size: 11pt; line-height: 107%;">W</span></b> </blockquote>
<blockquote class="tr_bq">
<span style="font-size: x-small;">L is the average number of items in the queue, </span><span style="font-family: Arial, sans-serif; font-size: x-small; line-height: 107%;">λ</span><span style="font-size: x-small;"> is the average arrival rate, and W the average wait time</span></blockquote>
Since that time Little's Law has found numerous applications in the study of general flow systems from telecommunications to manufacturing, including in Kanban systems. Because throughput or delivery rate is the more significant attribute for management of such systems (and <i>on average</i> it is approximately equal to arrival rate), it is often expressed as follows:<br />
<blockquote class="tr_bq">
<b style="background-color: white; color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;"><span style="font-family: Arial, Helvetica, sans-serif;"><span style="text-decoration: overline;">Delivery Rate</span> = <span style="text-decoration: overline;">WiP</span> / <span style="text-decoration: overline;">TiP</span></span></b> </blockquote>
<blockquote class="tr_bq">
<span style="background-color: white; color: #222222; font-family: Arial, Helvetica, sans-serif; font-size: xx-small; line-height: 14px;">The overline indicates the arithmetic mean, WiP is the number of items in the system, and TiP the "time in process" from entering to leaving the system under consideration. See this <a href="http://xprocess.blogspot.co.uk/2015/05/glossary-proposal.html">Glossary</a> for further explanation of the meaning of TiP, versus Lead Time or Cycle Time (and why I don't use Cycle Time!).</span></blockquote>
However when we look at data from actual Kanban systems, where the averages are over relatively short periods (say a week or a month), or where average arrival rate does not equal average delivery rate, it is Little's <i>Inequality </i>that applies, not his Law. Juggling the terms above we can express it in this way:<br />
<blockquote class="tr_bq">
<b style="background-color: white; color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;"><span style="font-family: Arial, Helvetica, sans-serif;"><span style="text-decoration: overline;">Delivery Rate</span> </span></b><span style="font-family: Arial, sans-serif; font-size: 14.6666669845581px; line-height: 15.6933336257935px;">–</span><b style="background-color: white; color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;"><span style="font-family: Arial, Helvetica, sans-serif;"> ( <span style="text-decoration: overline;">WiP</span> / <span style="text-decoration: overline;">TiP</span> ) </span></b><span style="font-family: Arial, sans-serif; font-size: 11pt; line-height: 15.6933336257935px;"><b>≠</b> </span><span style="background-color: white; color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;"><span style="font-family: Arial, Helvetica, sans-serif;"><b>0 </b><i>("Little's Inequality")</i></span></span></blockquote>
This is because if the system itself is trending in some way (technically the system is not <i>stationary</i>), or if the scope of the averages is not so wide that every item that entered has left the system - usually both these conditions are true for the periods we wish to analyse - then Little's Law does not apply exactly.<br />
<br />
That might seem to imply Little's Law is not useful to us. However the degree to which the law is not true is very relevant and does give us important management information:<br />
<blockquote class="tr_bq">
<b style="background-color: white; color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;"><span style="font-family: Arial, Helvetica, sans-serif;"><span style="text-decoration: overline;">Delivery Rate</span> </span></b><span style="font-family: Arial, sans-serif; font-size: 14.6666669845581px; line-height: 15.6933336257935px;">–</span><b style="background-color: white; color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;"><span style="font-family: Arial, Helvetica, sans-serif;"> ( <span style="text-decoration: overline;">WiP</span> / <span style="text-decoration: overline;">TiP</span> ) <</span></b><span style="font-family: Arial, sans-serif; font-size: 11pt; line-height: 15.6933336257935px;"> </span><span style="background-color: white; color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;"><span style="font-family: Arial, Helvetica, sans-serif;"><b>0</b> <i>More work is being taken on than is being delivered</i></span></span></blockquote>
<blockquote class="tr_bq">
<b style="background-color: white; color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;"><span style="font-family: Arial, Helvetica, sans-serif;"><span style="text-decoration: overline;">Delivery Rate</span> </span></b><span style="font-family: Arial, sans-serif; font-size: 14.6666669845581px; line-height: 15.6933336257935px;">–</span><b style="background-color: white; color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;"><span style="font-family: Arial, Helvetica, sans-serif;"> ( <span style="text-decoration: overline;">WiP</span> / <span style="text-decoration: overline;">TiP</span> ) </span></b><span style="font-family: Arial, sans-serif; font-size: 11pt; line-height: 15.6933336257935px;"><b>=</b> </span><span style="background-color: white; color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;"><span style="font-family: Arial, Helvetica, sans-serif;"><b>0 </b><i>The system is balanced</i></span></span></blockquote>
<blockquote class="tr_bq">
<b style="background-color: white; color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;"><span style="font-family: Arial, Helvetica, sans-serif;"><span style="text-decoration: overline;">Delivery Rate</span> </span></b><span style="font-family: Arial, sans-serif; font-size: 14.6666669845581px; line-height: 15.6933336257935px;">–</span><b style="background-color: white; color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;"><span style="font-family: Arial, Helvetica, sans-serif;"> ( <span style="text-decoration: overline;">WiP</span> / <span style="text-decoration: overline;">TiP</span> ) </span></b><span style="font-family: Arial, sans-serif; font-size: 11pt; line-height: 15.6933336257935px;"><b>></b> </span><span style="background-color: white; color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;"><span style="font-family: Arial, Helvetica, sans-serif;"><b>0 </b><i>More is being delivered than new work being taken on</i></span></span></blockquote>
<div class="separator" style="clear: both; text-align: center;">
</div>
This looks like actionable data for managing flow in Kanban Systems - a number that shows bias in the system towards (or away from) delivering. Let's look at the set of graphs in the figure above that demonstrate this. The data set is from <a class="g-profile" href="https://plus.google.com/109077487035516407422" target="_blank">+Troy Magennis</a>'s <a href="http://bit.ly/SimResources">SimResources</a> website and uses his data, spreadsheet and some of the graphs he provides to assist with his forecasting models<span style="font-family: Courier New, Courier, monospace;">[mage]</span>. You can find more about Troy's work at <a href="http://focusedobjective.com/">FocusedObjective.com</a> and also download these spreadsheets to explore what your data reveals about your Kanban or Scrum systems.<br />
<br />
Firstly the figure shows graphs of the 3 main variables in Little's Law: WiP, TiP and Delivery Rate, The next graph is a plot of <i>Little's Inequality</i> - labelled <b><i>Delivery Bias</i></b>, showing whether it is greater or less than zero at any point in time. Note that the formula above is normalised relative to the overall average delivery rate for the whole dataset (AvDR) so that the range (in this case between -1 and +1) is comparable with other datasets. The final graph in the set shows <i>Net Flow</i>, the difference between items completed and started - it is one of the metrics included in Troy's spreadsheet and it again provides a view of how balanced the system is.<br />
<br />
<div class="separator" style="clear: both; text-align: left;">
As expected the graphs show a strong correlation between Net Flow and Little's Inequality for most of the range. Clearly if we're starting more than we're finishing we should expect both the inequality and the Net Flow to be negative. What's interesting is where they don't correspond, and why. Look at weeks 2015-11 and 2015-12. Why in week 11 are we finishing more than starting and yet we still have a negative value for Little's Inequality? The clue is in the TiP for these weeks. In week 11 the average TiP is much lower than in week 12. Perhaps this indicates the items closed that week were smaller in size - or maybe they were "expedited" at the expense of other items in progress. When the items that had been in process longer are closed the following week, Little's Inequality indicates more strongly that balance is being restored.</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
Little's Inequality as expressed above focuses on Delivery Rate, hence the label Delivery Bias. It could be re-expressed to focus on Time In Process as follows:</div>
<blockquote class="tr_bq" style="clear: both; text-align: left;">
<b style="background-color: white; color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;"><span style="font-family: Arial, Helvetica, sans-serif;"><span style="text-decoration: overline;">TiP</span> </span></b><span style="background-color: white; color: #222222; font-family: Arial, sans-serif; font-size: 14.6666669845581px; line-height: 15.6933336257935px;">–</span><b style="background-color: white; color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;"><span style="font-family: Arial, Helvetica, sans-serif;"> </span></b><b style="background-color: white; color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;"><span style="font-family: Arial, Helvetica, sans-serif;"><span style="text-decoration: overline;">WiP</span> / </span></b><b style="background-color: white; color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;"><span style="font-family: Arial, Helvetica, sans-serif;"><span style="text-decoration: overline;">Delivery Rate</span> </span></b><span style="background-color: white; color: #222222; font-family: Arial, sans-serif; font-size: 11pt; line-height: 15.6933336257935px;"><b>≠</b> </span><span style="background-color: white; color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;"><span style="font-family: Arial, Helvetica, sans-serif;"><b>0 </b></span></span><b style="background-color: white; color: #222222; font-family: Arial, Helvetica, sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;"> </b></blockquote>
<div class="separator" style="clear: both; text-align: left;">
This metric might be labelled <i>Time in Process Bias. </i>We want TiP values to be as low as possible, but a negative value of this metric is likely to indicate an issue to address, since it would indicate that the TiP of the work in progress is likely to be longer than the items recently delivered.</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
The time an item stays in the process is also the focus of a new metric from <a class="g-profile" href="https://plus.google.com/115697407714646375151" target="_blank">+Daniel Vacanti</a> recently published in his <i>Actionable Agile Metrics</i> <span style="font-family: 'Courier New', Courier, monospace;">[vaca]</span> (see also <a href="http://actionableagile.com/">ActionableAgile.com</a>). He also looks at the degree to which a given system follows an ideal flow through a metric he calls "Flow Debt" (roughly translated as delivering more quickly <i>now </i>at the cost of slower times <i>later</i>). Dan prefers the term Cycle Time to Time In Process and so defines Flow Debt as the difference between the "Approximate Average Cycle Time" (AACT) as observed on a Cumulative Flow Diagram and the "Average Cycle Time" (ACT). Comparing these 2 items gives an idea of whether Flow Debt is being created or not. Flow Debt is accumulating when AACT>ACT. You can calculate AACT by looking at the time since the cumulative arrivals into the system equalled the current cumulative deliveries. ACT is calculated from the arithmetic mean of the actual times for delivered items in the period. Again the degree to which these quantities do not match indicates the degree to which the system is out of balance.</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
All these metrics - Little's Inequality (or Delivery Bias), Net Flow and Flow Debt - provide insight into the behaviour of Kanban systems based on the degree to which the system follows Little's Law over the period of study. Further experimentation and experience will show the best ways to use them in concert and the best ways to visualise the flow characteristics of the systems and how to intervene to improve them.</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
If you have data which you would like to analyse using these metrics do let me know. I'm happy to share spreadsheets and advice with anyone who contacts me. Equally check out Troy Magennis's and Dan Vacanti's web sites referenced above for more tools and insights.</div>
<br />
<b>References</b><br />
<ul>
<li><span style="font-family: Courier New, Courier, monospace;">[litt]</span> Little, J. D. C. "A Proof of the Queuing Formula: L = <span style="font-family: "Arial",sans-serif; font-size: 11.0pt; line-height: 107%; mso-ansi-language: EN-GB; mso-bidi-language: AR-SA; mso-fareast-font-family: Calibri; mso-fareast-language: EN-US; mso-fareast-theme-font: minor-latin;">λ</span>W," Operations Research, 9, (3) 383-387. (1961) </li>
<li><span style="font-family: Courier New, Courier, monospace;">[mage]</span> Magennis, T. "Forecasting and Simulating Software Development Projects: Effective Modeling of Kanban & Scrum Projects using Monte-carlo Simulation", FocusedObjective.com. (2011)</li>
<li><span style="font-family: Courier New, Courier, monospace;">[vaca]</span> Vacanti, Daniel S. "Actionable Agile Metrics for Predictability: An Introduction". LeanPub. (2015)</li>
</ul>
Andyhttp://www.blogger.com/profile/04231681582044414408noreply@blogger.com0tag:blogger.com,1999:blog-21436926.post-72988285684499636512015-05-27T15:39:00.001+01:002016-04-15T18:11:58.792+01:00Glossary Proposal<div style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhZLbvjG-7LHk3VCtLx3ZzwpuWR2SPfzt0Jp25cdDvVi53Z-YM6O4SZDhdKhnStz7qFdoFJ_U6cntKMGg3Nq37VlJMcbCXHfwICpJvmp2tZjPAIeAC8-xEg199rrwCJvkCh4-rV/s1600/glossary.PNG" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><span style="font-family: "arial" , "helvetica" , sans-serif;"><br /></span></a><span style="font-family: "arial" , "helvetica" , sans-serif;">One of the problems Kanban practitioners have faced over the past several years is the lack of agreement of the terminology to use to describe flow systems. This in turn has led to confusion in both those learning the method and those implementing tools to support it. This blog has made a few previous attempts to disambiguate common terms (see discussions of <a href="http://xprocess.blogspot.co.uk/search/label/Cycle%20Time">Cycle Time</a> for example). Mike Burrow's <a href="http://edu.leankanban.com/kanban-glossary-terms">Glossary of Terms</a>, <i>[burr]</i> reproduced on the Lean Kanban University site <i>[lkun]</i> is also very useful, though it does not give guidance on wh</span><span style="font-family: "arial" , "helvetica" , sans-serif;">ich terms to use when applying Little's Law to sub-processes in a more complex Kanban system. </span></div>
<div style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;">
<span style="font-family: "arial" , "helvetica" , sans-serif;">This article is another foray into this minefield and is principally a proposal for the definitions of commonly used terms relating to Little's Law, particularly seeking terms applicable in complex flow systems and sub-processes within such systems. It is an invitation to others in the community to endorse these definitions, or propose alternatives. Let's not go another seven years with this unresolved!</span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><br /></span>
<span style="font-family: "arial" , "helvetica" , sans-serif;"><i>Note: </i>This is a work in progress and will be updated from time to time in response to feedback from other authors and practitioners.</span></div>
<span style="font-family: "arial" , "helvetica" , sans-serif;"><br /></span>
<span style="font-family: "arial" , "helvetica" , sans-serif;"><br /></span>
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhZLbvjG-7LHk3VCtLx3ZzwpuWR2SPfzt0Jp25cdDvVi53Z-YM6O4SZDhdKhnStz7qFdoFJ_U6cntKMGg3Nq37VlJMcbCXHfwICpJvmp2tZjPAIeAC8-xEg199rrwCJvkCh4-rV/s1600/glossary.PNG" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><span style="font-family: "arial" , "helvetica" , sans-serif;"><img border="0" height="105" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhZLbvjG-7LHk3VCtLx3ZzwpuWR2SPfzt0Jp25cdDvVi53Z-YM6O4SZDhdKhnStz7qFdoFJ_U6cntKMGg3Nq37VlJMcbCXHfwICpJvmp2tZjPAIeAC8-xEg199rrwCJvkCh4-rV/s200/glossary.PNG" width="200" /></span></a><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhZLbvjG-7LHk3VCtLx3ZzwpuWR2SPfzt0Jp25cdDvVi53Z-YM6O4SZDhdKhnStz7qFdoFJ_U6cntKMGg3Nq37VlJMcbCXHfwICpJvmp2tZjPAIeAC8-xEg199rrwCJvkCh4-rV/s1600/glossary.PNG" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><span style="font-family: "arial" , "helvetica" , sans-serif;"><br /></span></a><span style="font-family: "arial" , "helvetica" , sans-serif;">The Kanban Method is a process improvement approach based on understanding knowledge work as a flow system. The life cycles of the "work items" in such flow systems are analysed and improvements to the process are made based on observable positive change. So let's start with Little's Law since it is the first basis of understanding flow systems. For a given system it may be defined as follows <i>[litt]</i>:</span><br />
<blockquote class="tr_bq">
<span style="font-family: "arial" , "helvetica" , sans-serif;"><b><span style="text-decoration: overline;">Arrival Rate</span> = <span style="text-decoration: overline;">WiP</span> / <span style="text-decoration: overline;">TiP</span></b> </span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif; font-size: x-small;">where the overline indicates the arithmetic mean in a "<a href="http://en.wikipedia.org/wiki/Stationary_process">stationary</a>" or other compliant system.</span></blockquote>
<b><span style="font-family: "arial" , "helvetica" , sans-serif;">Arrival Rate</span></b><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><i>Measured in</i>: work items per unit of time (seconds, hours, days. working days, etc.)</span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><i>Definition</i>: The number of units entering the system per unit of time. The work item must be defined for the metric to be meaningful (e.g whether a User Story, Feature, Case, Initiative, Physical Item, Episode, Request, etc.). Little uses <b>Arrival Rate </b>in his definition of the law. In a "compliant" system the average rate of items arriving in the system and leaving it must be equal:</span><br />
<blockquote class="tr_bq">
<b style="font-family: Arial, Helvetica, sans-serif;"><span style="text-decoration: overline;">Arrival Rate</span> = <span style="text-decoration: overline;">Throughput</span></b><b style="font-family: Arial, Helvetica, sans-serif;"> </b></blockquote>
<span style="font-family: "arial" , "helvetica" , sans-serif;">Throughput and Delivery Rate are usually treated as synonyms in Kanban systems. However if a distinction is made between delivered and discarded items (essential if we are to understand productivity effectively), a distinction should also be made between these terms. Since items may be either delivered or discarded:</span><br />
<blockquote class="tr_bq">
<span style="font-family: "arial" , "helvetica" , sans-serif;"><b><span style="text-decoration: overline;">Throughput</span> = <span style="text-decoration: overline;">Delivery Rate</span> + <span style="text-decoration: overline;">Discard Rate</span></b><b> </b></span></blockquote>
<span style="font-family: "arial" , "helvetica" , sans-serif;">If the <b>Discard Rate</b> is not significant or we exclude discarded items, we can use the common formulation of Little's Law found in Kanban system analysis:</span><br />
<blockquote class="tr_bq">
<b><span style="font-family: "arial" , "helvetica" , sans-serif;"><span style="text-decoration: overline;">Delivery Rate</span> = <span style="text-decoration: overline;">WiP</span> / <span style="text-decoration: overline;">TiP</span></span></b></blockquote>
<span style="font-family: "arial" , "helvetica" , sans-serif;">If the <b>Discard Rate </b><i>is </i>significant, the historical values of <b>WiP </b>should include only those items that have been <i>delivered </i>and <b>TiP </b>should be the time in process for <i>delivered </i>items only, not discarded ones. (Alternatively use <b>Throughput</b> and ensure that the time in process for discarded items <i>is </i>included.)</span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><i>Related terms</i>: <b>Throughput, Delivery Rate</b>, <b>Discard Rate</b>, <b>Discard</b>, <b>Abort</b></span><br />
<i style="font-family: Arial, Helvetica, sans-serif;">References: </i><i><span style="font-family: "arial" , "helvetica" , sans-serif;">[</span><span style="font-family: "arial" , "helvetica" , sans-serif;">ande], [burr], [litt], [vaca]</span></i><br />
<div>
<span style="font-family: "arial" , "helvetica" , sans-serif;"><br /></span>
<span style="font-family: "arial" , "helvetica" , sans-serif;"><b>Throughput</b></span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><i>Measured in</i>: work items per unit of time</span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><i>Alternatives</i>: Throughput Rate, Departure Rate, Processing Rate <i>[rein]</i></span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><i>Definition</i>: The number of work items exiting from the system per unit of time, whether delivered or discarded. See also: <a href="http://xprocess.blogspot.co.uk/2015/07/postscript-on-throughput-and-delivery.html">Postscript on Throughput and Delivery Rate</a>.</span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><i>Related terms</i>: <b>Delivery Rate</b>, <b>Arrival Rate</b>, <b>Discard Rate</b></span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><i>References: [vaca]</i></span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><b><br /></b></span>
<span style="font-family: "arial" , "helvetica" , sans-serif;"><b>Delivery Rate</b></span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><i>Measured in</i>: work items per unit of time</span><br />
<i style="font-family: Arial, Helvetica, sans-serif;">Alternatives</i><span style="font-family: "arial" , "helvetica" , sans-serif;">: Completion Rate</span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><i>Definition</i>: The number of work items emerging <i>complete </i>from the system per unit of time, This is a key metric to understand the productivity of the system.</span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><i>Related terms</i>: <b>Arrival Rate</b>, <b>Discard Rate</b>, <b>Throughput</b></span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><i>References: [ande], [burr]</i></span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><b><br /></b></span>
<span style="font-family: "arial" , "helvetica" , sans-serif;"><b>Discard Rate</b></span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><i>Measured in</i>: work items per unit of time</span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><i>Definition</i>: The number of work items discarded before completion per unit of time. In typical Kanban systems this metric may be significant relative to <b>Arrival Rate</b>, particularly where the "2 stage commit" is used to prepare but not necessarily complete options. <b>Discard </b>is a general term for abandoning a work item. More specifically to <b>Abort </b>a work items means to discard the item after the <b>Commitment Point </b>in a development system</span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><i>Related terms</i>: <b>Arrival Rate</b>, <b>Throughput</b>, <b>Delivery Rate</b>, <b>Commitment Point</b>, <b>Abort</b>, <b>Discard</b></span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><b><br /></b>
<b>Commitment Point</b></span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><i>Measured in</i>: not a metric, a specific point in a defined process</span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><i>Definition</i>: In a development system process, it is the point at which a commitment is made to develop the work item. Before this point work done supports the decision <i>whether or not </i>to develop the item.</span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><i>Related terms</i>: <b>Abort</b>, <b>Discard</b></span><br />
<div>
</div>
<span style="font-family: "arial" , "helvetica" , sans-serif;"><b><br /></b>
<b>Abort</b></span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><i>Measured in</i>: not a metric, an action</span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><i>Definition</i>: To <b>Discard </b>a work item after the <b>Commitment Point</b>.</span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><i>Related terms</i>: <b>Commitment Point</b>, <b>Discard</b></span><br />
<div>
<span style="font-family: "arial" , "helvetica" , sans-serif;"><br /></span></div>
<b><span style="font-family: "arial" , "helvetica" , sans-serif;">Discard</span></b><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><i>Measured in</i>: not a metric, an action</span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><i>Definition</i>: To stop work on an item and remove it from the process. Note that an item is "discarded" in this sense even if it might be worked on in the future, for example if the work item is moved <i>back</i> to a queue prior to the system/sub-process under consideration. The term is not specific about when in the process the item is discarded, however in a development system process it may apply to items discarded prior to the <b>Commitment Point</b>, since after this point the term <b>Abort </b>is applicable.</span><br />
<div>
<span style="font-family: "arial" , "helvetica" , sans-serif;"><i>Related terms</i>: <b>Abort</b>, <b>Commitment Point</b></span><br />
<div>
</div>
<span style="font-family: "arial" , "helvetica" , sans-serif;"><b><br /></b>
<b>WiP, Work in Progress</b></span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><i>Measured in</i>: work items</span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><i>Definition</i>: The number of work items which have entered the system but which are not yet either completed or discarded.</span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><i>Related terms</i>: <b>Arrival Rate</b>, <b>Throughput</b>, <b>Delivery Rate</b>, <b>TiP</b></span><br />
<div>
<i style="font-family: Arial, Helvetica, sans-serif;">References: </i><i><span style="font-family: "arial" , "helvetica" , sans-serif;">[</span><span style="font-family: "arial" , "helvetica" , sans-serif;">ande], [burr], [hopp], [marc], [rein]</span></i></div>
<div>
<span style="font-family: "arial" , "helvetica" , sans-serif;"><br /></span></div>
<div>
</div>
<b><span style="font-family: "arial" , "helvetica" , sans-serif;">TiP, Time in Process</span></b><br />
<div>
<span style="font-family: "arial" , "helvetica" , sans-serif;"><i>Measured in</i>: units of time</span></div>
<div>
<span style="font-family: "arial" , "helvetica" , sans-serif;"><i>Alternatives</i>: <b>Cycle Time </b>(but see cautionary note below), <b>Lead Time </b>(when referring specifically to the time in process in a Kanban development system from the Commitment Point to delivery), Throughput Time <i>[modi]</i>, Time In System <i>[rein]</i></span></div>
<div>
<span style="font-family: "arial" , "helvetica" , sans-serif;"><i>Definition</i>: The time that a work item remains in the system or sub-process under consideration prior to being either completed or discarded. This is the key metric in understanding the <i>time </i>to delivery of a system. More specific terms may be derived by replacing "Process" with the particular part of the process of interest, for example "Time in Development". As with all the terms in Little's Law the <i>scope </i>of the system or sub-process under consideration must be well defined to ensure they are meaningful.</span></div>
<div>
<span style="font-family: "arial" , "helvetica" , sans-serif;">A key reason for recommending this term is that it sidesteps the "Cycle Time versus Lead Time" debate which shows no sign of resolution within the communities that use these terms.</span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><i>Related terms</i>: <b>Cycle Time</b>, <b>Lead Time</b>, <b>Touch Time</b>, <b>Takt Time</b></span><br />
<i style="font-family: Arial, Helvetica, sans-serif;">References: </i><i><span style="font-family: "arial" , "helvetica" , sans-serif;">[</span><span style="font-family: "arial" , "helvetica" , sans-serif;">macc]</span></i></div>
<div>
<span style="font-family: "arial" , "helvetica" , sans-serif;"><br /></span></div>
<div>
<b><span style="font-family: "arial" , "helvetica" , sans-serif;">Cycle Time</span></b><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><i>Measured in</i>: units of time</span></div>
<div>
<i style="font-family: Arial, Helvetica, sans-serif;">Alternatives</i><span style="font-family: "arial" , "helvetica" , sans-serif;">: For CT1 (defined below) use its reciprocal - </span><b style="font-family: Arial, Helvetica, sans-serif;">Delivery Rate</b><span style="font-family: "arial" , "helvetica" , sans-serif;">; for CT2 use <b>TiP</b> or (where applicable) <b>Lead Time</b></span></div>
<div>
<i style="font-family: Arial, Helvetica, sans-serif;">Definition</i><span style="font-family: "arial" , "helvetica" , sans-serif;">: The time taken for a "cycle". This is a very ambiguous term which should <i>not </i>be used in Kanban without qualification. Examples of where it is commonly used in the literature are:</span><br />
<ul>
<li><span style="font-family: "arial" , "helvetica" , sans-serif;">In a factory: the time between completed units exiting the system <i>[chew], [like], [marc], [woma]</i></span></li>
<li><span style="font-family: "arial" , "helvetica" , sans-serif;">For a queue: the time an item remains in the queue <i>[litt]</i></span></li>
<li><span style="font-family: "arial" , "helvetica" , sans-serif;">For an airport security control: the (average) time between two items completing the process <i>[modi]</i></span></li>
<li><span style="font-family: "arial" , "helvetica" , sans-serif;">For a work station or machine: the time between completed parts exiting the station <i>[chew], [like], [marc], </i><i>[woma]</i></span></li>
<li><span style="font-family: "arial" , "helvetica" , sans-serif;">For a worker/team: the time between starting and completing an item </span><i style="font-family: Arial, Helvetica, sans-serif;">[hopp], [modi], [rein], [vaca]</i></li>
<li><span style="font-family: "arial" , "helvetica" , sans-serif;">For a project/team: the time between deliveries of completed items <i>[beck]</i></span></li>
</ul>
<span style="font-family: "arial" , "helvetica" , sans-serif;">It is incorrect to use the term for any period which is not contiguous, e.g. <b>Touch Time</b> or aggregated time in a column. Unfortunately such usage may be found in some tool implementations.</span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><br /></span></div>
<div>
<span style="font-family: "arial" , "helvetica" , sans-serif;">Broadly speaking there are two categories of usage for Cycle Time which may be referred to as CT1 and CT2. CT1 is the time between successive items emerging from a station or system. CT2 is the time an item takes from entering the system to leaving it. It is left to the reader to decide which of the examples above are CT1 or, CT2. Note that there is a special case (when WiP=1) where CT1=CT2. Unfortunately this just tends to confuse people further, especially when the example given to define the term is an example where WiP=1!</span></div>
<div>
<span style="font-family: "arial" , "helvetica" , sans-serif;">Where Cycle Time is used in the Kanban community, its definition "generally" coincides with that of <b>Lead Time</b> for Kanban development systems given below.</span></div>
<div>
<span style="font-family: "arial" , "helvetica" , sans-serif;"><i>Author's Note: </i>Since there is no universally accepted definition of what Cycle Time means in a flow system, the term should simply be avoided.</span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><i>Related terms</i>: <b>TiP</b>, <b>Lead Time</b>, <b>Touch Time</b>, <b>Takt Time</b></span><br />
<i style="font-family: Arial, Helvetica, sans-serif;">References: </i><span style="font-family: "arial" , "helvetica" , sans-serif;"><i>[beck], [burr], [chew], [hopp], [litt], [marc] [modi], [rein], [roth], [vaca], [woma]</i></span></div>
<div>
<br />
<div>
<b><span style="font-family: "arial" , "helvetica" , sans-serif;">Lead Time</span></b><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><i>Measured in</i>: units of time</span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><i>Definition</i>: In general usage, Lead Time means the time from the request for an item to the delivery of the item (this may simply be the time to get an item from stock or the time to specify, design, make and deliver an item). However its usage in Kanban development systems is more specific. It indicates the time from the <b>Commitment Point</b> to the delivery. For this to be useful the commitment and delivery points must be made explicit.</span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><i>Note</i> there remains some ambiguity in this term and I would recommend using <b>TiP</b> in most circumstances, and certainly when analysing sub-processes in a larger flow system. If you use Lead Time, qualify it if necessary (e.g. Development Lead Time and ensure that you define the meaning that you wish to be assigned to it in your context.</span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><i>Related terms</i>: <b>TiP</b>, <b>Cycle Time</b>, <b>Touch Time</b>, <b>Takt Time</b></span></div>
<i style="font-family: Arial, Helvetica, sans-serif;">References: </i><i><span style="font-family: "arial" , "helvetica" , sans-serif;">[</span><span style="font-family: "arial" , "helvetica" , sans-serif;">ande], [burr], [marc]</span></i></div>
<div>
<br />
<div>
<b><span style="font-family: "arial" , "helvetica" , sans-serif;">Touch Time</span></b><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><i>Measured in</i>: units of time</span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><i>Alternatives</i>: Value-Creating Time</span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><i>Definition</i>: The sum of all the times during which a work item is actively being working on (excluding wait times, for example being held in stock or in queues).</span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><i>Related terms</i>: <b>TiP</b>, <b>Cycle Time</b>, <b>Lead Time</b>, <b>Takt Time</b></span><br />
<div>
<i style="font-family: Arial, Helvetica, sans-serif;">References: </i><span style="font-family: "arial" , "helvetica" , sans-serif;"><i>[modi], [</i></span><span style="font-family: "arial" , "helvetica" , sans-serif;"><i>woma]</i></span></div>
<div>
<span style="font-family: "arial" , "helvetica" , sans-serif;"><br /></span></div>
<div>
<b><span style="font-family: "arial" , "helvetica" , sans-serif;">Takt Time</span></b><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><i>Measured in</i>: units of time</span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><i>Definition</i>: The projected customer demand expressed as the average unit production time (i.e. the time between the completion of work items) that <i>would be</i> needed to meet this demand. It is used to synchronise the various sub-processes within the system being designed to meet demand without over or under production.</span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><i>Related terms</i>: <b>TiP</b>, <b>Cycle Time</b>, <b>Lead Time</b>, <b>Touch Time</b></span><br />
<div>
<div>
<i style="font-family: Arial, Helvetica, sans-serif;">References: </i><i><span style="font-family: "arial" , "helvetica" , sans-serif;">[marc], [</span><span style="font-family: "arial" , "helvetica" , sans-serif;">rike], [woma]</span></i></div>
<div>
<span style="font-family: "arial" , "helvetica" , sans-serif;"><br /></span></div>
<div>
<b><span style="font-family: "arial" , "helvetica" , sans-serif;">Flow Efficiency</span></b><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><i>Measured in</i>: %</span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><i>Definition</i>: The ratio of the time spent working on an item (<b>Touch Time</b>), to the total time in process (<b>TiP</b>), i.e.:</span><br />
<blockquote class="tr_bq">
<span style="font-family: "arial" , "helvetica" , sans-serif;"><b>Flow Efficiency = </b><b><span style="text-decoration: overline;">Touch Time</span> / <span style="text-decoration: overline;">TiP</span>
</b></span></blockquote>
<span style="font-family: "arial" , "helvetica" , sans-serif;"><i>Related terms</i>: <b>Resource Efficiency</b></span><br />
<div>
<i style="font-family: Arial, Helvetica, sans-serif;">References: </i><i><span style="font-family: "arial" , "helvetica" , sans-serif;">[</span><span style="font-family: "arial" , "helvetica" , sans-serif;">modi]</span></i></div>
<div>
<span style="font-family: "arial" , "helvetica" , sans-serif;"><br /></span></div>
<div>
<b><span style="font-family: "arial" , "helvetica" , sans-serif;">Resource Efficiency</span></b><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><i>Measured in</i>: %</span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><i>Definition</i>: The ratio of the time a resource (for example a person!) is actively working on a work item, to their total available time.</span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><i>Related terms</i>: <b>Flow Efficiency</b></span><br />
<i style="font-family: Arial, Helvetica, sans-serif;">References: </i><i><span style="font-family: "arial" , "helvetica" , sans-serif;">[</span><span style="font-family: "arial" , "helvetica" , sans-serif;">modi]</span></i><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><span style="font-family: "times new roman";"><br /></span></span>
<span style="font-family: "arial" , "helvetica" , sans-serif;"><span style="font-family: "times new roman";"><br /></span></span>
<span style="font-family: "arial" , "helvetica" , sans-serif;"><i><u><b>References</b></u></i></span><br />
<ul>
<li><span style="font-family: "arial" , "helvetica" , sans-serif;"><span style="background-color: white; color: #222222; font-family: "courier new" , "courier" , monospace; font-size: 13.1999998092651px; line-height: 18.4799995422363px;">[ande] </span></span><span style="color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;"><span style="font-size: 13.1999998092651px; line-height: 18.4799995422363px;">Anderson, <span style="font-size: 13.1999998092651px; line-height: 18.4799995422363px;">David J.</span> </span><i>Kanban</i>, Blue Hole Press. (2010)</span></li>
<li><span style="color: #222222; font-family: "courier new" , "courier" , monospace; font-size: 13.1999998092651px; line-height: 18.4799995422363px;">[beck] </span><span style="color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;">Beck, Kent and </span><span style="color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif;"><span style="font-size: 13.1999998092651px; line-height: 18.4799995422363px;">Martin Fowler</span></span><span style="color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;">, </span><span style="color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;"><i>Planning Extreme Programming</i>,</span><span style="color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;"> Addison Wesley </span><span style="color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;">(2000)</span></li>
<li><span style="font-family: "arial" , "helvetica" , sans-serif;"><span style="background-color: white; color: #222222; font-family: "courier new" , "courier" , monospace; font-size: 13.1999998092651px; line-height: 18.4799995422363px;">[burr] </span><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;">Burrows, Mike. </span><span style="color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif;"><span style="font-size: 13.1999998092651px; line-height: 18.4799995422363px;"><i>Kanban from the Inside</i>, Blue Hole Press. (2014)</span></span></span></li>
<li><span style="font-family: "arial" , "helvetica" , sans-serif;"><span style="background-color: white; color: #222222; font-family: "courier new" , "courier" , monospace; font-size: 13.1999998092651px; line-height: 18.4799995422363px;">[chew] </span><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;">Chew,</span><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;"> W. Bruce,</span><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;"> </span><a href="http://hbswk.hbs.edu/archive/1460.html" style="font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;"><i>Harvard Business School Glossary of Terms</i></a><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;"> [as referenced by </span><a href="http://www.isixsigma.com/methodology/lead-time-vs-cycle-time/" style="font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;">Fang Zhou</a><span style="color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif;"><span style="background-color: white; font-size: 13.1999998092651px; line-height: 18.4799995422363px;">].</span></span><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;"> </span><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;">(2004)</span></span></li>
<li><span style="font-family: "arial" , "helvetica" , sans-serif;"><span style="background-color: white; color: #222222; font-family: "courier new" , "courier" , monospace; font-size: 13.1999998092651px; line-height: 18.4799995422363px;">[hopp] </span><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;">Hopp, W.J and M. L. Spearman, </span><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;"><i>Factory Physics</i></span><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;">, 3rd ed., McGraw Hill, International Edition. (2008)</span></span></li>
<li><span style="font-family: "arial" , "helvetica" , sans-serif;"><span style="background-color: white; color: #222222; font-family: "courier new" , "courier" , monospace; font-size: 13.1999998092651px; line-height: 18.4799995422363px;">[like] </span><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;">Liker,</span><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;"> </span><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;">Jeffrey K.</span><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;"> </span><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;"><i>The Toyota Way</i></span><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;">, McGraw Hill.</span><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;"> </span><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;">(2004)</span></span></li>
<li><span style="font-family: "arial" , "helvetica" , sans-serif;"><span style="color: #222222; font-family: "courier new" , "courier" , monospace; font-size: 13.1999998092651px; line-height: 18.4799995422363px;">[litt] </span><span style="color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;">Little, J. D. C and S. C. Graves.<i> </i></span><span style="color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;"><a href="http://web.mit.edu/sgraves/www/papers/Little%27s%20Law-Published.pdf"><i>Little's Law</i></a></span><span style="color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;">, pp 81-100, in D. Chhajed and TJ. Lowe (eds.) Building Intuition: Insights From Basic Operations Management Models and Principles. doi: 10.1007/978-0-387 -73699-0, (c) Springer Science + Business Media, LLC. (2008)</span></span></li>
<li><span style="font-family: "arial" , "helvetica" , sans-serif;"><span style="color: #222222; font-family: "courier new" , "courier" , monospace; font-size: 13.1999998092651px; line-height: 18.4799995422363px;">[lkun] </span><span style="color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;">Lean Kanban University. <a href="http://edu.leankanban.com/kanban-glossary-terms"><i>Glossary of Terms</i></a>, from <i>Kanban from the Inside</i>, </span><span style="color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;">Mike Burrows. (2014)</span></span></li>
<li><span style="font-family: "arial" , "helvetica" , sans-serif;"><span style="font-family: "courier new" , "courier" , monospace;"><span style="background-color: white; color: #222222; font-size: 13.1999998092651px; line-height: 18.4799995422363px;">[m</span><span style="background-color: white; color: #222222; font-size: 13.1999998092651px; line-height: 18.4799995422363px;">arc] </span></span><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;">Marchwinski, C.</span><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;"> </span><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;">et al</span><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;"> </span><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;">Eds, 4th ed,</span><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;"> </span><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;"><a href="http://www.amazon.co.uk/Lean-Lexicon-Graphical-Glossary-Thinkers/dp/0966784367/" style="color: #888888;"><i>Lean Lexicon</i></a></span><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;">, </span><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;">a graphical glossary </span><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;">for Lean Thinkers.</span><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;"> </span><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;">(2008)</span></span></li>
<li><span style="font-family: "arial" , "helvetica" , sans-serif;"><span style="color: #222222; font-family: "courier new" , "courier" , monospace; font-size: 13.1999998092651px; line-height: 18.4799995422363px;">[macc] </span><span style="color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;">Maccherone, Larry.<i> <a href="http://maccherone.com/publications/LSSC2012-IntroducingtheTimeInStateInSITeChart.pdf">Introducing the Time In State InSITe Chart</a></i>. LSSC. (2012)</span></span></li>
<li><span style="font-family: "arial" , "helvetica" , sans-serif;"><span style="color: #222222; font-family: "courier new" , "courier" , monospace; font-size: 13.1999998092651px; line-height: 18.4799995422363px;">[modi] </span><span style="color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;">Modig, N. and P. Åhlström, <i>This is Lean</i>, Rheologica Publishing. (2013)</span></span></li>
<li><span style="font-family: "arial" , "helvetica" , sans-serif;"><span style="background-color: white; color: #222222; font-family: "courier new" , "courier" , monospace; font-size: 13.1999998092651px; line-height: 18.4799995422363px;">[rein] </span><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;">Reinertsen, </span><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;">Donald G,</span><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;"> </span><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;"><i>The Principles of Product Development Flow</i></span><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;">,</span><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;"> Celeritas Publishing. (2005) </span></span></li>
<li><span style="font-family: "arial" , "helvetica" , sans-serif;"><span style="background-color: white; color: #222222; font-family: "courier new" , "courier" , monospace; font-size: 13.1999998092651px; line-height: 18.4799995422363px;">[roth] </span><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;">Rother, </span><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;">Mike</span><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;"> and John Shook,<i> </i></span><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif;"><span style="font-size: 13.1999998092651px; line-height: 18.4799995422363px;"><i>Learning to See: Value Stream Mapping to Add Value and Eliminate Muda</i>, </span></span><span style="color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif;"><span style="font-size: 13.1999998092651px; line-height: 18.4799995422363px;">Lean Enterprise Institute.</span></span><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif;"><span style="font-size: 13.1999998092651px; line-height: 18.4799995422363px;"> </span></span><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;">(2003)</span></span></li>
<li><span style="background-color: white; color: #222222; font-family: "courier new" , "courier" , monospace; font-size: 13.1999998092651px; line-height: 18.4799995422363px;">[vaca] </span><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;">Vacanti, Daniel S. <i>Actionable Agile Metrics for Predictability: An Introduction</i>,<i> </i>LeanPub. (2015)</span></li>
<li><span style="font-family: "arial" , "helvetica" , sans-serif;"><span style="background-color: white; color: #222222; font-family: "courier new" , "courier" , monospace; font-size: 13.1999998092651px; line-height: 18.4799995422363px;">[woma] </span><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;">Womack, J. P. and D. T Jones,</span><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;"> </span><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;"><i>Lean Thinking</i></span><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;">, Simon and Schuster</span><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;">.</span><span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13.1999998092651px; line-height: 18.4799995422363px;"> (1996, 2003)</span></span></li>
</ul>
<br />
<div>
</div>
</div>
<div>
<div>
<div>
<div>
</div>
</div>
</div>
<div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
Andyhttp://www.blogger.com/profile/04231681582044414408noreply@blogger.com0tag:blogger.com,1999:blog-21436926.post-43604581176471207102015-05-15T09:00:00.000+01:002015-05-19T10:44:10.942+01:00Growing Kanban in Three Dimensions<div class="separator" style="clear: both; text-align: left;">
Kanban systems can work at different scales and in widely different contexts. Indeed any organisation that delivers discrete packages of value ("work items") and which is interested in maximising the value and timeliness of its delivery, can analyse and improve its performance using the Kanban method. </div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
Kanban systems can <i>grow </i>- in fact in most cases it's much better that they grow than a massive process change is made suddenly across a whole organisation. "Big bangs" tend to be quite destructive, even if they could clear the way for something new. There are three dimensions in which Kanban systems grow:</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEilqFjcFP3Z4gfq6yQAiaWUQpkkWbbKYb53OLQ_XtfAPwqiwQTJGOFO-xPE9fEOLv3wQLIS41tt1BnCJ0cIAdqIY89tKJ7N09FShs7oiso1C5Y6v6d4cmghOu_mR7CTnTb8MotA/s1600/GrowingIn3D.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="225" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEilqFjcFP3Z4gfq6yQAiaWUQpkkWbbKYb53OLQ_XtfAPwqiwQTJGOFO-xPE9fEOLv3wQLIS41tt1BnCJ0cIAdqIY89tKJ7N09FShs7oiso1C5Y6v6d4cmghOu_mR7CTnTb8MotA/s400/GrowingIn3D.JPG" width="400" /></a></div>
<br />
<ul>
<li><b>Width-wise</b> growth: encompassing a wider scope of the lifecycle of work items than the typical "to do - doing - done" a single division of the process. It can cover from the idea to real value - or "concept to cash", though cash may come before or after the realisation of real value.</li>
<li><b>Height-wise</b> growth: by considering the hierarchy of items that make up valuable deliveries, each level of the hierarchy having differing flow characteristics. (This dimension use the "scale-free" nature of Kanban, the same principles and practices apply whatever the size of the work item.)</li>
<li><b>Depth-wise</b> growth: not only depth of understanding but depth of penetration through the full set of services required by the organisation to deliver value. (Sometimes referred to as "Scaling by not scaling" or "service-oriented Kanban", the approach here connects multiple services at the same level through feedback loops that balance the capacity of the various kanban systems.)</li>
</ul>
<br />
We'll look at each of these dimensions in upcoming articles. Which dimension to grow first will depend on context and the motivations for change. Any change needs to pay for itself with improvements in the flow of value, so asking "why?" is a more important first question than "what?".<br />
<br />
When you come across a good idea ("agile" in general springs to mind at this point) it is very tempting to sweep away whatever you were doing before you were converted to the new idea, and start doing it <i>everywhere</i>. It should not come as a surprise to those who do this, that very soon a new idea will come along. With the poor results from mass conversion to the caricature of the original idea you adopted, the same cycle will be repeated. Instead grow the changes organically.<br />
<br />
Try this: start small; understand the ideas as you assimilate them; grow what works and understand what doesn't work; work out why. Success will follow.<br />
<br />
<i>Acknowledgement: Thanks to <a class="g-profile" href="https://plus.google.com/106535047060799402650" target="_blank">+Pawel Brodzinski</a> for the discussions on Portfolio Kanban... and one of the graphics on the top floor of the above diagram.</i>Andyhttp://www.blogger.com/profile/04231681582044414408noreply@blogger.com0tag:blogger.com,1999:blog-21436926.post-2910624884596030632015-05-14T15:40:00.001+01:002015-05-15T08:54:38.660+01:00Earned Value Management and Agile ProcessesI've recently been working with a client whose customer requires project reporting using Earned Valued Management metrics (EVM). It made me realise that, since they are also wishing to use agile methods, a paper I wrote back in 2008 could be relevant to them, and maybe a few others. When I looked for it online it was no longer available, so I thought I'd remedy that here. You can access the paper by clicking this link: <i><a href="https://drive.google.com/open?id=0B8VOX22A2sWMTWNtY2FXZ2ozbzQ&authuser=0">EVM and Agile Processes – an investigation of applicability and benefits</a></i>.<br />
<br />
EVM is a technique for showing how closely a project is following both its planned schedule and planned costs. It's a superior method to simply reporting time and cost variance, since if the project has slipped but also underspent you cannot tell from the simple variances the degree to which the underspend has caused the slippage. EVM's cost efficiency and schedule efficiency (nothing to do with efficiency by the way!) can tell you this.<br />
<br />
However agile methods do not have a fixed scope during their lifecycle and this can make EVM reporting effectively meaningless. The paper explains a technique for using the substitutability of User Stories, estimated in points, for overcoming this problem. If this is relevant to your business environment, I hope you find it useful.<br />
<br />
Agile EVM has continued to develop since this paper and you can find more details and further references in the Wikipedia entry here: <a href="http://en.wikipedia.org/wiki/Earned_value_management#Agile_EVM">Earned value management: Agile EVM</a>.<br />
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgjn0b_nrk57-UdPHNhDat-LS2PS0VY3wXBFzsmImCVweFMKS2dFhgD2iOLKu1rFebojziBWMAPkG2Zec4e5-rJBHz9r147wGv06xvAizX71nknmt0zddXXHuaVqm5UXWgRuE2R/s1600/EVM+and+Agile+Abstract.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="287" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgjn0b_nrk57-UdPHNhDat-LS2PS0VY3wXBFzsmImCVweFMKS2dFhgD2iOLKu1rFebojziBWMAPkG2Zec4e5-rJBHz9r147wGv06xvAizX71nknmt0zddXXHuaVqm5UXWgRuE2R/s400/EVM+and+Agile+Abstract.JPG" width="400" /></a></div>
<div style="text-align: center;">
<span style="font-size: x-small;"><i><b>Citation</b>: Andy Carmichael (2008). EVM and Agile Processes – an investigation of applicability and benefits, The 2nd Earned Value Management Conference, NEC, Birmingham UK, 12 March 2008. <br />Project Manager Today Events. www.pmtoday.co.uk.</i></span></div>
Andyhttp://www.blogger.com/profile/04231681582044414408noreply@blogger.com0tag:blogger.com,1999:blog-21436926.post-52978594149600809692015-03-20T12:27:00.002+00:002015-03-23T10:20:08.688+00:00Does your Definition of Done allow known defects?<b>Is it just me or do you also find it odd that some teams have clauses like this in their definition of done (DoD)?</b><br />
<blockquote class="tr_bq">
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; margin-left: 1em; text-align: right;"><tbody>
<tr><td style="text-align: center;"><a href="https://hpc.cimne.upc.edu/wp-content/uploads/2013/04/done.gif" imageanchor="1" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" src="https://hpc.cimne.upc.edu/wp-content/uploads/2013/04/done.gif" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Done... or Done-But?</td></tr>
</tbody></table>
<i>... the Story will contain defects of level 3 severity or less only ...</i></blockquote>
Of course they don't mean you <i>have </i>to put minor bugs in your code - that really would be mad - but it does mean you can sign the Story off as "<b>Done</b>"<b> </b>if the bugs you discover in it are only minor (like spelling mistakes, graphical misalignment, faults with easy workarounds, etc.). I saw DoDs like this some time ago and was seriously puzzled by the madness of it. I was reminded of it again at a meet-up discussion recently - it's clearly a practice that's not uncommon.<br />
<br />
<b>Let's look at the consequences of this policy. </b><br />
<br />
Potentially for every User Story that is signed off as "Done" there could be several additional Defect Stories (of low priority) that will be created. It's possible that finishing a Story (with no additional user requirements) will result in an increase in the Product Backlog size! (<i>Aaaagh...)</i> You're either never going to finish or, more likely, never going to fix those Defects in spite of all the waste that will be generated around recording, estimating, prioritising and finally attempting to fix the defects (when the original developer has forgotten how he coded the Story, or has been replaced with someone who never knew it in the first place).<br />
<br />
<b>What <i>should </i>happen then? </b><br />
<br />
Clearly the simple answer is that if you find a bug (of whatever severity) before the Story is "Done", <u>fix it</u>. You haven't finished until it works - just avoid double-think like I've finished it even though the product now contains new defects.<br />
<br />
<b>Can there be exceptions to this?</b><br />
<br />
Those who think quality is "non-negotiable" would probably answer "No", but actually (whether acknowledged or not) we all work with a concept of "sufficient quality". It is inherent in ideas like "minimum viable product" and "minimum marketable feature". Zero defects is a slogan not a practicable policy for most product developments. Situations where we find defects that are hard to fix when working on a User Story, bring this issue to the fore.<br />
<br />
So here's what I recommend Product Owners do. Firstly, don't sign off a Story if it contains defects! Secondly if defects are found choose to do one of the following:<br />
<ol>
<li><b>Insist it's fixed.</b> Always preferred, and should nearly always be followed. Occasionally however it is too expensive, but unless the cost of fixing it is greater than the time already spent on the Story I would always recommend fixing. (We discuss below the problem of "deadlines".)</li>
<li><b>Accept it's not a defect...</b> at least not a defect that will ever get fixed (unless it's found and added to the Backlog by users). This doesn't <i>feel</i> right but it is more honest than adding items to the Product Backlog that will never be prioritised.</li>
<li><b>Agree the defect is actually a different Story</b>, functionality that will be covered elsewhere even though it is part of the same Epic or Feature. The original Story will not be released without all the functionality of that Epic/Feature, so it will be fixed before release. Note that this option depends on a well understood concept of Epic/Feature and appropriate release policies around it.</li>
</ol>
What I am arguing for here is that our Definition of Done trumps deadlines, Sprint boundaries and Sprint "commitments". I believe it is confusion in this area that leads teams to adopt misguided DoDs. That confusion in turn results in the need for "Maintenance Teams" that clear up after Development teams have scattered defects through the product, or the common practice of dumping defects into massive Defect logs that will never be cleared, even if the development continues for decades! As <a class="g-profile" href="https://plus.google.com/115577948885665029512" target="_blank">+Liz Keogh</a> has observed, deadlines should really be renamed "sad-lines" - if they're missed nobody's dead; maybe a few are sad! It is not that such planned dates are unimportant, of course they are not. It is that agreed dates should not have <i>greater </i>importance than agreed quality.<br />
<br />
These "Done-But" policies are most common in development departments where the concept of <b><i>commitment</i> </b>("Look me in the eye and tell me you will complete these Stories by this date") is considered more important than <i><b>Done</b></i>, i.e. that completing a Story means it will be at the quality agreed. The <a href="http://www.scrumguides.org/">Scrum Guide</a> replaced the word "commitment" with "forecast" in a recent revision for a reason - commitment should be what a team member brings to the overall goals of the organisation, not to a date that at best was derived from very limited information.<br />
<br />
Of course in reality both commitment to dates and a particular Definition of Done must be subservient to the overall business goals. We can move a release date for an Epic/Feature to a later (or earlier) date if that will better fulfill the overall goals. Similarly changing the DoD or quality expectations up or down should always be considered in order to improve business outcomes.<br />
<br />
Does your Definition of Done allow known defects? If so please come back to me and tell me why... or if you would change it, tell me how?Andyhttp://www.blogger.com/profile/04231681582044414408noreply@blogger.com0tag:blogger.com,1999:blog-21436926.post-83039158319995626382014-11-07T11:26:00.003+00:002014-11-07T11:33:44.174+00:00How a Product Team is improving value delivery rate with Kanban<iframe frameborder="0" height="400" marginheight="0" marginwidth="0" scrolling="no" src="//www.slideshare.net/slideshow/embed_code/41251241" width="476"></iframe><br />
<br />
Here are my slides from #lkuk14. Full video available soon from <a href="http://lkuk.leankanban.com/">Lean Kanban UK</a>.Andyhttp://www.blogger.com/profile/04231681582044414408noreply@blogger.com0tag:blogger.com,1999:blog-21436926.post-59928362047703021852014-09-16T12:08:00.001+01:002015-07-17T12:42:43.882+01:00Care about business strategy? - Tune to this channel...If you think the principles and values of agile extend beyond the narrow boundaries of software development teams to organisations and corporate cultures, I think, like me, you'll be inspired by a couple of presentations from the recent Agile On The Beach conference, They are great bedtime viewing (for when you've finally had enough of Bakeoff!).<br />
<br />
Firstly a video from Tom Sedge: <a href="http://www.ambitiousmanager.com/tdd-for-business-strategies/">TDD for Business Strategies – Developing Business Strategies Test-First</a>.<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://vimeo.com/105514504"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEihfS-C_xKYSAVJ1_0ljMXHajUEGN3sJkMSfh_DzHyXUzy084-LZqeR3IeK7_NyWetP5_uI0A8a6qL9SGTIKl-nhJXNEwmFRMWdf815VvYY7kyhOMqu0KUYWJDskV8v9EBD6vc1/s1600/Capture.JPG" height="197" width="400" /></a><span id="goog_1797370507"></span><span id="goog_1797370508"></span><a href="https://www.blogger.com/"></a></div>
Tom Sedge provides very practical advice on how to define <b>mission </b>(why we're here - our purpose and driving cause), <b>vision </b>(where we're heading - how the world will be different), <b>goals </b>(what we want - destinations or desired outcomes), and <b>strategies </b>(how we will get there - potential routes to the destination). His examples of good (Tesla, SpaceX) and bad (Kodak) missions/visions are particularly helpful. How could the inventor of the digital camera go bust, just as digital photography exploded on scene, particularly as their founder George Eastman expressed his vision in the 1880's as "a world where the camera is as convenient as the pencil". These days I quite often wish I had a pencil on me, yet I always have a camera! His vision makes a sad contrast with Kodak's mission and vision statement from the early 2000's - a paragraph of unmemorable platitudes about customer focus and shareholder value, that no one outside the company would care a fig about!<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://echo.falmouth.ac.uk:8080/ess/echo/presentation/d81fc6d4-ea5a-4d2f-9b75-242c47afe57b"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhukGjSC5DSjGUaIUF1BawaqWsQL9rv2y9A9qEOFplb9tsQsWwEdNk-J8qeraYOTWWPgXPbbl6DLxyX6FibOYI66573zTbfSSymwSD_ALZSX1yJC5ZwJE4sBcHscJsJyvICsEDQ/s1600/Capture2.JPG" height="212" width="400" /></a></div>
<br />
The second one is from Bjarte Bogsnes, Vice President of Performance Management Development at the major international oil company, Statoil. It's on <a href="http://echo.falmouth.ac.uk:8080/ess/echo/presentation/d81fc6d4-ea5a-4d2f-9b75-242c47afe57b">Beyond Budgeting – an agile management model for new business and people realities</a>. If you give it a listen you'll understand why (even though I think budgets are essential) I'm not that keen on investing much time in <i>annual </i>budgeting. In his words, the approach "... is about rethinking how we manage organisations in a post-industrial world, where innovative management models represent the only sustainable competitive advantage ... releasing people from the burdens of stifling bureaucracy and suffocating control systems, trusting them with information and giving them time to think, reflect, share, learn and improve."<br />
<br />
Remember he's talking about a massive oil company - not the easiest place to introduce agile thinking! Gives hope to the rest of us.<br />
<div>
<br /></div>
Andyhttp://www.blogger.com/profile/04231681582044414408noreply@blogger.com0tag:blogger.com,1999:blog-21436926.post-26079242126376275342014-09-11T12:15:00.002+01:002015-07-17T12:45:21.144+01:00x-Banning a processI've just proposed an experience paper for LKUK14 - "x-Ban the process! (or how a product team is improving value delivery rate with Kanban)". Feel free to vote for it by the way <a href="https://leankanban.uservoice.com/forums/258875-lkuk14-call-for-proposals/suggestions/6422788-x-ban-the-process-how-a-product-team-is-improvi">here</a>!<br />
<br />
Scrumban, Xanpan (XP-ban) - even Prince-ban and DSDM-ban - have all been used as portmanteau words to explain the journeys from a particular named process or framework to a continually evolving and improving process, guided by the principles and practices of Kanban. If you are trying to apply a named process but frustrated by a patchy track-record of improvement, consider the alternative: x-Ban it!<br />
<br />
When I was asked in early 2013 if I would work with <a href="http://www.clearvision-cm.com/">Clearvision</a>'s product development team, they had just adopted Scrum (a matter of weeks before). Their process, like most I've reviewed from teams claiming to use Scrum, was not compliant with a large number of Scrum rules. It was pragmatic, constrained, variably applied and ripe for improvement... but it certainly wasn't Scrum. We had two choices - apply Scrum rules as soon as possible (defining the backlog of necessary changes and a timetable to apply them), or “x-Ban” it (use Kanban to attain evolutionary changes that we kept only if we were confident they resulted in improvements). We did the latter.<br />
<br />
There are many lessons I've learned from this experience: some things that worked - and some that didn’t. They're lessons and general principles that others can apply on a similar journey. It has taken much longer to adopt some practices than I expected, the current process is quite different than I expected when I started 18 months ago (it’s more Scrum-like now than when I arrived for example!), but it is a route I would recommend to others.<br />
<br />
Start x-Banning <i>your </i>process now!Andyhttp://www.blogger.com/profile/04231681582044414408noreply@blogger.com0tag:blogger.com,1999:blog-21436926.post-50691839698564602592014-08-28T15:42:00.001+01:002014-08-28T15:42:17.065+01:00Improving Software Development at Scale: Promise and Pitfalls<iframe allowfullscreen="" frameborder="0" height="270" src="//www.youtube.com/embed/kTQwWyJXeiQ?list=PLKBhokJ0qd3-OMgwC7f9yBDeQ56BYUiQ-" width="480"></iframe><br /><br />
<br /><br />
Here's my talk from the London Lean Kanban Day 2014. Enjoy!Andyhttp://www.blogger.com/profile/04231681582044414408noreply@blogger.com0tag:blogger.com,1999:blog-21436926.post-67017895829020849612014-03-14T15:58:00.000+00:002014-03-14T17:32:17.555+00:00Not all work "flows"I've written elsewhere that it's key to focus attention on <a href="http://www.clearvision-cm.com/blog/work-that-flows/">"Work that Flows"</a> (see <a href="http://www.clearvision-cm.com/blog/">Clearvision's blog</a>). That is, work that has a beginning, middle and end (delivery) and some tangible value as the outcome. The thing is not all work <i>does </i>flow. A lot of our time is dedicated to tasks that are simply "overhead". They might be waste - they add no value and serve no useful purpose - but equally they might be <i>necessary </i>activity within the context of how you deliver your work, yet not actually attached to delivery. Project management for example will need to be done for as long as the project lasts - it is not something can be completed independently from the delivery tasks. Sometimes overhead tasks can be removed if the process is changed, but more often they are a pretty-much immovable feature of the way we work.<br />
<br />
I just want to make one point about this - you should know the difference between work that flows and work that doesn't - i.e. overhead work. Don't put overhead tasks on your Scrum or Kanban boards for example. Focus on the work that flows. Whenever you can, eliminate (or minimise) the overhead tasks!Andyhttp://www.blogger.com/profile/04231681582044414408noreply@blogger.com0