Agile Methodology
Traditionally software development projects have been managed in much the same was as physical engineering: a long planning stage, during which no code is produced but lots of plans are produced, is followed by an intense implementation phase, in which the plans are followed carefully to create the final product.
When building a physical artifact, like a bridge, this methodology works well – everyone knows what the bridge is supposed to do, and the inflexibility of materials like poured concrete and steel means that once implementation is started, opportunities for change are extremely limited.
Agile methodology makes use of the fact that software is a much more flexible material than physical construction to mitigate one of the primary problems with traditional software engineering – the customer is often not entirely sure of how the finished product should work until half-way through the implementation phase.
The “Agile Manifesto” 1 provides the following principles of project management.
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
The agile principles recognize that software projects are subject to continuous change, both in terms of client expectations and underlying technology, in a way that traditional engineering projects are not, and that software has properties that allow different management techniques to be used.
- A half-built bridge is probably non-functional. With an agile methodology a half-built piece of software can be functional and usable, at least for a subset of its expected functions. This allows agile methods to provide customers with “continuous delivery”, a working piece of software at very regular intervals.
- A customer knows what a bridge will do from the start. A customer may change her conception of what a piece of software will do mid-stream, in response to being exposed to an interim delivery. Continuous delivery drives a process of continuous refinement of requirements.
- A customer can only provide continuous refinement in the presence of good information about the progress of the project, the limitations of the underlying technology and other factors. Transparency of process and high levels of communication with the customer are key to an agile approach.
Scrum
Refractions uses a particular agile methodology called "Scrum" 2. Scrum provides the planning tools to achieve the goals of the agile manifesto:
- A product “backlog” of prioritized work to be done. The backlog is made up of easily-understood “user stories” that illustrate an increment of product functionality.
- Completion of a fixed set of backlog items in a series of short two- to four-week iterations or “sprints”. The relative shortness of the sprints improves the transparency of the process and gives the development team regular and achievable goals.
- A brief daily meeting or “scrum”, at which progress is explained, upcoming work is described and impediments are raised. The daily scrum is at the heart of the process, allowing management to understand and resolve issues before they become serious (and unnecessary) delays.
- A brief sprint planning session in which the backlog items for the sprint will be defined. Much like a traditional planning process, but more effective because of the smaller development increment – there is less opportunity for error because the delivery is only one iteration away.
- A brief sprint retrospective, at which all team members reflect about the past sprint. Feeding the lessons of the previous sprint into the next sprint allows the team to self-tune and achieve more with each increment.
The Scrum process in a project can be visualized as a set of feedback loops with larger and larger cycle times. At the end of each two- to four-week “sprint” cycle, the project will have a working piece of software suitable for demonstration and discussion with the customer.
Why Agile?
Because building software is not the same as building a bridge, and traditional engineering project management methodologies do not reflect the way software is built and the quality improvements that can be achieved by having customers involved in the process all the way through.
How is Agile Different?
As a customer, you will be engaged in the whole process, not just at the requirements gathering stage. You will have full access to the project team, will receive regular demos of the project, and will have full access to the internal documentation and discussions that go along with software development. All to ensure that your participation is one of collaboration, not negotiation.
How is Agile the Same?
Planning and requirements are still carried out in an agile process, the increments of planning and delivery are just smaller. Instead of delivering the whole project in one development increment, several increments are used, with opportunities for review and change at each successive planning stage.