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.
While many Agilists have been celebrating attempting to adopt Agile as crossing the chasm, it’s been little noticed that we’re on the edge of a new paradigm. While not yet named, it’s been called “FLOW”, “product development flow”, and “business agility”, among others. This paradigm shift goes beyond Lean’s paradigm shift (which Agile has not yet embraced). Essentially, it’s both a different focus on value & a different way of getting there.
The focus is on value to the business (which, of course, is mostly comprised of value to select customers). It also has an organizational instead of team centric. Another difference is a belief that, although, or even because) product development is embedded in the complex system called an organization, it is important to attend to laws and principles of product development. But the biggest shift is that instead of focusing on frameworks to help us, we need to focus directly on the work to be done. Here are the shifts:
- Focus on the system not individuals
- Use science of flow, systems-thinking and lean
- Focus directly on what we’re trying to achieve instead of frameworks Paradigm shifts are shifts in beliefs.
This is not the same as putting flow or Lean into Agile.
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).
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”
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.
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
I was first introduced to XP in 1999. I remember getting into an avid discussion on the XP user group about TDD. I could never remember what it stood for, often calling it “Test-Driven Design” because I recognized that TDD helped people design their code when using it. This was consistent with the first mantra of design patterns, “Design to the behavior of objects.” Focusing on behavior informed design.
I also remember getting some flack for it. People said things like, “tests couldn’t possibly inform design.” My opinion was, and is, that they not only could they, but they should. Continue reading “Understanding the Concept of Testability: A Worthwhile Remembrance”
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
- Technical debt
By working directly on these, here is what you would have. Continue reading “Intermediary Practices vs. Practices That Work Directly on Flow”
I’ve created a new design for my book and am pretty excited about it. There are five parts to it:
- Part 1: Workbook: understanding what’s required for flow in your organization
- Part 2: Workbook: Using FLEX to transform your organization
- Part 3: Topics in depth
- Part 4: Using FLEX w/SAFe
- Part 5: Resources on the Net Objectives Portal
The first two parts cover the basics of FLEX. They present what the effective enterprise of the future looks like, giving a vision for the transformation. They are designed as workbooks to guide readers via a way to learn by doing. They are also relatively short so they represent a quick overview of the entire approach.
Part 3 provides an in-depth explanation of the topics used in the first parts. Part 4 discusses how to take advantage of FLEX’s Lean portfolio & prod management approach for those using SAFe.
The last part of the book is online, providing the latest ideas and practices we are coming up with.
If you are looking for a more effective approach than either SAFe or LeSS, I invite you both to look at the book as it is uploaded. If you are interested in using it to help with your own adoption, let me know as I am looking to work with a few people while it is being written
To see the book, go to Going Beyond Lean and Agile: Introducing FLEX (FLow for Enterprise Transformation) (online book)