Manifesting Business Agility

This is a rough draft, but looking for what I left out.
 
Having done Agile at the team level for 22 years, I have come to the conclusion that the following are extremely helpful and should be included in any approach. An approach that misses any of these concepts leaves the team with more work on their part to figure out.
 
1. Provides objectives to be achieved- when practices are provided, they are done within the context of these objectives
2. Provide the why for the objectives and suggested practices
3. Use double loop learning must be done on a
frequent basis to question all objectives and practices. Nothing is sacrosanct.
4. Has a positive attitude towards management. If they are not cooperating ask what they are not seeing and then provide that to them.
5. Design for incompleteness. No system is complete, but approaches should provide guidance on how to fill in the blanks
6. Attend to the factors for simplicity (e.g., value, batch size, efficiency of value stream, visibility, workload, # of interruptions, rate of feedback, quality, value creation structure)
7.Provide guidance for when cross-functional teams don’t exist or are not achievable, and when iterations are not appropriate
8. Provide insights on how to start with a fit for purpose solution
9. Use these insights to also guide improvement on an ongoing basis
10. The approach must be designed so that no useful practice is outside of its scope (this doesn't mean its included, it means doing it won't take you out of the approach)
11. The amount time to get people started should be relatively short. Either a couple of days if delivered as a workshop but also deliverable by an internal coach over time.
12. Provide a navigable list of practices to choose from so people aren’t required to invent their own
13. Provide a way to learn and improve practices on a continual basis.
 14. Include a way of specifying what should be built next and what capabilities are required to build it

When we talk about “simple” we must keep in mind we are more concerned with “simple to use well” than with “simple in design.” Think of a self-driving car.

Note: Disciplined Agile Scrum achieves all of these. For those of you doing Scrum Guide Scrum I'll let you decide how many it provides.

I have often mentioned the failings of Scrum. I have been doing this for almost 2 decades when after initial success with it, I found other approaches more useful. My intentions have been to create some clarity on what would be an effective team approach. Scrum is ubiquitous and, in my mind, seriously flawed in design.

I have long felt that if I could be just clear enough, people would see what I see and other methods would become more widespread. However, I have seen that this has turned into more discussion about Scrum, which I'm trying to get past, than about what's possible. My past approach has been impacted by the reality that these reflections illustrate:

- "if all you have is a hammer, everything looks like a nail" - Abraham Maslow
- "it's hard to get a man to understand something when his salary depends upon his not understanding it" - Upton Sinclair
- All truth passes through three stages. First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident." Arthur Schopenhauer

I have been thinking for a while that I needed to focus more on the future. Create an understanding of what effective Agile would look like and stop focusing on fixing the past. I recently saw the quote in the attached picture. It has pushed me over the edge.

While I will still refer to Scrum and SAFe at times, I am going to focus more on what effective Agile would be. I already know what this is. I'm mostly having to see how to explain it concisely. It is based on the objective of business agility. Taking a scientific, engineering and systems thinking approach. It incorporates theories of Flow, Lean, ToC, complexity thinking (a la Goldratt's inherent simplicity) organizational development, individual psychology and uses pattern to organize it. It will provides methods for team, sub-orgs of a company and full enterprises.

And most importantly, It provides simple starts while providing ways to learn and improve and is not overly complex. This is not new. This is the approach I've been working on for almost 2 decades. I'm just going to be more explicit about how DA FLEX in particular and Disciplined Agile in general, follows this model.

Note that I may post some previously published Linkedin articles here which may refer to Scrum more now than my current efforts.

There are two common flaws I see in the logic in the Agile community. These are conflation and polarization. By conflation I mean taking two concepts and speaking about them as if they were the same. For example, the concepts of:
1. The ease of using something
2. The ease of configuring something so it can be used
3. The design of what is being configured and used
are all different.

It is true that we'd like each of them to be "simple". But focusing on the simplicity of one often makes another more complex. For Agile approaches, being easy to use is much more important than the cost of configuration. And this is more important than the ease of its design. This conflation is one of the reasons Scrum is "simple to understand, but difficult to master." While simple in design, it is not readily configurable which makes it often not fit for purpose while also providing few insights on going beyond it.
 
Polarization (going to extremes) is also common. We see this in complexity thinking. It is true that organizations doing knowledge work are complex adaptive systems. We cannot take a mechanistic or reductionist view of things and be totally effective. But even complex systems have causes and effects that, when ignored, create havoc. In knowledge work this is often seen as people violating basic laws of flow and lean. That is having large batches of work, slow feedback, handoffs, etc. While a fully linear approach doesn't work, abandoning it completely can be even more problematic.
 
