Organizations Against Scrum: Iterations First

"Scrum doesn't work here"

"We tried Scrum and it introduced a bunch of problems"

"We failed a big project because of Scrum and management doesn't want to try it again"

I hear these things every now and then and they stick in my brain. My first thought when somebody says something like this is that Scrum didn't cause any problems, so much as it exposed problems that were probably already there. As you can guess, this can cause some mild discomfort in any development team.

For instance, you say, "We never had enough time for testing at the end of the sprint"

And I hear, "We trade quality for speed in development and we immediately see the effects of that decision within a sprint". Essentially, you're seeing that you actually do not gain any time by hurrying development in the beginning, you just push it off until later and that's uncomfortable for your PMO to hear (although your developers have probably been telling you this for years).

That isn't a problem with Scrum, but it is a bad habit your organization has developed over the years and Scrum will pull that out into the open for you to fix. This is not a failure of Scrum, in fact some would argue that it's the whole point of doing Scrum to begin with. If you fail to fix your testing problem, then it's likely that you'll feel the effects when testing comes around anyways. This would be true in a waterfall project as well, the only difference is that the time between the issue and the consequence is longer in a waterfall environment.

I could go on with at least a dozen or so more examples, but at least with this post, I'm not going to go into the myriad of different ways that you can force a development project to fail using Scrum (that's a very long post for a future date). I'd like to talk about how to reintroduce Scrum to a wary audience.

Don't call it Scrum.

Yup, it's that simple. Start with something basic like building in iterations. You can even grab work from the schedule based on due dates to decide on your sprint backlog if you can't get a product owner to provide priorities. Start building in iterations and inspect and adapt after every single one of them.

The iteration (or sprint) is the cornerstone of Scrum and also the hardest part to do because it exposes problems and this can cause some discomfort. You'll discover things like how poorly your team estimates or how bugs really affect the productivity of the team (this often hides in the latter part of a waterfall project and is quickly forgotten by the time the next project rolls around).

Solve these problems over your first iterations, earn some credibility and then start implementing more Scrum and Agile concepts. Remember that when attempting to convert a skeptic, the best way to start is to show them something concrete rather than asking them to take a leap of faith.

*Disclaimer* I'm not suggesting that you introduce Scrum to your team like this, if you're new to Scrum then try to do things close to the correct way as possible. The iterations first method should really only be used if your organization is specifically entrenched against Scrum to begin with and you need to establish Agile. *Disclaimer*

Related Posts:
Implementing Scrum - The Top Down Approach
Implementing Scrum - The Bottom Up Approach
Your First Scrum is going to SUCK!