Project Management

Manifesting Business Agility

by
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

RSS

Recent Posts

Why if you are a PMP who understands the value of Agile your next workshop should be the Disciplined Agile Value Stream Consultant

My views (past posts) on cause and effect in complex systems

Transcend the thinking that scope, time and cost are in opposition to each other with Lean-Thinking

What I've found a team approach to Agile must include

A shift in my efforts

How the lack of critical thinking is killing Agile

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.

Posted on: August 31, 2021 05:43 PM | Permalink | Comments (0)

Empiricism and values alone are not enough

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

Posted on: August 30, 2021 01:00 PM | Permalink | Comments (2)

How Disciplined Agile Avoids the Blind Men and the Elephant of Agile

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.

Posted on: August 29, 2021 04:54 PM | Permalink | Comments (2)

How to tell if you're in a complex system

There is a lot of talk about complexity now in the Agile community. I am not a big fan of sense-making frameworks that talk about simple, chaos, complicated and complex.  But I wrote this post on linkedin (including it here) to let us know when you are in a complex system.

Go through the questions one by one. Give yourself 2 points for each question answered "definitely" and one point when answered "to some extent." At the end we'll total up your score and tell you if you're in a complex system.

  1. are you doing knowledge work?
  2. are there more than 20 people involved?
  3. do you have to interact with people outside of your group for which you have no control?
  4. are there many dependencies between the different groups involved?
  5. is much of what's happening not visible to people?
  6. can small misunderstandings cause big challenges?
  7. are you doing something never done before?
  8. are you trying to learn how to do what you're doing better?
  9. are people's livelihoods at stake based on the success of what they are doing?
  10. is it impossible to keep everything that's going on in your head?

Now, total up your answers. If your score is 2 or more you're in a complex system.

The question isn't if you're in a complex system, the question is what are you going to do about it? How are you going to navigate it?

-----

To learn more about how to deal with complexity, check out Dealing With Complexity by Creating a Bias for Simplicty

 

Posted on: August 27, 2021 11:54 AM | Permalink | Comments (1)

Using Disciplined Agile Insights to Create a Quick Start for Effective Team Agility

Scrum as a Double-Edged Sword

One of the attractions of Scrum is its simple definition and ability to start a team quickly. But this has proven to be a double edged sword. While one of Scrum’s creators, Ken Schwaber, implores “Scrum is simple, just use it as is” many teams find they can’t get the value out of Scrum that they had thought they would. Teams struggling with Scrum abound. So much so that they’ve been given names – “dark Scrum” and “Scrummerfall.” The reasons for this is Scrum’s simple start is, unfortunately, simplistic. Scrum is based on a set of values and empiricism. This enables it to provide a how and who. It’s lack of theory makes it unable to provide the required what and why. Empiricism alone is insufficient in that it doesn’t provide the forward looking ability to predict what changes may be useful that theory does. Scrum’s claim of being based on Lean-Thinking is unfounded*. This leaves Scrum practitioners without the knowledge that is necessary to fill in the gaps and enable Scrum Guide Scrum to be modified to avoid the challenges so many people face with using it.

Applying Lean theory will almost certainly take people away from the immutable aspects of Scrum, so they will no longer be doing Scrum. This tends to subtly create a limitation on thinking since many Scrum practitioners were only trained in Scrum (especially those certified as ScrumMasters) so there is a natural reluctance to look outside of Scrum's allowed practices. While this limitation can be a good thing when people don't understand Lean, it creates a situation where practices that are not ideal for the team are being followed.

The concept of “Scrum” originates in the New New Product Development Game by Hirotaka Takeuchi and Ikujiro Nonaka, published in 1986. This entails:

  1. Having a team that understands or can learn what is needed

  2. Setting up a process to achieve quick feedback on what is being built

These two concepts provide the rationale for the two iconic aspects of Scrum – the self-organizing, cross-functional team and using sprints, or iterations in the generic Agile vernacular. This combination enables the team to pivot after working towards an interim solution. The term Scrum comes from the sport of rugby. A scrum in rugby is a way of restarting play. Scrum’s daily scrum is done to restart the day, to see where impediments are and how to get past them. Scrum itself is based on the regular “restart” of what’s being built. Teams sprint in creating an aspect of the product and then stop, reflect, and restart for the next sprint.

