Implementing Scrum: Top Down and Bottom Up Approach Part 2

We've already discussed implementing Scrum from a top down approach and came to an interesting conclusion. Establishing trust between the Scrum Master and the Team is key in a top down implementation.

So what about implementing Scrum from the bottom up? This is sometimes referred to as the "grass roots" movement for Scrum where a development team decides to abandon some of the more traditional aspects of how they make software and move towards a more Agile environment.

This type of Scrum implementation can cause an entirely different class of ulcers for your average Scrum Master since the business employing everyone is not likely to be enthused about a large change in the way they interact with IT that they did not initiate.

In order to find a solution here we first need to understand the problem. Unfortunately, things aren't quite as clear cut as they would be with a top down implementation of Scrum. The reason here is that different businesses have different needs of their development teams and it might be difficult to communicate how Scrum fits into to all of that. So your first job is to find out what the business needs from the team, while there's no definitive list for this here's a few that I've seen as common:

• The business needs the product to be useful
• The business needs ALL of it's requirements met
• The business needs software quickly
• The business needs predictability

Understanding the businesses needs (which may or may not include "Being Agile" so much as "Making Software" or "Having Software") is the first step here. The second part is to actually give them what they want.

The Business needs the product to be useful

It's fair to say that somebody would eventually like to use this software. Since we're building software in iterations and we have either somebody from the business or somebody focused on the business's needs setting our priorities the end-product will be in a useful state much faster.

The business needs ALL of it's needs met

This also needs to be taken into account with two important caveats:

• The needs of the business at the start of a project rarely match up exactly with the needs of the business at the end of the project.
• It's impossible to gauge the usefulness of a tool until you have it in your hands.

Both of these problems are solved with one simple axiom: Ship software faster. Will the first release to production include all of the requirements laid out up front? No, but this release hits all of the primary concerns, you can begin using it almost immediately and we're working on the remainder of the requirements as we speak. This brings us to the next concern for the business.

The business needs software quickly

Very rarely are you going to get a project that needs to be shipped a year from now, usually it's a project that needs to be shipped today but will be shipped a year from now because that's how long it will take to create. So let's shorten that first ship date and satisfy the most important of the businesses needs now (or as soon as possible) and use their feedback to make the product better with the time we have remaining.

The business needs predictability

This last part can be a bit more difficult since we live in an unpredictable world but predictability can mean a lot of things. Instead of predicting "It will take us 13 months to finish this product", start with something like "I can have you something that works within 3 months and we can figure out where to go from there". While it may not be possible to predict with certainty everything that you can get done in 3 months you can probably guess that the team can get something that works done in that period of time.

I can go on about any of these topics way more but this is a blog post and not a thesis so I'll leave it brief for now. Here's the important part, you have to figure out what the business needs, tell them how you're going to deliver on those needs and then you have to deliver. That's important so it'll get it's own paragraph.

You have to figure out what the business needs, tell them how you're going to deliver on those needs and then you have to deliver.

The reasoning behind this is simple, management, your customers and/or the business that supports you needs to embrace Scrum every bit almost as much as the team. This is especially true since you'll be bugging them much more often for collaboration than you did previously. If you do it right though, you'll be able to show them results and results are difficult to argue with.

By delivering results you'll have gone a long way towards earning trust and that trust allows you to ask for things that you'll need down the road such as a path into the backlog for every stakeholder, a strong product owner (which you may not actually get to start with) and a little bit of understanding as to how development actually works.

Like most relationships built on trust, you'll need to extend yourself (along with the team) first. That may mean starting your first sprint without a full-time product owner or without a lot of room for collaboration on the backlog items.

Luckily though, you have the team to back you up here and they're primarily what you need to ship software. The team's performance is what's going to earn that trust from the business so get out of their way, let them ship software, keep the business off their backs and deliver software. When you're asked why your performing so much better, tell the world "Were doing Scrum now and it's going really well, we could do better though. I need some help from the business side for that."

Related Posts:
Implementing Scrum: The Top Down and Bottom Up Approach Part 1
What Does a Scrum Master Do All Day?
Your First Scrum is Going to SUCK!