Manifesting Business Agility

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.

Five critical aspects of an Agile transformation are:

1. Understand your challenges
2. Decide where to start
3. Understanding the nature of the work
4. How organizations can improve
5. Having a clear direction for improvement

Different frameworks take different approaches to each of these. Scrum, for example, says:

1. Do Scrum to discover your impediments
2. Start with the immutable roles, rules, artifacts and events of Scrum
3. The best approach is empiricism – guide your work primarily from feedback and not an underlying model (theory) of what’s happening
4. People on the team will figure out how to improve
5. Build tested code that satisfies customers on a frequent basis

DA suggests:

1. Use the theories of Flow and Lean to understand where you are before starting
2. Choose a way of working to start solving these challenges
3. Delve deeper into the theories of Flow and Lean so they can understand the root causes of these challenges
4. Help organizations improve by presenting options as needed
5. Increase the quality and innovation of teams to provide greater value quickly to their customers.

By basing itself on the scientific method DA also applies these to itself to be continuously improving. 

Consider how Scrum suggests how to start, learn, and improve. It starts in one place, learns via retros at end of a sprint and teams are to improve via figuring it out themselves.

Lean suggests started based on where you are along with learning and improvement methods that are continuous. It also provides many practices not in Scrum in order to make Scrum simpler as if there weren't ways to add options without adding complexity to the user.

Requiring certain practices or getting the response "then it's not Scrum" has detrimental side effects. We should be learning whether something is effective and not whether it is part of the framework. Any framework not handling this is flawed.

I consider that Dark Scrum is often caused by not following all of its immutable rules, roles, artifacts & events to be a fault in its design. Frameworks must adapt to where they are being used.

At Disciplined Agile (PMI) we believe that choosing your own way of working is important. The small amount of upfront decision making more than compensates for the large amount of coaching that otherwise will be required later. But this decision making process continues as people learn how to improve and apply that knowledge.

For more on what I believe Scrum should look like see "The New Scrum Game" https://bit.ly/2OiJxX4

I had thought that driving in New Zealand was insane. That is, until I realized they drive on the left side of the road. Just kidding, but it’s not unlike many consultants complaining about how difficult software development is. Yes, it is difficult. But so is driving. And both can be made easier by attending to the right things.

Consider how the following makes software development easier, albeit, still difficult.

• Learn what works Vs Learn a framework
• Inherent simplicity Vs apparent complexity
• MBIs to enhance products Vs MVPs to enhance products instead of making new ones
• Work your own Way Vs set starting points
• Architecture Vs keep it simple
• Test-first right away Vs Test-first eventually
• Start by choice Vs Start with a set way and expect people to learn how to change practices later
• Double loop learning Vs Cognitive bias
• Systems-thinking Vs key set practices
• Changing systems Vs changing people
• Flow vs iterations

I am sure there are more.

But consider that  circumnavigating the world, going to the moon, heavier than air flight and other things were hard. I can think of few things more important than learning to create software well. It'd change the economy of the world.