Project Management

Manifesting Business Agility

This blog concerns itself with organizations moving to business agility—the quick realization of value predictably and sustainably, and with high quality. It includes all aspects of this—from the business stakeholders through ops and support. Topics will be far-reaching but will mostly discuss FLEX, Flow, Lean-Thinking, Lean-Management, Theory of Constraints, Systems Thinking, Test-First and Agile.

About this Blog


Recent Posts

Shu Ha Ri at Disciplined Agile

Framework proponents - you don't get a pass by blaming your adopters' failings on them

Attending to Cause and Effect in Complex Systems

The Most Compelling Reasons for Using the Minimum Business Increment

The FLEX Playbook For SAFe

Shu Ha Ri at Disciplined Agile

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.

Posted on: July 05, 2020 12:02 PM | Permalink | Comments (1)

Framework proponents - you don't get a pass by blaming your adopters' failings on them

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.

Posted on: July 02, 2020 10:44 AM | Permalink | Comments (1)

Attending to Cause and Effect in Complex Systems

(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.

Posted on: July 02, 2020 10:43 AM | Permalink | Comments (2)

The Most Compelling Reasons for Using the Minimum Business Increment

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:

Posted on: April 28, 2020 10:59 AM | Permalink | Comments (5)

The FLEX Playbook For SAFe

SAFe often achieves unjamming dev orgs that hadn't been able to work together. However, true organizational agility requires the creation of a network of semi-autonomous teams working together to deliver value to customers. After organizing people into ARTs that have the abilities to build products it is important to be able to decompose these ARTs into smaller teams, each aligned to a particular product. SAFe, unfortunately, provides little guidance in how to do this, often resulting in a stagnated SAFe adoption. 

FLEX's playbook for SAFe is designed to accomplish the decomposition of ARTs to align to business stakeholders, shorten the horizon for planning and allow agile budgeting,all the while simplifying SAFe. This playbook has 4 phases:

1. Improve in place. Use 2 new concepts &a few plays to improve SAFe’s core practices.
2. Restructure teams & shorten their planning cycles. Use Lean thinking to decompose ARTs into dedicated product teams
3. Align teams to business stakeholders. Achieve the desired network of semi-autonomous teams aligned with business stakeholders. Move to agile budgeting as possible.
4. Guided continuous improvement. Continue tuning your methods, trains and workflows by attending to flow.

Posted on: April 23, 2020 08:58 PM | Permalink | Comments (3)

"There are two types of people in this world, good and bad. The good sleep better, but the bad seem to enjoy the waking hours much more."

- Woody Allen