Manifesting Business Agility

Everyone agrees that simple is better than complicated. But there's not a lot of agreement on what simple means. Many in the Agile community view simple as meaning minimalistic - having as few parts as possible. Scrum in particular, has intentionally been defined as a minimalist framework in order to keep it simple. While Scrum may be simple, if any of its immutable roles, events, artifacts and rules don't fit a team then this lack of fit will make its adoption more complicated than it would be if a fit were provided.

Some people believe the only alternative to Scrum's minimalistic approach would be a framework that is too complicated because of all of its options. I do not agree with the presumption that including more choices results in more complexity. In the same way a well architected software application will only expose those options that make sense for the user, a well architected framework will do the same. This keeps the number of exposed options similar to a fixed set. 

The purpose of architecture is to avoid this from occurring. Software developers have been doing this for decades with application and system architectures. We should expect frameworks be architected as well to enable us to have multiple implementations to choose from without adding complexity. This enables us to choose what we need instead of reinventing it or possibly never knowing it exists.

Architecting frameworks this way also makes it so those new to Agile don't need to re-invent the practices they need. Although it is presumed they will, they often don't and when this happens Dark Scrum is a common result.

Consider how tool boxes in an auto-repair shop are organized. The top drawer contains the commonly used tools. But underneath the top drawer are other drawers - each containing more specialized tools. Mechanics don't think of the toolbox as one big container, but rather as an organized set of tools that they navigate according to their need. 

When a new mechanic is being trained they may not even be aware of many of these tools. But as we need them, they can be explained to the newbie.  They certainly don't need to be re-invented. This organization enables easy access to what's needed without overloading anyone. 

Users of a framework should not have to worry about how the framework is architected as much as how it is used. Choices can be presented without adding complexity. If this is not done then practitioners are often required to use practices that are not really suited for them. Using practices that are not fit for purpose adds complexity on its own. 

This is the idea of Disciplined Agile's Way of Working. It enables you to find practices that are fit for purpose. The Disciplined Agile framework has been designed to be easy to navigate and make choices. That's our job. The user's job is define their challenge. They get help in doing this from Flow and Lean thinking on which DA is built. 

It is easy to design something that is simple to understand but difficult to master. But this is often the result of poor design. Good design separates the user interface (in this case, how the framework presents itself to the user) from how the system is implemented (in the case, the inner workings of the framework). This is one of first laws of design - decoupling interface from implementation.

With proper design, frameworks can make things much simpler by focusing on fit for purpose instead of fewest components/practices available. Most frameworks need to step up to this. Fortunately, Disciplined Agile already does. 



 But the focus on the individual and team to get there is mis-directed.

From the Scrum Guide – “When the values of commitment, courage, focus, openness and respect are embodied and lived by the Scrum Team, the Scrum pillars of transparency, inspection, and adaptation come to life and build trust for everyone. The Scrum Team members learn and explore those values as they work with the Scrum roles, events, and artifacts.”

I think this is more hope over experience. The lack of trust is often rooted in the relationship between the team and their management. Scrum often works to further this isolation – providing only visibility of input and output of the team. There is little collaboration created.

“It is easier to work your way into a new way of thinking than think your way into a new way of working” has been ignored. Many of the problems that teams have are due to actions that take place outside of the team. Teams need to work with management to create trust. Avoiding interruptions by not allowing them with the threat of abandoning the sprint.

Lean thinking can provide an answer here, but this thinking is more holistic in nature not merely putting in a few Lean practices

For 15 years i've used Lean & Flow thinking to make decisions on what to do to help people improve their methods.. Understanding that we’re in a complex adaptive system I felt that I could get some general improvement by attending to the relationships in the system while looking at them in the context of the entire system.

I started working on defining an expert system about 6 years ago. In 4 years I built two of them – each having some success rate, but not greater than 50%. The problem was I could see what to do but it was often difficult to get folks to understand why. Part of the problem was me, part of the problem was the experience it took to understand the solution. But given we’re in a CAS, I felt the difficulty was inherent in the problem.

I persevered, however, and in the last year I’ve used Chris Alexander’s “Timeless Way of Building” approach. It led to the FLEX system and I found that I could convey what I do to people with a few years of experience. It was based on what I call natural laws – how the relationships between parts of the system worked. This greatly simplified the solution, but it was still complex. I had tangible evidence that I now had a better approach. It was still complicated, but it was more useful. I had pretty much relegated myself to coming up with complicated solutions for complex problems – not too bad, but requiring a lot of work.

