Let's be nimble, let's be agile

Maricris Nonato -

Programming in Ruby on Rails introduced me to agile software development. I have been used to development in the traditionally confusing and dirty process of coding system. Agile development is different.

In the good old waterfall model, there is a strict flow of activities and process that is followed in the exact manner as they are described. What I really liked about agile method is that its ability to be adaptive, thereby allowing more programmer sanity. As defined by Wikipedia,

Some of the principles behind the Agile Manifesto are:

  • Customer satisfaction by rapid, continuous delivery of useful software
  • Working software is delivered frequently (weeks rather than months)
  • Working software is the principal measure of progress
  • Even late changes in requirements are welcomed
  • Close, daily cooperation between business people and developers
  • Face-to-face conversation is the best form of communication (Co-location)
  • Projects are built around motivated individuals, who should be trusted
  • Continuous attention to technical excellence and good design
  • Simplicity
  • Self-organizing teams
  • Regular adaptation to changing circumstances

The scrum method is but one of the many (that I don't know of currently) and what we currently use in our team.

Scrum is an iterative incremental process of software development commonly used with agile software development.

During each sprint, a 15-30 day period (length decided by the team), the team creates an increment of potential shippable (usable) software. The set of features that go into each sprint come from the product backlog, which is a prioritized set of high level requirements of work to be done. What backlog items go into the sprint is determined during the sprint planning meeting. During this meeting the Product Owner informs the team of the items in the product backlog that he wants completed. The team then determines how much of this they can commit to complete during the next sprint. During the sprint, no one is able to change the sprint backlog, which means that the requirements are frozen for sprint.

-- Scrum in Wikipedia

The scrum system involves two roles which group different user roles. One role is directly involved in the dirty part of the task.. those directly involved with the code and the system. The other role is the one that influences the product specs and expectations. The user roles that are important are:

  • The Product Owner - this person is responsible for putting up the Product Backlog wherein all the specs and expected output go
  • The Scrum master - takes the lead on managing the specs and the Team itself, responsible for putting up the Sprint Backlog; measures progress, removes impediments, and leads the team meetings
  • The Team - usually comprised of 5-9 professional developers

Scrum method uses a Sprint cycle that is usually lasting from 2-4 weeks and no more than that. The method defines a process of three phases.

image from http://www.codeproject.com/KB/architecture/scrum.aspx

The pre planning stage involves everyone directly responsible to the product. This is where the requirements are set down at the start of the sprint and the product owner, scrum master as well as the team sit down and discuss the technical details of each task involved. After the details have been discussed, all tasks get estimates which should be a maximum of 16hours. Any task longer than that should be further broken down into smaller tasks. In relation to this, I would suggest using Evidence Based Scheduling and the Burn down chart.

The middle stage is where all the action takes place. This is usually called the development week. Here, everyone gets their peace and just do their job. Everyday though, the scrum master meets the team and addresses current issues. This is usually the same 5-minute stand up meeting used by XP (extreme programming method). A real quick communication exchange is key quality of the Scrum method. Each developers must update their EBS or BD chart as they progress with their tasks.

After the first two phases, comes the closure. Here, the key players are the testers or the QA team. They work on checking each tasks whether it has been completed or not. Any further ideas that might come in during this time should be included in the next sprint backlog. Bugs are also iteratively fixed until they are closed. When there are open bugs, then the sprint has not been closed.

The sprint cycle is further illustrated by:

The scrum is important for the following reasons:

  • solves the typical problems such as (1) changing requirements, (2) unrealistic estimates of time, cost, and quality of the product, and (3) developers are forced to lie about how the project is progressing
  • problems during the development itself get addressed very quickly
  • the requirements are set before the start of the sprint; should there be changes they are carried over to the next sprint backlog
  • at the end of each sprint, work is sure to be accomplished without sacrificing programmer sanity and even customer requirements
  • developers are given their own voice every scrum meeting
  • uncompleted new tasks are carried over to the next sprint backlog (EBS is a good asset/practice to justify work)

Its quite hard to let go of the usual Waterfall model or even Cowboy coding style, but everyday is a new commitment to improvement. The only key to improvement is the willingness to change. Or even if you do this practice already, it is best to review your day to day accomplishments.