What can an Agile Case Study tell us about the benefits of Agile Project Management? There are many Agile and Traditional Project Management Case Studies out there. Most of these case studies are not particularly compelling supporters for either method. The real reason for this is that it is not about the approach, it has to do with the people. This includes the people who make up the Project. It includes the people who approved the Project in the first place. It also includes the people who described what the expected Deliverable should look like and how it should perform. There are points of failure in any initiative. Most of the Project failures can be attributed to those two frequently heard words “human error”.

Agile Case Study Vs Human Error

Usually the ‘human error’ is triggered by a deviation from what should occur. The Process was not followed correctly. This can happen due to an error, due to Politics, Ego or maybe even Fear. A good dose of plain incompetence often both underlies and magnifies these aspects.

So, while it would be fantastic to have a comparative case study of an Agile and a Traditional Project, we have taken examples from 2 extremely big and crucial Projects and highlighted where Agile could have produced better results.

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, however we will provide 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, watching as we sipped cold, non-alcoholic refreshment, while various Team members were called forward and awarded prizes and recognition for Work well done. Obviously this was implied to be a ‘morale-booster’ for the unfortunates on the Project. However it sent out an ‘equally unfavourable message’ to everyone else in the IT Department. It was OK to fail.

Agile Case Study: Fail Fast

This Project was at least 3 years behind schedule. There was nearly 100% churn, other than for a couple of staff members (who received awards). Whatever was initially defined was not going to fit. It would not fit no 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 fifth unfortunate person to assume the role. At least one of the Project Managers had attempted and failed to cancel the Project. This led to them leaving the Role. Clearly, the Project executive must have put a stop to it long ago, instead of permitting a consistent drain of resources. There is also the added impact of the change in Project Manager in terms of time and cost of the handover.

Agile Case Study: Resolving the Situation

The bank went out and purchased 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 a lot more pricey. Although there has been a Deliverable that has been implemented.

The bank eventually learnt its lessons and now has moved to Agile for all their ‘web-based in-house development’, with some capable executives overseeing the teams and their progress.

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

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

You may have heard this before on other Projects. This was a Project that had been a catastrophic and very Visible failure. We had been called in to help the Business turnaround. The first remedy was to implement a very tedious meeting, first thing in the morning, where everyone involved in the debacle had to attend, and truths were unlocked by going through the minutes of the day before. These meetings were so terrible that everyone was galvanized into action, just so the torture would stop. The individual who made this statement, added that “this is why they ignored the very comprehensive requirements document, and clearly did not see this as a problem”. He left before he was fired.

Agile Case Study: Business Involvement Throughout

The Scrum Product Owner is both involved and committed in the Project from the start and to the finish. This commitment is observed whether the Requirements are in a hefty Requirements document or in many little bits in a Product Backlog. Without the Product Owner there would be no opportunity for the Scrum Team (Agile Scrum Master, Scrum Product Owner and Scrum Development Team) to discuss the Requirements. Without this discussion difficulties will begin to Develop. These problems led to incorrect assumptions being made and the Project started to deviate from what the Customer wanted.

While the new Project was still a Waterfall Development, it included continuous vigilance from the Business to guarantee that the proper Requirements were being Developed. This was especially needed as the Development had been moved Offshore.

Blaming: Well, Everybody

Many left and many heads rolled. What was still difficult to comprehend was how the Product had actually gone live in the first place. It transpired that User Testing was done by the IT Department and the Product was launched onto an unsuspecting Market. This was a very small company (under 200 employees) and the Business could not afford to spare their key resources for Testing – or so they thought. There was a huge culture change in the IT Department as well, going forward.

Agile Case Study: How the Situation was resolved

The Project was started again with eagle eyes in oversight (this consisted of the market who were reliant on the Product). Weekly Meetings (Sprint Planning, Daily Stand-up, Sprint Review and Sprint Retrospective) were held to Review any discrepancies from the Requirements. Product specialists were involved every step of the way (in effect acting as Product Owners) and a strong Test Management Process was carried out. The Project still took longer than it should have, but there was an effective result, and the Company’s credibility was restored.

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

Would Agile Have Saved the Day?

Both these cases were large Projects, and Traditional Project Management was most likely the best choice at the time, because of the size and intricacy; Agile was not as typically applied then. In the second case, there was an Offshore Scrum Development Team, which needed strong oversight due to Cultural and Time Differences. In fact, if you review what happened in both cases, it was a lack of compliance to Project Management Practices that resulted in both failures.

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 or would have realigned the effort to match the desired results. That is providing the approach was stuck to.