Saturday, May 23, 2015

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…
…then you might be doing Fragile.
 
If you adopted a couple of Agile practices, e.g. a daily stand-up meeting, but haven't seen any improvement in your engineering team's productivity, predictability or general satisfaction; and are thinking that Agile is a load of hogwash…
…then you might be doing Fragile.
 
If you are not doing retrospectives or post mortems after every milestone…
…then you might be doing Fragile.
 
If your stakeholder’s don’t have complete transparency into your process and progress…
…then you might be doing Fragile.
 
If you are not using an Application Lifecycle Management  platform like Team Foundation Server to support your adoption of Agile…
…then you might be doing Fragile.
 
If you are not doing Build and Test Automation…
…then you might be doing Fragile.
 
If you don’t require that developers write tests for the code that they write…
…then you might be doing Fragile.
 
If you believe that human beings can estimate complex tasks (greater than 8 hours) with any degree of accuracy…
…then you might be doing Fragile.
 
If you are not refactoring user stories and work items into smaller user stories and work items to mitigate the above human limitation…
…then you might be doing Fragile.
 
If you think that you can mitigate the unquantifiable risks associated with emergent complexity with a fixed-size contingency buffer
…then you might be doing Fragile.
 
If your Scrum Master (or whatever you call her or him) is A Boss
…then you might be doing Fragile.
 
If anyone on your team asks, "what should I be doing next?”
…then you might be doing Fragile.
 
If any stakeholder has to call up a lead or manager and ask "when will my feature be ready?"…
…then you might be doing Fragile. 
 
If anyone in a meeting does not know whether they are a Pig or a Chicken, or does not know what that even means…
…then you might be doing Fragile.
 
If you are not doing sprints or iterations, or if those iterations are measured in months as opposed to weeks…
…then you might be doing Fragile.
 
If you are not doing backlog grooming with stakeholders multiple times during each iteration…
…then you might be doing Fragile.
 
If the total daily time commitment required by each developer in the development process, that is not related to designing software or writing code, is more than about 15 minutes…
…then you might be doing Fragile.
 
If your development leads spend more time managing the process than writing code…
…then you might be doing Fragile.


Please don’t do Fragile.

No comments:

Post a Comment