Teams using lean and agile ways of working often rub up against traditional modes of governance which can slow them down or demoralise them. Governance can become a blocker. I drew this picture describing how that can feel..
Hierarchies and imposed structures, designed to simplify and streamline management become process overhead that disempower teams. The forums used to make decisions become distant, far removed from the reality of delivery. Teams often feel the pressure of delivering to please their sponsors rather than their users. Governance becomes an industry and the currency of success becomes dates, deliverables and documents.
Instead, organisations wishing to embrace lean and agile ways of working should promote governance structures and behaviours that:
Focus on outcomes, not deliverables - because truly understanding and driving towards an outcome (e.g. something starting/stopping/continuing, people feeling different, changes of behaviour) is much more valuable than focusing on the delivery of a thing (an artefact, a feature, a system) that might, you guess, produce an outcome. Focus on the change you desire, not on delivery of the bet you’ve placed. Unlearn the muscle-memory of caring most about dates and deliverables.
Measure what matters - agree how you’ll measure an outcome but also recognise that there’s a context for what’s meaningful to measure at any given time. That a new product can successfully meet the core needs of 10 users is very meaningful in the beginning and that should be an organisation’s initial focus; be patient before you pile on the pressure to measure % uplift in sales or efficiency. Be careful what you pick to measure and when to avoid unintended behaviours.
Ensure teams are the units of delivery - trust in multidisciplinary teams and let them get on with it. Build a team, not a big up front plan. If you’ve communicated the right problem to solve to a team that are invested in solving it, with the right support around them, you will all have a higher chance of succeeding. Good teams, with the right mix of skills and experience, figure it out. Good teams fail when you give them a solution, a date, the name for the thing… and tell them how to do it. People over process.
Establish networks of teams not hierarchies - because as soon as an organisation pre-determines a structure to deliver a thing they've exercised an upfront bias towards a particular solution. Over engineered programme-level hierarchies produce noise; noise slows down self-organising, motivated teams. By all means design and promote the glue between teams but do it organically, with teams not to them. Think about designing a supportive network, not inflicting unnecessary hierarchy and decision makers or forums.
Make quality everyone’s responsibility - because everyone involved needs to understand what good looks like and is responsible for delivering that. Don’t make quality assurance a ‘gate’, title or a role. Make it part of what a teams does every day. Bake it into the way a team works and thinks.
Assure as you go - because using iterative ways of working and effective feedback loops gives an organisation regular opportunities to check that the right work is being done in the right way. Try to avoid making assurance activity scary, lumpy or as a bolt on.
Remember that behaviours matter more than documents - because by regularly observing team behaviours (e.g. how they collaborate, communicate, validate their assumptions, seek feedback, measure impact, deliver, learn — is way more valuable than warm-fuzzies and false certainty of documented proof. Go see delivery. Witness running code and listen to feedback from actual users.
Fieldnote:
When I share this list with senior people their normal response is “it makes sense; it’s kinda what we do anyway”. That’s always good to hear but I’ve learned that’s rarely the case. For example, when I hear these things I know there’s a whiff:
“When’s the x delivered?”
“This team sits in the x programme in the y work stream”
“We need to get Programme/Strategy/Ops/Security/Data board to sign it off”
etc.
In and of themselves each of these are innocent enough but they can add up to something significant. They are the tells of how an organisation thinks about agility, risk, org structure (read: silos) and team empowerment. Maybe there’s another blog post in that.
*thank you to Ella and Amy who helped me structure my thoughts in the original, longer version of this post on Co-op’s blog. I didn’t say that in that post so it worth saying here. 🙏