Agile Software Project Delivery in a Waterfall World – Part 1

Agile Software Project Delivery in a Waterfall World – Part 1

For many years now those of us in the software development world have heard and participated in Agile development methodology.  It is really a great way to help shape, define and deliver an otherwise ambiguous project.  These projects move along well with short sprints and refactoring of user interfaces and services until upper management starts to demand project milestones, end dates and completion.   That’s where the trouble usually begins.  Suddenly, this iterative approach has to change gears having “signed off” requirements and feature/code freezes due to pressure from above, which ends up cutting off the iterative agile cycle short and  ruining the benefits of Agile.   Why do we find ourselves proceeding in what appears to be lock-step with upper management in running Agile software projects from the start, and yet the delivery, expectations and funding is always waterfall?

The answer to this question lies in the basic tenet of any engineering project, software or otherwise.  An organization as a whole, must undertake a project from inception to completion with the same philosophy all around.  In other words, you can’t mix methodologies between business operations and software project development.    More specifically,  the concept,  budgeting, funding and procurement early stages of a project must use the same methodology as the development, testing and rollout.   Businesses, small, medium and large, usually budget operations and  projects on a fiscal year cycle.     This inherently is a waterfall method and the expectations are that budgeted money is consumed and then something is delivered as a result.   Either that has to change to accommodate a software project,  or the software project methodology has to change to match.

 So how do we, as software professionals, work within these confines and still run projects in an Agile fashion to gain its  benefits ?   One way is to break up the sprints  and limit/focus the iterations so that  there are smaller goals,  sort of fitting revisions into a time box.  Such as “we will have 3  2-week sprints of UI design/prototyping”, instead continuing to have Ui design and redesign over the course of the entire project.   Another idea is to earmark sprints according to a milestone schedule to retro-fit  into a more waterfall framework.  For Instance:  sprint 1 – 3 are the UI sprints,  4-6 will be the data modelling sprints,  7-10 service and database development,  10-12 UI functional coding,  etc.

By using some of these techniques, the spirit of Agile development methodology is incorporated which will improve the final finished product.  The added benefit is that the owners and management team will see progress moving ahead.

Leave a Reply