As the saying goes, Scrum is easy, Implementing Scrum is hard. My CSM course taught that Teams go through transitions during Scrum adoption and it typically follows the phases of forming, storming, norming and performing:
Forming: doing something new is always fun, shakeups seem to spark more interest and commitment
Storming: the team realizes that it’s pretty hard, management sees the process “failing”, critical that the Scrummaster remains a solid coach
Norming: the Team starts to get into a rhythm, more Scrum rules get adopted, the team starts to self-manage better
Performing: the Team “gets it”, they adopt XP practices, self-manage almost entirely by themselves and really crank out great value
Seems logical enough for me, and having spent the last 4 – 5 months re-implementing Scrum I can say these are the phases we went through. I constantly refer back to my CSM training and am quite pleased I documented the process as far as where I was before it started and how I could relate what I learned practically. There are many negative “Smell of Scrum” type of posts everywhere, I am choosing to focus on how we de-funk-ified the smell.
I’m sure most Teams new to Scrum go through these same transition phases, here’s some of the bumps we hit along the way and how we dealt with them:
Forming
We have a small team filling support, professional services and development so there is overlap with the folks in the group. After some spirited lunch and learns with management and the team to point out what we were doing wrong, we all bought into the process. That’s the short version, it can be rough to be told you are wrong, but the point is we were ALL wrong. You fail, then you learn.
The Team was given 2 scenarios for handling the structure of the team, one being more client facing, the other strictly development. These scenarios outlined the pros and cons for each and at the end of the day the team chose to have 1 team for all of it. All was good.
Storming
The Team learned pretty quickly that the same people took the client related stuff and the same people took the development stuff. All teams are different, some people are great at certain tasks, others, not so much but the point was they were resorting back to the way it always was and there was some visible stress amoungst the group. I preach truthfulness and honesty constantly but it was understandable that folks didn’t want to call out other co-workers who they felt were under-performing.
Management was then starting to see lower productivity and they weren’t pleased, but I was happy the team was learning and re-iterated the importance of letting the team figure this out themselves with my coaching.
I introduced a few processes along the way:
- daily scrum tip: started with the foundations of scrum, truthfulness and then tips based on output of the previous day that would help
- Q&A: encouraged each team member to bring a question each day in “stump the scrum master” type of fashion
- $5 for being late to the standup (to prove a point, I was late on purpose the first day(shhh, don’t tell them!) to prove to the team I am committed to the process and I am not exempt from this rule.)
- Scrum scorecard: rated how we were following the rules
The Team decided after 3 or so sprints they needed to keep the process, but split the team back into Client/PS and Dev teams. Our retrospectives revealed some dysfunctional activities but we worked through them. I could see the clouds clearing up so I knew we were coming out of it.
Norming
The business started prioritizing better and providing more visibility into what was coming down the pipe so the Team could now understand context of what they were building instead of “you tell us what to do, we’ll do it”
Since we were following the rules and clearing technical debt we really weren’t establishing velocity so we started estimating bugs for the sake of getting better at estimating. I am sort of half-product owner as well as scrum master so I constantly hammered on business value and let the team decide how to achieve it. As long as they understood the business value, they would do the right thing.
Initially the team wasn’t completing all the tasks in the sprint so there was always spillover but they got better at it as time went on. We still miss a few tasks, but by and large we’re ‘done’ at the end to the point where it’s shippable and they can show business value at the demo.
Performing
After some pain, arguing, lower productivity and fun retrospectives the Team really started getting the hang of it and at the end of our last sprint delivered substantial business value and managed the sprint themselves. To put some context around it, the Team originally thought the Scrum Master was a project manager and was responsible for organizing the sprint, creating the agile wall, setting up the demo, reminding the team to wash their hands after they use the bathroom etc. When they hit this phase, they really understood that THEY are the process.
The business was also pushing for “more, better, faster” and has since learned that’s not the way to go. Trust the team and you’ll get results.
These are a few of the things the team is doing now that they weren’t doing well or at all before:
- writing their own tasks and breaking their own dependancies
- creating their own agile wall (I always iterated that the wall was for THEM, not me)
- entering their own issues into our tracking system
- adopted TDD and work agreements/rules within the team (that was based on management drive priority of zero defects and “do it right, not fast” That was based on a release the failed miserably due to “do it fast”)
- given value only, not a solution or a demand by the business
- defined done for tasks, stories, sprints and releases
In the case of the last sprint, the team was given a business goal and accepted the stories into the sprint. During the sprint our architect came up with something that would provide much better ‘bang for the buck’ and the team accepted their own scope change into the sprint all the while keeping the existing scope intact. Let’s just say they knocked it out of the park.
The moral of the story is, when applied properly, Scrum works. I cannot stress this point enough, trust the team, support them and do not give up. The whole company needs to buy in to the process or it simply will not work. Scrum is easy, implementing Scrum is very hard and requires a change in mindset. It doesn’t happen overnight and needs commitment.