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.”

Practical Approach to Delivery Enablement

Abstract: The job of the influencer or coach/mentor in a software team, regardless of title (Manager, Director, Agile Coach, Scrum Master, Tech Lead, etc) isn’t to evangelize best practices and beat people over the head with manifestos. Rather, the job of any professional in an Agile environment is delivery enablement, which I define as enhancing/optimizing delivery of value to the customer and our stakeholders. This translates into working code in production. Everything we do should roll up to that, and the 9 Business Outcomes* described below.

When coaching a new team or set of teams, and especially when joining a new company, it is very important to bring with a great amount of intellectual humility. I have seen many folks come in guns-blazing with their ideas, trying to implement what they did at previous work places too quickly. This is far too common, and it usually has multiple consequences:

  • Ignores the unique context of the new team(s) or company (context-oblivious vs context-aware)
  • Proofs-of-concept executed without first understanding context can fail, even if they might have been a good idea, due to lack of buy-in and ownership (command and control approach vs coaching/mentorship)
  • Can be off-putting to partners and team members who know the system better and may already have ideas they were hoping you’d pair with them on instead (know-it-all vs collaborative partner)
  • Multiple other detriments, including the burning of bridges and very quickly becoming seen as someone to be worked around instead of worked with (seen as an impediment rather than a delivery enablement advocate)

It is important to show care about the people more than anything else up front. The technology problems will come, believe me, and when they do, you need to be respected and trusted in order to be an effective value delivery enabler.  So, what is my mental model and the approach I take when being faced with new teams or a new environment?

Practical Approach to Delivery Enablement

First 30 Days (Initial Absorption)

It is important to learn the various team contexts and people at play; gaining trust and building chemistry, rather than making suggestions out of the gate…

  • Heavy Learning of various team frameworks, contexts, scrum events, communication patterns, practices, tooling, dependencies, etc.
  • Build Partnerships with key technology and business stakeholders (via 1-on-1s, team outings, troubleshooting, cultural events, etc).
  • Identify top 2 or 3 Impediments (‘pain points’) experienced by the development and product team.
  • Gain Consensus on prioritization of the 9 Business Outcomes (below) with Tech/Product delivery leadership buy-in.

Day 30-90 (Planning and Experimentation)

At this point, I’ve reached the second stage of learning and I seek to leverage new relationships to start planning how to tackle delivery impediments…

  • Prioritize and Generate Impediment resolution plan: The “How” and any possible solutions must come from the team, or indirectly through coaching (e.g. Socratic Method)
  • Upstream Coaching: Management and other influential business stakeholders external to the development team may need to be educated on inhibitive anti-patterns observed – Start small and build conversational safety (more offering up questions than definitive changes at this point).
  • Fill Agility Practice Gaps: Delivery Transparency via Dashboarding/Metrics, Various trainings, Balance team protection with stakeholder needs, and more.
  • Canary-in-a-Coalmine: Execute small proofs-of-concepts (POC), targeting the more experimental/open teams, to gain traction on any new or pivoted agility or engineering practice. (The goal here is to avoid command-and-control practice setting but letting peer-to-peer influence abound post POC).
  • Conduct initial Team Health & Agility assessments at both the ART/org and team levels (gain consensus on which categories matter to move the needle)
  • Consult development team Retrospectives on any new POC or change and bubble up feedback as appropriate to management and influencer level.
  • Widen circle of go-to partners, allies and proactive stakeholders (leverage strengths, interests to get POCs off the ground).

Day 90+ (Coaching and Optimizing)

A success measurement at this stage is having gained the trust and respect of the development team, other peers and leadership such that the continued momentum and desire for continuous improvement stays strong. We can close the loop by both directly and indirectly affecting the business outcomes that the business previously prioritized during the first 30 days…

  • Continue to Fill Agility Practice Gaps: Optimize Value-flow through ART (Agile Release Train), PI Planning, Risk & Dependency Tracking, Hardening/Innovation allocation, and more.
  • Engineering Practices: Provide coaching on Shift-left DevOps embracement, CI/CD gap identification, automation opportunities, unit testing, build and deployment gates, quality and development risk modeling and test strategy (contextual depending on Monolith or Microservice), SDLC optimization, Vertical Slicing of teams, monitoring and alerting and more.
  • Tool Optimization & Information Radiators: Offer guidance on ALM configuration and visibility, provide stakeholder-appropriate value-driven dashboards (Product v Business v Devops, etc).
  • Impediment Removal: Continually facilitate team and org level technical and non-technical roadblocks.
  • Conflict Resolution: Manage team conflict via iterative stages only escalating when appropriate through 1-on-1, 2-on-1, then manager level if proven necessary or for recurring trends – (e.g. keep ‘team business’ at the team level ideally).
  • Ongoing Agility Health Assessments: Continue to asses/re-assess quarterly, or every 6-months depending on environment and contextual maturity.

The Nine Business Outcomes

Everything we do should roll up to one or more of these 9 Business Outcomes. Whether you area  developer, tester, product owner, or otherwise, it is important to gain consensus with your stakeholders on which outcomes are and are not a priority in their minds. This then allows delivery teams to move in the direction that our stakeholders across both IT and the rest of the business have in mind…

PathToAgility-9 Outcomes

Let us rise above the average statistic that says 64% of the features we build are rarely or never used. Image how much time and OpEx waste that is ($$). This is what we need to think about as developments teams (Product Owners, Engineers, etc). The goals of Agile isn’t just shortening the feedback loop, but also the learning cycle so we CAN deliver the right thing. More on that in the video link here, David Hawks – User Stories Suck

*Note: The Nine Business Outcomes content is part of the Path To Agility (PTA) program – more information can be found on PTA at the link provided.