Manifesting Business Agility

I'm not the person to talk to about the actual path and certification program for becoming a certified Disciplined Agile instructor. But as the creator of several team approaches and the Disciplined Agile Value Stream Consultant program I know what you should know to be an effective one.

There are many things that are different between the Disciplined Agile approach to Scrum as well as Agile at scale. I put together a list of these here

In addition, each week I'll be posting 1-3 lessons that are useful for Agile coaches in general - at both the team and at scale. It will either come from the aforementioned list or from the Disciplined Agile Value Stream consultant. 

These posts, and follow up conversation will take place on the Disciplined Agile Linkedin group.. Go there for more information. Search for the tag #CDAILearningPath

I am setting up a mailing list of interestied people. Please email me if you're interested (see my Linkedin Contact info for my email).

Large software systems are usually complex due to a combination of poor design/architecture and tech debt. The factors to attend to to reduce this complexity is well known (cohesion, coupling, encapsulation, testability …) along with methods to achieve these (design patterns/principles).

We would never take a “probe-sense-respond” approach with software. Instead we attend to design qualities and use automated testing to validate our changes.

There is an equivalent approach when it comes to improving our value stream - Dr. Goldratt's Inherent Simplicity. It too requires attending to certain factors which I suggest, for product development are:

1-The value density of the items being worked on
2-Batch size of work
3-How workload relates to capacity
4-The value creation structure of the organization
5-Effectiveness/efficiency of the value streams
6-Visibility of work and workflow 
7-Quality of the product
8-Culture of the organization

We must, of course, validate our changes (reduction in cost-of-delay and/or cycle times are good measures). But if they don’t result in an improvement, they will result in learning. It should never be fail fast, but rather learn fast.

You can see more at Dealing with Complexity by Creating a Bias For Simplicity h

It Ain’t What You Don’t Know That Gets You Into Trouble. It’s What You Know for Sure That Just Ain’t So–Mark Twain

Once, a professor went to a Zen Master. He asked him to explain the meaning of Zen
The Master quietly poured a cup of tea. The cup was full but he continued to pour
The professor could not stand this any longer, so he questioned the Master impatiently, "Why do you keep pouring when the cup is full?"
"I want to point out to you," the Master said, "that you are similarly attempting to understand Zen while your mind is full. First, empty your mind of preconceptions before you attempt to understand Zen"
"If your mind is empty, it is always ready for anything; it is open to everything. In the beginner's mind there are many possibilities, in the expert's mind there are few." Suzuki Roshi

This is a story I often here but see little followed. Our cognitive bias, Duning-Kruger and lack of double loop learning gets in the way. The problem is you don’t know what you don’t know. 

A way into beginner’s mind is to respect the thinking others. If you engage in a conversation as if you are not the more experienced or knowledgeable (even if you are), you have an opportunity to truly listen to something new and get it

In the 80s I learned that skill is only in a domain. For example, Bobby Fischer was brilliant as a chess player but not in social skills. I learned our skills are often dependent upon how we see the world and the language we use to describe it. While the Inuits don't actually have 50 words for snow, they do have hundreds of ways to describe it. That's because the type of snow you are in can be life or death in the wilderness.

These differences are called "distinctions." The number of distinctions a person has in an area is usually more highly correlated to ability than experience is. For example, a doctor can see all sorts of things in an xray while I'd just see shades of gray.

When faced with someone who says there’s a difference between two things that you don’t see, consider these two ways of having a conversation with them. You can say “there’s no difference between these two things” or you can ask “I don’t see the difference between these, can you explain what you see?” The first sets up a competition between the two of you while the second gets around cognitive bias (which is an impediment to learning) to some extent. Someone who sees a difference is not always right, of course, but there’s more to learn if you consider the possibility.

I’ve always hated the retort–“well they weren’t following Scrum” when a team abandoned a Scrum practice and failed. It certainly sounds logical. Since Scrum defines certain practices to be immutable then if you don’t do them you’re not doing Scrum. But this immutability creates a trap for many teams.

For example, when a team can’t get their stories done at the end of a sprint, after a few sprints of this they often give up in frustration and abandon sprints.

Yes, they’re not doing Scrum, but this happens so often, perhaps its inherent in Scrum’s design. There’s an assumption teams will figure out how to solve their problems with the immutable aspects of the framework. Evidence, however, shows they often don’t.

But what if the team was taught the theory that delays cause waste? That bigger items are harder to finish in a sprint. That we need to manage queues. How to substitute an “immutable” practice with something else that meets its intention.

I suggest this not only arms Scrum teams in how to do Scrum better, but it enables them to avoid the limitations its immutability sets up. Dropping the immutability shifts Scrum’s focus to what’s needed, not Scrum’s practices. This creates a more proactive attitude about what to do.