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:
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 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
To Do
Analysis
In Process
Verify
Complete
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:
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:
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.