An experiment in the power of perspective

sAs I’m completing my book the thought that keeps coming back to me is that when you look at things the right way they get a lot easier. And that much of what’s hard about Agile is that people aren’t looking at it the right way.  I don’t mean the “being of Agile” which I believe is a red herring.  Let’s run a little experiment. Please explain the following:

5+2= 7



For those of you who know bases you’ll figure out this is addition in base 8.

Now, show this to someone who can do addition but doesn’t know bases. See how long it takes them to figure it out. I would guess many won’t.

But what if you had an easy way to explain bases and base addition (I do but it’s not important to the point of this post so I won’t bother here). Understanding bases makes a certain problem easy that is impenetrable when you don’t have that insight.

I believe we have this problem in Agile. People are looking at examples of what to do (practices) instead of the equivalent of bases in Agile. I’m not saying it’d be easy (e.g., add 142372341539243 and 524234714234 🙂 ) but it’d be easier. 🙂

Why Shu Ha Ri and Scrum Can Make for a Dangerous Combination

This was originally published May, 2017

Note: This blog assumes the reader understands the basic roles and practices of Scrum.

Scrum suggests that the way to improve a team’s workflow and the organization within which it works is to remove impediments to its core roles (product owner, team, Scrum Master) and practices (cross-functional teams, daily standups, and using time-boxing for work, demos and building backlogs). It takes an inspect and adapt approach that requires little understanding of the underlying laws of software development other than an acknowledgement that reducing the time for feedback is essential and that small batches are better than large ones.

Continue reading “Why Shu Ha Ri and Scrum Can Make for a Dangerous Combination”

Complexity is Not What it Used to Be

This was originally published in May 2012.

Those who cannot remember the past are condemned to repeat it. George Santayana

The time was 1847. The place was the Vienna General Hospital. New mothers in the doctors’ wards had been dying of puerperal fever with an extremely high mortality rate – three times that in the midwives’ ward. It was a mystery. It could not be explained. But Ignaz Semmelweis had been observing this for years. Had studied the situation and made some interesting connections.

The situation was very puzzling. There were two clinics in the hospital Semmelweis oversaw. Clinic one was the teaching service for medical students; clinic two was where only midwives worked. Why was the presence of doctors apparently killing new mothers? Women were coming to the hospital’s maternity ward for the benefits of the child care they would receive. But the high mortality rates had them try to avoid coming on a day when they would be admitted to the first clinic. In fact, many preferred to have their births in the street, then come to the clinic for the benefits. Surprisingly, the mortality rate for those giving birth in the street was significantly lower than for those giving birth in the doctors’ clinic. It was a mystery, and nothing could explain it.

Until Semmelweis figured out the connection. And proved it – lowering the mortality rate from the 10-35% it had been to 1%. The connection was doctors working on cadavers (it was a teaching hospital) and then going to do their rounds with patients. The solution was Semmelweis instituting the practice of hand disinfection with a chlorinated lime solution he created. The results were dramatic. But his theory was incomplete. He could not explain why it worked. The existence of germs had not been postulated yet, let alone detected.

His theories were scorned. Administrators of hospitals thought the suggested disinfection process would take too much time. Doctors were not eager to admit that they had caused so many deaths. It was not until years after Semmelweis’ death that his theories were accepted – after Pasteur could demonstrate the existence of germs. For more on Semmelweis, see Wikipedia.

How does this relate to us? I would suggest the knowledge of germs to doctors is like the knowledge of flow to software developers. It is not all there is (other things cause disease than germs) but it is pretty important to know. Things that often appear complex and unknowable, are, in fact, complicated but unknown. BTW: I am not suggesting that software development as a whole is not complex, just that not all of it is complex.

I have been doing some form of agile consciously for over 20 years. I have been doing agile practices at one time or another for over 3 decades Unfortunately, that “one time or another” was hit or miss. I did it when I intuited a solution, but that was relatively rare. I am a big believer in understanding why what you are doing works – see an old blog of mine – Smart People, XP and Scrum – Is There a Pattern?

It seems the software industry has hit a crisis in the adoption of Agile. It is almost to be expected that when you hear about a large organization successfully adopting Scrum for several teams working individually, you learn they can’t quite get it to work well across teams. Why is this? Well, it’s a mystery for some. Not for others.

Since 2005 we (Net Objectives) have been helping clients who have been encountering cross-team challenges in their development methods (IT and products). Many of the insights we’ve had have come from looking at the theories of Flow and how they apply to software development. This is one reason I am so passionate about the need to understand that Scrum itself, is a manifestation of Flow and Lean thinking. By not being consciously aware of this, many Scrum practitioners can’t extend it as needed, or abandon it for better methods when available.

I have seen some development groups (75-150 folks) transform themselves almost overnight by attending to flow. I have also been somewhat mystified by much of the Agile consulting community’s resistance to many of these ideas – having once been thrown off a discussion group for insisting they were a better alternative than (still) popular methods of team collaboration.

The need to teach the principles that drive practices with the practices

This is an except from Al Shalloway’s upcoming book: Going Beyond Lean and Agile: Introducing FLEX – FLow for Enterprise Transformation. It is from a particularly important section called Teaching and Adoption.

I have never liked the common Scrum/SAFe approach of teaching select practices that are expected to be used as is. Their justification is that you need to understand how to use these practices before going beyond them. I have observed that while people need a set starting point they also need to understand why things are working. This creates learning opportunities from the start and enables a gradual improvement, or even, transcendence of the practice.

