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
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.
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.
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.
When to use it? If you’re being pushed to deliver by a certain time, to highlight the impact of this on scope.
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.
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).
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).
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.
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.
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.
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.
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
Here’s another good one that fits into the same bucket (agileinanutshell.com)
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.
When to use it? To put a smile on the face of your team and to secretly test your stakeholders…