Systems thinking and complexity

An excerpt from the preface of my book.

One important aspect of systems-thinking is that a system is not its components but is defined by the way these interact in a way that creates the behavior.

But the nature of these interactions are very complex – meaning that they can’t be predicted. Unforeseen events & interactions occur. And sometimes small mis-understandings cause huge side effects. This is a reflection that product development is both complex (unknowable in advance) and chaotic (small things can have big effects).

While I believe a deep understanding of complexity can be useful, very little is needed to attend to it. In the same way engineers were quite effective in building magnificent edifices (e.g., the Pyramids) without a full understanding of the science underneath them, it is possible to adjust the behavior of complex systems without understanding the exact results of proposed changes.

We mostly need is to know that 1) our changes may produce unexpected behavior and 2) we are embedded in a system where small errors can cause big changes. This requires quick feedback both about the actions we take and process improvements we try. Both agility of development and improvement of our methods is required.

Impediments to flow

Flow-thinking is my latest thing. It’s looking at how to achieve value in the quickest way. This is not necessarily going faster – but mostly avoiding delays. I have observed that when I consult with clients I look for the following:

  1. hand offs (these delay value because they typically cause a degradation in understanding)
  2. delays in workflow (i.e., waiting for someone)
  3. interruptions to workflow (often caused by working on too many things)
  4. delays in feedback – a symptom is when work goes upstream (e.g., dev back to product owners)
  5. doing less valuable work than what could be worked on
  6. doing work manually that could be automated

As you minimize these you almost certainly will improve your value delivery. Quality typically goes up as well.

Question to ask when you hear something you know is wrong

When we hear something that we know is wrong we typically ignore it or argue with it. But there is often truth in something we don’t yet understand. One can’t tell at this point of course. It could be wrong. But it could hold some value if we’d explore a little further.

I have found it valuable to ask the question:

“what if this (absurd) statement is true?”

A good way to explore this question is to pretend the statement _is_ true – at least for a little while. This opens the door to many other questions such as “what am I not seeing?” “what am I looking at that is in my way?” “what does this person see that I don’t?” “what are they not looking at that I am looking at?”

You can even (for a limited time) act as if it is true and see what happens. Maybe you’ll learn something. Worst case is you’ll learn you were right (or still think so).

It’s not GETTING Agile that takes the time, it’s the NOT getting it

I had a mentor a long time ago who would say “it’s not getting it that takes the time, it’s the NOT getting it that takes the time.” I have seen this over and over again. I remember when I was learning design patterns 20+ years ago I spent 6 months NOT getting it. Then, in one 15 minute (imaginary) conversation with Chris Alexander I had the epiphany that led to my truly understanding what patterns were (they are well beyond “solutions to a recurring problem in a context” and was the basis for Jim Trott and my Design Patterns Explained book).

6 months NOT getting it.

15 minutes GETTING it.

Most of the 6 MONTHS of NOT getting it was studying and thinking about patterns. The 15 minutes of GETTING it was preceded by 6 HOURS of working on my problems.

The insight was not based on information but came from a slight mind-shift.

Maybe we need to learn by doing and not by being in a course where we are not working on our own tasks. This is the basis of scaled, flipped classroom learning.

Agile Developer Habits 101 – Focus on Finishing to Manage Work in Process

Kanban suggests we manage work in process (WIP). Many people interpret this to mean add WIP limits on queues. But that’s not the only way to do it. And it often takes a very disciplined team to do that.

An easy way to start managing WIP is to simply build a habit of looking to finish something before starting something new.

Habit – manage Work in Process

Trigger: When you complete a task.

Action: Look to see if there’s another task that’s already been started that you can finish. If it’s yours, just finish it. If it’s someone else’s see how you can help them.

Intention: Avoid increasing WIP above capacity without having to put a lot of effort on it while also creating opportunities for cross-learning and collaboration.

Announcing On the Job, Online Training for Scrum & Kanban Coaches

The best way for people to learn is on the job over time. The worst is in a 2-4 day course with where you learn information about something but don’t get a chance to try it. Studies have shown that 90% of what was learned in a classroom is forgotten in less than a week.

5 years ago I asked myself – “what would I do if a company asked me to train their thousands of Agile coaches who needed to become more proficient?”

