Agile vs. Waterfall (Part 2 of 5). What is an agile methodology?Digital Project Management
Welcome back to part 2 of Agile vs. Waterfall. Our first part introduced the Waterfall model. In this part I will go into describing the agile methodology.
If you haven't read part 1 it can be found here.
Otherwise, lets dig in!
Agile development model
The basic idea behind any agile development process is that it is iterative or cyclic in nature, meaning that the implementation of the software happens incrementally. There are a number of different iterative approaches in existence today e.g. Scrum, Kanban, RUP, Extreme Programming, Rapid Application Development etc. As mentioned earlier I will focus on Scrum since this has gained the most media popularity amongst the methods.
Scrum is a way for teams to work together to develop a product. Product development, using Scrum, occurs in small pieces, with each piece building upon previously created pieces. Building products one small piece at a time encourages creativity and enables teams to respond to feedback and change, to build exactly and only what is needed.
The figure below shows an example of the Scrum approach towards software development.
Rather than creating all tasks and schedules up front, all time is time-boxed into phases called sprints. Each sprint has a defined duration, which is usually a few weeks, with a running list of deliverables, planned one sprint in advance. Deliverables are prioritized by business value as determined by the customer. If all planned work for the sprint cannot be completed, work is reprioritized and the information is used for future sprint planning.
In the figure it is seen that work is taken from an ordered list, the backlog, prioritized into sprints and then developed. Items at the top of the backlog are more refined than items further down. In order not to waste time and money, backlog items should only be expanded enough so that proper planning decisions can be made. For each backlog item, a user story, the implementation and testing is done in the sprint.
As work is completed during each sprint, it is continuously reviewed and evaluated by the customer. All work that is completed should be defined as shippable, meaning that it shall work as intended and have been through testing. As a result, agile relies on a very high level of customer involvement throughout the project since they need to validate the functionality and accept that it works as intended. This cycle goes on until the product is complete and ready to be deployed or deemed acceptable by the business.
Comparing this approach to the Waterfall development model, the business value is delivered constantly and at regular intervals, whereas the Waterfall model delivers all business value at the end of the project. By choosing the Scrum approach it can be easier to maintain control of the project with regards to cost, return of investment (ROI) and overall business value. It makes the project much more transparent. In a Waterfall approach it can often be extremely complex to see the total benefit of the project, until development is very close to being complete. This is not necessarily a bad thing about Waterfall though! More on that in the next posts.
This was the end of part 2. I hope it was understandable and informative.
Come back and read part 3: Agile vs. Waterfall. Cost, functionality and time.
Photo by The Chef!