{"id":12284,"date":"2020-11-25T17:05:45","date_gmt":"2020-11-25T16:05:45","guid":{"rendered":"https:\/\/www.codemotion.com\/magazine\/?p=12284"},"modified":"2022-01-05T20:06:46","modified_gmt":"2022-01-05T19:06:46","slug":"scrum-master","status":"publish","type":"post","link":"https:\/\/www.codemotion.com\/magazine\/devops\/scrum-master\/","title":{"rendered":"What Every Scrum Master Gets Wrong"},"content":{"rendered":"\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t\tTable Of Contents\t\t\t\t\t\t<\/div>\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t
  1. The Scrum Masters\u2019 myth of full task lists<\/a>
  2. What can we do about it?\u00a0<\/a>
  3. Achieving flow optimisation<\/a>
  4. \u201cJust in time\u201d and lean production<\/a>
  5. Applying this to software delivery<\/a>
  6. Applying Lean in practice<\/a>
  7. The benefits of getting it right<\/a>
  8. Summary<\/a><\/ol>\t\t\t\t\t<\/div>\n\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\n\n\n

    Project<\/span> management is all about maximising productivity<\/span> and efficiency while minimising resources and costs. This becomes especially important in the Agile<\/span> world, where you need to deliver constant improvements to the customer<\/span>. There are many approaches to achieving Agile<\/span> Development<\/strong>, including Scrum<\/span><\/em>, Kanban and extreme programming. <\/p>\n\n\n\n

    This article is aimed primarily at Scrum<\/span> Masters, but there are valuable lessons for anyone leading<\/a> or running software development<\/span> projects<\/span><\/em>. So, read on to learn how to achieve the seemingly impossible: doing less while delivering more.<\/p>\n\n\n\n

    The Scrum Masters\u2019 myth of full task lists<\/h2>\n\n\n\n

    The world is full of managers<\/span> who subscribe to the myth that unscheduled time is wasted time. If your staff haven\u2019t been assigned back-to-back tasks then they will be unproductive. To see why this is a myth, let\u2019s look at the problem of doctors\u2019 appointments. <\/p>\n\n\n\n

    Everyone knows that sinking feeling of arriving on time for an appointment only to be told: \u201cplease take a seat\u201d. You know that you are now in for an unpredictable wait until the doctor is ready to see you. But why does this happen? Why, when we schedule<\/span> the exact date and time in advance, do we end up waiting a long time? Let\u2019s look at this example from a flow perspective. <\/p>\n\n\n\n

    In this model<\/span>, patients are tasks that the doctor (the resource<\/span>) needs to process.  Usually, patient visits are planned one by one, not leaving any empty gaps in the doctor\u2019s schedule. This is an attempt to optimise resource efficiency<\/span><\/strong> by making sure 100% of the doctor\u2019s time is utilised.<\/p>\n\n\n\n\n\n\n\n

     <\/td>Tuesday<\/strong><\/td>Wednesday<\/strong><\/td><\/tr>
    9:00<\/strong><\/td>John<\/td><\/td><\/tr>
    9:30<\/strong><\/td>Tom<\/td><\/td><\/tr>
    10:00<\/strong><\/td>Paul<\/td><\/td><\/tr>
    10:30<\/strong><\/td>Anna<\/td><\/td><\/tr>
    11:00<\/strong><\/td>Michael<\/td>Mona<\/td><\/tr>
    11:30<\/strong><\/td>Andrea<\/td>Phil<\/td><\/tr>
    12:00<\/strong><\/td>Stephen<\/td>Mike<\/td><\/tr>
    12:30<\/strong><\/td><\/td>Elton<\/td><\/tr>
    13:00<\/strong><\/td><\/td>Alex<\/td><\/tr>
    13:30<\/strong><\/td><\/td>Janet<\/td><\/tr>
    14:00<\/strong><\/td><\/td><\/td><\/tr>
    14:30<\/strong><\/td><\/td><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

    In an ideal scenario<\/span>, every patient comes on time and their consultation lasts no more than 30 minutes. Let\u2019s ask ourselves: how often does this ideal scenario<\/span> become a reality? The answer: almost never! The reason is that it is very difficult to predict how long the visit will last and what treatment or tests the doctor will need to perform for each patient.<\/p>\n\n\n\n

    The analogy with Agile software development<\/h3>\n\n\n\n

    Why talk about doctors waiting lists in an article about software development? What is the relevance to Scrum<\/span> Masters<\/strong> or Agile development<\/a>? Well, as you can see, there is actually a clear analogy here. If we add urgent cases (expedited items) to the example, it looks even more similar. <\/p>\n\n\n\n

    The two mentioned factors are key: the unpredictability <\/em>of work and expedited <\/em>items. These factors are the main reasons why high resource<\/span> utilisation does not equate to work optimisation in software development. Indeed, instead of benefits, we get big delays, long queues, low employee satisfaction, and high pressure.<\/p>\n\n\n\n

    What can we do about it? <\/h2>\n\n\n\n

    Fortunately, there are better alternatives for achieving efficient delivery. We need to start by optimising flow efficiency<\/span> and then moving on to resource<\/span> utilisation. The quadrant chart below compares resource<\/span> and flow efficiency<\/span>. <\/p>\n\n\n\n

    Our aim is to reach box 4 at the top right, where both the flow and resource<\/span> utilisation are at their most efficient. However, all too often we end up in box 1.<\/p>\n\n\n\n

    \"Every
    Every Scrum Master should aim to maximise resource and flow efficiency<\/figcaption><\/figure><\/div>\n\n\n\n

    What does this mean in practice? It means that we first aim to make sure that we deliver early and often rather than keep everyone busy with 100% utilisation. <\/p>\n\n\n\n

    Achieving flow optimisation<\/h2>\n\n\n\n

    Flow optimisation<\/strong> isn\u2019t unique to software development<\/span>. Indeed, it is a widely studied field of research<\/span>. I always encourage fellow Scrum<\/span> Masters to look to other fields for inspiration. One of the most important applications<\/span> is in highway management. <\/p>\n\n\n\n

    A 100% utilised highway is simply one big traffic jam. No one can move anywhere, which is frustrating, expensive and increases pollution. <\/p>\n\n\n\n

    Highways engineers are constantly looking at ways to improve the situation. The old-fashioned answer was just to build more and wider highways. Sadly, this just seems to increase the overall volume of traffic and means any traffic jam is even more disruptive! <\/p>\n\n\n\n

    Instead, the better approach is to limit the number of vehicles occupying each stretch of highway. This can be done in a couple of ways:<\/p>\n\n\n\n

    1. by controlling entry at the slip road, but this just moves the problem to the side roads<\/li>
    2. by pacing vehicles on the highway using lane markings<\/li><\/ol>\n\n\n\n

      To see why pacing works, think about what happens when you are travelling at full speed and suddenly come across a traffic jam. Every car now slows down rapidly, triggering a traffic wave<\/a> that eventually leaves the highway at a standstill. When it starts to flow again, all the vehicles are closely packed and the traffic jam will stretch a long way.<\/p>\n\n\n\n

      \"Scrum
      Scrum Masters can learn valuable lessons from highway engineers<\/figcaption><\/figure><\/div>\n\n\n\n

      Rather than allowing all the cars to bunch up and create a full highway, it\u2019s more efficient to adjust the flow rate. This is done by pacing vehicles and keeping them at a correct distance. That means they have time to react to any problem, thus improving the overall efficiency<\/span> of the highway. <\/p>\n\n\n\n

      Now, cars have time to react more safely to the heavier traffic and no one comes to a full halt. The result is a better-utilised highway. This may seem counter-intuitive, since it seems to create wasted capacity, but it is proven to lead to an overall increase in throughput over time.<\/p>\n\n\n\n

      \u201cJust in time\u201d and lean production<\/h2>\n\n\n\n

      Over several decades, Toyota developed its Toyota Production System<\/a>. This approach to manufacturing is sometimes called just-in-time<\/em>. It is based on the principle of delivering parts to the factory just in time for them to be used. This has a number of benefits. <\/p>\n\n\n\n

      Firstly, it cuts the need to store parts, allowing factories to be smaller. Secondly, it allows flexibility in your supply chain<\/span>. Thirdly, it means you can create a more predictable manufacturing process. This has since evolved into the Lean Manufacturing or Lean Production<\/a> approach. <\/p>\n\n\n\n

      One of the basic principles of the Lean approach is to deliver just in time.<\/em> This means that we need to constantly limit the work in progress and review our queue. This needs you to ask yourself the following questions:<\/p>\n\n\n\n