February's topic is the SCRUM agile development method and will start with a short overview presentation by Shveta Mehtani. Also present will be a developer from a local company that is using SCRUM. We will be particularly interested in how SCRUM addresses customer involvement, tying back to previous discussion threads.
See the new book, Agile Software Development with SCRUM, by Mike Beedle and Ken Schwaber and the websites http://www.controlchaos.com/ and http://jeffsutherland.com/ for more information on SCRUM.
Slides from Shveta Mehtani's presentation
The meeting began with introductions - names, current position, agile experience or goals. Attendance was 28 or so, with about 10 going for drinks afterwards.
SYNOPSIS:
Scrum is an approach to systems development first presented to OMG in 1995 by two companies concerned over the lack of breakthrough productivity in object-oriented development projects. At its core is the philosophy that systems development cannot be well understood and planned in entirety, but instead must begin before everything is understood about what needs to be done. It is a "wrapper" around existing engineering practices, an agile and lightweight PROCESS to manage and control development.
MEETING NOTES:
Shveta Mehtani presented a series of slides that outlined Scrum, with everyone having a printed copy to follow. Along the way, questions were asked of Don Marquart and Darragh Murphy, who have used Scrum for 16 months at MTS. They represented, respectively, the development team and product management sides of the process. In these notes I will summarize the slides first and the MTS experience second.
Shveta indicated at the outset that most of the material for the slides came from www.controlchaos.com, and also recommended a recent book, "Agile Software Development with Scrum" by Ken Schwaber and Mike Beedle, from Prentice Hall.
Scrum is not an acronym (which is why I'm not writing it as SCRUM), but instead borrows the term from Rugby, where a team of players pack together around the ball and everyone in the pack works together to move the ball down the field. This image helps to serve the "aggressive removal of obstacles" that Scrum is designed to achieve. Scrum is intended for use by teams in environments where requirements are rapidly changing or initially unclear. The Scrum process has two phases: a short planning period where customers/product management work with the development team to choose what pieces of work are to be done in the second phase, called a Sprint.
Scrum is intended for use by small teams (< 10 people), with Sprints of 1 to 4 weeks. The goal of each Sprint is to present visible, usable increments of progress in the overall project. In the planning period, pieces of work are estimated by the development team to understand what can fit in the Sprint time frame. The pieces of work that end up being in the Sprint are assigned to members of the development team so each person has a clear idea what they need to do.
The Sprint is where the heart of Scrum takes effect. The team has total focus to work on the goal of the Sprint, with NO unwanted diversion. The team has a ScrumMaster who's responsible for protecting the team members from unwanted diversion. Every day, the ScrumMaster holds a 15-minute meeting with the entire team to ask each member: What did you complete yesterday? what got in your way of completing this work? what are you going to do today? Whatever obstacles got in the way of anyone's work is up to the ScrumMaster to remove. While the Sprint is underway, customers can't bother anyone on the team for more features or for support on other systems, technical hurdles are made visible as soon as they crop up, non-cooperation from other teams can be addressed immediately, etc. It is this swift detection and removal of obstacles that allow Scrum projects to maximize productivity.
At the end of the Sprint, a Release Meeting is held, first with a presentation/delivery of the increments completed in the Sprint, and "lessons learned" or surprises are reported. Then the planning period begins again; a new set of pieces of work are estimated, chosen, and assigned for the next Sprint. Typically the next Sprint would build on the previous Sprint. Alternatively, this is the time to decide the project should be cancelled or a change in direction should be made. This is why Sprints are kept short, so a project has frequent checkups on its value to the organization and how the process can be improved. This is also how a proposal to use Scrum might get off the ground, as the proposer can say, "Try it for 30 days, and if you don't like it you can kill it".
Don Marquart and Darragh Murphy from MTS provided useful examples and clarification of Scrum questions that were raised. Scrum is not a solution for poor requirements or a process to define goals; it can make the organization aware of the NEED to define goals. It doesn't make estimation of work any easier. Choosing pieces of work involves business knowledge, user input, and technical input. Once they are chosen, then estimations go into more depth and team tasks are broken out in more detail. Scrum does not address the breadth of possible projects within an organization; it's benefit is the Sprint has a definite goal.
MTS highly recommends the daily meeting take place DAILY; at least commit to meeting every day at the outset of using Scrum. This meeting does not have to be the first or last thing in the team's day, it can be held anytime, flexible enough to include part-timers and telecommuters.
MTS has used 5-week Sprints from the beginning, and it works well for them. Their Release Meeting is usually 4 hours. The time between Sprints can vary, but is usually a week or less. A piece of work might be desired that the team does not yet know how to implement; the goal of a Sprint can be to determine the feasibility of various implementations and choose one for the eventual implementation in a future Sprint, in which case the "visible, usable increment" delivered is a software description document or a protoype application. It is also possible to include refactoring in the estimate of a piece of work. The team for a Sprint is made up of whatever you need on the team; it may not be the same people each time.
Product Management has to sign off on the Sprint, up front, including whether the Sprint is strictly time-boxed or feature- driven. Ideally it is both, but if the functionality must be implemented, the Sprint may extend to complete it. If strictly time-boxed, the team may have to eliminate features delivered if they fall behind. It may be hard to reach the ideal until estimations get better and the use of Scrum improves. MTS would like to do more pair programming, to spread knowledge around, because right now they have 1-programmer backlogs when only one person can do what needs to be done. They are trying to get requirements to improve. Testing gets overwhelming; it is conducted by a separate team outside of the Sprint processes, and they are not always completed with the last Sprint's testing when the next Sprint is complete.
MTS likes that risk management is at a finer detail, with the Project Manager (ScrumMaster) having a daily handle on things. Their potential pieces of work are captured -- from anyone who has a suggestion -- in a database, but one and only one person is reponsible for prioritizing the pieces. They of course take input and meet to discuss and learn about the work, but one person makes the call, and MTS finds that to be useful in moving things along. They found it real easy to start using Scrum -- just went with it within a week of learning about it, not having much to lose.
Special thanks to Advanced Technologies Integration, Inc. for providing the space, refreshments, and support.
[I see that I left out a nice point made by Don Marquart, that the three questions asked daily can be boiled down to one as a refrain in each team member's mind:If what I'm doing is not going toward the goal of the Sprint, why am I doing it?
By the way, if you would like to contact MTS, Don's email address is don.marquart [at] mts [dot] com. Darragh Murphy's is probably discernible from that, but I did not ask him his.
Gordy]
The Agile Experience Group meets and collaborates to share experiences, suggestions, and ideas about moving software development efforts towards more agile, more lightweight practices. Extreme Programming (XP), SCRUM, Crystal, FDD, and ASD are agile approaches. See www.agilealliance.org
We meet in the Twin Cities, Minnesota area and are a special interest group (SIG) of the Object Technologies Users Group (OTUG). See www.otug.org.
To get meeting announcements, subscribe to our low-volume list server by sending an email to:
Agile_Experience_Group-subscribe@yahoogroups.com
or subscribe from the web at:
http://groups.yahoo.com/group/Agile_Experience_Group/