Having been a developer for a several years, I recently stumbled upon a term that was new to me. It’s called Scrum, and it’s a form of project management. With its beginnings in manufacturing I had my doubts that it would be a workable system for managing software development projects, however, the more I read about it and toy with the idea, the more impressed I become. This style of project management seems surprisingly agile, and really encourages cooperation and communication by all levels of the project team.
How Does It Work?
Essentially, you start with a backlog of items that need to be completed and work your way forward like any other type of project management. You have a meeting with all the project members, decide what will be the focus of the current development period (called a “Sprint”), analyze possible issues that may arise to slow the process, then go to work. Once you’ve finished the Sprint, which typically has a set time-period of 2-4 weeks, there is another meeting to discuss the progress made during the Sprint. In this meeting, incomplete items are returned to the backlog, and a demo of the completed functionality should be provided.
Who Is Involved?
The Development Team
As you might have guessed, this role is filled by a group of software developers who are to complete items for the Sprint.
The Scrum Master
While some of us are ready to pull out our 20-sided die and roll out some hurt on an ogre or two, there actually are some similarities. The Scrum Master is responsible for ensuring that all the Scrum protocols are followed by all members of the project, and that there are no issues that will prevent the members of the development team from completing their Sprint tasks.
The Project Owner
This role represents the customer. The person or company for whom the software is being developed. Of course, in development departments, this role may fall to a manager within the development company’s own ranks. The Project Owner determines what items to add to the backlog, and prioritizes the backlog to make sure that these items are completed in a particular order. The use of largely fictional user stories are employed to illustrate how a certain feature of the software will behave.
It all starts with a “Sprint Planning Meeting”, which should last no more than eight hours. This is where the team gets together and determines what is to be accomplished during the current Sprint’s timeframe. Communication between all parties is very important to decide what the development team(s) will be able to carry out from the list of items the Project Owner wishes to accomplish.
After the Sprint Planning Meeting, there are a couple of daily meetings. The first of these, the Daily Scrum, is centered around the core roles with a length of 15 minutes. During this meeting, group members discuss their progress since the last meeting, and their plans for the time before the next meeting. The second daily meeting, known as the “Scrum of Scrums”, is composed of a single member from each group discussing each group’s progress in the current Sprint. One important commonality between the two is the determination of any impediments to either a group or individual’s progress. Reporting this to the Scrum Master is a necessity so that they may carry out their function and fulfill their role in the project.
The Sprint Review Meeting, with a typical length of four hours, occurs at the end of each Sprint, and covers the accomplishments of the Sprint, and demos the work done during that time period. During this meeting, the work is showcased to the project owner for verification.
- All those involved are always informed.
- Developers are better able to focus on the task at hand with the help of the Scrum Master.
- The Project Owner sees regular status updates and demonstrations of their project.
- A lot of meetings may take away from development time, even if they are short.
- The process makes working from a central office almost necessary (no telecommuting is increasingly becoming a bad thing these days).
While the pros definitely outweigh the cons from where I’m sitting, I’m certainly not sold. It resembles a traditional project management schema in many ways, but enforces a strict protocol to make sure that everyone is doing their job. In some cases, this might lead to issues where developers may feel mistrusted by their supervisors, though I believe those would be a minority. Scrum really simplifies the process, and seems to make everything much manageable.