The “Right Framework” and Right Organizational Structure

I had a conversation with a group of managers and executives who had formed a committee to research and identify the organizational structure that would accommodate the continued adoption of “Agile | Scrum.”

Resisting the temptation to launch into a conversation about what flavors of Scrum would not be agile, I asked them what their current situation was, and what their intention is.

They explained that they had 1 team that had been doing Scrum for a couple of years, and was decent at doing it, but they wanted to gradually launch an additional 1 or 2 Scrum teams, before the end of the year, but they did not have any new Product Owner or Scrum Master to belong to these new teams, and they were hesitant to have Managers fill those roles, as they were inclined to previously, and felt violated the key principles of Scrum.

This line of reasoning led them to a new question for me which was, “What kind of role does the Manager have in an agile | Scrum organization, if any?  They still think they are responsible for the outcome of the projects.”  I told them that I have a professional opinion on the topic, but wanted to delay offering my professional opinion, until after I have given them some counter-intuitive information about the topic of discussion, which might influence how they frame the question they are asking me, and how they approach getting an answer to this question.

So, I asked the group, “What do you think of letting the people who do the work decide how they will adopt agile | Scrum?”  A voice on the phone said that they had considered doing that in the past, but they were confident that if left to their own normal way of doing things, the workers would get bogged down in thinking about the best approach, get distracted with the current project work at hand, and never really get started with the change.  They reasoned: there needs to be an official leader with authority to require the workers to take specific steps on certain deadlines, and to deliver working software within a reasonable cadence of about 2 weeks, like Scrum says.

I proposed, “Why not let the Agile Manifesto do all your lifting for you?”  I proceeded to read aloud Principle 3 of the Agile Manifesto to them directly from the website.

“Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”

So, if you have someone who has official authority in your organization, providing “Handrails” giving a wide berth for the teams to experiment within, they will find something that might work, and then stand behind it because it was “all their idea.”  If YOU tell them both WHAT to do, and HOW to do it, in Scrum…you’ve smothered the empirical cycle of developing the product, and iterating on it is utterly meaningless.  Agile is by definition an iterative, incremental approach to delivering working software.

A voice on the other side of the phone says, “Show Jon the slides we made for the future organizational structure.”  The email with PowerPoint attachment arrived at my In-Box, and upon opening it, I found 5 slides of about 7 identical Scrum Teams, bundled together into a program.  “It resembles something like Scaled Agile Framework in the Enterprise.” I said.

“What’s that?  Could you say that slower, Jon?” Then another voice says, “It’s SAFe.  Jon broke out the acronym for you.”  I reluctantly let the cat out of the bag: I’ve heard that a majority of the Fortune 500 companies have implemented SAFe somewhere in their organization, to date.  The irony is that the corporate sponsors of adopting SAFe in their organization quite frequently don’t remember hearing from Dean Leffingwell (it’s inventor) or any Scaled Agile training, that all of the practices introduced in SAFe are meant to be carefully considered, experimented with, pruned or adapted to fit the work context.

Inspect & Adapt is the mantra of SAFe, and yet many people think it is an immutable pattern to be cookie-cutter implemented everywhere, for everything.  They’ve lost the forest for the trees.  The same is said of any flavor or variety of agile methodologies: Enterprise Scrum, Kanban, Scrum, XP, Mob Programming, FAST, GROWS™ Method,   Scaled Professional Scrum,  LeSS, Scrum@Scale  or otherwise.

So, what I’m proposing is to hold space for the teams to use the Wisdom of Crowds, in an empirical way, to figure out HOW to be agile in their work context, by iterating and incrementing along as they go.  Just give them the WHAT (agile, please!) and let them empirically discover the HOW.

The first Scrum team has already proven inside your work context that this is perfectly reliable: you play Planning Poker to have the people who do the work, carefully and collaboratively interact, inside a light-weight structure, to understand WHAT the market wants.  Only the people on the team who are saying they are Willing to do the work of building the product, are the ones who should be involved in estimating the amount of work it will take to make it, and they collaborate (Wisdom of Crowds again!) with the Product Owner to order their Product Backlog (essentially a build sequence) and Sprint Backlog, adjusting the Product Backlog order, as feedback from a customer proxy emerges.

