Lately, there’s been a lot of talk about Agile within IT Services.  Many universities and companies are successfully using Agile to manage their IT projects.  Agile promises a number of benefits that are very appealing to IT Services.  In this post, I want to point out one of those benefits that have been mentioned in Agile seminars I’ve attended recently.  I encourage others to post additional information about Agile as well.

Reducing Work in Progress

Traditionally, organizations (including Miami) have assigned multiple projects to individuals or groups concurrently.  In fact, we list the ability to work on multiple projects concurrently as a preferred qualification in our job descriptions.  This is measured as a metric known as the “Work In progress” or WIP.  Currently, IT Service’s WIP is around 80.

The diagram below shows a very simplified visualization of this scenario with 6 different projects for 6 different clients.  (Of course, not all projects are the same size, start at the same time, end at the same time, etc. but I’ve created a simplified example for demonstration purposes.)

In this simplified example, the WIP would be 6 as there are 6 concurrent projects for this person/group.  Notice in this scenario, we’ve stretched all projects across our available resources – everyone gets a little piece of the available resources.  Each project gets 1/6th of the available resources.  Also note that all clients have to wait until the end to get benefit from any of the projects.

Agile promotes a reduction in the Work in Progress.  For any particular person or team, Agile recommends reducing WIP to one or as close as possible to one.

Below is the same simplified scenario but with a WIP of one.

In this scenario, we put 100% of our resources on a single project at a time.  This allows projects to complete much quicker (every month in this simplified case).

To the client waiting on Project 6, nothing is different – they still get use of their application on July 1. However, the clients waiting on the other 5 projects get benefit much sooner than they would have in the original scenario (as represented by the blue arrows).  In corporations, this could amount to millions of dollars in additional benefit.

In addition, studies have shown that people think they multi-task well, but in reality, they don’t.  Just like computers, there’s a significant loss for context switching between tasks.  Reducing the WIP to as close to one as possible reduces the number of context switches taking place with developers.

This is, of course, a simplified example.  In the real world, you have the issue of the mythical man-month to contend with as well as other potential issues that affect the outcome.  However, studies have shown that the benefits of reducing WIP and the other Agile practices can still be significant.

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.