Researching Scrum

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.

The Meetings

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).

Final Thoughts

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.

Scrum Process Diagram
Scrum Process Diagram

One thought on “Researching Scrum

  1. I work for a company that uses the Agile process, or at least some variant thereof. In general it is a good thing, but there are some weaknesses in it, mostly caused by poor management.

    First, ideally Product Owners would write the requirements in the form of User Stories, and the prioritize it so that the project team knows what it needs to work on. However, if your organization has come from a more traditional development system, then the Product Owner might write requirements in other documents, and then tell the developers to write the User Stories from those, and prioritize them themselves. This removes the Product Owner from the Agile process, leaving the Stories as a cheap stand-in for actual requirements, and breaks the cycle.

    Second, the Product Backlog should be a prioritized list of all the new features to be added, and the project team should be able to decide what stories to take up in a sprint, usually pulling from the top of the backlog (most important). At the end of the sprint, they show off what is done, and go on with the next items in the list.

    However, what usually ends up happening is that there is a fixed amount of work to be done (commitments to a customer), in a fixed amount of time (deadline), with a mostly fixed number of developers. This means that no matter what the team says they can accomplish, they must accomplish all of the work. What usually gets cut is the “non-essential” things like code quality, automated tests (unit tests, regression scripts), regression testing, and even sometimes the process itself.

    Both of these major issues could be linked to one root cause:managers not following the process and allowing it to work. If the team is not empowered to point out these and other problems and have them fixed, then they wont get fixed. Retrospectives are usually a good forum to point out problems like these. They get noted as problems, and, unless they are something the team can do internally, they get ignored.

    I don’t think that Agile is at fault here. I think it is more that Agile exposes existing issues, and possibly makes the issues more of a problem. Managers could get away with some of these cheap tricks when the only checkpoints where few and far between (beginning and end of projects), while checkpoints every other week show that the problem isn’t with developers not developing, but with the process not being followed.

    If you are considering implementing Agile in your development process, consider enabling your team to make reforms in the rest of your process to allow them to do their job.

Comments are closed.