{"id":254,"date":"2018-02-18T02:12:58","date_gmt":"2018-02-18T02:12:58","guid":{"rendered":"http:\/\/freedville.com\/blog\/?p=254"},"modified":"2019-04-12T14:04:31","modified_gmt":"2019-04-12T14:04:31","slug":"work-in-progress-delivers-no-value","status":"publish","type":"post","link":"https:\/\/freedville.com\/blog\/2018\/02\/18\/work-in-progress-delivers-no-value\/","title":{"rendered":"Work in progress delivers no value"},"content":{"rendered":"<p>One of the key tenets of the Agile\/Lean method of delivering software is the concept of reducing time to value.&nbsp; This is done with a laser-focus on value &#8211; simply there is no value from code that is not in front of a user.&nbsp; A necessary corollary of this is that there is no value from work in progress.<\/p>\n<p>This is difficult for both producers and consumers of software to internalize.&nbsp; The managers of producers may be delighted to see high utilization from their development team.&nbsp; Consumers may be impatient with software progress and compensate by requesting more features be worked on.&nbsp; Both of these can produce waste by creating too much work-in-progress.&nbsp; Let&#8217;s consider an example.<\/p>\n<p>Assume we have two pieces of work, &#8220;A&#8221; and &#8220;B&#8221;, each requiring 5 days of effort, each requested by a different user.&nbsp; We may placate the pair of users by alternating effort by day, thus treating the two users equally by working on both pieces of work at the same time.&nbsp; Our timeline looks something like this: ABABABABAB.&nbsp; At day 9 the first user receives A, on day 10 the second user receives B.&nbsp; Development was fully utilized, users were treated equally, but it took 9 days to deliver any value despite each piece of work taking 5 days!<\/p>\n<p>Let&#8217;s consider an alternate scenario, where a strong product owner prioritizes work and minimizes work-in-progress.&nbsp; In this scenario there is no multi-tasking, work progresses as AAAAABBBBB.&nbsp; Now the first user receives value in 5 days (the second user still receives value at day 10).&nbsp; The strict prioritization decision reduced the work-in-progress and reduced overall time to value.<\/p>\n<p>Work-in-progress is even more insidious.&nbsp; Whatever we build, we must consider not only if we are building it correctly but if we are even building the right thing!&nbsp; When we have a lot of work partially done, we are robbed of the chance to find out what our users think.&nbsp; We don&#8217;t see how it delights them, or how it confuses them, or how it&#8217;s not quite what they want.&nbsp; Without having finished code in front of users, we don&#8217;t have the opportunity to make the critical adjustments that take our users from &#8220;meh&#8221; to &#8220;wow&#8221;.<\/p>\n<p>Agile scrum-masters only track two kinds of work: &#8220;done&#8221; and &#8220;not done&#8221;.&nbsp; (Some practitioners place even more emphasis on done, calling the final state &#8220;done done done&#8221;.)&nbsp; I used to think this was just a thin veneer on a collection of states in issue tracking software.&nbsp; I now realize this labeling is critical to keeping laser focus on what matters.&nbsp; It doesn&#8217;t matter how utilized the team is or how much work is in progress, rather it matters whether code is in front of users or not.&nbsp; Is that code providing value or not.<\/p>\n<p>This lesson is difficult to keep in mind during the louder phases of a software project.&nbsp; There are many competing concerns that are difficult to balance.&nbsp; Find success by laser-focusing on what matters: providing value through completed code.&nbsp; There&#8217;s no value to your users from work-in-progress.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>One of the key tenets of the Agile\/Lean method of delivering software is the concept of reducing time to value.&nbsp; This is done with a laser-focus on value &#8211; simply there is no value from&#8230;<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[1],"tags":[11],"_links":{"self":[{"href":"https:\/\/freedville.com\/blog\/wp-json\/wp\/v2\/posts\/254"}],"collection":[{"href":"https:\/\/freedville.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/freedville.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/freedville.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/freedville.com\/blog\/wp-json\/wp\/v2\/comments?post=254"}],"version-history":[{"count":4,"href":"https:\/\/freedville.com\/blog\/wp-json\/wp\/v2\/posts\/254\/revisions"}],"predecessor-version":[{"id":407,"href":"https:\/\/freedville.com\/blog\/wp-json\/wp\/v2\/posts\/254\/revisions\/407"}],"wp:attachment":[{"href":"https:\/\/freedville.com\/blog\/wp-json\/wp\/v2\/media?parent=254"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/freedville.com\/blog\/wp-json\/wp\/v2\/categories?post=254"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/freedville.com\/blog\/wp-json\/wp\/v2\/tags?post=254"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}