Wherein the Hero Observes
I do like a lot about this agile methodology - the stand-up meetings, the transparency of the process, the use of user-stories to describe a feature. However, I've seen a few pitfalls occur that make the process a bit cumbersome - a tendency for the stand-up meetings to devolve, a fixed-role mindset, and a concentration on visible results.
Wherein the Hero Complains
Scrum itself seems to be great at project management. There is little in it that relates specifically to software development. Scrum gives advice on how to manage a subset of tasks within a set time frame with the specific goal that it can be delivered or given to someone else in a ready state. The various stages can be applied to any sort of project, which can be argued is one of the strengths of the system. It provides little guidance to help cull the backlog into a subset of work for a given sprint.
As great as the stand-up meetings are, there is a tendency for these to stop being status meetings and devolve into problem-solving meetings, or discussions between a subset of the Scrum team, or loud diatribes. Scrum itself attempts to address this by stating that status meetings are stand-up only (no sitting down, getting comfortable, and pontificating) and time-boxing them to fifteen minutes. This is a complete waste of everyone else's time, and should be taken elsewhere. I'm guilty of it myself, but I'm trying to get better at keeping the status meeting just a status meeting, and taking others to task for breaking the status meeting rule.
Scrum works best when the team comes together and work to address some lapse - such as a team member's lack of availability. But there is a natural tendency for the developers to be just developers, the testers to be just testers, and so on. The times we've gotten a lot of work completed was because people stepped out of those tendencies and realized we had a lot to do in some area and worked on getting those tasks done. Conversely, there is a bit too much emphasis on a team's self-management or self-organization. The participants have strength in a particular area; that is why they are on the project in a particular role. Cross-over can only lead to duplication of effort or lackluster results.
One of the better ideas in Scrum is that there is a shippable product at the end of a sprint. This means that user-stories were implemented end to end and tasks all verified and everything works properly. The idea being the code could at that time be in the hands of a customer. In practice, I've seen more concentration on tasks that have a presence in the user-interface rather than infrastructure or architectural work that is at least as important. There's no clear cut answer for how to address this - if someone feels strongly that something should be done, they need to convince everyone it is important in the planning meeting.
Finally, Scrum seems to provide little for the coordination of multiple teams. Certainly there is the possibility of joining in sprint planning, stand-up meetings, and retrospectives of other teams; but I have my own work on my own project that needs my time. Scrum has the concept of a "scrum of scrums", but this just sounds like too many meetings to be productive.
Wherein the Hero Changes
A few of the tweaks I've seen happen at work are:
- A whiteboard is set up to track everything within a sprint. A single color of post-it notes per user-story, and tasks within a user-story progress vertically from pending to development to verification through to completion.
- Using SharePoint to track the product backlog (this since proved cumbersome and the software change process is now used for this).
- Using a SharePoint wiki to author user-stories. This seems to work well when everyone actually participates. The end result is a user-story that makes for a comprehensive test plan and makes for a good demo in the sprint review meeting.
- Teams I've been on have been using a point system (e.g. 1, 2, 3, 5, 8, 13, 20, 40, 100) to measuring the amount of effort a user-story and tasks require. If a task is more than twenty points, it's too big and needs to be broken up.
- The verification of a task makes use of builds coming out of our continuous integration process as opposed to the formal build process. The CI server builds a lot more often, making it easier to verify a single item's completeness and provide feedback immediately.
Wherein the Hero Concludes
All in all, using Scrum has certainly been enlightening. I've grown rather fond of the methodology, particularly in the short and sweet status meetings and the transparency of the process. It's been nice to know what every one has gotten done and what they will do at every step - makes it easier for me to plan what I will be working on. I like having the dedicated Scrum master resource - the person I tell what is keeping me from completing my work and its their job to take care of it.
In practice, it takes some getting used to - the speed of iteration is faster than I've experienced in the past. There is a substantial amount of time wrapped up in planning and task allocation [that is well worth it], along with the overhead of tracking user-stories and tasks, but the results are fantastic.
Resources