We think we’ve come up with the best way to deliver on this. It also turns out to also be the most economical. The format we use is called “flipped classroom”, a method developed at Harvard. Essentially each lesson starts with a reading and video. An assignment is then given that participants work on with their team. Two live sessions are also provided so participants can ask questions before and after their assignment. Participants learn by doing while having the support they need. In addition, participants are provided access to an online support system that covers virtually all of the common challenges faced by teams. In this way participants can learn both the curriculum they need and get help on their own specific problems. The next program starts 1/28. Contact me if interested.

Elephants in the Room and No Clothes on the Emperor

There are many things I, and many other consultants believe, that are not politically correct to talk about. I am going to talk about them now. The reason is if you are a practitioner and these resonate with you, then you might want to consider working with people like me to help you get better. If you don’t want to work with me, then use this as a checklist to vet your potential providers.

Both coaching & training is more expensive than they need to be. Much of this happens because the certifying bodies control the number of trainers by quantity. Many of the top trainers in the industry have no certification by choice.

The biggest problem with the Scrum-Kanban confrontation is that neither are the right thing to do all of the time. Usually some combination of the two is best.

Intense training, except where people do hands on work is effective. True learning takes place over time in the learner’s workplace.

People need a support system that can be used to provide them insights into their own problems. Reinventing the wheel should not be required.

AFAIK our Advanced Scrum Master / Kanban Online Workshop is the only workshop that fits the above. It’s worth checking out.

How I define Lean-Scrum (how Net Objectives does Scrum)

I mostly love Scrum, but I am concerned with that it:
1) doesn’t work everywhere but is promoted as if it does
2) sets up a sub-conscious resistance to go beyond it as because the case where “We do Scrum, but we do X instead of Y” is virtually always considered negative whether it is or isn’t. Also, when you are certified in Scrum and go beyond it the value of your certification is lessened

Lean-Scrum differs from Scrum in the following ways:
1) Scrum practices & roles are considered to be ways of achieving particular intentions
2) The team needs to fit into the context of the organization
3) Any part of Scrum can be modified as long its intention is still retained. This may have you no longer be doing Scrum but you should still be doing some form of team-agility
4) It considers Scrum as a tool in a toolbox with other tools being needed (e.g., Kanban)
5) Scrum mostly works iterations & cross-functional teams are advisable
6) We don’t really care if we’re doing Scrum or not as long as we’re consistent with Lean principles
Lean-Scrum is an approach where use take what’s useful and leave what isn’t.

Be clear, Lean-Scrum is not Scrum. But my 19 years of doing & helping others do Scrum has demonstrated it is more effective

Making Frameworks Elegant: Avoiding the Simplistic or Complicated Trap

I define elegance as enhancing while simplifying.

These two have to go together. The result of enhancement without simplification is complicated. The result of simplification without enhancement is simplistic. In tour complex world both of these extremes are high risk approaches.

In the “enhance alone” approach we have people trying to follow something that tends to grow over time. But this inherently creates confusion. People also don’t usually have the time to learn all of the necessary intricacies. What happens is they proceed with a limited understanding and make up things as they go forward. This causes confusion and going back to old habits.

In the “let’s keep it simple” approach, people are forced to figure things out to fill in the gaps. This may work for early adopters, but is not so good for others. The result is again going back to old habits.

We often hear proponents of frameworks following one of these approaches exclaim that things would work if people would only use the framework. But that ignores the reality of how people adopt new ideas. Without clarity, old habits return.

While it is difficult to create an elegant approach, it can be done, and you should not accept less.

The Next Chasm To Cross

There is no question that Agile at scale has crossed the chasm. I would say that even the late majority is now involved. But where are the innovators and early adopters now? I would say they are:

  • Using operating models instead of frameworks
  • Focusing on business agility
  • Driving from Lean principles
  • The use of scaled leraning

However, as I go to conferences & write posts on social media I see that these endeavors are not limited to innovators anymore but are being pursued by many early adopters – the so-called “pragmatists.” The “chasm” between early adopters and the early majority is already being crossed.

I am seeing more and more companies who are looking for what works, even if they have to fill in the blanks a little themselves. While frameworks provide set solutions with some leeway for filling in the blanks, they rarely fit organizations perfectly. Also, current frameworks are based more on Agile than on Lean (even SAFe which incorporates many Lean principles supports a bottom up implementation approach). I think (and hope) that 2019 will see a crossing the chasm of the above topics. To facilitate this is the purpose of my new book and some new social media collaborations. Let me know if you’re interested.