Iron Triangle Meets Agile
We all know about the Project Management Triangle: the rules of the game dictate that all project decisions are tradeoffs between “more”, “cheaper”, “faster” and “better”. We all know that… but do we?
We all know about the Project Management Triangle: the rules of the game dictate that all project decisions are tradeoffs between “more”, “cheaper”, “faster” and “better”.
We all know that… but do we? What if it were possible to change the game?
Let me share a story from personal experience (not to toot our own horn so much, but rather to demonstrate what can be achieved with Agile).
A few years ago we started working with a new customer, a global provider of consulting and technology solutions in the benefit and human capital space. To be more competitive in a tightly regulated and highly fluid market, the company made a decision to develop a brand new Data Management platform. Since doing it in-house was not feasible, they engaged a large Asian outsourcer to deliver the system with an offshore development team. The customer negotiated an aggressive rate card that spelled significant cost savings on development; they had a detailed, telephone book-thick functional spec; all that was left to do was to for the outsourcer to deliver against that spec. What could go wrong?
Well, as you probably expect, many things could, and did.
It was a typical “outsourcing disaster” scenario. Twelve months into the project, not only was it not on track, it hadn’t even really begun tracking. The number of change requests was piling up quickly, and progress was excruciatingly slow. Moreover, the low hourly rates were looking more and more like a curse rather than a blessing. The provider was clearly unable to provide experienced people at that rate level, and the customer kept having to reject one unqualified developer after another, resulting in two complete team refreshes over the course of the year. With this critical project effectively going nowhere fast, the client was looking for alternatives.
Luckily, the customer’s Project Manager was a Certified Scrum Master and a big fan of Agile development. With the project in such dire straits, he was finally able to convince the management to try converting the process from waterfall to Scrum in the hopes of getting things on track and addressing the growing backlog of change requests. However, the client’s organization hadn’t had any direct experience with Agile, and so the decision was made to seek out a new provider who would be able to deliver the project while simultaneously bootstrapping the customer’s in-house team in the Agile process and best practices. That’s how we first came on the scene.
One of the key problems encountered by the customer during the first 12 months had been the lack of effective project governance and communication. The offshore team and the in-house developers and multiple project stakeholders weren’t working in sync, and the customer felt like they had little control over what the vendor was doing. To make sure that didn’t happen again, we were asked to bring a team of eight people onsite for at least six months to establish a well working process and ensure proper cohesion and communication. Actually, the customer wanted a team of 6 engineers, but based on prior experience, they were expecting two people to wash out, and they did not want to lose momentum by replacing resources and re-training them in midstream. We accepted these terms with the caveat that the team would go back offshore if the client determined that the quality and the performance were there.
Needless to say, when our guys arrived onsite, they had their work cut out for them. Not only did they have to grasp the intricacies of the application, including its complex integration with various existing systems; they also had to introduce the in-house team to a completely new process. Naturally, this transition to Agile had its share of humorous quirks. For example, one morning early on the client’s Project Manager was taken by surprise when our guys asked him where they could get some screwdrivers. When asked why, they explained matter-of-factly that they wanted to take down the cubicle partitions to allow space for pair programming. The same Project Manager also quickly noticed how restless our Tech Leads were getting during the daily stand-ups. When he probed them about it, they said that they were anxious to get back to work, because those meetings routinely lasted over 50 minutes. (I’m not even sure those were real stand-up meetings – how can anyone stand around discussing things for an hour?? After all, keeping things short and to the point is exactly what stand-ups are designed to accomplish!). Acknowledging their frustration, the Project Manager then explained that even keeping meetings to an hour was setting a world land speed record in this client’s office culture.
What’s noteworthy is how drastically the customer changed their approach to costs, going from the emphasis on low rates and a fully offshore team to a more expensive vendor (our offshore rates were 50% higher), plus bringing the team onsite for several months. So, did this radical shift pay off?
Well, let’s see. The new Data Management platform was successfully delivered in 8 months, 3 months faster than expected (!!), and the customer acknowledged that code quality of the final deliverable exceeded the code quality of all previous projects implemented at the company. Two points for Scrum. But that’s not even the most interesting part. The system actually contained 40% more features than originally specified, delivered at the expense of features that the customer found were no longer needed, based on changing market conditions. The customer admitted that without the new features, the original specification would probably have been delivered as shelfware. Clearly, this was only possible because the Scrum team was delivering working code for business user review, validation and feedback every two weeks, and because this incremental, iterative approach allowed for a more thorough and granular analysis of requirements from the standpoint of their business value, and for the ability to make continual changes to the product backlog. There is no way waterfall could have allowed that without incurring enormous costs.
(As an aside, the client agreed that the team could work offshore after only two months onsite, based on their performance. And those two extra developers who were expected to wash out? Well, since no one was replaced, the two were re-assigned to another one of the client’s troubled projects.)
The project made such a strong impression within the client’s organization that as a consequence, the CIO mandated that all future projects valued at more than $400K be delivered using Agile, and initiated a company-wide Agile training program.
P.S. As an added bonus for us, we were later awarded a separate $2.7M sole-sourced project. Now that’s what I call a win-win.