"We were never Agile anyway"
One of the worst thing I could hear as a new Agile Coach. After working with teams as a lead, I found I was still adjusting to a different approach. If only I had not let ego get in the way, I could have asked the team the following question.
What kind of Agile is that Agile?
To me, it's one where... well, actually, it's not about me. As an Agile Coach, being able to leave my bias and ego out of answering this question is the perfect way for me to help.
The status quo
Having moved from a Team Lead role to a Coaching role the transition has been interesting. Instead of serving the team and dictating how they will achieve delivery, I can now take a different approach that enables teams to decide how they will deliver real value. For me, that is the real goal of being Agile.
A team that is left to manage their own processes are still able to deliver and self-organise, however counter intuitive this may seem. In my experience teams normally nominate one person to speak to the business on their behalf to minimise interactions and distractions.
Disrupting the teams status quo and enabling them allows for more agility. The team no longer serve 'Time', 'Quality' and 'Features' in a vain attempt to be agile, they now can help the business by delivering real value in a responsive way.
Having reflection points instead of retrospectives are more useful. Lessons can be learnt at any time by reflecting back to the team or individual what has happened and by closing the feedback loop early with meaningful discussion, they can maximise the learning opportunity.
The power of language
There is a real risk of moving away from team development to siloed development patterns especially when an influencing force leaves such as the Lead, Scrum Master or Coach. In turn there is no one paying attention to needs of the team.
Consequences can include enabling the business to apply more pressure to deliver once they realise that the "team guardian" is no longer around. This highlights a new concern, were the team ever out of the siloed mind frame and did they ever own the process? No wonder a common team complaint is that they were never "agile".
By using clean language, you can ask the team a simple question. 'What kind of Agile is that Agile?' You can open the door for discussion. It's important to be open, honest and curious with it. Create a safe, trusting environment and discuss what works and what doesn't.
To enable real reflection let's take it a step further and ask 'What kind of X is that X?'. Where X could be the agile framework chosen, it can, in context allow the team to take real ownership of their process allowing for better team agility.
Experimenting with Agile and Clean
At work I was shown the Clean Language model created by David Grove and 'The 5 minute coach' by Lynne Cooper and Mariette Castellino. I haven't looked back and I am now able to have great conversations that enable a team to find their own solutions. My agenda no longer interferes and I meet the team where they are and can then guide them towards improvement, using what they know.
Recently, I worked with a client using the Spotify model. Each squad could identify their bottlenecks to delivering value but were unable to make any process changes. In turn throughput and quality hardly improved for various reasons.
The first step is to understand where the team is now with their process. Observing one period of work I discovered various process blockers that I felt wasn't working for them. Such as story pointing, missing requirements and having various stories all in progress. Often with one developer owning up to three at a time, if not more. A story I'm sure we are all familiar with at some point.
As a coach it's important to make a safe environment for experimentation and to build trust with the team and business. I make it quite clear to clients that I need the freedom to enable the team. I sometimes like to believe that this can involve but is not limited to my tried and tested techniques such as "Boat rocking", "Throwing the rule book out" and "Just going straight to the source for information".
I then offer the team, no, insist to the team that they can "blame the coach". Building a safe space for experimentation and failure if something goes wrong, the team are able to do their best, safe in the knowledge that if it goes wrong, no one will be blamed for trying. Well apart from me and that is ok.
In this instance I focussed on Improvement actions that would be owned by individuals and benefitted the team as a whole. I am a firm believer that the team own all the actions and an individual or action champion should take ownership of it.
The important step to take was not to rush in and rescue the team but to coach them into creating small improvement actions. Instead of using tried and tested "Mad, Sad and Glad" or the "4 L's". I would use a couple of clean language questions to get them started. The team then created a list for each action, explaining what steps were needed to get the action to "done".
By asking "and then what happens?" ensures that we capture as many steps of the process to delivery as possible.
Asking "what happens just before X?" ensures as much of the work required has been thought through.
Then asking "what needs to happen for X?" or "can X happen?" Allows the team to highlight issues, such as needing approval from another department or a change to infrastructure because it's too problematic to work with.
Walking through the actions can highlight impediments early. The team and not one person are responsible for the change and their commitment to it.
The results were striking in this one case. Switching to no estimations as an action and measuring cycle and lead time instead, the team were able to improve and gather feedback instantly. They kept an open mind during the experiment. Ensuring they closed the feedback loop as soon as possible. They even paired up, which is no easy thing to ask a team to consider let alone do.
They now continue improving their process without relying on a particular role to lead them, finding further improvements they can make and experiment with.
My job now is to ensure they are not leaping too far ahead with the amount of enthusiasm they possess. Experimenting in a manner that allows them to change their process and habits.
I must caveat the above with a warning that this wasn't the first team I had helped. It was one that made the most progress as I refined my questions and approaches. Something I might talk about in another post.
Using a coach to guide teams until they are running processes without one, may mean I put myself out of a job at the end (which in reality is the goal of all coaches) in the hope that the team improve upon the process themselves. Teams and individuals tend to reinforce positive behaviours, especially when they demonstrate the value of their work inside an agile process they own.
So. What kind of Agile is that Agile?
and for me, that is a good place to stop.