A Scrum-ptious Methodology?
The other day I attended the Chicago VSTS Users Group meeting where the focus of the meeting was the Scrum methodology. Ed Chaltry from Centare Group led the meeting. He probably felt like he was defending Scrum instead of just presenting it as there was a lot of good lively discussion. It was a VSTS meeting, so a couple of tools that work with TFS Conchango and eScrum were demoed a bit. The emphasis was more on Scrum than the tools, however.
What is Scrum? Scrum is one the agile methodolgies of software development. Wikipedia has an overview here. I have a decent amount of experience working in an agile development model: small teams, including users, SMEs and QA early in the process, following an iterative timeline. Only once, though, have I worked on a project that truly ran under the Scrum methodology. After attending the user group the other day, I was reinspired to evaluate and share my take on Scrum.
The gist of my thoughts on Scrum? Scrum works well in some instances and should not be used in others. I think there are some things to take from Scrum and use and there are some things to get rid of. Some things make sense to me and some I don't Wow! That's genious! Okay, okay. I have more thoughts than that. Below is a breakdown on what I like and don't like. I'd love to hear other people's thoughts.
Burndown
One thing I really like about Scrum is the burndown concept. Your backlog of tasks starts with initial estimates for time and each task is updated on a daily basis to reflect to the amount of work left. What I like about this is that you can see a great view of how your project is progressing. You can see if your estimates were off. You can see when new items have been added. And it is really easy and makes sense. No percentages complete, just what is left. It can all be rolled up nicely into a "Burndown Chart" to show you how your doing. Here's an example.
To get the complete picture, I like to add a line that shows the total estimate. At first you might think that that doesn't help much because it shouldn't change. Well you and I know that that isn't usually the case. This new line on the chart shows how many new items and how much work has been added to the iteration (just in case things slip you can see why, not that that ever happens). Scrum tries to protect the development process: it allows for new tasks to be added to your sprint backlog, there just not supposed to be new features. Again, I think this is not often the way things work out.
All Aboard?
This brings me to my next point. The business side of the development equation has to be on board with the Scrum process for it to work. That might sound obvious, but unless you have a strong voice that will respect the rules, Scrum isn't going to work out. The business will have to know that that new feature will need to wait until the next Sprint. So culture here is really important to your success. That's going to be true with any software development process. With Scrum, I feel like you really need that buy in.
Requirements Aren't Perfect
Like I said before, the idea of a backlog of features is great. "We need to be able to view our orders by state." That's a feature that is pretty straight forward. Put it on the list. Prioritize it. We'll get it into a Sprint and out in a release. Sounds good. But there are always questions to ask about those features. Or there are features that aren't so straight forward. "Our customers need a better view of their orders". They're never perfectly documented or straightforward when they come to a developer. The business analyst might capture what they think the user wants, but there's often back and forth necessary when you start building the feature. So how do you estimate for that? Do you pad for additional requirements gathering time? I think that is what Scrum wants you to do. And the first day of the Sprint is a planning day so you may get some of that done there. So this might be handled in Scrum, but this is one of the things that I think is much harder to do successfully that it sounds.
Long Term Planning
Something that I don't understand about Scrum is how it accounts for long term planning and changes from a technical standpoint. If you're building out a new system, there is going to be a decent amount of technical design required before any coding starts. There might not be any deliverable code at the end of this. Scrum seems to require a potentially releasable deliverable. That isn't always going to be the case. Somethings take longer than a month. For example if you're moving from from oracle to sql server and you know you can't do that in a one month period, do you do it as a sprint do you? Do you start the new work in a Sprint that won't yeild a release while continuing to deliver new features for the current system in a separate sprint? What if you need to do some evaluation of your application. If you were going to evaluate a new third-part toolset or tweak performance? Or if you're changing to a more service oriented architecture that you didn't realize was needed at first. How do you handle this? Can you add technical-only items to you backlog?
This is where I think the 2-4 week strict Sprint timeline breaks down a bit. I get that you can get a rythm going if your consistent, but I just don't think that everything can or should be done in such a strict timeline. What's wrong with a 3-month first phase? This may be where some semantics come into play. You could say that a 3-month phase is just three Sprints. Some things, though, should just be taken out of band.
Daily "Standup" Meetings
My last thought on Scrum is about the daily meetings. Scrum demands a daily "standup" meeting where the team reports quickly on what they've been doing, what they're going to be doing and if they have any roadblocks. Communication is important - no question. And I like the concept of team members committing to what they will be working on. But a daily 15 minute meeting never seems practical to me. Everyone is supposed to stand to keep things moving, maybe even pass something around to designate the speaker. And the Scrum Master is supposed to take issues offline for subsequent meetings. Sounds good.
Realistically people are on a roll come meeting time or they get distracted and pulled in different directions and can't make a daily meeting. At the very least this can cause someone to be late. This is killer if that person is the Scrum Master. Roadblocks that arise often involve the majority (if not all) of the team that is present, so it just makes sense to talk about them a little bit while everyone is there. Autonomy of the developers is a tenet of Scrum, yet developers have to check in every day. Or maybe you don't trust your team? That's one way it could look to a developer. Let's let everyone sink their teeth into something and do a couple days worth of work and then report back.
The daily stand up meeting is likely to fail. This can lead to resentment toward the whole process and subsequently low morale. Weekly meetings and the responsibility to raise issues as needed work better in my opinion.