I was talking with a former collegue the other day about his desire to bring in a Scrum Master to help with their move to Agile. They had a pilot team running using a home-grown implementation and he felt it was time to bring in some outside help.
As I collected more data, it became clear he was looking at a larger transformation effort. This particular organization was large and complex (~300 people in the IT department alone) and the nature of their industry breeds more conservative and political culture which would make transitioning less about “Agile” per se and more about Lean. Arguing about what is Agile and what is Lean isn’t the focus of this post, it’s simply a matter of what approach to take for the transition.
So what is a coach going to give you compared to a Scrum Master? Scrum talks about a Scrum Master as the team facilitator, someone who is there to protect the team, remove obstacles and help the team function better. Essentially the scope of a Scrum Master is local optimization for the team. Once the team is optimized other business problems are going to be exposed and depending on the expectations that have been set, this can be a good thing or enough to kill your adoption.
A coach, on the other hand, will be focused on optimization of the organization. Often they are working and thinking on multiple levels and deeper when team output is exposing other organizational dysfunctions. Team symptoms such as bad estimates, missed commitments and poor quality are indicators there are larger organizational nuts to crack.
You’re Looking the Wrong Way
A client I’m working with had asked for me to put together a session on splitting stories and backlog grooming because they couldn’t figure out how to make their stories small enough to get done in a sprint. Management’s perspective was that the team couldn’t estimate properly and kept missing their commitments. I suspected this wasn’t really the problem and it was a great opportunity to help the team become aware of what the issues likely were.
After the session, I talked with one of the BA’s to collect more data about a particular story that ‘was impossible to split’. She explained to me that this story had about 30 different scenarios (it was a billing application with complex billing rules per state) and they couldn’t split it up since all the work had to get done for all states for the release. First I suggested the usual way of splitting, implement the changes for a company that has one facility in one state and go from there.
She said it wasn’t possible because there was so much effort to fully regress the application that they would have to make each change, manually regress the changes for all scenarios and then fix whatever got broken. Then I asked her about how they test the application and she mentioned that it’s all manual and very complex. I said it sounded like a case of 5% “programming work” and 95% “testing work” and she agreed. This problem was compounded by not wanting programmers to be idle since there so much testing effort, so they would make the changes, the testers would test the changes and the programmers would move on to the next batch of changes.
New issues would be tossed back into development while they were working on the next set of changes and this created a vicious snowball effect that was raising frustrations for the team and management as the release date got closer and closer.
The System is the Problem, Not the Team
To summarize, the team asked for help on splitting stories and the problems exposed were much more severe:
- Silos on the team: they felt they had no other option, the SM on the team promoted this behaviour
- Lack of testing automation: automation doesn’t solve everything but no unit tests and no automated regression resulted in extremely long regression periods
- Complex code: talking to the programmers revealed extremely complex and tightly coupled code which made even making changes difficult let alone testing and regressing. Ever hear programmers say the code isn’t testable? That was there reality in this case.
- Management frustration: desire to clamp down on the team more since management didn’t trust their estimates.
- Un-realistic release dates: releases were missed frequently all the while ‘gotta get done by this date’ attitude was still very much alive and well.
In this particular scenario a Scrum Master will focus more on local optimization yet the impediments the team is facing are organizational problems typically outside the scope of what a Scrum Master is. A Scrum Master will help the team optimize their process while a coach will be operating on multiple levels to figure out the root cause.
Another advantage a coach will have is that the scope of their engagement will extend beyond the team. To be blunt, the people with the power and influence to help with change are more likely to listen to a coach than a Scrum Master as the intent of hiring a coach is bigger picture thinking than hiring a Scrum Master.
Tips and Conditions for Being Successful with a Scrum Master:
- you’re starting with a pilot project and the scope is the team
- you have a tight budget to experiment with agile
- your organization is small(er)
- politics aren’t a factor
- flatter organizational hierarchy
Tips and Conditions for Being Successful With a Coach:
- you have no idea what to expect by ‘going agile’
- you’ve heard the good things about agile and want to see if you’re ready
- large(er) organization with taller hierarchy
- you desire training at all levels (organization, management and team)
- suspicion you’ll need to ‘sell agile’ to management
- organizational politics are an issue
In short, it’s really easy to under-estimate the time, effort and complexity of transitioning to Agile. A coach is going to help you understand the impact of the transition and help figure out a plan that will work for your organization. There are many tools and practices available in a coach’s toolbox that a Scrum Master might not have.
When you’re ready to try Agile, take a bit of time to figure out what skillset you need and talk to people otherwise you can end up just making the hill a whole lot harder to climb later on.