Self-Organization is a Nuanced Balancing Act

  • Published
  • Updated
  • 4 mins read
  • 0 Comments

Self-Organization is a Nuanced Balancing Act

You are currently viewing Self-Organization is a Nuanced Balancing Act

I was reading a post by my friend and colleague Mike Hall the other day. It was entitled—Teams Should Choose Their Agile Approach!  

I read it based on the title alone and found it insightful and well-intentioned. But that being said, I’m not sure that I agree with the absoluteness of it or the extremeness of it. Not that Mike used extreme language, but the intent of the approach was extreme, at least to me.

It seemed like Mike was saying that—

Under all conceivable circumstances, conditions, and contexts—teams should be fully autonomous in defining their agile operational dynamics.

And it made me think of a client story from quite a few years ago.

I met with this client. He was an organizational leader, general manager, of a large engineering group. To put it into Scrum terms, his organization was made up of ~100 Scrum and Kanban teams. They had been using both frameworks for about 18 months and he called me out of utter desperation.

He and his leadership team were befuddled as to why they couldn’t get a handle on delivering products, projects, or value streams using agile. Sure, the teams were working hard, with each delivering stuff. But the integration of their work into a comprehensible stream of work that could be predicted, communicated to, and delivered to their customers, seemed to be nonexistent.

And, the leadership team didn’t know why. From their perspective, they had let the teams totally self-select and become “Agile”.

I was invited in to do an assessment of sorts across all of the teams to see if I could understand what might be going on and to suggest some improvements. What I found was—

  • Every team was absolutely unique in their practice of agile ways of working. Some liked retrospectives and others had opted out. Some estimated and others did not. Some wrote things down and others didn’t.

  • Their tool-sets were equally disparate as their approaches. There were probably ~30 different tooling approaches being used across the teams. Without any integration.

  • The results were all over the place. There seemed to be a drumbeat of “we’re doing agile” without any of the customer or stakeholder accountabilities in place. And, when the leaders tried to influence the practices, they were met with “that’s not Agile, so no” in response.

To me, this client context was the epitome of the Inmates are Running the Asylum. And…

I remember meeting with the leadership team after my brief assessment. There was a physical pain in the room and a sense of helplessness. I remember the GM saying that “if this is what Agile is, I’m not sure we’ll survive as an organization”.

My reply was that—this isn’t “Agile” or “agile” or anything similar. I said that they had gotten the balance wrong. That they, the leadership team, have given 100% of the decision-making to the teams and then abdicated their leadership roles and responsibilities.

For example, I mentioned that it is fine (not required) to have leadership-driven constraints or guardrails in place for their teams. For example,  

  • To clearly define critical conditions of done and acceptance;

  • To establish organizational standards for tooling such that they (the leaders) can effectively communicate with their leaders, stakeholders, and clients;

  • To establish a small to a singular set of tools, standard ways of working, and integration guidelines, for their teams.

In other words, to lead. YES, the teams needed to be self-directed. But they also had a business to lead that served their internal and external clients.

So, I recommended a bit of “rebalancing” with an eye towards challenging their (and the team’s) previous assumptions.

As I read Mike’s article and considered much of my experience, it seemed similar to my story and had the potential of creating similar imbalances. Particularly in many of the client contexts that I experience.

I also wondered if it was a reaction to the reverse phenomenon that I’ve also frequently seen? One where the leaders apply far too many constraints on their agile teams and impede their autonomy, evolution, and results. 

You see, I think the devil is in the details of achieving a BALANCE between the leaders and the teams. And getting that balance right requires thoughtfulness, understanding, and empathy of all constituents engaged in an agile transformation.

Stay agile and stay balanced, my friends,

Bob.

Leave a Reply