So, what if we transpose that product development paradigm to the question of HOW to build “The Right” work system for the entire organization?  If we Open up (rather than Shut down) the conversation about work systems and frameworks, to the people who will occupy those work systems, describing WHAT it should be like when we’re “Done” defining it, the people who are curious, passionate and responsible will show up to talk in that Space.

So, optionally inviting (rather than forcing) everyone in the organization to this Open Space will be the way of filtering out those who are NOT curious, passionate or ready to experiment, because only they were free to self-select into or out of it.  When only the Willing show up, they are automatically super-engaged and naturally collaborate with each other.  They are self-enrolling.  And THAT is who you want to work with.  It’s just so little drag on the system.  They will play within your Guard Rails.

They’ll boldly take calculated risks with experiments, and resiliently rebound from setbacks.  They’ll proudly trumpet their triumphs telling impactful narratives about their successful experiments.  Those tales enroll the previous fence-sitters, who form the next wave of emboldened Willing volunteers.  (Incrementally delivering you a more and more transformed organization.)  Each round of Open Space conversations and experiments is a new iteration.  Sounds agile, right?   Yeah, agile about Practices like you’ve been agile about the Product.

The voices over the phone pause.  I start imagining crickets reaching for some micro-violins.  Wait for it…wait for it:  “Yeah!  I get it.  That’s what I was talking about.”  They are eating out of my hand at this point.

I slow down my narrative, and sharpen my rhetoric, “Well, that sounds nice and all, but you still haven’t answered your question about the Manager’s role.  And neither have I.”  There are all kinds of workers with all kinds of comfort levels around change, and managers are no different.  I can say what I think the managers can do to add value, but then it would just be my truth.  No solitary person has cornered the market on truth.  We all have our piece of it, which describes a few limited aspects of it, but people tend to think their piece is the “Right Piece” of the truth.  So, spoon-feeding them what to think just doesn’t work.

What’s worse: folks won’t necessarily tell you when they’re fed up with your forced feeding them.  If they think the political climate is NOT conducive for their minority view that your version of agile is bad for them, or your approach to agile is flawed, they will NOT air their grievances to you, and instead, they will just take their resistance underground.  Nothing stings and disrupts as absolutely as subversive resistance.  Avoid creating it like you avoid spreading the plague.

If you focus on only working with the Willing, then you’re effectively leaving the Unwittingly-Future-Willing, alone.  They might sound like a “No!” to your agile transformation right now, but give them some time.  As they see the Fence-sitters, turn into the newly Willing, then turn into the Advocates, they’ll turn into the “Go-Along-To-Get-Alongs.”  And that’s all you need.  -In fact, it’s all you can handle, after all.  You’re doing an incremental transformation, not a Big-Bang, monolithic transformation, right?

“Yeah!  That’s right! Big-Bang sucks…it’s too risky.” they chime in.  -My point exactly.

So, here’s how you do a micro-filter litmus test on just the Managers: invite them to an informal table conversation around coffee.  –Lean Coffee.  Give them a topic like, “How could we see how agile might work around here?”  Then, get out of the way, shut up and listen!  -No!  I mean: watch.   Just watch who does what.   Nevermind whatever comes out of their mouth.  Blah, blah, blah…It doesn’t mean anything.

Just look to see which Managers engage in the conversations.  -The ones who really pull it into them.  They reach out for the sharpies and stickies.  They walk over to the board or table.  They waive their hands wildly and look up dreamfully into the ceiling.  -These are your Willing managers, who you want to work with.   Don’t hassle the rest.  Help them feel heard, if they want to, and let them walk off with impunity if they want to.   Nobody is a slave or a drone here.  Nobody drives this conversation; it’s lightly facilitated.   The same goes for the big All-Hands Open Space event.  -Facilitated under the auspices of your executive sponsor.

“Jon, as a next step, could you please put together a proposal with some pricing for us?  Just to facilitate these kinds of conversations?”   Of course I can.  I do it all the time.  Thanks for calling me.  I’ll be in touch.  Click.

My cell is: 949-922-4050

Leave a Reply

Your email address will not be published. Required fields are marked *