Tag: Scrum

This past Fall, the only class I took was Project Management. The reason I signed up for this class was because I thought it would be a nice break from the classes I had been taking like Distributed Systems and Artificial Intelligence. Ha Ha Ha. Now I know why the PM’s at work have such long hours and pained looks on their faces (or maybe it’s because we use waterfall).

In order to give students in the class a full-on project management experience, our instructor broke us into groups, gave us some requirements from which we had to produce a working application. I ended up being elected the PM for my group. Since there has been a serious lack of coverage for Agile Software Development in my classes, I organized us to use Scrum because of an interaction I’d had at the Google Test Automation Conference (GTAC).

When I attended GTAC last Fall, I had a great conversation with a man named Pete from F5 Networks. We were sitting at a lunch table where we were supposed to be discussing Agile development. He told me that he had used Scrum and been pretty happy with it on his team. I didn’t get the chance to ask him how he had implemented Scrum, but he did tell me an interesting fact he had read. He said that he had read somewhere that of all teams implementing XP or Agile software development, the teams that used Scrum were more like to stick with and have success with that process. This stuck with me when I returned home and had to quickly organize our group.

Since I didn’t know anything about Scrum, I looked for a reference on O’Reilly Safari and found The Enterprise and Scrum
by Ken Schwaber. Appendix A, “Scrum 1-2-3” was most helpful. Not only did it have an overview of the whole process, but also included examples of the documentation typically used for a Scrum project.

 

Scrum documentation for a project manager consists of a Product Backlog and a Burndown Chart. The product backlog is a high-level listing of activities that must be completed, the number of hours the activity is expected to take, and a listing of actual hours spent as the weeks progress. Activities are grouped on the chart according to Sprints. (The sprint is the basic unit of time around which activity is organized, 2-4 weeks). The burndown chart is a more detailed listing of who has taken responsibility for which activity and how they are progressing. This chart, produces a weekly graph of how the team is progressing.

Based on our academic calendar, I broke up our project into 5 1-week sprints. It took, no kidding, 8 hours just to break down our tiny set of requirements into the 2 charts. Following the scrum methodology of teams being self-organizing, once I had the activities listed, I went back to my team and asked team members to volunteer for assignments.

As the weeks progressed, we worked hard on our project. We filled out the chart every week, activities were finished and our application was completed. No one stayed up all night and we delivered exactly what we said we would. Oh yeah, and I made an A! So, what worked and what didn’t?

Stuff that didn’t work so well:

Team members who don’t pull their weight mess up all of the assignments. We had one team member who volunteered in front of the whole team to take half of the programming assignments. Afterward, he decided not to do any work. Since the burndown chart was already filled in with his name on several assignments, it was difficult to figure out how to deal with the hours he was supposed to work but didn’t. We had to reshuffle several activities among team members which threw off our initial chart. We handled this by re-organizing the chart.

Activities that slipped became difficult to track. Since each activity is supposed to be listed in one sprint category, I wasn’t sure how to track that activity if it wasn’t finished by the end of the assigned sprint. We ended up adding a column for the actual total hours required since our chart initially only had estimated total hours required.

One of the basics of Scrum is having a 15 minute daily “stand up” meeting where everyone answers the questions, “what did you do yesterday,” “what are you doing today,” “what is blocking you.” Those daily 15 minute meetings did not happen for my group because our schedules did not match up at all. That said, I think these meetings are crucial to the success of a scrum project. People need to know what’s going on and who is blocking who. If we had been having the daily meetings, we would have known that our slack programmer was slacking much earlier. To me, this also means that Scrum works better if teams are co-located. My team was not co-located, which put a serious damper on having any meetings. This was also partly due to the fact that not all of us had equal access to computers at home.

Stuff that really worked:

We were able to re-organize every week depending on how well we’d met the previous week’s goals. This is really the greatest part of Scrum organization for me. When the one guy decided he didn’t want to program (to be fair, it was his last semester), we were able to completely re-organize for the next week’s work. We were also able to adjust the workload depending on who had more or less time to do work.

The charts made bottlenecks very clear. For about a week, I was the scrum master and the lead programmer. Everyone on the team, including me, knew that we couldn’t finish the semester this way, and our instructor noticed it from our chart and the number of assignments with my name attached. Because there is so much detail to be tracked for the Product Backlog and the Burndown chart, there is no way that one person can shoulder updating the charts and producing significant amounts of code. As I said, the whole team knew that we’d have to make changes, and we did. I pretty much handed scrum-master activities to someone else when we were half-way through the project.

Testing happened throughout the project which meant that no one had to stay up all night at the end. For this reason, I think that Scrum or any iterative process is highly effective. It was still challenging to keep the test team busy during the early and middle stages of the project, but we all felt better knowing that what we had produced was working correctly.

My conclusion about Scrum:

Project tracking, in general, is much more complicated than I had anticipated. Producing the artifacts for Scrum took some time and they were not always easy to maintain. Even so, I can’t speak for the whole team, but I know that I had a much better grasp of what was happening because of our documentation. I’m sure documentation is a challenge on any project, and the fact that we were able to keep up with ours is extra points for scrum. I think that iterative software development is much more effective and gives teams a much better chance to course-correct if something goes awry. The self-organizing aspect of choosing assignments also appealed to me. I am a tester, but I could see helping out with documentation or maybe switching and doing some coding on certain assignments. This aspect of Scrum seems likely to keep team members from burning out project-to-project while also providing opportunities to learn something new. I liked using scrum. Hopefully, I’ll have opportunities in the future to work on a team using Scrum.