Author: Alexey Krivitsky
"If you are a hammer - everything is a nail."
Over the last years we've trained an army of ScrumMasters and Agile coaches.
Sadly some of them can be dangerous. As they can be carrying hammers in their pockets.
That hammer is called 'Scrum' or sometimes is referred to as an 'adaptive team-based framework for process improvements'.
Watch out!
No, I'm not going mad. I still think Scrum is a great tool for some of us to get started gaining agility. I saw many successful implementations and happy endings. Still I know it is a dangerous tool. And shall be used with care and knowledge. And also - not always.
Joshua Kerievsky is speaking these days on the thing called modern agile - I even now have a sticker on the back of my laptop describing its four principles.
And one of them is "making safety a prerequisite" - that's they one on a blue background:
Joshua has lots of stories why focusing of safety at work is the key factor for increasing productivity, responsibility and happiness.
I recently had a talk with a ScrumMaster who said that he is not accepted by his team. The team hates Scrum. But since the ScrumMaster has the top manager's mandate to "implement Scrum", he is trying hard to convince his team. The battle is on.
Hammer is a dangerous tool. As well as Scrum or any other top-down change initiatives are. And some safety prerequisites need to be taken care of.
Individuals and interactions over processes and tools. We all know that, so how come we are keeping 'hammering people with Scrum'? (I'm pretty sure David Hussman has coined this term).
So how not to? There is an approach I'd use instead:
1. Respect what is there (sounds like a Kanban advice... so true!)
Talk to your team(s) and help them see where they are already good at, what's already working well. There is always something to be proud of. Spend at least 10% of the workshop time on this. This is vital
Then help them discuss the challenges they are having. Your goal here is to help them agree and find a common starting point. It can be anything from a prioritized list of impediments to a list of potential process improvements they are dreaming to make.
2. Connect to the purpose
Invite your product people and executives to shed some light on the upcoming challenges, projects and product development initiatives.
(By the way this is their main job. So don't be hesitant to ask and invite them over. Make them come, even for an hour or so.)
3. Facilitate collective process design
Yes, only now you are allowed to mention specific agile practices, like continuous integration, automated testing or pairing. You can even go further and start discussing some frameworks like Scrum.
But it won't do that. I'd rather start with agreeing on the core working principles we as a team want to stand for. Examples? Quick feedback. Automated everything. Early prototyping. Face-to-face collaboration. High team involvement. Freedom to pass... Anything goes as long as the team is in consensus on why this is needed.
You as a ScrumMaster (I'd rather call myself an 'agile coach' because this doesn't imply Scrum is the only tool I have) shall help understand why certain agile practices (like sprint planning or continuous backlog refinement) can be good experiments to start with to increase agility? That's where you should be good at. Initiate brainstorms, add your suggestions, tell stories, be listening and respecting. Don't insist or push.
These 3-point agenda can be nicely fit into a half-day or a full-day workshop. It is a great investment and can save you months of fighting, conflicting and resisting - tons of wasted efforts.
Remember, Scrum is never the goal. Agility is.
Write a comment