Learn more about how DevOps teams must adopt a more agile development process, working in parallel instead of waiting on other teams to finish their components or for resources to become available, brought to you in partnership with CA Technologies.
"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"
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
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.
Discover the warning signs of DevOps Dysfunction and learn how to get back on the right track, brought to you in partnership with CA Technologies.