Introduction
About seven months ago, the team at mSpoke decided to start using scrum as our framework for our agile software development. I’ve joked that I ‘drew the short straw’ and ended up serving as our first scrum master. Ironically, this also coincided with me taking over all product management responsibilities. At that time, I posted some resources which provided me with a good overview of the scrum process and promised an update on our experience once we got our feet wet. I never got around to writing an update (I’m sure you were all very disappointed.) A few weeks ago, I officially handed over the scrum master responsibilities to my friend and colleague John Campbell. Therefore, I thought this was as good a time as any to share my thoughts on the process. Plus I’m in a noisy hotel in Silicon Valley for the Always On Stanford Summit and can’t sleep.
In this post, I’ll share my feedback on the process, a few techniques we didn’t follow the letter of the ’scrum law’ and some creative ways I could imagine applying the concept.
Note: I’m not leaving mSpoke. Just the opposite, we have a lot of great stuff going on and my plate was just to full. Specifically, I’m still responsible for Business Development and Product Management.
Feedback on the Process
I’ve been involved in watching and helping get quite a few software products get out the door. At a high level, I would strongly recommend anyone consider using scrum for their software development management. However, like all frameworks it is only as good as the people involved in the process. At mSpoke, I couldn’t be prouder of the team I get to work with everyday! To be clear, if you have a weak team, no process is going to change the range of products you can create. This probably goes without saying, but I always get nervous when I read methodologies that present themselves as ’silver bullets.’ There is no substitute for great people!
Specifically there were three concepts I really liked about Scrum:
- The Approach to Estimates
- Common Vocabulary
- Sprints Driven By Days Not Tasks
Each of these three things are far from complex. Yet, I think their simplicity is actually part of the value. Scrum is a process that is easy to understand and apply. I was at Carnegie Mellon’s SEI before starting my Research Fellowship at the Sloan Center and watched to many companies spend too much money (in my opinion) teaching their teams how to apply the CMM methodology.
The Approach to Estimates
If you’re not familiar with Scrum, all estimates for a task are given for the time remaining to completion instead of the time spent. In general, this means that as you work on tasks the estimate should be revised down. That certainly isn’t always the case, sometimes a developer will work on a feature and end up realizing it is considerably more complicated than he/she anticipated. In this case, they would actually increase their estimate. The taks estimates are revised daily and relatively quickly the team ends up settling into a pretty consistent number of hours / day the total estimates decrease. (This is called the team’s velocity.
There are two things I really liked about this. First of all, when looking at the amount of work remaining and average velocity it becomes easy to quickly get a sense when a feature or set of features wil be complete. The other powerful thing is that likely delays are realized very quickly. Often in other processes I’ve used / watched, teams fool themselves for some amount of time by tracking how long they are spending on a feature and assuming they must be close simply because they are approaching the amount of time they estimated it would take when it started. This always seems to end up with trade offs being made after the team has already missed their initial deadline. In my experience, using scrum’s approach to estimating is much more effective at raising tradeoffs and challenges sooner.
Sprints Driven By Days Not Tasks
This concept actually took me some time to really grok. The sprints (or chunks of work) are also ‘time boxed’ instead of determined by a specific set of features to complete. The team works for a fixed amount of time against a set of work (called the backlog). However, time is the key unit not the work remaining. As John Campbell our new scrum master regularly said, “there is no penalty for getting done early.” Also, if you aren’t going to get all the features in the backlog complete then the team goes through an efficient process for making tradeoffs on what to eliminate. We did make a few tweaks to the process - both in terms of length of sprints and how to handle releases. (I’ll talk about that below) Sometimes the team realizes that for different reasons it doesn’t make sense to finish the work remaining and can’t come up with reasonable subsets so they ‘blow up the sprint’ and start a new one.
I think a lot of what makes this so effective is that it forces the team to step back at discrete units of time (end of each sprint) and look at what was accomplished and the velocity. Then we as a team pick a reasonable set of work to accomplish in the next sprint. The nice thing was that you also could look at the number of sprints left before a target release date and have a pretty good sense what could be included in the release by a certain date. Alternatively, you can push that target release date back or even move it forward.
Common Vocabulary
Finally I came to appreciate the set of terms that were coined by the scrum process. At first I found them to be a little cheesy. However, over time I really came to appreciate the fact we were all using words that had been clearly defined in a short 158 page book on Scrum. This is key because it really avoided us talking past each other and actually increased the transparency into the process. I realized that it actually saves considerable time to say this was our velocity yesterday for example and have everyone on the team know what you’re talking about. For a good list of the terms used in Scrum, check out Scrum Alliance’s Glossary of Terms or read Agile Software Development with Scrum. The only exception to this was the term scrum master, personally it never felt very comfortable but we did use the term. I think it fits John much better as we’re now one sprint in and he definitely has managed it masterfully!
Our Tweaks to the Process
We made two tweaks the process both around the sprint structure. The first is that we didn’t always follow the advice to always make sprints last 30 days. At first we did this with trepidation because the Schwaber’s book was so definitive about keeping to 30 day sprints. However, there were some outside circumstances that made a different sprint lengths more effective. Interestingly, over time this came to actual feel very normal.
Also, we ended up adding a concept which we’ve called Release Sprints to the process. These tend to be approximately 2 week ’sprints’ that are driven by bug reports (Trac tickets in our case) and run jointly by the scrum master and QA manager. We started by trying to include the QA process into the sprint and just include releasing as part of our sprint goals. However, we’ve found that it really does work better to have the process separate. We still try to remain disciplined to make sure each sprint ends with quality code in the system. But we’ve found there is no substitute for a few weeks of hammering on the system.
Creative Applications
I actually think many of the tenets of scrum would be extremely effective outside of the software development process. For example, mSpoke ended up moving to some better space about a month ago. The team focused on the move actually ended up using the scrum process to manage all the tasks that needed to be completed to effectively setup shop. I wasn’t part of that team, but it seemed to work well. I also found myself often thinking that many of the techniques could be extremely effective for managing consulting projects regardless of if the deliverable was a software application. As I thought back to my time consulting, I felt like it would have been a great framework to appropriately manage both client and the team’s expectations. Although this is purely intuition at this point.
Conclusion
Wow, if you’re still reading my sleepy thoughts, I hope this has proven useful! (And the typos and dangling sentances haven’t gotten too annoying.) The hotel is at least starting to quiet down. Please let me know if you have any questions in the comments below. Also, I’d love to hear your experiences with scrum or software development processes.
