10 killer visuals that every Scrum Master needs

10 killer visuals that every Scrum Master needs

Like it or not, scrum masters are constantly challenged on the value of agile. You need to be able to educate teams and stakeholders on the magic of working in this way. You need to remove the mystery and be able to evidence the logic and theories behind it.

You need these killer visuals up your sleeve.


1. Chart of productivity loss (Gerry Weinberg)– the perfect representation of the damage and lost time caused by asking colleagues to work on more than one thing at a time.

For example, if you have a product owner split across 2 products, this doesn’t mean each scrum team gets 50% of their time and focus. Each team will only get 40%, as 20% gets lost to context switching. Find out more here

context-switching_thumb

When to use it? To highlight to stakeholders the benefits of having your scrum team (including product owners) 100% allocated.

2. The cone of uncertainty –  in 1981 Barry Boehm came up with initial ranges of uncertainty at different points in a project.

cone-jpg

 

When to use it? To illustrate that we need to accept there will be a significant period of time before being able to reduce uncertainty of what can be delivered (and when) and as such any early estimates on cost and time are subject to huge variability.

3. The iron triangle(s) shows the constraints of project management, with the constraints considered “iron” because you can’t change one constraint without impacting the others. The original iron triangle, (the one on the left) proposed by Dr. Martin Barnes in 1969, follows a waterfall approach to product development: scope is fixed and resources and time are variable.

waterfall-v-agile-iron-triangle-v03

When to use it? If you’re building a team of individuals used to working using waterfall development / new to agile development, this helps demonstrate the important thing to remember is the difference between what is fixed and what is estimated. Unlike waterfall development, agile projects typically have a fixed schedule and resources while the scope varies. Find out more here.

4. Fixed time vs Fixed scope forecast – (Henrik Kniberg) 2 gems that add to the conversation started above.

fixed-time-kniberg

When to use it? If you’re being pushed to deliver by a certain time, to highlight the impact of this on scope.

fixed-scope-forecast

When to use it? If you are being pushed to deliver a fixed scope, to highlight the impact of this on time.

5.  Stacey matrix of  complexity and organisational reality (Ralph D Stacey) this shows the closer you are to agreed requirements and agreed technology the more you increase certainty. it also shows that even with well understood requirements, if the technology to deliver it is not understood (or vice versa), you’re still working in a complex space. Most software projects fall into the complex or complicated categories.

stacey

When to use it? When you’re having trouble getting stakeholders to understand the difficulty of accurate estimation in your teams early sprints. To highlight the environment you are working in when starting to develop a new product with new technology. Being pushed to work with requirements that are not agreed. How breaking work down into small chunks helps improve understanding and therefore certainty.

To take this a step further you could overlay the Cynefin framework (Dan Snowden). This model isn’t in as one on it’s own right as it takes a little more explaining to use as a stand alone visual. It does however work very well as a supporting tool (especially for the Stacey matrix).

cynefin-model

When to use it? When working in a complex or complicated space and being challenged that the team in not demonstrating best practise. To map out where your teams activities sit on the framework i.e. which bits are highly predictable, versus which require analysis or expertise to determine the relationship between cause and effect.

6. The build, measure, learn feedback loop (Reference: Eric Reis ‘Lean startup’) which demonstrates the need for and benefit of continuous feedback. It explains a more scientific, empirical approach to product delivery. Create a hypothesis, test your hypothesis, learn from it and use that information to determine next steps i.e. persevere (stay on the same path) or pivot (take a different path).

build-measure-learn

When to use it? To highlight the benefit of reducing your cycle time i.e. get feedback quicker. To explain the difference between a project (which starts and ends) and a product (which has a life –  the first release is just the start).

If you have a team that wants to explore this a little more, you could also look at using the mobius loop(Gabrielle Benefield) which provides a problem-solving framework, to help teams decide what to work on, and even more importantly what not to work on, based on delivery of value.

mobius-loop

When to use it? To demonstrate the difference between a project (fixed end date) and a product which has a life. Or whenever there needs to be a focus on defining and delivering value. PDF version is available for free here

7. Kanban board example(Reference: Essential Kanban condensed by Andy Carmichael and David J. Anderson) simple, yet articulates something very powerful.

kanban

When to use it? When introducing the concept of a visual board or kanban principles to newbies.

8. Strengths bell curve(Reference: The speed of trust by Stephen M.R. Covey) highlights the importance of hitting the sweet spot when striving for a cross functional team. If everyone stays focussed on working to their strengths or ignoring their strengths, it creates weakness for the team overall.

bell-curve

When to use it? When discussing the benefits of skills and knowledge sharing, or pairing with your team.

9. Henrik Kniberg’s Venn diagram – identifies the focal point for high performing teams as getting the balance right between 3 key drivers.

henrik

When to use it? If you identify that your scrum team is pulling themselves into one of the circles at the detriment of the others (typically the pink one), or if a product owner / external stakeholder is trying to push you into the yellow circle.

10. Scrum vs Waterfall (Scrum.org) – clearly articulates the differences between the 2 methodologies across 4 key areas

scrumbenefits1

Here’s another good one that fits into the same bucket (agileinanutshell.com

cost-of-change

When to use them? Educating stakeholders / colleagues familiar with waterfall, but new to agile.


Bonus – 11. Dilbert – if there’s a Dilbert cartoon about it, it must be interesting! If you show these to a stakeholder and they don’t get the joke…get your coat.

dilbert-agile-triangle

128c6f87-a881-41cb-ad46-ace12bd27e3f-large

When to use it? To put a smile on the face of your team and to secretly test your stakeholders…

Related Posts

Subscribe and get the ultimate office cheat sheet FREE, plus future posts sent straight to your inbox. No cost. No spam, ever.
There are 3 comments for this article
  1. Jim at 11:08 am

    Nice blog!

    The biggest point I try and make is:

    Agile is NOT cheaper. It does not reduce your cost. It REDUCES THE RISK of 1) developing the wrong product and 2) failing to deliver at all.

    If you want cheaper, you need to move to towards lean methodologies.

    Everyone has an opinion though. Just my 2 cents.

    Jim

    • Noel at 8:01 pm

      Indeed Jim. I also make sure I tell clients that Agile doesn’t deliver your scope quicker. It can deliver some of your scope quicker…

    • Robb at 2:36 pm

      Jim, I agree to a degree with you here, and I appreciate that this is your own opinion; however, I recommend you add a vital word in your point:

      “Agile is not NECESSARILY cheaper. It does not NECESSARILY reduce your cost.”

      If you’re developing a product and it takes you as long as it would do using a waterfall approach, as you quite rightly said, the risks are reduced but you probably won’t be saving any money (though you may be making money because of early releases of limited functionality – but that’s for another day).
      However, if you’ve just completed Sprint X and there is still 30% functionality to build but the customer feedback is that they are happy with what there already is and they don’t need anything more, you’re not going to continue just because there is still budget available. You’ll stop. This would reduce costs, thus making it cheaper.
      That’s why I find “necessarily” such an important word. Sometimes it is, sometimes it isn’t.

      Cheers

Leave a Reply

Your email address will not be published. Required fields are marked *