It is difficult to get a man to understand something, when his salary depends upon his not understanding it. Sinclair
The task is, not so much to see what no one has seen yet; but to think what nobody has thought yet, about what everybody sees.
All truth passes through three stages. First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident. Schopenhauer
Those who do not learn history are doomed to repeat it. George Santayana
I am enthusiastic over humanity’s extraordinary and sometimes very timely ingenuity. If you are in a shipwreck and all the boats are gone, a piano top buoyant enough to keep you afloat that comes along makes a fortuitous life preserver. But this is not to say that the best way to design a life preserver is in the form of a piano top. I think that we are clinging to a great many piano tops in accepting yesterday’s fortuitous contrivings as constituting the only means for solving a given problem. Buckminster Fuller
First, I promise I am not trying to get a surreptitious sales call. I am wanting to do marketing research. Here is the situation. I am looking to disrupting the big 8 as I’ll start calling them (Scrum.A/I/O, SAFe, DAD, LKU, LeSS, Spotify). There is more goodness outside of them than inside of them (& i’m excluding what i have to offer when i say that).
I don’t want to go into details yet, but i’m hoping to get a better understanding of the attraction of the certifying bodies as well as well what might be more attractive.
Anyway, if you’re willing to give me 15 minutes of your time I’d greatly appreciate it. Just email me at alshall netobjectives com thanks.
I often hear complaints in the Agile space about how leadership and management don’t get Agile. I think much of that is because of how they are talked to. But I also believe it is the set of practices used makes it hard to see their role without doing a deep study of Agile – something they are neither interested in or going to do (and not something they need to do).
It recently occurred to me that one way to evaluate the quality of an approach is how it affects the conversation with leaders and managers.
I just updated my chapter on Using the Intake Process to Educate Leadership.
SAFe is not Agile if you are planning 3 months ahead
For companies that couldn’t get anything done in a year and are now getting things done in 3 months, SAFe is great. But don’t consider it Agile.
Quarterly planning presumes more certainty than we have. It’s waterfall thinking. Going from 12 to 3 months is an improvement. But don’t stop there.
If you are a development group of less than 300 people you probably could be doing 2 week plannings or even flow. Every now & then you can do a big room planning for the social benefits that provides, but it’s not needed for planning.
Long planning periods:
- require reworking requirements in last couple of sprints
- loses focus on realizing value
- makes it more likely that features will be bigger than needed
- loses focus by teams on releasable value
- results in more work being injected into already planned work
- has the refinement of any stories pushed out of the PI due to new work be waste
- makes it harder to pivot
- causes a loss in a sense of urgency
- requires more refinement up front without advantage of feedback
- establishes a baseline of “not good but good enough” so improvement stops
It’s fine to do high level quarterly planning but then work in a flow model to implement it.
One important aspect of systems-thinking that has long been ignored by the Agile community is that a system is not its components. Rather, it must be recognized that 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 occur, unexpected interactions and sometimes small, even obscure events happen that cause huge side effects. This is a reflection that product development (creating the unknown) by a group of human beings (by nature unknowable) comprise what is known as a complex system.
Many people have gotten caught up in the theory of complexity going further than what I need is necessary for pragmatic effect. While it is true that complex systems can’t be predicted, there are many patterns of behavior exhibited by them. In the same way engineers were quite effective in building magnificent edifices (e.g., the Pyramids) without a full understanding of the science underneath the methods used, it is possible to adjust the behavior of complex systems without understanding the full nature of the principles involved.
We mostly need to know that 1) our changes may produce unexpected behavior and 2) we are embedded in a system where small errors can cause big, undesirable affects (the essence of Chaos Theory). However, instead of giving up and saying we can’t predict things, we can move forward with an knowing our understanding is always incomplete. We do, of course, need quick feedback, both of our actions in our work and in any actions we take towards its improvement.
Both agility of development and improvement of our methods is required.
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.
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:
- hand offs (these delay value because they typically cause a degradation in understanding)
- delays in workflow (i.e., waiting for someone)
- interruptions to workflow (often caused by working on too many things)
- delays in feedback – a symptom is when work goes upstream (e.g., dev back to product owners)
- doing less valuable work than what could be worked on
- 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.
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).
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.
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.