I apply a lot of techniques in my work and I often explain those techniques to people in the training sessions and workshops that I run.
Sometimes the techniques are well documented on the web somewhere and I provide people with a link, but over the years I have also found myself summarizing many of them on this blog.
But since this is a blog, it is often hard to find things in it. So this page is really just an index to some of the articles that might be useful, broken into the topics that they relate to:
- Collaborative problem solving
- Defining the purpose of a team and helping them change
- Working in an agile context
- Communicating ideas to others
- Risk assessment and risk management
Collaborative problem solving
Some simple approaches
Value stream mapping: Using value stream maps
Card sorting: Card sorting – agile BA technique 158
The Cause and Effect clock (also a description of a baseline for coaching and an end to end workshop structure): The cause and effect clock for agile coaches
The Plan on a page as part of a workshop: How we defined the problem in our workshop, plus a plan on a page
Affinity diagrams: Collaborative problem solving with affinity diagrams
Force field analysis: How to use force field analysis
Trade-off matrices and several approaches to finding solutions: The humble trade-off matrix
Setting the scene by defining the problem
Some approaches to re-framing problems in order to tackle them. Can be used with a person or with a team in a retro or problem workshop
- Its a catastrophe – how does an agile coach respond?
- Its a catastrophe – option 2
- Its a catastrophe – the doctor’s office
- Its a catastrophe – the kindergarten approach
- Its a catastrophe – the reality check approach
Some question patterns that can help you get to the bottom of things
- Focusing questions and project charters are great, but where do you start?
- On the one hand, I always ask the same questions
- One the other hand, your question compass is better
Creating a project charter to set the team up for success: A project charter for lazy teams
Consolidating ideas and summarizing findings
The river diagram: Use the river diagram to communicate data
Quick voting approaches: Thumb based voting and 5 and 10 finger voting
Defining the purpose of the team
Understanding the value proposition and services a team offers
This is a series I did on defining the purpose of a team and then clarifying what the team does and what skills it needs to build:
- Defining the brand and value of a team (using a consulting team as an example)
- Defining the services that the team will offer
- Assessing the alignment of the stakeholders, services offered and skills available
Assessing the ability of a team or teams to adopt change
These articles look at the ability of the team to adopt new ways of working (and likelihood of doing so). I suggest starting with the easy one and then consider the others if you have time.
- Assessing the potential for change over a coffee and the general theory behind it
- A more detailed change readiness assessment – using the 7S approach plus a couple of questions
- Some more ideas that might be going over the top – I use this but it is a bit hard to grasp until you use it. It is called the Arenas of Change. If you are doing this then you will probably also want to consider where power is situated in a team since will impact the change effort
This will also help when the team is evolving (or even just cruising) – an article on pragmatic succession planning as your team evolves
Working in an agile context
Roles in agile projects
Agile is a mindset so you the roles depend on your context. But these are the typical roles that I come across:
Building agile roles from scratch using “speed dating:” Clarifying agile roles – speed dating? and a slight modification – Minor update to role speed dating
The BA: Business analysts on agile projects – why would you want one take 2?
One approach to BA work in an agile project (sneaking the BA in when nobody knows they need one plus applying an old school BA approach): A mechanical approach for a BA on an agile project
A rough view of what I saw happening to business analysts in agile teams:
The agile coach:
- This is a good summary of my conclusions: Extending the coaching agreement – what do agile coaches actually do?
- This then looks at how the agile coaches might play different roles: What does an agile coach actually do – is it really that simple?
- This is what they should not be doing: Extending the coaching agreement – when is an agile coach not an agile coach?
The Tester: What do testers do on agile projects?
The project manager:
- An example of an agile project manager when we do not have a separate PO and team facilitator True confessions. I was an agile project manager
- Agile project management when other people are playing the common agile leadership roles Leadership and project management in a typical agile team and how I often see this play out in practice Agile project management patterns
- Some of the major challenges that project managers face when going agile The problem with project managers and self managing (agile) teams and The problem with project managers and product based thinking
The Product Owner:
I have not created an article on this because I think it is really well covered in other places
- This is a great summary: https://www.kbp.media/product-owner/
- This video is also a great summary: https://www.youtube.com/watch?v=502ILHjX9EE
Story walls and other things you might see on the wall
- Notes on story walls – simple task walls
- Notes on story walls – story or task?
- Notes on story walls – longer term planning
- Velocity – What does a velocity chart look like in an agile team? and Velocity is great but meaningless on its own
- Risks and issues made visible: A risk register for lazy project teams
Starting out with a good agreement:
- An example of a coaching agreement: Rough example of a coaching contract
- An approach to creating an agreement: Notes from the secret agile playbook, creating a coaching agreement
Health checks and ideas for retrospectives:
- Assessing the value of a retrospective or other agile ceremony: Do you get value from your retrospective?
- Some alternatives for quick health checks Quick and easy health checks for Agile teams and Different Retrospectives and pre-mortems
Some approaches to coaching discussions:
- A high level view: Would you prefer coaching or coaching?
- The what-why-how pattern: “What why how” coaching for skills
- Tougher and more meaningful discussions (covered in a story-telling format)
- A general principle that seems to work: Dealing with your stakeholders – the bozzo hypothesis
Games to help people learn agile
My release planning game is free and covers a lot of learning around planning and re-planning in an agile context.
I love it and it works well, but it can be a little complex to master when you are facilitating it. Eduardo Meira Peres in Brazil came up with a much simpler version based on rebuilding the “lost” alphabet. This version is really simple to set up and run and focuses on understanding concepts like velocity and planning sprints to create iterative value.
You can find them here: Agile release planning game downloads
I have also slightly updated the “lost alphabet” version for use in some training courses – you can find it here.
I also like the “hard choices” game that helps people understand architectural planning and decisions in a changing environment. You can find it here – https://resources.sei.cmu.edu/library/asset-view.cfm?assetID=28919
I am still looking for a good game that really teaches the concept of estimating in an agile context – let me know if you find one.
Testing in an agile context:
Setting up testing in an agile team is both critical and seemingly one of the hardest bits to going agile.
- Creating a basic strategy: A test strategy for lazy project teams
- A complete guide to testing in an agile team (from me – a non-tester): A mechanical guide to testing on agile projects
- getting value from regression testing when it is not something you think will be fun
- Exploring the value of regression testing: Making regression testing suck less and yet be more effective – exploratory testing
- Day by day guide to getting regression testing going:
- Predictable errors to test for or anticipate
- International standard for being stupid – the errors we all make
- An international standard for being scared? – applying standard risk management questions to find potential issues
Communicating ideas to others
Creating a simple and pragmatic communication plan: Creating a basic communication plan
Presenting ideas to the team: Facilitation tip – introducing new ideas
When presenting ideas is tougher – Presenting new ideas – when you need to be more convincing and Introducing ideas when you need more credibility and When you lack evidence (or have too much)
Dealing with tougher situations
Challenging people who are doing the wrong thing: Coaching when they will do the wrong thing and Dealing with baddies on agile projects. But see also the links under “Setting the scene” as a part of collaborative problem solving
Understanding power and related issues before tackling people – Power, politics and readiness for change and Understanding the background to power in a group
Thinking things through before you dive in: The dark art of politics – do you need values or a brand to win and The dark art of office politics for IT leaders (part one – why is it stressful?)
Dealing with bias: Bias and decision making.
Converting conflict to collaboration: The Options Generator
Risk management techniques
Here are some approaches to assessing and analysing risks:
- Analyzing risk Risks in IT Operations – some analysis tools
- More risk management approaches: Unusual risk analysis techniques
- The prophets of doom (similar to a pre-mortem): A prophets of doom workshop
- Estimating risk impact: Estimating the cost impact of risks