capital one

The Binge-Purge Cycle of Frameworks

Abstract: Process frameworks are all the rage; some sold as magic pill, a silver-bullet to solve your organization’s problems toward achieving rapid delivery. They all have pros and cons, so I won’t spend time on belaboring what’s already widely discussed out there. Instead, I wanted to share my thoughts about the vicious cycle they can perpetuate within companies, as demonstrated by a history of many organizations continually adopting then scrapping these frameworks (most recently CapitalOne). The binge/purge cycle is staggering to me.

Recently, Dean Leffingwell, posted on LinkedIn about SAFe 6.0, a new version of his framework. My positions on these process frameworks have evolved over years and at this point, I’m convinced they are more for corralling and controlling systems that have other systemic issues at play (whether they intend to do this or not). Below was going to be my reply to Dean’s post, but it was too long for LinkedIn’s character limit, so I decided to post it here. Would love to hear your insights and feedback.

The more I interact with different software companies, the more I feel these frameworks are being used (many times unintentionally) to mask unrelated problems in that given system.

For example, when a system (software division) suffers from one of many pain points (e.g. let’s use ‘poor talent and hiring practices’ for the sake of this exercise), these process frameworks can mask the symptoms of that source issue. They do this by producing more busyness, sometimes only as the ‘appearance’ of work.

Now, it’s likely that none of us would claim that any of these frameworks have the ability to increase the software engineering acumen of employees; however, the new busyness being observed may cause leadership to feel like the framework is being successful, when actually it is only masking the source.

No, this framework doesn’t purport or claim to raise engineering talent; yet, when management sees busyness from formerly lower-performing employees, those leaders may not feel the pain of that source problem anymore. If there’s no pain, then there will be no intrinsic motivation to solve the real core issue of poor talent and hiring practices. However, over time, that problem becomes more distinguishable and dissociated from the efforts of applying the framework. Years later, new leadership witnesses this along with other unrelated systemic issues (corporate culture, product quality, innovation, etc) and deems the framework isn’t working. They either change to another out-of-box solution, complete with more promises, or they discontinues its implementation entirely. Ever heard a version of this statement? – “We tried Agile. It didn’t work”. Maybe it failed for legitimate reasons, but more often than not, that’s the exception and not the rule.

There are at least two issues here that bother me, compounding one another:

1) The original source problem of poor talent was hidden by the framework’s implementation.

2) The assertion that the framework was a failure or the cause of other systemic inefficiency, is false.

Both of these are misleading, but due to the nature of short human memory and new leadership rotation, the cycle continues. I’ve seen this repeated in many places I’ve worked or consulted, and I am curious how long it will take leadership in this community to recognize this cycle and preventively squash it for future generations. Or (I fear) is the rent-seeking nature too alluring and will continue to overtake true craftsmanship?

Anecdotally, the most successful environments I’ve worked, where engineering talent and soft skills were high, operated fabulously without any kind of heavy process framework.

The Agile community needs an upheaval, a revolution, similar to what the testing community started to go through in the early 2000s. Will that happen soon? 8-Ball reads, “Future uncertain.”