O the Agony - Merging Scrum and Waterfall
- by John K. Hines
If there's nothing else to know about Scrum (and Agile in general), it's this:
You can't force a team to adopt Agile methods. In all cases, the team must want to change.
Well, sure, you could force a team. But it's going to be a horrible, painful process with a huge learning curve made even steeper by the lack of training and motivation on behalf of the team.
On a completely unrelated note, I've spent the past three months working on a team that was formed by merging three separate teams. One of these teams has been adopting and using Agile practices like Scrum since 2007, the other was in continuous bug fix mode, releasing on average one new piece of software per year using semi-Waterfall methods. In particular, one senior developer on the Waterfall team didn't see anything in Agile but overhead.
Fast forward through three months of tension, passive resistance, process pushback, and you have seven people who want to change and one who explicitly doesn't. It took two things to make Scrum happen:
The team manager took a class called "Agile Software Development using Scrum".
The team lead explained the point of Agile was to reduce the workload of the senior developer, with another senior developer and the manager present.
It's incredible to me how a single person can strongly influence the direction of an entire team. Let alone if Scrum comes down as some managerial decree onto a functioning team who have no idea what it is. Pity the fool.
On the bright side, I am now an expert at drawing Visio process flows. And I have some gentle advice for any first-level managers:
If you preside over a team process change, it's beneficial to start the discussion on how the team will work as early as possible. You should have a vision for this and guide the discussion, even if decisions are weeks away.
Don't always root for the underdog. It's been my experience that managers who see themselves as compassionate and caring spend a great deal of time understanding and advocating for the one person on the team who feels left out. Remember that by focusing on this one person you risk alienating the rest of the team, allow tension to build, and delay the resolution of the problem.
My way would have been to decree Scrum, force all of my processes on everyone else, and use the past three months ironing out the kinks. Which takes us all the way back to point number one.
Technorati tags: Scrum Scrum Process Scrum and Waterfall
