{"id":158,"date":"2011-07-22T15:29:33","date_gmt":"2011-07-22T15:29:33","guid":{"rendered":"https:\/\/benjaminmitchell.wordpress.com\/2011\/07\/22\/removing-the-bubbles-solving-bottlenecks-in-software-product-development\/"},"modified":"2011-07-22T15:29:33","modified_gmt":"2011-07-22T15:29:33","slug":"removing-the-bubbles-solving-bottlenecks-in-software-product-development","status":"publish","type":"post","link":"https:\/\/techpeoplethrivi-i2tkeoduos.live-website.com\/removing-the-bubbles-solving-bottlenecks-in-software-product-development\/","title":{"rendered":"Removing the bubbles: solving bottlenecks in software product development"},"content":{"rendered":"
A challenge with software product development is visualising the work so that you can spot where there are delays in the process of converting ideas from \u201cconcept to cash\u201d. This post shows how a cumulative flow diagram helped identify a pattern of queues over time. Removing these queues had many benefits such as fewer errors, increased team communication and improved team capacity.<\/p>\n
Make the work visible <\/a><\/p>\n The kanban board is useful for a \u201cmoment in time\u201d view, but it\u2019s not possible to easily see patterns that might develop over time. Looking at the kanban board on a particular day doesn\u2019t make it easy to answer questions like these:<\/p>\n To find these answers and look more clearly for patterns over time we built a cumulative flow diagram (CFD, also called a \u2018finger chart\u2019) by counting the number of post-it notes in each stage (column) in the team\u2019s process after each daily stand-up. Unlike my earlier post on using three forks and a hand-drawn chart to help a team improve<\/a> in this case we used an Excel spread sheet.<\/p>\n Visualise the work over time to better understand queues (\u2018bubbles\u2019) <\/a><\/p>\n Do the detective work necessary to understand what causes the queues (\u2018bubbles\u2019) The functional testing involved someone other than the person who developed the functionality (user story) validating that it worked functionally (there were no obvious errors). Once functional testing was complete then the acceptance testing stage was performed by a business analyst or the product manager.<\/p>\n The team were releasing to production every second Wednesday. On the middle Wednesday the person who did the functional testing switched to doing the integration testing (ensuring the features which were created as a package to go to production worked individually and combined, as well as running a set of manual regression test scripts to make sure that the new functionality hadn\u2019t had any impact on the rest of the website). During the week spent on Integration testing, no functional testing was done, which we believed was the cause of the queues or orange bubbles on the chart.<\/p>\n Creating a new policy to reduce the queues (\u2018bubbles\u2019) <\/a><\/p>\n We also mapped out a new \u201cpolicy\u201d that described what the person doing testing did for for the week spent integration testing:<\/p>\n While performing the Integration Testing in the week before the release, if there are any work items in the Functional Testing column, spend up to an hour each day doing them.<\/p><\/blockquote>\n We experimented with the new policy for the last third of the cumulative flow chart. The cumulative flow diagram showed that the queue (bubble) in the Functional Testing (orange) step virtually disappeared, as did the queue in the Acceptance Testing (red) stage. The CFD not only highlighted the initial problem, but it also validated the experimental change we made in policy resulted in an improvement (it allowed us to answer the critical question – \u201cdid the change we made to our process result in an improvement?\u201d)<\/p>\n It\u2019s the system!<\/strong> Benefits Hi, I\u2019m Benjamin<\/a>. I hope that you enjoyed the post. I\u2019m a consultant and coach who helps IT teams and their managers create more effective business results. You can find out more about me<\/a> and my services<\/a>. Contact me<\/a> for a conversation about your situation and how I could help.<\/p>\n","protected":false},"excerpt":{"rendered":" A challenge with software product development is visualising the work so that you can spot where there are delays in the process of converting ideas from \u201cconcept to cash\u201d. This post shows how a cumulative flow diagram helped identify a pattern of queues over time. Removing these queues had many benefits such as fewer errors, […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5,6,10,13,15,16,17],"tags":[],"_links":{"self":[{"href":"https:\/\/techpeoplethrivi-i2tkeoduos.live-website.com\/wp-json\/wp\/v2\/posts\/158"}],"collection":[{"href":"https:\/\/techpeoplethrivi-i2tkeoduos.live-website.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/techpeoplethrivi-i2tkeoduos.live-website.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/techpeoplethrivi-i2tkeoduos.live-website.com\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/techpeoplethrivi-i2tkeoduos.live-website.com\/wp-json\/wp\/v2\/comments?post=158"}],"version-history":[{"count":0,"href":"https:\/\/techpeoplethrivi-i2tkeoduos.live-website.com\/wp-json\/wp\/v2\/posts\/158\/revisions"}],"wp:attachment":[{"href":"https:\/\/techpeoplethrivi-i2tkeoduos.live-website.com\/wp-json\/wp\/v2\/media?parent=158"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/techpeoplethrivi-i2tkeoduos.live-website.com\/wp-json\/wp\/v2\/categories?post=158"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/techpeoplethrivi-i2tkeoduos.live-website.com\/wp-json\/wp\/v2\/tags?post=158"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\n<\/strong>The first task\u00a0is making the work visible. In knowledge work, such as software development, it is difficult to see the work being done, which is why a visualisation approach such as kanban can be so useful. Here\u2019s a view of a kanban board from an\u00a0earlier client team:<\/p>\n\n
\n<\/strong>The cumulative flow diagram for this team helped make visible that there were consistent queues of work in the functional testing and acceptance testing processes over time. These queues are visible as \u201cbubbles\u201d that develop in the cumulative flow diagram.\u00a0 See the highlighted in orange and red stages below (click the image for a larger version).<\/p>\n
\n<\/strong>Around two-thirds of the way through the above chart (which covered about 36 weeks) we decided to focus on studying what was causing the queues to develop in functional and acceptance testing.<\/p>\n
\n<\/strong>We sat down with the person who performed the Functional and Integration Testing and mapped out the schedule of their work across the fortnight between releases (see the hand-drawn diagram we came up with below).<\/p>\n
\nThis example demonstrates\u00a0how changing the way the work is structured can produce improvements without having to change the work that team members were doing. <\/strong>This example shows that the queues caused by the way the work was structured (e.g. the system we had designed) and not the work of the team members. It speaks to Deming\u2019s \u2018provocation\u2019 that \u201c95% of the variation [in how long the work takes] is due to the system and not the individuals\u201d.<\/p>\n
\n<\/strong>There were many benefits to the changes that we made above:<\/p>\n\n