I was working with a team when someone mentioned that they wanted to do “Agile with Rigour”. This made me very curious, so I discussed this with them. My summary of what they wanted was to do Agile – as the “with Rigour” is oxymoronic.
Work is complex, and to honour the empirical approach is harder. It requires trust, in order to be transparent. If you are transparent, then you can inspect and adapt.
There are a number of comments on the interweb that highlight that people are jaded.
From the “flaccid Scrum” blog by Martin Fowler to the many comments on social media.
A recent one that has caught attention was from a presentation by Ryan Lockard following interviews with some of the authors of the Agile Manifesto. The attention-grabbing quote is below:
Agile now means, we do half of Scrum poorly and use Jira – Andy Hunt
The challenges that following any of the agile framework presents is that you need to use the whole framework to get the real benefit. I have worked with teams using many frameworks, and the successful ones use all the aspects of their chosen framework with mindfulness and intent.
Scrum – start with the roles, artefacts and events – learn and grow using the values to guide interactions
XP – use all the elements and the values to guide interactions
Kanban – Employ all the 6 principles, particularly the metrics
Using the framework to help understand your context and situation and learn!
Don’t change the recipe until you have tried it
You want to make a cake, so you grab a recipe from a friend. You look at the recipe, change the sugar to salt, mess with the ratio of ingredients, and ignore the method. When the cake comes out of the oven, it looks bad and tastes worse.
Would you tell your friend that their recipe is wrong?
How many teams have you heard say “we do the Daily Scrum every week”, or “We do Kanban – but I don’t know the throughput”, or “We do XP, and we haven’t got our Continuous Integration server working”.
They aren’t using the framework!
I was playing chess with my son a few years ago, he saw a solution (great) and moved his queen to the perfect location.
“Checkmate!” he exclaimed – he had won, except that the move was illegal. The game was no longer chess – so it is arguable whether the victory condition was met.
It is football if you use your feet, if you pick the ball up – it is rugby. Lots of things change at that point.
Use Empiricism
The heart of the agile methods is to employ Empirical Process Control – Transparency, Inspection and Adaptation. When information is shared freely it allows people to understand the context of their situation – which improves communication and feedback. Having this openness allows empowered team to use the data to make decisions with the most impact. By having a tight feedback loop close to the data allows Agility – which is the point of changing the process - right?
This is why the three most used frameworks (Scrum, XP and Kanban) all rely on having feedback loops and pull based mechanisms to give the teams delivering the work the flexibility to focus on delivering value.
The ultimate indicator is the working product – the Done, potentially releasable product increment. If that isn’t built in a Sprint in Scrum or Iteration in XP, that is a great learning. In Kanban there will be a long cycle time to get the change to the customer. The transparency of having work finished is critical. When a team is starting out, there may be a long process after the work leaves a Development Team, this stabilisation time should be made visible.
Reveal not Resolve
The intention of the frameworks is to reveal, not resolve.
In a recent training Daniel Vacanti highlighted that the purpose of the Kanban board is to guide the team to ask the right question.
The purpose of the Scrum Master in acting as a servant leader is to guide the team through exploration and enquiry, rather than a process administrator telling people what to do.
Within XP, having at least a pair working every problem fosters collaboration to resolve.
This builds the intent of purposeful learning and curiosity.
- Is this the best value we can deliver?
- Is this the optimal way to solve the problem?
- What can we do as a team to improve?
All the frameworks are extensible
The whole point of a framework is to act as a skeleton, that you apply to solve your specific context. If needed extend it as necessary, in a mindful and considered way.
Every time you extend the framework it may work for a specific context or situation that you are in at that time, it does not guarantee that your extension will work in all situations.
There are many techniques that have emerged in the 20+ years since the Agile Manifesto was drafted. This does not mean they do not have any relevance or place in your team. Adding a complimentary practice to the base framework provides your team with more tools and techniques to solve whatever complex problem they are facing.
LeanUX, DevOps, Design Thinking, A/B testing, Multi-Variant Testing can all be used, on the base of your framework. The purpose of agile is to be iterative and incremental, on your product and your process.
What is your next experiment?
Allow your teams to be creative
You have a team of talented creative individuals – the challenge for a leader is to get out of the road and let them be creative. Blending the ideas of David Marquet and Jocko Willink, the role of each individual on a team is to take responsibility of the shared outcomes that the team is working towards.
Each person needs to own their stake in what the team is doing. It is up to them to understand the purpose, what constraints are in effect, and how to work with the people around them (control mechanisims).
Once the team have figured out what the sandpit looks like, then they can build the best sandcastle!
Most of the time it is a matter of shining a light on the goal, highlighting the guardrails, and getting out of the way.
How are you helping your team?
What is the smallest experiment you could run to improve?