Cause and Effects to Look For and How to Use Them

There are many cause and effects in the complex adaptive system called knowledge work. However, because these are embedded in a complex system they are not always readily seen. This is because systems are more about the relationships between the components in the system than the components themselves. Knowledge work tends to involve many different “components”, especially at scale when there are many teams involved in producing value.

This does not mean that we can predictably move forward with our efforts for improvement. Besides not always being able to see important relationships, how people interact with any change is especially difficult to predict – culture often having a significant impact. And, even when making solid decisions, there is always the chance of having a chaotic (non-linear) event occur. This is when a small change makes a big difference – for example the Martian Climate Orbiter when engineers failed to convert units from English to metric. I would suggest that chaotic events impact us significantly more than complexity and is the primary reason we need feedback in all of our workflows.

Common cause and effects to look for

These are not all of the causes and effects that can be found in knowledge work companies. But these are the ones often overlooked that have a significant impact on the effectiveness of the organization.

Intake process. Not having an effective intake process often causes

  • overworked implementation teams
  • difficulty in collaboration
  • delays in value delivery

Not limiting work in process. When too many things are being worked on the teams are overworked, increasing delays, multitasking and induced work. Requires an intake process.

Not using pull to manage workflow. When teams are told to do work when they are not ready to do it several bad things happen. First of all, work in process exceeds effective levels. This causes cascading scheduling problems between teams, making things even worse. Used in intake process.

Lack of an equivalent concept to the MBI. The use of MVPs, epics and features don’t capture the concept of an artifact the describes the smallest releasable increment that provides value to the customer and makes sense when transaction costs are considered. Epics are too big to do cost of delay calculations on and features are too small. MVPs a la Lean Startup don’t make sense to use when the increment is an enhancement of an existing product and being implemented by several teams.

Poor value creation structures makes it difficult to complete things quickly. This inherently causes delays in the workflow creating induced work. It is a form of siloing.

Silos in the organization make it difficult for tight feedback looks and collaboration. The delayed feedback causes a significant amount of induced work. See Why Looking at Delays in the Value Stream Is So Important

Attempts to have a one size fits all approach to work across an organization creates a lack of fit for purpose for many of the teams. This causes confusion, resistance and waste.

Not allocating CapEx and OpEx Funds at the same time. Allocating these separately may cause some potentially valuable increment not be funded for operations and therefore not be able to be delivered or supported.

Not attending to the customer experience. The customer experience is really what we’re trying to improve. The operational value stream of the customer, however, is usually impacted by several different development groups. Consider a pizza delivery software system that has different teams building the order taking system, the pizza making system, the delivery system, the payment system, …  The customer experience cuts across all of these. If these systems are built separately it is likely that a smooth customer experience won’t take place.

Not having effective teams will result in longer and lower quality development cycles.

Not having any cross-team coordination will cause delays in implementation. As stated earlier, this creates extra work.

Not having dev and ops working together will cause unnecessary delays in release.

Not taking a value stream perspective tends to have people not see how they adversely affect others further down the value stream.

Having poor quality code causes delays in changing existing code, sometimes severely.

Cause and effect does not make things predictable

Just because A cause B does not mean removing A will stop B. The reason is something else may also be causing B.  These other things are sometimes difficult to see because it may be the result of several things. It might also be the result of how people are interacting with the attempts to improve things. The issue is not just if you improve, but if you don’t, learn why not and what you might try to improve next

Our approach forward

Even though we may not have predictability, we can move forward removing bad practices we know cause problems and adding good practices for our situation that helps things. If we don’t get the benefit immediately for our actions we will learn more about what’s going on.  It’s not about “fail fast” it’s about “learn fast.”

When looking to make improvements in an organization it is wise to first see where you are, then take a look at what improvements may be and consider the right pace of adoption. Doing everything is usually not the best approach.  We therefore want to consider those adverse cause and effects we have and consider what we should do first. This requires considering not just the pace of adoption, but also avoiding overloading any one part of the value stream. Therefore, for each action we’re considering, we want to see how much benefit there will be plus what the cognitive load on the change will be.  Consider the cause and effects mentioned above. Here’s a table with these factors:

 

Cause Impact Effort to implement correction
Intake process High Low
Not limiting work in process Requires intake process Medium
Not using pull to manage workflow Requires intake process Medium
Not using MBIs High Low
Poor value creation Structure High High
Attempts to have one size fits all Medium Low
Not allocating CapEx and OpEx Funds at the same time
Not attending to customer experience
Not having effective teams
Not having any cross-team coordination Easier with MBIs
Not having dev and ops working together High Medium
Not taking a value stream perspective High Low
Having poor quality code High High

Resources