Agile Development with Scrum
We’ve all been there: the project that never ends and no
light at the end of the tunnel. Nothing is more disheartening to a developer,
DBA or anyone else that may be on a project than a finish line that has no end
in sight or worse yet, one that keeps moving. Agile and Scrum development
methodologies aim to fix this problem and others by applying what will appear
to be common sense after you engage in the methodology for a few projects. This
article will get you acquainted with my now-favorite development methodology
that can really be used for any project, whether a SOX compliancy, a DBA
maintenance, or a standard development effort.
Agile development is a methodology that teaches some very
products based on need from high-priority down.
the absolute minimum that the customer wants.
waste from your projects wherever possible.
projects in short bursts, called iterations.
Agile has sprung many variants of these core believes. Scrum
is one of those children that is my personal favorite.
Scrum is a rugby offensive term
where a team pushes forward to score as a single unit. Scrum is a communication
methodology more than a development methodology and because of that, it can be
applied to almost any type of project. Scrum consists of the following core
customer lists all the features they want in priority order.
efforts are broken into 30 day iterations called sprints.
- Scrum teams are multi-functional
teams of 5-10 that contain all the facets of the team that is needed to
complete the projects. For example, you may have developers, DBAs and a business analyst.
have a daily stand-up meeting with the Scrum team called the Daily Scrum. It lasts no longer
than 15 minutes.
Product and Sprint Backlog
The product backlog
is a list of everything the customer wants out of their product. It is in
priority order. To kickoff the Scrum process, you have a Sprint Planning Meeting where you spend the first half of the meeting
picking what items from the product backlog you can do in the next 30 day
sprint with the customer. That list of items becomes the sprint backlog. The last half of the meeting is spent driving down
the feature into technical tasks without the customer. Sometimes these meetings
can stretch to be 2 hours. The important part of this is to make it a working
meeting and engage each of your team members. Once the team accepts its
responsibilities for that sprint, there’s very little turning back.
I typically like to have a room with wall-to-wall
whiteboards or I’ll put big butcher paper up and draw a grid on it. Essentially
the grid will look like this but you can alter it to your liking:
Feature / Story
Parking Lot / Descoped
Build a new BI proof of concept
Build a test environment
Improve scalability in SQL environment
Once you have the
features you’d like to accomplish over the next sprint, that list becomes your sprint backlog. You then draw out each
technical task it will take to get the three features you have listed in the
above grid to a reality. Each feature may have 5 or 20 subtasks under it. An
individual task should take no more than 2 days to accomplish. I represent a
task with a sticky note and will generally go through a pack per project per
iteration. So for the first feature above, you may tasks that look like this:
a data model
a test ETL process
out some stored procedures to access the data
a rough UI
Each of those tasks would have a sticky note in its square
based on where it is in the chain. I also put a rough idea of how many hours
it’s going to take. After complete listing all the tasks on the board, the team
then volunteers for their tasks. You may be surprised how well this goes. If
some tasks go untaken then a little prodding may have to occur but I’ve never
seen this needed. In reality, the above tasks would be pretty aggressive for a 30 day iteration so you may have to scale it back to a lot
more stubbing out of items or faking certain data.
Every day the Scrum team meets for a ritual called the Daily Scrum. This meeting should be in
the same place and time every day and last no longer than 15 minutes. Any
longer than that amount of time will cause people to stop coming. This takes
the place of your weekly one hour long status meeting and gives people a
general read on the project.
Most people do this in the room with whiteboards around it
and the meeting consists of the Scrum
master (project manager or team lead) going around the room asking three
questions of each member:
did you do since the last Daily Scrum?
are you going to do until the next Daily Scrum?
impeding you from completing work?
This meeting is not a problem solving meeting because
there’s just not enough time to make that happen. Generally if the Scrum Master
sees the meeting going off track with the third question more than a few
minutes, he’ll ask anyone interested in this question to wait after the meeting
to address it. I like to meet in front of our task chart and move the sticky
notes as each person answers the three questions. It adds an element of
peer-pressure to hopefully make a person feel they have to move a sticky note every
The Scrum Master takes notes of any roadblocks from work
(the third question) and his or her main job becomes removal of those
roadblocks. For example, a roadblock may be, “I can’t get the server
development group to return my calls on the server configuration.”. In this case, the Scrum Master jumps in and makes the
call or escalates the issue. Thirty days isn’t enough time to have too many
roadblocks and the Scrum Masters main job is the roadblock removal person. If
someone doesn’t have a roadblock for a week, them something may be indeed wrong
because everyone has an issue eventually that slows them down.
Remember, not every iteration must go to production but the
goal is to show client value in each iteration and when you try to add a new
feature, ensure that the client actually will use the feature. I know, this
seems like a obvious idea but it’s amazing how many
features (82% from a recent poll I read) go unused. If a feature is rather
large, break it into small chunks between iterations to ensure there will be
adoption. For example, if a client wants a rules management system, maybe you
code the rules into the DB in the first iteration and provide them read-only
access to them. In the next iteration, you give them the ability to modify the
rules. The old adage is small steps, small mistakes.
At the end of the iteration, everyone gets together for an
informal Sprint Review Meeting. This
meeting is where the product owners, the team and the customers get together to
demonstrate what they did over the last iteration. You can also invite anyone
else in the organization that you wish that may benefit. This meeting will help
steer your team to make sure you’re going in the right direction and is the
team’s payoff for such hard work. No matter how high in the organization the
customer is, that person should be there to partner with the team and show his
or her support. It’s fantastic PR for your team and it puts a face on the
customer to the team.
There should also be overlap between you iterations. For
example, as the team begins to wind down at the end, they should begin to plan
the next iteration to avoid peaks and valleys in work. Instead the goal is a
normal 40 hour work week with little overtime.
It’s important to note that you must morph the methodology
to what works for you. It may take two or three iterations before you start to
see a transformation but you’ll really see the change. In my organization, it
fostered an environment of collaboration and got rid of the statement, “I’m waiting
on requirements” (where the word requirements can be anything). I’ve used it
for both new projects and existing projects that are under way. With projects
that are under way, you may have to find a logical line in the sand to begin.
Lots of luck and let me know what you think by clicking Your Opinion below.