Manifesting Business Agility

In ’09, after Kanban had its coming out party at the Miami Lean-Kanban Conf, Ken Schwaber blasted the “explicit workflow” concept of Kanban on the misguided thinking that people would follow this explicit workflow

Explicit means “stated clearly and in detail, leaving no room for confusion or doubt"

Implicit means “implied though not plainly expressed”

There should be no inference that explicit means hard to change or something to follow. It just means that we’ve stated what we think the best way of working is. It's changed with just another explicit statement

Part of an explicit workflow can also have an out like – “except when” or “let someone know when you don't do it, if there's a better way"

The agreements they represent are a reflection of what the team believes is the best way of working, not something to be followed

The idea that explicit means hard to change or to be followed is one of the great misunderstandings of Lean/KB still in the Scrum community. A common understanding of how people are working improves collaboration and discovering better ways of working. W/o explicit workflow it gets hard to make improvements since no one is sure what is being done. 
 

For more, read Why DA FLEX Suggests Having Explicit Workflow and Agreements 

I was introduced to the term "one's listening" by Dr Fernando Flores in the 80s. This “listening” is what’s going on in a person’s head when they listen or read. You’re experiencing this now, likely asking yourself “what the hell is he talking about?” That’s what I’m referring to as “your listening.”

Words, in themselves, don’t have meaning. Rather they mean what the receiver gets evoked in their head. This is why communication is so fraught with mis-understanding. If people have different understandings when one person says something another person may very well hear something else (not in their ears but in their head).

This is why it is so important to attend to someone’s listening. When we've described certain concepts repeatedly, we can even anticipate what this listening will be based on past conversations. And, of course, we can ask. When writing or creating training materials, however, it is important to make a decision about what the likely listening for your audience will be.

Explanations that take this listening into account will be better than just an explanation of what you are trying to describe.

One of many "emperor has no clothes" factors in the Agile world is that our most popular methods don't suggest an Agile manner of adoption. Scrum's "just do it" & SAFe's "all in all the way" both have you just jump to their solution w/neither a transition path nor any real insights on how to do it

There are two significant challenges to this. The first is the lack of transition to the practices can cause confusion and resistance. For example if you don't have cross-functional teams or ARTs, it may take a few steps to get there. Without guidance, teams and organizations may never get to where they need to be. 

More significant, however, is the mental aspect of making the adoption, which is basically ignored. This is exacerbated by the large # of adoptions where people are told to do Scrum or SAFe. In the same way there is no one size fits all solution, there is no one size fits all adoption path.

Here are some factors to consider:
1) perceived safety
2) level of siloing present
3) bonus programs that encourage people to expand their # of direct reports
4) degree of micro-management
5) level of respect by managers for their people
6) pressure from the C-suite to get things done
7) degree of overwork
8) level of technical debt

Others?

Someone posted this:

I Didn't Get The Memo....

Did anyone receive a memo that calls for the suspension of #systemic or #holisticthinking, where outcomes and actions in our system are now independent of other outcomes and actions?
----
This was my response

It didn't come in the form of a memo, it comes in the form of describing frameworks in a way that is not holistic and systems thinking oriented. This perspective ends up having people not taking an holistic or systems thinking view.

Frameworks by their nature - focus on
some parts. Plus, most focus on the team and then how to expand it. An holistic
approach would focus on the entire organization and while including how the
teams fit in (see Challenging the Assumption That One Must Get Teams to Work
First https://bit.ly/2LAbj3Q

Also, a focus on the framework and not the work itself leads to non-systemic thinking. See:

• We need to focus on our intentions, not our problems, before we look for solutions ​
• Why to Focus on Flow of Value and Not Iterations 
• Don't Focus on Frameworks 

In a nutshell from Emerson – “what you do speaks so loudly I cannot hear what you say”

-----

I loved this response as well: Probably you don't need a memo for the suspension of something that almost never existed.

The Spotify model is being touted by some as a way to scale Agile. While it has many useful insights, this is not what it was designed for. At Net Objectives, in 2010-11 we had created a way of coordinating teams that exactly matched the model but with different terms. When, the Spotify Model came out in 2012 I remarked to myself “cool, not a surprise since the chief consultants know Scrum, Lean and Kanban.” Good structures tend to follow the laws of Lean and Flow. I had seen different consultants who knew Lean creating similar results before.

While the model provides great insights on how to organize groups of teams as they grow, I didn’t really think about it much until recently. Unfortunately, it is now being used in ways for which it was not designed and which can cause damage. The first is when it is used to scale. Arbitrarily binding teams together in the model just adds a structure that makes coordinating the teams more difficult. Large orgs need to be decomposed, not organized together.

I have also seen it used to organize teams within a silo. This creates a structure to abide by that doesn’t add value. The overhead will make finding a useful solution more difficult.

See There Is No Spotify Model for Scaling Agile by Henrik Knieberg, one of the early coaches at Spotify who provided a window into how Spotify uses agile.  Here are some excerpts: in the words of its creators – “the ‘Spotify Model’ is not an Agile Method”, “Nor is Spotify a Scaling Model”, and “Mimicking the Spotify Agile Model is lazy.”

Personally, I'd run from any consultants promoting it as one instead of as a source for insights.