Staying Curious with Clean Language

skillmatter
skillmatter

Recently Tony Piper and I had the privilege of presenting to the Digital Project Managers London meetup group about Clean Language and the use of two questions that could improve any conversation within an Agile space.

It was an heroic effort by us to cut the presentation down so people got to experience Clean Language for themselves within an hour and now you can view the results by watching the video here Staying Curious with Clean Language.

Happy watching.

What kind of Agile is that Agile?

"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.

Conclusion

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.

Planning for failure

How often have you sat down with your team and have asked them to plan a project to intentionally fail? Often we plan for success, we strive to be optimists and in doing so we end up believing we have covered all eventualities as fewer and fewer issues arise.

A deliberate exercise

In a group, your only requirement is to make the project a failure. What would that look like and could you do anything to prevent it?

Asking people that know the business and systems to tell you where your blind spots are will return massive results. Suddenly you are looking at extremes of failures and now have to ask which one can seriously hurt your goal or the project.

Asking a team that represents the entire business is beneficial as you gain different view points.

Asking a team made up of developers or just testers can also lead to interesting outcomes, as this SHOULD BE a representative team effort you should ensure that a mixture of people and skills are there to play.

Yes play, have some fun. Treat this as a game because you would be surprised at how creative people can get attempting to destroy a project.

Jot down on post-its, index cards or even on a white board something that could cause the project to fail. From Dave being abducted by aliens to a process not being followed correctly.

Once you all have had fun doing trying to destroy the project, a member of the group should be nominated to read out the first failure, discuss it and vote on a scale of unlikely to likely to hurt the project, then rotate to the next person in the group to read out the next failure.

Once you have those notes in some order on that scale. Ask people to vote on the ones they would like to see rectified, then ask people to take ownership if they can.

Yes even the Line Manager can take ownership to prevent Dave's abduction.

Plan to meet again to discuss if progress has been made on any failures and what is blocking that progress, can somebody in that group help or should it be flagged to someone else?

Even a temporary chat channel is ideal at this point.

It sounds like a retrospective from a sprint and in some ways it is, adjusting this tool slightly for another use can help uncover areas outside or inside the project that you and your team can control. Ensuring the business is fully aware of all the risks facing another successful project.

Happy failing.