Why the assumption that starting with a pre-pset start creates consistency is flawed

The two most popular Agile frameworks today suggest a preset starting method. Scrum with cross-functional teams and SAFe with Essential SAFe.

Both have the rationale that people need to start in a well-defined way and abide by it until they learn more. SAFe also promotes that consistency of practices is needed across the organization.

Continue reading “Why the assumption that starting with a pre-pset start creates consistency is flawed”

There’s more to coaching than “being”

I’m not saying that how a coach “be’s” is not important. But it’s also not the only critical aspect of things. Good energy, knowing what to explain and explaining them well are critical. A great coach can explain the right things to people so that they can learn on their own.

The Agile community is currently focusing on certification and frameworks that make it easy to start. I believe this is much of the reason for Dark Scrum and Fake Agile.

We need to shift our focus to the laws of effective software development embodied in Flow and Lean thinking. These are usually touched on in framework training but then used to justify practices that are only partially consistent with them.

It’s amazing to me how this is as effective as it is. It is better when you integrate true Flow and Lean thinking with your practices. Go for smaller pieces, shorter timeframes and greater visibility. How to do this is easier with a framework designed around the value stream.

Don’t rely on framework thinking, rely on real thinking-yours. Don’t buy the quick excuses I hear many consultants espouse- “if only they’d do what’s in the guide”, “management wasn’t involved”, …

The job of the consultant is to guide the way, not blame their clients. That’s true being.

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

14+13=27

14+15=31

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

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.

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”

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”

Something has Happened to Me (Not My Normal Rant)

I’ve been having a very interesting two weeks. I would like to say that whenever I go into a client, I am always on, and always get my clients to see new opportunities. But I’d be lying.

However, for the last two weeks, that’s been what’s been happening… with five clients. While I feel I’ve been “on” and empathetic, that only explains half of it. Something else has been going on.

Here is what I think has been happening. In all of the cases, I started out with:

  • Depicting a value stream representing what they’d like to happen
  • Adding their team names, relating this to what people were doing now (making it less theoretical)
  • Identifying the client’s problems in this ideal flow

At this point, they started asking how to solve their problems. Often, they are stumped about how to work with non-Agile teams or how to create predictability. They would ask, “How can you do this in Agile?” “What do you think about LeSS?” Essentially they were taking solutions they knew, or had heard of, and were trying them on.

It’s like shopping for clothes. Every company is shaped differently. There may be lots of clothes (solutions) out there that don’t always fit. That’s when you want to learn to be a tailor.

This is the first of a series on the implications of these insights.

Walking my Talk – Integrating our On-the-Job Online Master Class With our Onsite Class

I’ve been espousing (a nice word for rant) about the need for scaled learning methods and how 2-day classes have low retention. I’ve decided to integrate our On-the-Job Online Advanced Scrum Master / Kanban Coaching workshop with our Team-Agility Coach (our integration of Scrum/Kanban workshop.

Our online workshop is normally $595 but when you take our Scrum/Kanban master course we’ll include that for $200 a person. This means that our 2 day workshop followed by our 3 month program is $10,400 for 12 people ($500 for each additional person).

The onsite aspect of this integrates Scrum and Kanban. The three month program has me work with participants helping them apply what they’ve learned, as well as advanced topics of Agile, with their teams.

Please message me if you’re interested.

Why I’ve Decided Not to Raise the Cost of Our On-the-Job Online Agile Coach Workshop

After writing about how our workshop avoids the issue of the 80-90% retention loss of normal trainings, covers twice the material of an Advanced CSM class, provides a performance support system and is provides timely coaching to its participants in their working with their teams, I had decided to raise the price from $595 to $895 – still a bargain compared to the common $1295 fee for an Advanced CSM class (not to mention the 2 days lost in an Advanced CSM class and likely travel time/cost).

But I’ve decided to go in the opposite direction. While the program is 3 months long, I will let people have access to the live coaching sessions included for 6 months along with the already annual access to the performance support system for a year.

I am committed to disrupting the current ineffective manner the industry now relies on for teaching people how to be Agile coaches. I am leading this workshop myself and promise it will change both how you look at Agile and Lean as well as your effectiveness.

We’re starting the next workshop this week, so please ping me if interested.

Why Agile Coaches Need to Know Both Scrum and Kanban



Scrum and Kanban are the two most popular Agile team-level methods available. While the difference between them is mostly thought to be sprint-based or flow-based, that is just one way in which they differ. Other significant differences include how to start, how to improve, and how people should be organized. They are based on different theories of how to manage software development work and whether you need to change your roles. And this creates other differences such include the amount of discipline to use them and the cultures in which they fit. Continue reading “Why Agile Coaches Need to Know Both Scrum and Kanban”