EN 
JA 
IT 
ES 
The Troublesome Transformation
I thought I’d approach this post from a different angle – a case study of a team requiring transformation and how I acted in my role as a Scrum Master. Full disclosure, I made mistakes! There are things I did that probably made the situation worse, but anyone that’s been in a similar circumstance will know that Scrum Teams are challenging beasts. When W.C. Fields said “Never work with children or animals”, I feel like he’d have added Scrum Teams to that list if he knew what they were!
Okay, enough waffle. Here was the situation I’ll be discussing:
Situation:
- A clear hierarchy in the Development Team, with dominant members controlling events and processes
- A Product Owner nowhere to be seen (despite being the end customer)
- A complex web of roles/people in the organisation (Project Managers, Business Analysts, Release Managers and Support Managers) – none of whom were in the Scrum Team
- Mechanical Scrum implementation, where the Scrum team would identify improvements but then never work on them
- The customer complaining about the lack of functionality delivered and its quality
Imagine this was a scenario-based exam question in the PSM II – what would you do first as the Scrum Master?
- Re-instate the Scrum events and facilitate to get them back to achieving their intended purpose
- Coach the Product Owner on their responsibilities to the Development Team to get value back on track
- Manage the team and task them onto the most appropriate work to ensure Sprint Goals are being met
I’m sure most of you probably picked B – and you’d be right (in my opinion)! You chose the option that didn’t solve the problem yourself, and worked on empowering the team to fix themselves. Well, I chose A. By choosing A I became a crutch for the team and whilst this immediately made things better, in the long term it wasn’t the right technique because it masked the true issue – the team weren’t empowered to own their process! They had stagnated and lost the desire to improve the situation. The organisation kept hearing that there wasn’t enough being delivered, and rather than find out the root cause, they cracked the whip!
I’ve been lucky enough to work with quite a few teams in my time as a Scrum Master, and my advice to anyone wanting to make rapid change is to ask the Scrum Team three questions. This is the approach I took with a Scrum Team over a morning session.
What does the perfect Scrum Team look like?
The question removes the overt self-reflection requirement. It makes the team feel safe to suggest things they don’t currently do. Why do I ask teams this? All team turnarounds, like a product, should begin with a vision – where do we want to get to? Now-Next-Then the output for a process improvement workshop. This is a great input for future Sprint Retrospectives.
Which behaviours and what ethos do we want our team to embody?
Basically, a behaviour charter. It converts the team from individuals into a unit…a Scrum! They share their ideals. This is a great opportunity for the Scrum Master to coach about the Scrum values – do this AFTER the charter; don’t seed the outcome. Empower the team to define who they are. They aren’t just Scrum team members of an organisation; they are a collection that has its own personality.
What are our responsibilities in turning this around?
Venn diagram time! Circles for the team and the organisation. If you’re wondering what the overlap is, they’re the things that the team don’t know how to/who to fix them. Do they sound like impediments? Yes! The Scrum team have just identified the highest priority issues you should be working on facilitating an outcome for!
_________________________________________________________________________________
Whilst I didn’t necessarily start the transformation off in the most effective way, the above really helped me to step back and get the team driving the transformation instead of me. A good Scrum Master not only facilitates, but also questions, coaches and smooths the way for their team to make progress. If you can do all this indirectly, I think you can say you’ve got a pretty damn good, self-organising Scrum Team!