Dealing with Complexity by Creating a Bias For Simplicity
|
It is difficult to make predictions, especially about the future. For every complex human problem, there is a solution that is neat, Looking at Complex Problems
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| What to avoid |
Factors for SimplicityPotential solution for improvement |
What to strive for | ||
|
More work enters the system than there is Work entering the system is not visible |
The amount of work entering the systemIf too much work enters the system the value streams are almost certainly going to be overloaded. Have a controlled intake process that uses pull methods to allow for controlling the level of work. Follow the mantra – “stop starting and start finishing.” |
The right amount and right size of work is started. Work entering the system is visible |
||
|
Large batches
|
Batch SizeSmaller batch sizes are generally good but one must attend to transaction costs of handling them as well. Use Minimum Business Increments (MBIs) |
Small batches | ||
| Work is well beyond capacity |
How close to capacity are people working?Manage work in process both at intake and throughout the value stream Manage the work entering the system Lower multi-tasking which lowers the capacity of people |
Work is below capacity | ||
| Viewing individuals and/or teams as components |
Attend to the effects of the system on peoplePeople are significantly effected by the system they are in. Systems inform behavior. Use systems-thinking |
Viewing the system as a whole | ||
| work is mostly in a waiting state than in a working state |
Delays in workflowDelays in workflow create work you must do but which does not add any value to the customer. Eliminating delays eliminates waste. Delays caused by too much work, poor collaboration, poor relationship between work and how people are allocated to it. Look for handoffs, handbacks and size of queues. Create cross functional teams to the extent possible. Avoid overloading people. “Flow when you can, pull when you must” |
work rarely waits | ||
| long delays |
Delays between making an error and detecting it.Delays in feedback both makes it more expensive to fix detected errors while cascading waste to others Achieve flow. Use test-first methods. |
no delay | ||
| Test after build |
Relationship between build and testIf testing lags building errors will be detected late. Use verification (test-first) methods. |
Building and testing are concurrent. | ||
| Many value streams |
Number of value streams people are inPeople should not be in so many value streams that they can’t finish a request from one before getting a request from another. Have people be in one value stream or make it clear how being in multiple value streams causes problems. |
One (idealized) | ||
|
Work not visible Delays not visible Agreements not made or not visible |
Degree of visibilityPeople can’t manage work unless they can see it. People can’t collaborate well unless what they are working on is clear and how they are working on it together is clear. Make all work and agreements explicit. |
Work is visible Delays are visible Agreements have been made and are clear |
||
| Poor collaboration |
How well people collaborateCollaboration is a critical aspect of removing delays in workflow and getting quick feedback. Achieve cross functional teams. |
Good collaboration | ||
| Teams work on their own |
Cadence and SynchronizationWithout this errors will propagate and not be discovered Use Continuous Integrate Continuous Deployment if possible. |
Teams work in a common cadence and synchronize on a regular basis. | ||
| Low product quality |
Product/service qualityProduct/service quality refers to both how fit for purpose the product/service is and how well it has been designed and implemented. Use verification (test-first) methods. |
High product quality | ||
Why A Bias for Simplicity Is Important
In "The Choice", Dr. Goldratt states "The first and most profound obstacle is that people believe that reality is complex, and therefore they are looking for sophisticated explanations for complicated solutions. Do you understand how devastating this is?" The "devastation" results from believing a system is complex and then looking for sophisticated explanations for complicated solutions. It's the search for sophisticated explanations that's devastating - because simple explanations are available but not being investigated.
We already have a great deal of experience with a bias for simplicity. It is often called "intuition." When we make an endeavor to discover this consciously, we become more adept at it and can greatly increase our understanding of what we need to do.
We need feedback, no matter how well we think we understand things
The potential of mis-understandings and other potentially chaotic (small error big damage) we must always get feedback on our actions. Therefore, however, confident we are, we must always be suspicious of our actions and use feedback to ensure we’re getting the results we want. We should also take the attitude that we are adding value when we learn.
If we don’t get the result we anticipate, we should ask why? It may be that we are in a part of the system that is unpredictable, but much more likely is there is a relationship that we either weren’t paying attention to or misunderstood. We can use the results we achieved (good or bad) to improve our understanding of the system.
By taking this attitude, is that even when we don't get the result we want, our understanding always improves.
A Short History About Getting to This Point
This section provides some insights by Al Shalloway for the interested reader about attempts to get here that, while somewhat effective, are not as effective as this.
I have long believed in looking at patterns. Christopher Alexander's work, in particular The Timeless Way of Building, has had a tremendous impact on me. My ability to digest a lot of disparate information and make a cohesive theory has long enabled me to go into organizations and see both what is happening and what to do. Admittedly I've had a lot of training in this - mathematics, psychology, engineering and science. Some people told me I've just got a knack for it. But I've always felt that all I was doing was bringing my instinctual observations up to conscious decisions. This meant others could do this if they knew how to look at the problem.
My first attempt to do this was to have a few solutions under my belt to bring out. But as I noticed more patterns of solutions I realized I could create entire solutions from them. This led to what I called "the inflection point system" which was a collection of options for most all of the problems organizations faced in product development/maintenance that had a software component. This had a decent track record (about 50%). Some of its failings was due to people sabotaging it, but regardless of why, it was not providing clear answers at least half of the time.
I then looked for what I called "natural laws" of development. These were concepts like big batches cause problems, multi-tasking creates additional work. This was very effective. But it still had complex solutions to solve. It focused on making a better understanding of the solution, not a simplification of the problem. I was still looking for solutions.
When I first came across Dr. Goldratt's inherent simplicity I misunderstood it to be the same as natural law view I was doing. But it isn't. Dr. Goldratt's intention for inherent simplicity is to create a simple system to understand by attending to it in a better manner. From here we can then look to see how to create solutions.
To learn more about Inherent simplicity, watch this four minute video – The role of the Thinking Processes of the Theory of Constraints by Dr. Eliyahu M. Goldratt
Using Inherent Simplicity to Guide Your Actions
| This post has Dealing with Complexity by Using Inherent Simplicity |
Why to use the word capacity instead of resource when referring to people
| There are many in the Agile community that believe referring to people as But there’s another reason not to call people We are trying to use whatever capacity we have on the most important tasks. So instead of resources, I do more than just calling people 'people'. I always talk about capacity. This not only will not |
Why Teams Should Have a Tailored Approach for Adopting Agile
| When considering how to start and continue an Agile adoption, there are several important aspects of the adoption to consider:
Attending to context. When starting, it’s easy for teams to get lost in their own world. However, the team itself is only part of the value stream Deciding how to start. Teams uniquely combine personalities, type of work being done and other factors. There is no one way to start that fits all teams. Adopting a framework that provides only one approach to starting runs a high risk that there is a large difference between what it suggests and what would be more optimal. This means our adoption will be slower than it needs to be. Fortunately, there there are a reasonably small number of solution patterns that covers most teams’ needs. In the same way we don’t need a Clarifying a team's improvement goals. While teams are unique, the objectives teams must accomplish to be effective are Challenges with not doing the aboveFew frameworks espouse the above adjustments. Most go Agile Frameworks Should Be Agile ThemselvesAgile means to be flexible. When we use Agile to develop
|
Eight Steps to Improved Scrum
| Scrum can be a solid foundation for software development teams. In the 24 years since Eight Steps to ImprovementStep 1: Consider Scrum as an example of Step 2: Use flow theory to create a focus on finishing and to avoid handoffs, Step 3: Base this new Scrum on Lean. Include systems-thinking to help you see the big picture and have explicit workflow to facilitate collaboration. Step 4: Test-first to some extent relating both to requirements and development understanding and requirements to implementation. Ask the questions:
Step 5: use Minimum Business Increments. While MVPs are in vogue, most companies are not making an investment to see if a new product is useful but Step 6: include management in improving the process. Servant leadership is to the organization not to the team. See Toward Middle-Up-Down Management: Step 7: Have everyone agree to the guardrails. The basic agreements are:
Step 8: Continuously improve by deepening your understanding of software development by using PDSA in your retros to improve your understanding of the challenges being faced |





