4 ways to make agile and waterfall work together

4 ways to make agile and waterfall work together

4 ways to make agile and waterfall work together

Whether it’s a consulting engagement or an internal software project, IT departments like the flexibility and productivity of an agile project. But in selling the project to upper management and the finance organization, waterfall concepts will nearly always be introduced as requirements. If you think hard about it, agile and waterfall are nearly contradictory philosophies. So how do you get them to work together? In too many software projects, particularly those involving consultants, it’s a pretty uncomfortable marriage. Unlike the song, opposites do not attract.

Since waterfall involves a fixed specification as well as a fixed budget and schedule, the flexible (or only vaguely-defined) outputs for sprints will mean a fair amount of tap-dancing. However, this can work when waterfall’s “specification” is ill-defined (because the customer does not know what they really need) or malleable (because an executive decides to preempt things). But beware: this tactic only works when vigilantly and aggressively applied, forcing conversations about de-prioritizing deliverables and avoiding scope-creep throughout the project.

Read Also:
Data lakes, don't confuse them with data warehouses, warns Gartner

Best Practice: Explicitly manage expectations in writing at the start and end of every sprint. Further, have a customer signoff for each feature delivered during the sprint.

Worst Practice: Head-in-the-sand behavior, hoping that the issue will just take care of itself.  

In waterfall projects, clients are used to the idea of change orders (and of course your contract stipulates them, right?). So, use that mechanism early and often. In one $700K project we were involved with, over 50 change orders were issued (even though there was only a tiny overrun).   The change orders need to be included as formal addenda to the statements of work (SOWs) and include a customer signature so they have contractual impact.

Best practice: Promptly issue a change order for every vaguely-specified item when the vagueness gets ironed out. Change orders should include both schedule and cost impacts, as well as feature details.

Worst practice: Delay or even skip the issuance of change orders, leaving it to “a verbal understanding” that will quickly be forgotten.

Read Also:
The Evolving Cybersecurity Regulatory Environment: Tracking Current Trends and Staying Ahead of the Curve

In typical software projects, an initial fixed-cost phase (comprising 10 percent to 25 percent of the total project effort) is devoted to the requirements discovery process. The output of that process is the statement of project functional requirements.   Even though it is common to discover many details after that first phase, these new items are not the project implementer’s problem: they are the consuming or client organization’s problem. They should not be accepted as binding requirements without a change order.

 



Chief Analytics Officer Spring 2017

2
May
2017
Chief Analytics Officer Spring 2017

15% off with code MP15

Read Also:
How analytics can prevent rather than explain tragedy

Big Data and Analytics for Healthcare Philadelphia

17
May
2017
Big Data and Analytics for Healthcare Philadelphia

$200 off with code DATA200

Read Also:
Monolithic vs. microservice architectures for innovation

SMX London

23
May
2017
SMX London

10% off with code 7WDATASMX

Read Also:
The Evolving Cybersecurity Regulatory Environment: Tracking Current Trends and Staying Ahead of the Curve
Read Also:
Focus on Benefits Rather than Features

Data Science Congress 2017

5
Jun
2017
Data Science Congress 2017

20% off with code 7wdata_DSC2017

Read Also:
Monolithic vs. microservice architectures for innovation

AI Paris

6
Jun
2017
AI Paris

20% off with code AIP17-7WDATA-20

Read Also:
71 percent of Australian-used IoT devices failed privacy probe

Leave a Reply

Your email address will not be published. Required fields are marked *