Reduce testing time & get feedback faster through automation. Read the Benefits of Parallel Testing, brought to you in partnership with Sauce Labs.
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
The Business needs the product to be useful
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:
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
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