Agile has reached the early majority, and is running into trouble. At best, it doesn’t deliver what it’s capable of when the shackles are off. At worst, its failure feeds the political beast and vaccinates the organization against future change. “We tried that Agile nonsense, and it didn’t work! I Told You So™!”
Usually, Agile fails because organizations leave out an essential feedback loop.
- A governance process sets scope, schedule, and budget before initiating the Agile project, disabling the feedback of observed productivity (velocity) into a variable scope (the prioritized backlog); the team devolves to Cowboy Coding under the schedule pressure, and the product remains locked into a definition created when everyone was the most ignorant they will ever be,
- The team doesn’t do automated testing because they don’t know how or aren’t given time, disabling the feedback loop that controls technical debt; refactoring—as-needed redesign—is too risky, and productivity drops because the design is becoming incoherent,
- A defined process, outside the control of the Agile team, inhibits meaningful change based on retrospectives, which become glorified lessons-observed post-mortems instead of the lessons-applied process feedback loop they were meant to be, or
- Functional boundaries inhibit the frequent, regular evaluation of finished software by production SMEs and stakeholders in production-like environments, disabling the right-thing-done-right feedback loop.
Since early 2009 (four years at this writing), I’ve been using the metaphor of a house’s load-bearing walls to explain this. You can remodel Agile to suit your environment, but you can’t cut through a load-bearing wall, or it will fall down. In a match between personal will or political “realities” against the laws of physics, the smart money’s on the laws of physics, every time.
But I just read an article called Your HR Department can be hurting your company that caused me to say, “Maybe I’ve been missing a wall!” It’s not the gist of his article, but Don Herrmann makes this fascinating statement:
The real focus should be on leadership and for that a leadership expert is better suited. Notice I said leadership, a method of self directed empowerment that has sustainable accountability. I did not say leader, an others directed process relying on personal style that is not sustainable. Focusing on leadership ensures the long term strategic direction of the company is properly defined, navigated and accomplished. It survives the natural departure of leaders by ensuring a replicable and consistent conductor culture for the company.
This lack of what I’ll try calling “Peer Leadership” in established organizations explains some things I’ve experienced.
I frequently use Facilitated Requirements Workshops to elicit and analyze software requirements. The tensest moment for me is what I call “marker allergy.” I’ve just asked them to start writing user stories on 4×6 cards, using the markers in the middle of the table, and they’re just sitting there. And I’m wondering, “Are they allergic to markers or something?” They’ve always started writing, eventually, but meanwhile you could cut the tension in the room with a knife.
Or, we’ve just come out of a cycle start meeting with the sponsor/product owner with a set of user stories we’ve committed to, and we need to organize the work. They’re usually OK with putting together a WBS (Work Breakdown Structure), but when it comes to “Who Does What by When,” they all look at me. I’m the expert. I’m the “leader.” So I’m supposed to issue orders, and go down with the ship if need be, and I’m instead impersonating a mime. Eventually they get over it, but meanwhile you could cut the tension in the room with a knife.
Agile proponents talk a lot about self-organizing teams. I’ve spent all of my programming life in cultures like academic research and then start-up businesses where this was a given. The people were there in part because they couldn’t stand being told what to do! So I never really thought about self-organizing teams because that’s all I knew, until I started consulting in organizations with a management culture, and a “but I followed instructions” response when things go awry. It’s not their fault. It’s what they’ve been conditioned to do. They expect it, and there’s safety in it. Like Wallace, I can tell the sheep to “get yourselves organized down there,” but the results (after about 1:30 in the video) might not be as spectacular.
Perhaps Self-Organization or Peer Leadership is a fifth load-bearing wall, but one that needs to be installed, not merely protected like the others. Maybe team members used to big-M Management need explicit help with Peer Leadership. As a first draft, I’d include training and then coaching on how to:
- Size up and divide work,
- Estimate work, and help others do the same,
- Suggest first-draft ideas without being afraid of being wrong (or “getting a bad grade”–there’s a lot of PTSD left over from school. Just ask about the dreams),
- Be mindful of the “vibe” of the team and the work they’re producing,
- Identify strengths and weaknesses in self, others, and team, and change your mind when the evidence suggests (tell Malcolm Gladwell of Blink to go to blazes),
- Give feedback without becoming snarky, and
- Receive feedback (even snarky feedback) without becoming defensive, or, as Alan Godwin puts it, how to have Good Conflict, and
- How to prepare and give a simple briefing to a project sponsor without freaking out.
I’d then prep the sponsor on how to respond when things go awry (and they will). Keep the “Who’s in charge here?“ inside, and instead say, “What do you all plan to do differently now?” The experienced sponsor should use that experience to ask questions that help the team strengthen their plan, and resist the urge to pull an Al “I’m in charge here” Haig.
When people start to learn that they can’t hide behind a manager, but that they can take responsibility for their successes and failures, choose how to respond to the latter, and not get shamed and whacked by those with Authority, I’ll know that Peer Leadership is taking hold, and that our load-bearing walls are complete:
- Frequent inspection of running software in a (near-)production environment, by production people (functionality and usability feedback),
- Commitments based on actual velocity (productivity feedback),
- Automated testing (quality feedback),
- Regular retrospectives, resulting in action (process feedback), and, welcome to our new load-bearing wall,
- Peer leadership (team cohesion feedback).
Let’s try it out. Let me know how it goes!