Another example of polarization is presenting the extremes of a position while ignoring a third, integrated alternative. For example, one is not limited to viewing a system as a whole without any decomposition or doing reductionist thinking. Using Christopher Alexander's approach he calls "complexification" provides a way to decompose systems without losing the relationships between the components.

The lack of critical thinking when people fall prey to conflation and polarization has many follow preset frameworks that are based on these mindsets. Disciplined Agile avoids both weaknesses by avoiding dogma and being pragmatic. While we have theory, we look to see what works and adjust accordingly.

There's an old marketing story about a cannery with pale salmon that was not doing well against superior, pink salmon. They created the slogan "guaranteed not to turn pink in the can." Great marketing - turning a weakness into a strength.

It occurred to me that this is what Scrum subtly does when it says it's based on empiricism - as if this is a strength. But every method uses empiricism. Some more than others. Ironically, Scrum uses it at the lower end of the spectrum. Let me explain.  

The scientific method is based on four pillars:
1-Empiricism
2-Theories that explain our experience
3-Validating or invalidating our theories in the face of new evidence or upon reflection of old evidence
4-Running experiments to gather new evidence to test our theories

A key aspect of the scientific method is that no theory is sacrosanct. Practices can be considered to be a theory that this is a good way to work. Since it’s been proven that no practices are universal, methods should avoid making any practice immutable. Instead, each theory about a practice being useful should include where it is useful. While objectives may be virtually universal (e.g., managing the amount of work being done) how you achieve them depends upon the situation you are in.

Approaches that require specific practices only work in certain situations. It is important to understand what these situations are when adopting such an approach. Unfortunately, because we live in a “caveat emptor” world (the buyer beware) don't expect proponents of an approach to provide this, although they may provide a statement that sounds like they do. For example, one hears Scrum proponents say “it works when teams are working in complex situations” but notice that does not really provide for which complex situations it works in.

Approaches can be made considerably broader if they
- are defined by a set of objectives
- provide a set of optional practices that can be used - this avoids starting from scratch
- provide a way to tell if a new practice is better than a current one - allowing for the creation of better practices

Frameworks that don't provide this will see practitioners drop a required practice when it’s not applicable but won’t know how to find a better one. This is a common occurrence in Scrum, which provides neither objectives for its practices nor a theory on which to see if a new one is better. The common phrase for when this occurs is “Scrum but.”

Empiricism is great. But it's not enough. This is why Disciplined Agile's Scrum provides what's stated as being required above, enabling a fit for purpose solution right at the start. If you like a preset, prescribed approach, you can also use DA Scrum to start with a default set of options that have you be consistent with Scrum practices. But then you’ll be able to change them as you learn and discover there is a better set – one meant for your team(s).

The parable of the blind men and the elephant describes how 5  blind men come across an elephant. Touching the tail, one says “it’s a rope.” Another, touching the leg says “it’s a pillar.” A third, touching the trunk, says “it’s a snake.” The fourth, touching the body says “it’s a wall.” And the fifth, touching the ears, says “it’s a fan.” They argue and state how the others are liars and don’t know the truth.

The point is that we are all blind in that we only see part of the truth and get into trouble when we think we see “the truth.”

Sound familiar? Agile is about “iterations”, about “cross-functional teams”, about “starting where you are”, about “flow”, about “lean”, about “…”. They are missing the other side of the story – if all of the blind Agilists understood they are only looking at one aspect of Agile and put what they knew together, they’d “see” the elephant (Agile).

Disciplined Agile avoids the issue of the blind Agilists by having been and expanded by almost a dozen people, at least 7 of which are authors. It’s based on pragmatism and agnosticism (no dogma). It integrates the best of flow, Lean, Theory of Constraints, Scrum, XP, organizational development, leader-leader and more. They key is everyone on the team contributes - we don't appeal to authority. This broad experience is a great battle against any one person's cognitive bias adversely affecting DA as a whole.

This enables DA to be an integration of many paradigms. While at first glance this may appear to make it more complicated, that's like saying an AM/FM radio is more complicated to use. While theoretically, maybe that one extra button is more complicated. But it enables the radio to be used in a better way.

Disciplined Agile consultants understand the issues of Agile deeper than those who ascribe to only one Agile approach. They can provide you with “simpler” in the form of fit for purpose. Arguing for the “one true way” is the anti-thesis of Agile and usually causes challenges down the road. You can avoid these by understanding that Agile is multi-dimensional and that looking at it from one perspective is little different than calling an elephant a wall.