Most organizations have fallen prey to a simple message — implement Agile as a series of ceremonies and everything gets better. Unfortunately, this is often not the case when the human-side of the equation is lost. By getting back to the basics of motivation and adaptive performance, you can build an organization that is truly agile. Harvard Business Review October 1, 2018. Why Agile Goes Awry — and How to Fix It.

I was feeling rather accomplished. This organization had finally figured out how to estimate their projects and then to deliver those projects on time with improved quality. After one review I even told one project manager that his project was the best planned project I had seen in this organization. However, soon after this transformation to data driven project estimates, I noticed we kept canceling projects. We seemed to be canceling all our interesting projects. By the time I dug in to see what was going on, the organization had switched back to the over-optimistic projects that would later, predictably, deliver late and buggy products. What the heck had happened?

We had just completed a large project and delivered on time with good quality. No previous project had ever delivered on time. Previously, product quality was always assumed to be minimally acceptable until we then delivered the first update to that product. I had fought for using a schedule that was based upon our past performance. After initially losing the battle and then after the inevitable first crisis we got the go-ahead to use my originally proposed schedule. We then nailed the delivery date. We blew through all our quality gates well under the defect rates past projects had been unable to pass (but got waivers to do so anyway). I recall the business manager for our project, who initially fought my schedule, saying “Hey Bruce, this stuff really works!”

Well, everyone got excited about using past performance based schedules. They all estimated their schedules based upon the actual time it took to deliver their past few projects. Unfortunately, they fell prey to the simple message of “use your past performance!” Well, actually, they fell prey to not understanding what using one’s past performance meant. What happened with all the canceled projects was that when an issue came up, the old habit was to argue for pushing the schedule out. Because the past performance schedule was already right at the limit of when the product would be viable in the market, moving the schedule out made the product no longer competitive. Now keep in mind that in the past we would never have entertained moving the schedule out. Our culture was “we don’t slip a schedule” at least not until the very end of the schedule. But in this new environment of schedule “honesty” the notion appeared that if we had an issue then the “right thing to do” was to push out the schedule. Projects were canceled. It was a disaster.

What they didn’t get in understanding the simple message of “use your past performance to estimate your project schedule” was that such a schedule was still aggressive but that it accounted for the typical things that go wrong with a project. So when an issue was found in the project, the management action should have been “our schedule already accounts for dealing with unanticipated issues as we had in the past, solve it and press on.” Instead, they conjured up the notion that slipping schedules out was now the thing to do when an unsolved issue arose.

Too often we fall prey to a simple message without understanding the full meaning. Without understanding the full rationale represented by the simple message we then make unforced errors in our day to day decisions. The simple message is almost always just a useful abstraction of a fuller methodology that needs to be understood.

Do you sufficiently understand the concepts you are using or implementing in your project?