The Barbarian Programmer: You Might Be Doing Fragile

Many years ago I attended a talk by Steve McConnell, the author of a number of seminal software engineering tomes including Code Complete, Rapid Development and Software Estimation: Demystifying the Black Art. I don’t remember the exact year, but it was around the time that the Agile Manifesto was published, and though the term Agile had yet to become an entry in the mainstream software developer's lexicon, many of the practices that we associate with Agile today were already being used in the industry.

During Steve’s presentation he said (and I am paraphrasing since I do not have a transcript) that in his experience the most important contributor to success in software projects was not which formal software development methodology a team followed, but rather on how disciplined they were in following the methodology or process that they had. You will note the use of the term formal in that last sentence; by this I am referring to mature methodologies that have evolved and survived in the crucible that is large-scale real-world software development.

Based on my own experience at the time, I immediately recognized Steve’s observation as deep wisdom, and this is as true today as it was at the time. Whether a team is following a Big Design and Estimation Up Front (BDEUF) or an Agile process, it is more important that they are disciplined in the adoption of that process, than which process they use.

Unfortunately, a lot of engineering teams who attempt to adopt Agile practices, fail miserably. And nine times out of ten they fail because they are undisciplined about their adoption, and they land up practicing what I call Fragile. Many managers don’t seem to get that there is no formal (there's that word again!) process called Agile; rather there are formal processes called Scrum, XP, Kanban, Lean, MSF, etc., that follow the Agile philosophy.

Though the aforementioned methods do lend themselves to customization, and in many cases demand it in the name of continuous process improvement, their initial adoption requires disciplined adherence to the specific principles and practices of the method. For example, just doing daily stand-up meetings, will not result in higher developer productivity, product quality or predictability. Stand-up meetings are just one part of Scrum and need to be combined with the other Scrum practices to realize the real benefits of the methodology.

And like any organizational change, the adoption of a formal Agile process also requires perseverance; it can take half a year before a team hits its stride with the new process. Unfortunately many failed attempts at adopting Agile become classic cases of throwing the baby out with the bathwater - after continued failure many teams abandon Agile practices and swing back to BDEUF, and then typically continue to fail with that approach.

I have heard it said that using Agile is just an excuse for poor planning or a justification for laziness, and that may sometimes be the case, but these are just examples of practicing Fragile. I have seen it time and time again where a team that has been doing BDEUF (please lets stop calling it Waterfall, since that moniker was used to describe how NOT to do software development!) resorts to Agile (read Fragile) when it becomes clear that there is no way they are going to meet their dates, requirements or features. It doesn’t help them, or stakeholders’ perceptions of the effectiveness of Agile practices.

So, with a nod to Jeff Foxworthy, here are a few ways you can identify if you are doing Fragile.

If you got part way through your BDEUF project and after realizing that there was no way that you were going to make your dates or scope you resorted to an Agile process…