Agile Lessons: Where Waterfall can Learn from Agile

There are case studies out there for both Agile and Waterfall projects. None of these case studies were particularly compelling advocates for either approach. The real reason for this is that it is not about the approach, it is about the people. This includes the people who make up the Project. It is the individuals who authorized the Project in the very first place. This includes the individuals who explained what the expected Deliverable ought to look like and how it needs to perform. There are points of failure in any initiative. Many of the Project failures can be associated to 2 words, “human error”.

Usually the ‘human error’ is brought on by a deviation from what needs to take place. The Process was not followed properly. This can take place due to an error, due to Politics, Ego or possibly even Fear. A good dose of plain incompetence frequently underlies and magnifies these elements.

While it would be great to have a comparative case study of an Agile and a Waterfall Project. This unfortunately was not possible. We have however taken examples from two very big and critical Projects. We have highlighted where Agile could have produced much better outcomes and where traditional approaches may be been better.

Case Study 1: The Project Death March

Some years ago, we were invited to a celebration of an IT Project in a very large bank. The Project had a name, but we will offer it the alias of “Project Albatross”. This Project had been running for 5 years, and was intended to revamp the branch ‘over-the-counter’ Processes. We stood in amazement, while various Team members were called forward and awarded prizes. Each were recognised for Work well done. Clearly this was meant to be a ‘morale-booster’ for the unfortunates on the Project. However it sent out an ‘equally negative message’ to everybody else in the IT Department. It was OKAY to fail.

The Lesson From Agile: Fail Fast

This Project was at least 3 years behind schedule, with nearly 100% churn. Only one or 2 workers (who received awards) had remained on the project from the start. Whatever was initially specified was not going to fit. It did not matter how many Scope Changes there had been over the years.

Agile caters for cancelling a Project quickly and decisively. This Project was probably going off the rails in Month 6 when remedial action should have been taken.

Pointing the Finger: The Executive

The Project Manager could not be blamed, this was the 5th unfortunate person to assume the role. At least one of the Project Managers had attempted and failed to cancel the Project,. This failure resulted in them leaving the Role. Clearly, the Project executive should have stopped it long ago, instead of allowing a steady drain of resources. There is also the added impact of the change in Project Manager. This impacts both time and expense for each handover.

Agile Lessons: Resolving Problems

The bank went out and bought an off the shelf Software Application. This is something large Organizations can do with impunity. Needless to say the off the shelf Software Installation was just as long and drawn-out and even more costly. There has however been a Project Deliverable.

The bank eventually learnt its lessons and now follows the Agile values and principles.

Case Study 2: “We Knew What the User Wanted”

You may have heard this before on other Projects. This was a Project that had actually been a catastrophic and very Visible failure. We had actually been contacted to assist the Business turnaround. The very first remedy was to carry out an extremely laborious meeting. First thing in the morning, everybody associated with the debacle had to attend this meeing. The truths were unlocked by going through the minutes of the day before. These meetings were so terrible that everybody was galvanised into action, just so the torture would stop.

We found these books great for finding out more information on Agile Scrum:

Agile Lessons: The Business is Involved Throughout

The Product Owner and stakeholders in a Scrum Project are involved and committed to the project from start to finish. This commitment is first observed by the Requirements being collaboratively documented and stored within the Product Backlog. The Scrum Team (Scrum Master, Product Owner and Development Team) review the Requirements together. Where difficulties start to arise, assumptions can be made and the Project can begin to deviate from the Customer requirements. Through the business and stakeholder involvement throughout the project, these deviations can be captured and resolved quickly.

Agile Lessons: Resolving Problems

Weekly Meetings were held to Review any discrepancies from the Requirements. Product specialists were included every step of the way and a strong Test Management Process was implemented. The Project still took longer than it should have, however there was a successful outcome. This assisted with the restoration of the Company’s reputation.

Agile Lessons: Would Agile Have Saved the Day?

Both these cases were huge Projects, and Waterfall was probably the best option at the time, as Agile was not as commonly used then. In truth, if you examine what took place in both cases, it was a lack of compliance to Project Management Practices that led to both failures.

Nevertheless, where an Organisation has adopted Agile, either for their IT efforts, or as a whole, the commitment of the Stakeholders throughout the Project would have stopped these disasters within the very first few months.