The challenge is that Scrum’s lack of theory as to what works in knowledge work requires it to define many prescribed practices which are immutable since no theory is provided to explain what other practices might work better in certain situations. While these will often work in situations where Scrum was originally designed (new product development by a cross-functional team) Scrum is now more often used in places outside of where it was designed for. Fortunately, just a little Lean-thinking can provide this necessary theory.

A Quick Introduction to Lean-Thinking

The essence of Lean-thinking is learning quickly. Taichi Ohno, the creator of the Toyota Production System from which Lean originated, was wont to say to his managers “if I come back here in 30 days and you’re still doing the same thing then you haven’t done your job.” Lean is based on the following:

  • Systems thinking. That is, looking at the whole and the relationships between the components in the system and recognizing that most of the behavior, and errors, that take place are the result of the system.

  • Just-in-time. This means avoiding doing things early since the delay caused by doing so creates waste. This is typically implemented in a pull system which also decouples events from each other to avoid a cascade of timing errors from occurring.

  • Fix common cause errors are soon as they are detected (stop the line). Systems theory tells us that almost all of the errors are due to the system, so when an error occurs we must fix the system.

While Scrum does partially follow some aspects of Lean-thinking, its equally violates it. In particular, Scrum’s foundation on batches (sprints) of work is the anti-thesis of Lean. This is particularly true in retrospectives taking place at the end of a sprint instead of on a more ongoing basis. Lean is about continuous learning, not learning after a batch of work. This quote by Edwards Deming, sums this up nicely “Experience teaches nothing. In fact there is no experience to record without theory… Without theory there is no learning… And that is their downfall." People copy examples and then they wonder what is the trouble. They look at examples and without theory they learn nothing.” Without a theory as to how to do knowledge, work, Scrum is doomed to remain in its own echo chamber. This is perhaps the biggest manner in which Scrum is inconsistent with Lean-thinking - Lean does not put any boundaries on what can be done - it is completely pragmatic and is about achieving results for the situation at hand, not by using pre-defined practices.

Taking a Disciplined Approach to Scrum

If we reformulate a team approach to creating new products based on the New New Product Development game but use Lean thinking to provide the why to Scrum’s prescribed how we can understand the what as well. That is, instead of starting with how to do new product development, let’s look at what’s required by understanding the theory underneath the work. This provides us with the why needed.

When we have the what, how, why and who, we are no longer constrained to the domain discussed in The New New Product Development game. That is, we can now figure out how to create new hows in the new context. This is the essence of Disciplined Agile’s choose your way of working. Don’t start with how but look at what you are trying to accomplish, understand the why and decide on the how and the who within your own context. 

The following tables describe what a Disciplined Agile approach to defining a team process would look like. It’s organized into three main sections: what (the intention we want to accomplish), how (a suggested practice or practices), and the why for both the whats and hows presented. This combination enables us to start with a way of working and then to modify it while ensuring we still accomplish what’s needed. The why column is based mostly on key Lean principles.

The table has two columns for the hows, one for an iteration based approach and one for a flow based approach. There is an ongoing debate as to which is easier to start with and our belief is that not only is there no correct answer, but each approach can be improved by attending to the other. Iterations provide more structure and can therefore be a better approach to teams. However, flow is an inherently more efficient method. Aspects of flow can often be incorporated into an iterative model and are shown when appropriate.

It is important to note that the collection of hows for the iteration approach is not Scrum Guide Scrum but rather an iterative model based on the whats and whys of knowledge work. It therefore includes practices that both substitute for and add to Scrum’s prescribed practices. One could say it’s a combination of ScrumButs that work, and ScrumAnds that extend.

 

The numbers in the what column refer to the factors for effective value streams we've found to be useful. They are summarized in the following table.

Note that this is a work in process. This is the first part of an article that will be expanded to present a guide to team agility that is about 15-20 pages long, but designed without boundaries, options to choose from and the thought process to make good choices.

If you want to learn more about having an Agile team approach that works for you I suggest looking at Disciplined Agile's Scrum Master (DASM) Certification. Or, if you are already familiar with Scrum and want to learn how Scrum teams can work together, check out the Disciplined Agile's Senior Scrum Master (DASSM) Certification.

* In ’07 Al Shalloway, on the Yahoo Scrum Development group, suggested that Scrum was a partial manifestation of Lean. Ken Schwaber vehemently disagreed, expelled Mr. Shalloway

Posted on: May 30, 2021 02:21 PM | Permalink | Comments (0)
ADVERTISEMENTS

"A thing worth having is a thing worth cheating for."

- W.C. Fields

ADVERTISEMENT

Sponsors