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.
This is going to be the first of two articles discussing the top
down approach (Executive decides that the team should use Scrum) and the
bottom up approach (the Team decides that they should use Scrum). Both
introduce interesting problems, so they're both worth discussing. Let's
talk about the top down approach first.
from the top down can be a bit daunting,
especially if the team you'll be working with is skeptical of Scrum. In
fact, you may be walking into a room of developers who already see you
as a liability, rather than an asset, before you even introduce
Make no mistake, without the trust of the team, you are doomed for
failure. Without establishing trust, you can't really expect the team
to really interact and collaborate with a non-developer (the product
owner) or expect them to estimate their work if they've never done that
before. These may be new things to the team and they'll need to trust
that you're not wasting their time.
So how do we get it? You'll have to understand the team, help
them achieve their goals and hopefully earn a little bit of trust in
To understand the problem, you'll need to understand this
first; it's very rare to find a developer who'll tell you that they'd
rather spend more time in meetings and less time writing code. In fact,
if you're a developer working in a traditional command and control,
rigidly controlled PMO type environment then in my experience you
probably want nothing more than to be left alone so that you can simply
write good code.
So give that to your team. It's as simple as that. As plainly
as you can, implement Scrum by telling the team that you're going to
start working in iterations, they can choose the iteration length with
some basic guidance (you don't get a 2 year iteration), they can
estimate in whatever way they want, they're not going to be individually
managed and they can use whatever engineering techniques they want.
Bonus points if you can communicate this without booking a conference
The catch? They have to write and test their code and have it
all potentially shippable at the end of the iteration. When they're
done they'll chat about how it all went down and then do it again.
In essence, you have to tell them that you're going to get out of their way and do the job that they signed up for.
Here's the hard part. You actually have to do that.
We've already established that your first sprint is going to suck,
so don't try to implement every Agile solution you know right up front.
In fact, implement as little of Scrum and Agile as you can feel
comfortable with. Believe it or not, software developers know how to
develop software, so you'll still get something done that you can
measure and improve on for the next sprint.
This means that a lot of the techniques and tools you learned
at your Certified Scrum Master training are about to take a back seat
to the team's solutions. That's okay, these guys are smart and they may
come to a lot of the same conclusions on their own, even if they don't,
they may ask you for advice or come up with a better solution on their
own. It's not your job or role to tell the team how to do their job.
- If the team doesn't want to estimate with points, don't make them.
- If the team doesn't want to partner program, that's fine.
- If the team doesn't like sub-tasks, that's okay too.
As a Scrum Master interacting with the team, you care about
two things, that the team has everything at their disposal to do the job
right and that the team remains uninterrupted during the sprint.
Everything else is details and in the grand scheme of things, those
details are not important.
You'll find that this builds the kind of currency (trust)
that you'll need down the road as you guide them further down the Agile
path or begin to facilitate collaboration or any number of other things a
good Scrum Master should do.
Trust is really the secret sauce that you'll need here, the
team needs to trust you to guide them and you need to trust the team to
make great software. Once you establish that trust you can take the team
anywhere they need to go.
As a Scrum Master, how have you built trust with your developers?
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.