Let me be up front about this: I think Scrum is a dumb name, especially for a development methodology. It's a reference to the part of a rugby game in which players wrap arms and heads around each other and push against the other team. Someone rolls a ball under their feet, and the action begins. It's clearly a team-oriented exercise, which makes a lot of sense as inspiration. But using that for a methodology name seems like a bit of a stretch to me. That may just because I live in a country where rugby isn't all that popular, and the term "scrum" is not used around the house much.
But that name is pretty much the only thing I don't like about the Scrum development methodology. It's an agile methodology, which means you already know I like it. It includes some very specific steps and guidance in the development life cycle. It encourages product owners, managers, and developers to work together towards a common goal. And it empowers each team member to make decisions appropriate to his or her role, rather than putting all control in the hands of one or two team members.
Specifics of Scrum
Scrum, like many agile methodologies, encourages a cross-functional team, which basically means that the "development team" is not just made up of coders, but includes designers, analysts, documentation writers, and testers as well. The usual role of project manager is replaced by a Scrum master, which is essentially a traffic manager for the project, in charge of making sure the Scrum process is being followed, coaching and refereeing the team, and removing impediments that are keeping the team from being productive. Responsibility for completing specific tasks are not divided amongst development team members, but rather shared by the whole team.
The Scrum process calls for dividing up the deliverables into chunks that can be fully launch-ready within a month. That is to say, the iterations are specified as lasting one month long, and those iterations are referred to as sprints. All functionality developed within any given sprint needs to be fully polished, tested, de-bugged, and ready for launch (whether it gets launched or not) at the end of the sprint. Actually launching the new functionality at the end of a sprint is a business decision, made by the product owner and stakeholders.
New funtionality that will be developed during a given sprint is tracked via a product backlog. This is a document that lists all functionality that should be built, and the relative priority of each functionality point. The list is managed by the product owner, who takes input from other stakeholders and adds it to the product backlog, and then gives each item a priority. That way any functionality can be added to the list of things to do, but each functionality point can be pushed to the top or bottom of the product backlog by the product owner.
At the beginning of each sprint the development team looks at the product backlog and indicates how much functionality they can successful deliver within the upcoming sprint. The amount that can be delivered is determined by the team, rather than by anyone who is not actually developing the functionality. The team members themselves bite off what they think they can chew, and then they are responsible for delivering whatever they have committed to. Their list of things to accomplish in the sprint is referred to as the sprint backlog.
The decisions about what goes into the sprint backlog are made at a sprint planning meeting, which is generally a half-day meeting attended only by the team members, the Scrum master, and the product owner. The product owner brings the prioritized product backlog to the meeting, and the team members bring their estimates for how long it would take to build the various product backlog items. They all work together to choose what can be built within the sprint, and then those items go into the sprint backlog. The development team decides how much will fit into the sprint, and the product owner decides which items should be chosen to fit into the time allotted.
At the end of the sprint there is another half-day meeting: the sprint review meeting. Generally this is open to all stakeholders and anyone the product owner would like to have attend. In the meeting, the new functionality that has just been created is displayed to the attendees. They are given the opportunity to comment and to ask for new functionality. The product owner acts as the gatekeeper for these requests. At the end of the meeting, those outside the team are dismissed, and the go/no-go decision for launching the functionality delivered is made by the team. This meeting generally happens at the beginning of the day that follows completion of the sprint's functionality, with the planning meeting for the next sprint following directly on its heels, at the end of that day.
Scrum and Team Foundation Server
Microsoft's Team Foundation Server (TFS) allows for a choice in development processes when a project is being created. TFS ships with two processes, and allows the end user to install additional ones, each of which customizes the TFS workflow to include the documents, work items, and development steps most appropriate to that process. A Scrum process has been created by the team that invented Scrum. It streamlines use of the Scrum methodology on a project, and includes product and sprint backlog documents, as well as a guide to developing with Scrum. You can check out the documentation for Scrum for Team System. The option to develop with Scrum using our development tool of choice is especially convenient.
The Scrum development methodology is easy to learn, highly efficient in dealing with the ever-changing product requirements we're often faced with, and very useful for properly setting the expectations of our product stakeholders. It seems to be superior -- at least to me -- amongst the agile methodologies. And it keeps product owners happy and well informed, which is really what we're going for, isn't it?
Ss.
No comments:
Post a Comment