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

key tenants:

• Deliver

  products based on need from high-priority down.

• Deliver

  the absolute minimum that the customer wants.

• Eliminate

  waste from your projects wherever possible.

• Deliver

  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

believes:

• The

  customer lists all the features they want in priority order.

• Development

  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.

• You

  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:

 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:

• Requirements

  documentation

• Build

  a data model

• Develop

  a test ETL process

• Stub

  out some stored procedures to access the data

• Develop

  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:

1. What

   did you do since the last Daily Scrum?

2. What

   are you going to do until the next Daily Scrum?

3. What’s

   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

few days.

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.