The martial arts model of “Shu (follow) Ha (break with) Ri (transcend)” is often used to justify this approach. But several several flaws exist in this logic. In the martial arts you are trying disengage your mind at first, not so in knowledge work In addition, no guidance on how to move from following (“Shu”) to breaking with (“Ha”) is provided. What’s worse, is that by defining Scrumbut in the way it has been, the belief that people who don’t “follow the rules” are somehow bad and get poor results.

The worst flaw, however, is more insidious. It’s the loss of the opportunity to learn while using. This would be to provide the underlying model of the practice. People can ‘follow’ the practice while seeing how it applies the underlying principles involved. This enables them to learn how to use these principles and tailor the practices for their own situation. They never break with the underlying principle but will break with the practice and possibly even transcend it completely. But not the principle.

Let me give you an example from sailing. Fledgling sailors are told to look at a flag or ribbon on the mast to see which direction the wind is going. But they are also told that they can learn to see the wind in the water if they look upwind and attend to the ripples on the waves. Newbies can immediately use the flag on the mast. But by looking at the more advanced practice of looking at the ripples on the waves they can learn to see the wind before it hits the sail – a very useful thing. So very quickly they learn to see the wind as it hits the sail and before it hits the sail. In addition, they eventually notice side ripples on the main ripples. These are from swirls in the wind. This tells them even more. They learn through a combination of using the basic practice, trying more expert practices, falling back to the basic one when needed and understanding what is happening much more. They never transcend the principles – only the practice that they started with. And they don’t have to do a sudden “break” with the practice, but can do it over time.

Learning with this combination of practices and principles is what sets Net Objectives training as different from frameworks. All frameworks are a combination of practices and principles. But the framework is defined by some core set of practices (e.g., in Scrum you must have time-boxing and cross-functional teams). The dangers of this are twofold. The most obvious one is that the practices prescribed may not fit your organization. But the other, more insidious one, is that doing this prevents you from learning as quickly as you would otherwise.

What I have Learned from Scrum

Here are some things I have learned from Scrum.

  • Cross functional teams are good. Just having them achieves a three to tenfold improvement over a group of people working on several projects at once. And they improve innovation by the team.
  • Time-boxing increases discipline, visibility and the ability to pivot.
  • Small batches are good and breaking work down into small pieces is essential.
  • Smaller release cycles improve most everything.
  • It is useful to have a team coach.
  • Do not expect people to figure out what they need to do just because you have put them in a framework.
  • Focus on learning the practices of a framework makes learning what you actually need to accomplish (flow) harder.
  • People like to be given a set of practices to use.
  • Defining a simple set of practices to use can lead to rigid dogma.
  • Take an approach that transitions you to the behaviors you need.
  • Approaches that work well in one context may not work well in another even though people them everywhere without noticing this.
  • And, just because you can put whatever you want into a framework, that doesn’t mean the framework is not prescriptive. In itself, the framework has things you must do.

Continue reading “What I have Learned from Scrum”

The Purpose of an Assessment

Assessments are not about where you are. They are about where you want to go. By seeing where you are and what challenges you are having a roadmap for improvement can be made more effectively.

Assessing can be done in several ways. The most popular Agile method is to see how well the company is doing from the perspective of the approach they are taking. For example, a common assessment for Scrum is the Nokia test which specifies how well teams are doing Scrum. SAFe® has its own assessments. But consider these as assessments in how well a framework is being adopted, not how well the company is delivering value. We have found that focusing on the work, not the framework, is a better approach.

Because FLEX is based on a model of flow, it can be used to see where an organization is having troubles with achieving flow; that is, performing its work with few hand-offs, turmoil, delays, and rework. Reducing these helps achieve business agility. It is more effective to attend to how work is being delayed or how extra work is being created than how well a practice is being followed. Therefore, an assessment should focus on the value stream and what is impeding it.

For more, see Using FLEX to Perform an Assessment for Small-Scale Organizations

Intermediary Practices vs. Practices That Work Directly on Flow

An intermediary practice is a practice that works indirectly on what you are trying to achieve. Before discussing examples and the risks of intermediary patterns, let’s look at some of the things needed to achieve flow (realizing value without delay):

  • Removing delays in workflow (hand-offs and waiting for others), feedback, learning, and between getting and using information
  • Manual testing
  • Interruptions
  • Technical debt

By working directly on these, here is what you would have. Continue reading “Intermediary Practices vs. Practices That Work Directly on Flow”

Using the Theory of Flow to Illustrate Impediments in Two Hours Instead of Two Weeks

Simply put, the Theory of Flow focuses on two areas:

  • The steps it takes from conception of an idea until value is realized from it
  • Reducing the Cost of Delay, the revenue or opportunity lost because of delays in realizing value

Reducing Cost of Delay (CoD) is essential to the goal of business agility, the quick realization of value predictably, sustainably and with high quality. Continue reading “Using the Theory of Flow to Illustrate Impediments in Two Hours Instead of Two Weeks”

Improve Your Scrum by Using Flow Thinking

Scrum is based on empirical process control, the pillars of which are transparency, inspection, and adaptation. This mostly means that instead of following a plan we observe how things are going and adjust accordingly. But this doesn’t mean that we can’t use theory. It’s just that when we do use theory we must verify it worked. Continue reading “Improve Your Scrum by Using Flow Thinking”

Nice to See Scrum Catching Up (or Trying To)

Recently, announced the integration of Kanban practices into Scrum and that “Observe Orient Decide Act (OODA) is the mindset of Scrum. This comes on top of the announcement of Scrum team training a few years ago. These are all good things. It’s nice to see the Scrum community trying to catch up to the many non-certifying consultants who’ve been doing these things for 5-10 before. Continue reading “Nice to See Scrum Catching Up (or Trying To)”