Implementing Scrum: Top Down and Bottom Up Approach

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.

Implementing Scrum 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 yourself.

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 the process.

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 room.

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?

Related Posts:
What does a Scrum Master do all day?
Your First Scrum is Going to SUCK!