"We be Scrummin'" is a play on Ice Cube's song "We Be Clubbin" mixed with the agile methodology known as Scrum. Now into our 24th Sprint, the Web Services team, at North Carolina Central University, is getting good at knocking out complex projects. With this blog entry, I would like to introduce you to Scrum.
It was nearly a year ago that we began using Scrum. I don't remember exactly how I fell upon it, but I remember we were getting slammed at work. The priorities were changing on a daily basis and we never had enough time to develop plans. As soon as we begin one project, the CIO was asking about the status of another. I was frustrated.
The appeal of agile, more specifically Scrum, was the short planning phase and the absence of a written document. The time we would have spent planning was time used to develop. At first, I couldn't believe my eyes. How was it possible?
The more I read up on Scrum and XP (Extreme Programming), the more I realized it could work for us. No, we don't develop software, but we do create dynamic web applications. The following day, I found a book entitled, "Scrum and XP from the Trenches." What a great book. The author, , spelled out the process of doing Scrum. From the planning sessions to the retrospective, it was all in there. I love it and highly recommend you read it.
Ok, ok, ok, what is Scrum? Scrum is simply a project management method. Instead of the traditional way (planning, pre-production, production, testing, review), we jump right in to the project and review our progress every two weeks. That is a very simplified answer, but that's Scrum in a nutshell.
At NCCU, we use Rally to keep track of all our projects. Rally is a web-based tool made for teams that use agile. The term “agile” describes project management methods similar to Scrum. Each time we receive new projects, we immediately add them to Rally’s backlog (project list).
At the beginning of our two-week Sprint, which is a blocked out time period used solely for projects, we review our backlog and select user stories (projects). Based upon the number of team members and total days of work (typically 10 days in two weeks), we can determine the number of user stories to choose. Our backlog is in priority order, so the most important user story is at the top and the least important is at the bottom. When selecting user stories for our Sprint, we start at the top (highest priority) and go down from there. The person responsible for setting priority is the Product Owner. This person can be a manager, director, or even president. Whoever this person is, they must have control over team priorities.
Once the user stories have been selected, the team reviews the description and creates tasks in support of the project. The development team has the sole responsibility of determining how long it will take to complete a user story, as they will be held accountable for finishing according to plan.
After sign-off by the team, the two-week Sprint begins. Each morning, the team gets together for 15 minutes to discuss the status of the Sprint. Each team member should answer three questions: a) What did you do yesterday?, b) What will you have done today?, and c) Are there any impediments? Did I mention that we're standing during this time? Yes, it helps keep the meetings short. The advantage of meeting each morning is to bring focus and alignment amongst the team. This time also helps flush out any known issues or opportunities.
One of the major changes we had to make during the early stages of Scrum was to get the team out of their cubicles and share a common area. We call this co-location. Additionally, the members break into pairs, where applicable, and work from a single computer. One person drives, using a keyboard, and the other engages through peer programming. This method decreases errors in the code and provides a better product.
At the end of a sprint, the team schedules a demonstration. We gather all of the decision makers associated with the project and highlight the changes we made during the past 10 days. At this point, we are open for feedback. Any suggestions or comments are immediately recorded and used during our next sprint. The benefit of doing this is client feedback during the process, not after. Through personal experience, I have found that clients don't really know what they want until they see it. The demonstration allows them to interact with the web site and make adjustments.
For the team, there is still a Sprint Retrospective. In this step, the team gets together and answers three questions: a) What went right during this Sprint? b) What could we have done better?, and c) What actions can we take in the future to be better? Based on the number of action items, we vote on three priority changes and incorporate those suggestions in the next sprint.
Scrum changed the way we do business. It has increased my team's morale and made completing projects much easier with support from our customers. If you haven't taken a look at Scrum, I would highly recommend you do. If I can help in any way, please let me know.
Until next time...