Manifesting Business Agility

There are two types of questions:

1. those for which you want an answer
2. those which lead to more questions

The value of the first kind is we may get an insight on how to solve a problem. We stop asking the question once we have an answer. The value of the second kind is that it keeps the exploration of our belief systems going.  We aren’t looking for an answer, we’re looking for more questions.

The first kind of question is useful, but the second kind of question is powerful.  There are useful for others and for ourselves. When interacting with others I try to imagine what their belief system is that they woudl be saying what they are saying.  I am not a mind reader, of course, so I have to ask them something to validate what they are thinking.  Sometimes I ask just that “why are you saying that? Note I’m not challenging you, I just want to understand.”  I also sometimes ask them something like “it sounds like you are saying XYZ, is that correct?”  Both questions show your interest and increase empathy.

If they are thinking something I believe is not true I ask them how things are working for them and when they aren’t. The idea is to get them to reflect on their thinking. I engage in the questioning to have us both learn, without an underlying assumption that I am correct. But there is an agenda. If there’s a conflict in our thinking I want to resolve it and am happy either way it goes because then at least one of us will learn something.

As for questions to myself, I look for what others I respect say/write that is inconsistent with what I believe. I ask myself what the difference is and where one belief works better than another. The key is to be questioning on a frequent basis. After finding some long held belief to not be true I take that newly acquired humility to ask what else might not be true. 🙂

See Agile Coaching Tips for more.

I have long railed against the misuse of Shu Ha Ri (follow, diverge, transcend) in the Agile community. Following preset practices is risky since no one size fits all. Diverging from them after gaining knowledge sounds good but no framework provide guidance on how to do this. Shu Ha Ri is often used as an excuse for an approach not being sufficiently complete

At Disciplined Agile we use Shu Ha Ri differently. The original intent of Alistair Cockburn introducing the phrase to the Agile community was that first one must learn basic practices before branching out on their own. Martin Fowler remarked “The fundamental idea here is that when teaching a concept, you have to tailor the style of teaching to where the learner is in their understanding & that progression follows a common pattern”

DA’s toolkit approach has people follow a way that has been created for them. Later divergence is guided by the multitude of options provided. Transcendence is supported by being based on Lean theory

DA uses Shu Ha Ri to indicate levels of learning – beginner, intermediate, expert. As people progress through Shu Ha Ri they are adding credibility to their DA certifications, increasing their ability to use context to choose pragmatic solutions for their clients.

One of the foundations of Lean is that it is based on systems thinking which tells our system causes most of our failures. When recurring failures occur, system thinkers don't look to blame those in the system, but rather look to the system itself. This is why in the 21 yrs of my adjusting my org improvement methods, I look for patterns of challenge.

Unfortunately, I see many proponents of several Agile approaches blame the people attempting to adopt them - saying things like "they didn't follow our methods" or "of course people blame the framework" or "frameworks don't tell you what to do."

Besides the lack of responsibility being taken here, it demonstrates a lack of systems thinking. What needs to be asked is "why do these patterns of challenges exist? What about my approach encourages this?" Poorly designed frameworks are the bane of Agile now. They are promoted as providing solutions without taking responsibility for how they are misused.

No approach is fool proof. All require people to truly want to improve. But many failures are due to the way an approach is designed. With little responsibility being taken by the designers, little improvement is made.

(These are some notes from the Disciplined Agile FLEX alpha workshop under development)

When looking for cause and effect one must remember there may be multiple causes. Hence, if you fix one thing you may not get the result you want because other things may be going wrong. Consider building a bridge. It requires attending to compression strength (think concrete) and tensile strength (think support cables). Failure in either one will result in failure. Hence, doing one right thing doesn’t guarantee success, but doing one wrong thing often guarantees failure.

The trick is to look at things as a system, and improve something that either leads to improvement or leads to the discovery of something else required.

Root cause analysis is not to get to the root causes, it’s to learn what’s going on. If multiple causes are in play you can pick which one will most likely improve things or lead to learning which can lead to improvement. Or which may get improvement at low cost. 

Also, consider which actions to take on how they affect others. In solution development actions upstream often have an effect on downstream work. MBIs can lead to less work hitting downstream teams which increases efficiency in and of itself. It also creates space for learning.

I have found the Minimum Business Increment (MBI) to be one of the most useful concepts in 20+ years of doing some form of Agile, An MBI is the smallest increment of value that can be created for which value can be realized by an internal or external customer. MBIs are defined from initiatives for specific market segments or customers. They are a focus on what to build and release the quickest.

Whereas MVPs are about discovering whether a new product is viable and what it should be, MBIs are used to define the smallest increment of value to realize for existing products. MVPs are typically built by small teams that can pivot, whereas MBIs are used to coordinate the multiple teams required to create them. MBIs can also be used to help define dedicated product teams for the initiatives they come from. 

Cost of delay (and therefore WSFJ) can be more effectively done on MBIs than on epics, since not all of an epic will be released at one time and features often are not releasable on their own.

Multiple teams can align around MBIs when making decisions on which item to work on next. While true for features, multiple teams should not be required to build a feature.

Summary in table form: