A primer on Agile software development

Until the introduction of Agile, the standard software development life cycle (SDLC) was a Waterfall approach, where each stage of the SDLC had to be completed before the next one could begin. Requirements had to be gathered in great detail. Design would only begin once the requirements were completed. Development began once the design was complete, and testing didn’t start until development was done. This method left those people with a vested interest in the project (stakeholders) wondering what was taking so long. There was nothing tangible to show that any progress had been made.

The basis of working Agile is the Agile manifesto from the founders of Agile: We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

• Individuals and interactions over Processes and tools
• Working software over Comprehensive documentation
• Customer collaboration over Contract negotiation
• Responding to change over Following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Let’s just establish right now that “Comprehensive documentation” is referring to planning and tracking documents, not user assistance. The point is that Agile values a product that people can use over writing about what that product is going to be or should be.

The introduction of Agile was a new way of thinking. Instead of detailed requirements, there were user stories. Each story identifies the person associated with the requirement, what the requirement is, and what this functionality will help the person to achieve. For example, purchasing agents need the ability to enter order information online so that it can be sent directly to outside vendors. This may be considered a very large user story, which is referred to as an epic. This epic can be broken into smaller user stories, which will make it easier to provide estimates and will enable work for smaller user stories to be associated with different iterations.

Some examples of smaller user stories that could be associated with this epic would be:

• Purchasing agents must have the ability to enter a vendor’s name, address and telephone number and associate it with a vendor number so that the purchasing agent can use the vendor number when placing future orders.
• Purchasing agents must have the ability to select from a list of standard products when placing an order so that consistent terminology is used and inventory can be tracked more effectively.

Using these user stories, the Agile team assesses and estimates the complexity of the software design and development associated with them. These estimates are in the form of points. The larger the number of points associated with a user story, the more complicated and time-consuming the design and development is believed to be.

Unlike a waterfall SDLC, which is a linear approach, Agile is iterative. Before each iteration, which is called a sprint, the Agile team agrees on the tasks they are going to complete during the sprint. The total points estimated for the completed tasks is referred to as the velocity. The planning for the next sprint should change based on what happened in previous sprints. For example, if the velocity for the previous sprint was 50 and the team had estimated they could complete 75, the team may select less user stories to complete and aim for 50 the next time. After a few sprints, the team and management can get a good picture of the velocity and predicted end date of the project, given the current scope and resources. That’s one of the benefits of Agile. The information learned during one iteration can be applied to the next iteration instead of identifying lessons learned at the end of a project so that they cannot be used until the next project.

A lot more can be said about Agile and Agile tools, but we’re hoping to just establish the background for you to understand the following series of stories. Debbie Kerr, Ursula McCloy and Fei Min Lorente are three people who work in Agile environments. This introduction will be followed by articles where each of them describe how Agile has been implemented at their work places. Although Agile provides a new paradigm for software development, it favours people over processes, making an Agile experience in one company vastly different from the next.