{"id":105,"date":"2011-06-29T09:14:41","date_gmt":"2011-06-29T09:14:41","guid":{"rendered":"https:\/\/benjaminmitchell.wordpress.com\/?p=105"},"modified":"2011-06-29T09:14:41","modified_gmt":"2011-06-29T09:14:41","slug":"how-three-forks-on-a-hand-drawn-chart-helped-a-team-improve","status":"publish","type":"post","link":"https:\/\/techpeoplethrivi-i2tkeoduos.live-website.com\/how-three-forks-on-a-hand-drawn-chart-helped-a-team-improve\/","title":{"rendered":"How three forks on a hand-drawn chart helped a team improve"},"content":{"rendered":"

After visualising the workflow of a recent client\u2019s software development process, and showing where the work was, the team realised there was a queue of tasks that had been developed and were waiting to be validated (\u2018tested\u2019).  The team decided to move from a \u201cI just do my task\u201d approach to a \u201cwhole team\u201d approach where they focussed on making a single task flow across all of the development process with minimum delay. They decided that rather than continuing to do more development and hoping that the validation work would eventually complete, the people who did development would go and help those who were validating the work.<\/p>\n

The problem was that the Development Manager (who believed his role was to maximise the number of development tasks completed) was concerned that if the development work stopped to reduce the queue in validation, then eventually the validation step might run out of work to do.<\/p>\n

In order to address the Development Manager\u2019s concern we went to the hand-drawn cumulative flow diagram (sometimes called a finger chart). The cumulative flow diagram was drawn each day, by the team member who ran the daily stand up, by simply counting the number of tasks in each stage of the workflow. The x-axis shows time in days, and the y-axis shows the number of tasks in each step of the workflow.<\/p>\n

As we had a couple of weeks data it was possible to extrapolate the rate at which the validation work was being completed. We were also able to extrapolate the rate at which development work was finishing. In order to do this extrapolation we grabbed the nearest straight-edge items we could find, which turned out to be forks!<\/p>\n

\"IMG_0131\"<\/a> <\/p>\n

As the photo shows, the forks indicated that it would take about two weeks for the validation step to run out of work to do if most of the people doing development spent their time helping do the validation. This data allowed the Development Manager to feel more comfortable about allowing the strategy a shot for a week, after which it could be reviewed.<\/p>\n

This example demonstrated the benefits of using quick, low-fidelity data collection methods. The discipline of hand-drawing the chart each day meant that it was better understood by the team members than if it had been automatically produced in an electronic tool.  The team were also able to see how the data could be valuable, as it allowed them to discuss the Development Manager\u2019s concerns with data rather than just opinion.<\/p>\n

In the end, the strategy to work as a whole team and focus on the validation step turned out very well. The team were able to reduce the time it took to validate tasks, providing quicker feedback to development (which reduced defects), increase the amount of work they got done at the same time as improving the team\u2019s morale.<\/p>\n

Do you have stories of using quick, low-fidelity data collection techniques to improve team performance?<\/p>\n","protected":false},"excerpt":{"rendered":"

After visualising the workflow of a recent client\u2019s software development process, and showing where the work was, the team realised there was a queue of tasks that had been developed and were waiting to be validated (\u2018tested\u2019).  The team decided to move from a \u201cI just do my task\u201d approach to a \u201cwhole team\u201d approach […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5,10,13],"tags":[],"_links":{"self":[{"href":"https:\/\/techpeoplethrivi-i2tkeoduos.live-website.com\/wp-json\/wp\/v2\/posts\/105"}],"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=105"}],"version-history":[{"count":0,"href":"https:\/\/techpeoplethrivi-i2tkeoduos.live-website.com\/wp-json\/wp\/v2\/posts\/105\/revisions"}],"wp:attachment":[{"href":"https:\/\/techpeoplethrivi-i2tkeoduos.live-website.com\/wp-json\/wp\/v2\/media?parent=105"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/techpeoplethrivi-i2tkeoduos.live-website.com\/wp-json\/wp\/v2\/categories?post=105"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/techpeoplethrivi-i2tkeoduos.live-website.com\/wp-json\/wp\/v2\/tags?post=105"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}