Then I was introduced to Inherent Simplicity and started reading Dr Goldratt’s The Choice. I saw the relationship between natural laws and inherent simplicity and realized I could now explain things much easier. As I’ve been doing this the last few months, I’ve been seeing that I’ve let the common complex-philia that seems to be present in our industry make me hesitant on looking for a simple way to understand our complex problems. While I knew that complex systems don’t resolve down to understanding the relationships and that a deductive approach wasn’t going to work, I had had a considerable amount of success taking this flawed approach.

As I read the Choice, Dr. Goldratt’s confidence in his approach gave me confidence that inherent simplicity went beyond relationships between the components of the system but were a way of looking holistically at the problem in a much simpler way. I’m now convinced that inherent simplicity can lead to a consistently simple way to view our challenges. We’re not going for simple solutions, but a simple way to view things to make effective decisions. I can’t prove this yet, of course, but already the inherent simplicity approach is better than my earlier expert systems.

I’m convinced that trying to solve our challenges in seeing what to do with inherent simplicity is a worthwhile task. It is at least worth exploring. The alternative is to continue struggling with the limiting belief (whether accurate or not) that we have little power in making insightful decisions that have a predictable outcome.

I am not suggesting that other approaches are wrong. I’m merely stating that looking for more effective ones is worthwhile.

If you want to learn more about my approach, which is at the heart of FLEX and Disciplined Agile, check out the article Dealing with Complexity by Creating a Bias For Simplicity.

An organization creating new products and services is a complex adaptive system. A CAS is a system in which a perfect understanding of the individual parts does not automatically convey a perfect understanding of the whole system's behavior. This means one can't be certain what change in one part of the system will have on another. But this doesn't mean that cause and effect doesn't exist for the system as a whole. Even in complex adaptive systems there is a cause and effect when one deals with the system as a whole. Here are some examples:

• overloading teams with work will lead to ineffectiveness - "Operating a product development process near full utilization is an economic disaster." Don Reinertsen
• a lack of visibility of what is being worked on will lead to extra work
• large batch sizes will lead to delays in feedback and delivery of value while increasing unplanned work
• the longer it takes to integrate across teams the more likely fixing the errors discovered will take more time
• having people work in multiple value streams where they are not allowed to finish their tasks in one before going to another will increase multi-tasking and create waste
• as code and product quality goes down, the amount of wasted effort goes up
• micro-management is a disincentive and loses the value of understanding that people doing the work have

There is nothing so useless as doing efficiently that which should not be done at all. Peter Drucker

For every complex human problem, there is a solution that is neat, simple and wrong. H. L. Mencken

If the brakes of your car were jammed on, you wouldn't try to improve your car's performance by getting a bigger engine. The same should be true for any improvement initiative - look for the real problem and solve that. Not overcome a side effect of the problem.

Unfortunately, with the rise of Agile, we are tending to do just that - solving team problems when our real root cause is elsewhere. While it is true that teams are not working effectively in most large organizations, the main cause of this may not lie with the teams.

Consider these questions to identify the source of your problems:

• is there was a clear vision for the company and everyone could see why what they were doing contributed to it?
• is the work being given to the teams formulated in small batches of work that can be built and value realized for or is what is given to the teams larger than necessary (epics) or inappropriate for the job (e.g., MVPs for established products)?
• is much of the work being worked on not as important as some of the work waiting to be worked on?
• Do executives interrupt the teams without considering the costs of the interruptions?
• Are there mostly stable teams working together on one project at a time?
• Do you have people working on multiple projects when their skills don't truly require that?
• Are your teams working on too many items?
• Do product managers and owners talk to the teams prior to the teams starting work so that the teams understand what is needed (i.e., test-first or verification is being used)?
• Product managers and owners are readily available to the teams 
• Are people rewarded on the basis of how they contributed to the whole?
• Is management is focused on improving the environments within which teams worked?
• Is there was an appreciation by management and executives of code quality and architecture?

Now, consider how much improvement would be made at the team level if you improved how you worked on these. My guess is quite a lot.  Now consider how much fixing the teams without fixing these first will have on these items?

This illustrates a factor for simplicity that actions upstream in a value stream have a direct effect on whatever is further down in the value stream. But that actions downstream have only an influencing effect on actions upstream.