I keep finding that the conflation of empirical process control and empiricism to be confusing for many.
Ken created Scrum on the basis of empirical process control, then conflated it with empiricism and then dropped the statement about EPC from the Scrum Guide.
EPC is when you manage a process by adjusting your actions based on what happens. Basically "inspect & adapt." You don't go back and adjust your initial assumptions (Scrum's immutable roles, events, artifacts and rules) but just live within the framework.
Ken learned EPC from chemical engineers. While the process varied, prior to see how to mix the chemicals was based on chemistry (theory) and for a particular situation. But transposing this type of process control to one of knowledge work is seriously flawed. Even if you get the right process in place, the needs will change as people learn.
Applying EPC without also providing a theory to change what you're doing is less effective than applying it, providing sufficient theory to guide your process and doing double loop learning on the process.
Posted on: January 03, 2021 07:01 PM
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).
Posted on: January 02, 2021 06:09 PM
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
Posted on: December 30, 2020 11:43 AM
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
Posted on: December 26, 2020 01:19 PM
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.
Posted on: December 25, 2020 04:52 PM