A Primer on Agile and Scrum Development Techniques
Rapidly evolving environment? Changing business needs? A basic primer on how Agile and Scrum development techniques help IT professionals quickly adapt to changing circumstances.
In 2001, 17 software practitioners met to discuss several different methodologies for programming. Out of this meeting came the Agile Manifesto, a new methodology for software development which challenged the idea of traditional sequential development.
This sequential method of development - the so-called waterfall methodology - was seen by many to be flawed because of its linear development. Each phase of development was segmented and given separate deadlines, providing for managerial control.
However, this meant phases could only begin when the previous was completed and there was little time for review.
In today's rapidly evolving IT and business environment, it's easy to see how this methodology became outdated and why there is demand for agile development techniques, which turn the waterfall methodology on its head.
Agile is an incremental and iterative methodology, which offers numerous opportunities for revision of a project as it progresses, ultimately created a product better suited to a client's needs.
The creators of the Agile Manifesto agreed on four key principles: individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation and responding to change over following a plan.
Under the agile methodology work is completed using a series of small stretches, known as sprints, which typically last for a period of two to four weeks.
Once these are completed, the work produced is reviewed, before the condensed work process is repeated again.
This means there are numerous opportunities for the direction of the project to be altered and potentially cuts the time it takes to get to market, as work on the different phases can take place simultaneously.
By undertaking frequent reviews, the developers can also ensure their software product is still as relevant to the market on the day it is completed as the day it was commissioned.
Several different methods of development came from the agile methodology, which focused on the philosophy of development, rather than how this can actually be implemented on the ground.
Scrum sets itself from the rest of these with its method of empirical controls, which address how the project will progress based on real-world experience rather than a projection.
After each sprint the scrum team meets with the intention of reaching an end outcome, often planning the next stage of the project.
Rather than a scripted set of actions, scrum is a framework which will allow the team to tackle the project as it sees best, based on its expertise in the area. The versatility of scrum development makes it appealing for a large number of projects, although those taking place in fast-paced industries find it to be most applicable.
The cross-functional teams used in the scrum methodology comprise of three roles: product owner, scrum master and team member.
Those taking on the product owner role are required to ensure the team understands the overall vision for the product, as well as representing the interests of the customer, and therefore hold the most responsibility.
The scrum master is charged with liaising between the product owner and the rest of the team and ensuring an obstacles to the team achieving the goals of the sprint are removed.
Finally, team members hold cross-functional roles which allow them to determine how the work will be accomplished during the sprint and ensure goals are met.
Team members are granted high levels of autonomy but will also act on the advice of the product owner. They will likely work within their own discipline, however, previous job roles will be insignificant when they form part of the team.
Among those which advocate the use of scrum is Microsoft. David Treadwell, corporate vice president of the .Net Developer Platform group at Microsoft, said although the methodology is not mandated, it is certainly encouraged.
Speaking to eWeek back in 2005, he explained: "We have realized inside Microsoft over the years that software practices we used in the mid-90s don't scale to the size of problems that were tackling today."