Another aspect promoted by Agile is the concept of frequent releases. To demonstrate this, I’m going to draw on a real, current project that I’m involved in. In this project, we’re developing a set of applications that contain approximately 15 major features between them. While there is a basic framework that ties them together, most components are relatively independent.
Waterfall Approach
With the project example above, we took a relatively normal waterfall approach. We started with gathering requirements, then created a design, did a lot of development and are now testing. The project timeline looks something like the following:
As is typical with long waterfall projects, several pieces work as expected but a number of issues have been found in the testing phase that are requiring considerable rework. Some of these issues are due to mistakes made back in the requirements gathering/design phase of the project. Since the project is being developed as a single, monolithic development, almost all aspects have to be delayed waiting on the rework of a few pieces that have problems.
The first pieces of this project started to move into production in January – 16 months after the project began. During that entire 16 months, the University gained no benefits from this project – no clients could use any of the work that had been worked on in the project.
Agile Approach
Now, let’s look at the same project and same timeline but using an Agile approach. With Agile, you organize the work into sprints (usually 2 weeks long) where you work on and complete a certain number of pieces of the overall project. At the end of each sprint, the work has been designed, developed, and tested and is ready for production. This requires a number of cultural shifts in the way we do work at Miami including the involvement of clients throughout the project to gather requirements, perform testing, and sign-off on completed work.
While work is completed every two weeks using Agile, it may not be in a form that’s ready for release to the general public. Typically, applications are released after a set of sprints have produced a usable solution.
Here’s a possible timeline for the same project with the same timeframe but using an Agile frequent release approach:
Note in this timeline that clients are able to use the first pieces of the project approximately 13 months before they could in the waterfall timeline. Any problems that are found that require rework only delay the parts that come after what has already been released. In addition, due to the increased client involvement and testing, rework issues should be caught earlier before they impact other aspects of the project.
What if the project were cancelled?
One more benefit of frequent releases comes in the case where the project is cancelled or put on hold in the middle of the project timeline. This could happen because of changes in business requirements, a realization that this project is requiring more resources than originally estimated, or a number of other reasons.
Below is a view of our project using the waterfall method if the project were cancelled 12 months into the project.
Note in this case that the project was cancelled before any components were released. Due to this, the work completed in the first 12 months of the project are completely wasted.
Now, let’s look at the same scenario using an Agile frequent release strategy.
In this case, some work is still wasted, but only about 4 sprints worth (8 weeks) instead of 12 months. The University still gets benefit out of the 11 features that were released prior to the project cancellation.
There are cases where projects are allowed to continue due to the work that has already been spent but which should probably be cancelled. Agile gives the University more flexibility to cancel projects that may no longer be in the University’s best interest.
Summary
Historically, IT shops have relied on large, monolithic releases at the end of a project to accomplish change. Redesigning our project plans to allow for frequent releases (whether you’re using sprints or not) can have real, tangible benefits to the University community and can help projects be more successful. When you undertake projects in the future, think about dividing up those projects into smaller chunks that can be released piecemeal and early on. The benefits to your clients and the University community may be significant.
Great post!
Another aspect of Agile to put your mind around in this scenario is how to handle an issue/bug found during testing. Keep in mind, the deliverable from the sprint is ‘done’ when the acceptance criteria for that particular user story has been met at the end of the sprint.
When an issue is found by the product owner (client), a new user story is created to resolve the issue and placed on the backlog (list of potential work for upcoming sprints). The product owner’s responsibility is to order the backlog. If the product owner deems the issue to be important enough or valuable enough to address in the next sprint, it gets ranked high in the backlog. If the product owner doesn’t deem the issue to be of enough importance or value to be addressed next, the product owner will order it lower in the backlog.
Assuming that every issue needs to be resolved immediately or at all should not be made. Depending on the issue, the product owner may be okay with leaving the issue as is and proceeding to more important, valuable deliverables.
Collaborate with your client before automatically proceeding with fixing every bug, particularly the small ones. Our clients have the best perspective to help us spend our time on what they deem to be the most valuable thing.
Nice post Kent!
Good Synopsis Kent.
Where’s the LIKE button on this thing?!?