Mixing Agile and Waterfall on a project

I have been working this year for a startup to help a former boss with project planning, with time I took a more active role and ended-up producing the project management plan to roll-out this company’s system.

I am writing this post to explain the overall PM approach we designed for this company and to get your feedbacks and recommendations. I always like a bit of a debate!

Right now we have not started the execution of the plan, so our approach has not yet been validated by experience. That’s bad if you read this to learn from a real life example, however it’s good if you want to give me your ideas!

Scope

The scope of the project is to roll-out a large number of devices equipped with digital media signage (DMS) capabilities into public areas. I am not allowed to disclose too much details about the project. We don’t do software development, all components are based on COTS products, there is a significant component of the project dealing with building works and physical components (on top of screens and computers for the DMS).

Drivers

The subject matter led initially to a traditional approach of building things separately, test towards the end and also create upfront very detailed requirements to get contracts going. But I wanted to bring agile into the picture for a number of reasons:

• we wanted to leave the door open to changes to the product delivered by the equipment and upfront we knew that things will change in SOME of the requirements as the project starts to adapt to market demand,

• what we are doing is fairly innovative and I wanted to be able to show tangible results early to the management, I wanted to be able to show every 6 weeks “real” things they could validate.

Approach

I designed an iterative plan whereby every 6 weeks we would deliver systems that could be validated by product management. User stories/features are grouped in themes and each of the Stories are assigned to a specific iteration.

To give you a sense of the granularity, a Theme is more or less a self contained component: DMS, Monitoring System, Data Network, Site installation, Hardware build…

User stories are block of features. For example for the digital media signage systems we want to be in a position to validate “basic” features of the system after 6 weeks. Basic features will be defined as we get closer to the project kick-off (depending on market needs), however we already have a good idea of what it means: display a scheduled programme of contents, supporting images, RSS feeds, videos, flash.

There are Themes that required planning to be done outside of iterations. As part of the project we need to build physical structures following a specific design. For these I used a traditional approach: we did an upfront full requirements and design exercise and we know understand the planning for ordering the physical items, setting up the plant to assemble the 100 structures hosting the DMS. These activities cannot be done with an iterative approach unless we wanted to spend a lot of money on trial / error / adjustments.

I however maintain the iterative approach for such themes. I took the output of my planning and match milestones to my 6 weeks iterations. For example, hardware components will come after 12 weeks lead time, I then put this feature in Iteration 3. This way my product backlog spreadsheet will show all project deliverables match to iterations. Obviously we know these assignments stories/iteration cannot be moved (that will delay the project as it is actually the critical path).

So I ended up with a mixed approach to the planning, Agile for things that are “changeable” – mostly software related deliverables, and Waterfall for things that are realistically not changeable: building physical stuff.

I found that using this pragmatic approach gave us a good plan to start the project.

Now the proof of the pudding will be in the eating. Your comments are welcome.