Chances are, if you work in IT you’ve heard someone evangelizing Scrum and Agile software development. There are 3 topics that software developers shouldn’t talk about at cocktail parties: religion, politics and which method they use to manage software projects. Most developers each have a strong opinion of what works and what doesn’t. So what is this Scrum thing, and why does it matter to database professionals?
Scrum is a software development methodology. The whole concept behind Scrum is to break large development efforts into smaller components that deliver functionality. You may hear Scrum referred to as “iterative development”; one characteristic of Scrum projects is that they have frequent small releases rather than larger releases that dramatically change functionality.
A development cycle in Scrum is called a Sprint. Sprints focus on delivering one element of functionality suited to the short development timeline of the Sprint. Each project team is different, but most work Sprints in 2 weeks or one-month intervals.
Scrum uses some key artifacts and techniques to manage each Sprint:
- The Product Backlog – This document is used by the project manager (often called the Scrum Master on teams using Scrum) to prioritize requirements. As new requirements are written, they are inserted into the Product Backlog and then prioritized against the other requirements in the backlog. Each Sprint is organized by choosing one or more requirements in the Product Backlog which can be accomplished in a single Sprint.
- The Burndown Chart – This chart consists of the development tasks that will be accomplished during the Sprint. The quality of Burndown Charts vary, but the best kind include:
o Each developer’s name and the number of hours they are allocated to the project. Some charts include day-by-day allocations to allow for vacation time.
o Each development task, broken down to a very granular level. Some Scrum teams require that each task be no longer than 4 or 8 hours. Each development task is assigned to a developer. Tasks are ordered based on dependency so that tasks can build on one another to complete the Sprint.
o The actual Burndown Chart, which shows a graphical progress of the amount of work remaining over time. As the Sprint proceeds the amount of remaining work gradually reduces. Successful Scrum projects have a very measured and predictable burndown patterns. Projects that are not working properly have ragged burndown patterns, which are caused by things like sluggish delivery of tasks followed by overtime-filled days of developers frantically attempting to catch up. Scrum provides all of these artifacts and methods to prevent projects filled with this kind of desperation.
- The Daily Stand-Up Meeting – Each Scrum project has a daily meeting of developers and the project manager, which other stakeholders in the project may join. The meeting is called a Stand-Up meeting to convey the idea that it is a very short, focused meeting, usually no longer than 15 minutes (the idea being that everyone in attendance can stand for the duration of the meeting). During the Daily Stand-Up Meeting, each developer answers three questions, which the Project Manager/Scrum Master uses to keep the project on track:
1. What did you accomplish since our last Stand-Up Meeting (usually yesterday)?
2. What do you plan to accomplish today?
3. What, if anything, is standing in your way?
Testing and Scrum
You may be thinking that a 30-day Sprint is not enough time to develop and test an individual release, and many development teams would agree with you. Teams often operate development Sprints, delivering the results to a testing team at the end of the Sprint. As the developers start their next Sprint, the testing team is operating their own testing Sprint. In my experience this method seems to work better, however the testing team can be derailed if emergency changes or serious defects are noted. Testing teams need to plan great flexibility in their Sprints, and the corresponding development teams need to ensure that bug fixes are planned for so that they don’t derail subsequent Sprints.
How Scrum Impacts Database Professionals
Database developers will often find themselves standing shoulder to shoulder with application developers during Sprints. This means reporting to daily Stand-Up Meetings prepared to answer the 3 questions.
Database designers (those who create schemas and plan the databases architecture) may find that some of their work needs to occur before the developers can start their Sprint tasks.
Other items, like creating stored procedures, need to happen as the application developers complete their tasks and the project evolves. Planning and lead time are key for database designers, so they should take an active role in the planning of each Sprint.
Database administrators will find that Scrum will result in more frequent releases, but those releases will require less work. One mistaken often made by projects new to Scrum is to skimp on testing, and that can result in botched releases. To combat this, the database administrator should insist on a few things to ensure successful releases:
- First, every release script must have an accompanying roll-back script to undo any changes found to be unsuccessful.
- Each script must be tested in multiple environments first, thus moving changes from development to test to production fix environments. The more times the script is executed before going into production, the more opportunities to iron out any problems that might occur before they derail the release. Make sure that the roll-back scripts get tested too; this ensures that they can actually reset the environment back to its state prior to the release.
A few tips to work well with Scrum Teams
- Know your part in the process, and help your project manager (or Scrum Master, if you prefer) cultivate realistic expectations. One caveat of Scrum is that you “Embrace Reality”. In my experience, Scrum participants often commit to too much work as sprints are being planned. Think about your other allocations outside of this project, such as production support tasks; also consider bug fixes and (even though it shouldn’t never happen in a proper Scrum project – ha ha) emergency requirement changes.
- End each work day by making some notes about your progress and familiarize yourself with your task for the next day. In other words, prepare to answer the 3 questions (see above) at the next day’s Stand-Up Meeting. Make notes to use the next morning. I highly recommend ending the workday with this ritual instead of beginning the day with it. Why? Stand-Up Meetings often happen early in the day, and if something delays your arrival to work (an accident on the freeway, for example) you’ll still be prepared when you rush in the door. Those who follow this tip appear reliable; those who don’t appear incompetent.
- Scrum historically uses the terms “Pig” and “Chicken” to describe the various roles and stakeholders in Scrum. (This apparently comes from an awfully dull joke.) Whatever you do, don’t ever use these terms when working a Scrum project! Many people don’t know what the terms mean, and people don’t take kind to being called Pig or Chicken.
- Sometimes I see developers who are hesitant to answer the third question (What, if anything, is standing in your way?) because they don’t want broadcast their faults. This fear is irrational and counterproductive, and could be the most destructive habit to Scrum projects. Scrum uses this question to help the Scrum Master remove barriers before they derail the project. Repeat after me: The technologies we use are so complex that no one knows all there is to know. We all need help sometimes, so answer this question honestly when problems come up. You’ll find that talking about the issue will often give you the answer you seek, and others are there to help you succeed.
Scrum can be a catalyst for creating productive development teams, and with a bit of planning can result in a more effective solution for dealing with database releases.
For more information on Scrum, check out Scrum in 5 Minutes.