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 you need Science as well as empiricism to enroll management in Agile

Making things simpler by providing choices with Disciplined Agile

Creating teams that are a great place to work is a central tenet of Agile

Why I believe Inherent Simplicity, or a bias for simplicity, will be the next big thing in making organizations more effective

Cause and Effect Does Exist in Complex Adaptive Systems

Why you need Science as well as empiricism to enroll management in Agile

I read many articles from Agilists about the difficulties they have with management. I believe that many of these problems spring from many in Agile (Scrum in particular) being based on empiricism alone and not the scientific method. 

Empiricism is a theory that states that knowledge comes only or primarily from sensory experience. The scientific method adds rationalism to add theories as to why we get our experiences. The scientific method includes empiricism to validate its hypotheses. Without this ‘model of understanding’ people tend to discount new ideas – especially people who have been successful and think highly of their own ideas.  See Evidence Without Theory Is Often Ignored.

i think much of the challenge with enrolling stakeholders and management in Agile is that many Agilists don't present a model that they can understand. Stakeholders and managers have often risen to where they are by being competent and fixing problems. Agile not only has a history of ignoring them, but with Scrum, for over a decade vilifying them in a subtle way (chickens and pigs). This hasn't fostered trust. 

This background should not be ignored - it certainly isn't by many managers. When the time comes where a manager feels they need to get something done, they probably don't feel very included or respected by the team.  So managers having a bad attitude with Scrum teams shouldn't be a surprise. But let's look a little deeper. How can the team convince the manager that interrupting them is a bad thing? What rationale can they use? The answer is - "it's against the rules of Scrum." Do you really think a manager cares about this? They may feel they are against the rules of Scrum."

What managers need to know is why the interruption would be a bad thing. Not from the team's perspective, but from the organization's perspective. This is where Flow and Lean thinking are quite useful. They present a scientific hypothesis on why injecting delays add waste, slow development down and increase the chance of errors. Now, I'm not saying managers will necessarily listen to this either. But a good one would - at least if the cost of the interruption were higher than the cost of not doing the interruption.

It also provides a basis for conversation and collaboration between the manager and the team. Empiricism alone won't enable this conversation - at best it would only create an agreement to try things. But managers have certainly experienced problems with imposed delays. If the situations are quite different, the abstractions (theory) that Flow and Lean provide may bridge the gap between manager and team. But without that, the manager may feel compelled just to impose his thinking on the team instead of just trusting them.   

Posted on: January 04, 2020 05:55 PM | Permalink | Comments (9)

Making things simpler by providing choices with Disciplined Agile

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


Posted on: January 03, 2020 12:52 PM | Permalink | Comments (8)

Creating teams that are a great place to work is a central tenet of Agile

 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

 

Posted on: December 15, 2019 02:52 PM | Permalink | Comments (4)

Why I believe Inherent Simplicity, or a bias for simplicity, will be the next big thing in making organizations more effective

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.

Posted on: December 11, 2019 04:24 PM | Permalink | Comments (5)

Cause and Effect Does Exist in Complex Adaptive Systems

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

 

Posted on: December 11, 2019 10:18 AM | Permalink | Comments (6)
ADVERTISEMENTS

"Karate is a form of martial arts in which people who have had years and years of training can, using only their hands and feet, make some of the worst movies in the history of the world."

- Dave Barry

ADVERTISEMENT

Sponsors