This page is a collection of random thoughts (slightly organized).
Table of Contents by Category
Table of Contents by Date
- Thoughts about Scrum Guide Based Scrum (Sep-27-2020)
- Why to Focus on Flow of Value and Not iterations (Sep-23-2020)
- Constraints are misleading ( Sep-23-2020)
- Difference between science and empiricism
- Why frameworks based on practices and empiricism necessarily become framework prisons
- Getting to Simple (you don’t get to simple by taking things away. There is no guarantee that a simple solution exists as a subset of a complicated one. You get to simple by first understanding your problem and seeing what is required and not going beyond that)
- Major causes of problems:
- Lack of adherence to Flow, Lean, ToC, organizational development (i.e., what works)
- Lack of predictability (due to complexity, poor code quality, tight coupling)
- Lack of resilience (due to tight coupling, poor feedback)
- Lack of visibility. note that while complexity causes problems, it is not the main problem or cause of unpredictability.
- How lack of a model of why Scrum works causes Scrum But
- Value streams. Go to How to Make Toast. At 2 minutes in, see how the process is described as a sequence of nodes and links. This is essentially a value stream. Note how much easier it is to understand what is happening when a value stream exists. Now, imagine the SAFe big picture. It’s a collection of notes, but is missing the links. It’s one reason it’s so hard to understand.
We don’t mean to imply that Agile and Flow/Lean/ToC are opposed or in conflict with each other by the title of this section. But there are differences in them – and learning these differences is useful.
Agile is usually described as a method of delivering value incrementally to customers. This comes from Scrum’s sprint. From the Scrum Guide – “The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created.” Sprints avoid getting locked into the constraint of trying to achieve a fixed scope in a designated amount of time at a specified cost. Most of Agile is based on this since Scrum is the foundation for LeSS, Scrum@Scale, Nexus, SAFe amongst others. While some of these are incorporating Kanban practices into the base Scrum practices of the sprint, Agile is still mostly viewed as creating value in iterations.
There is a subtle problem with this perspective when it comes to convincing management how to interact with Agile teams. Prior to Agile, executives have been under the impression that merely making greater demands on development teams would get the job done when additional requirements demanded it. While this approach is not effective, it often gets deliveries done on or near on time. The problem is that scope and quality are both dropped out. This is often not immediately noticed by the executives since the problems caused by this show up later and the executives just tend to blame the developers when they arise.
Many people expected the adoption of Agile would correct this because they believed that executives would understand that the amount of work that can be accomplished needed to be decided by the team. But I’ve always felt this was wishful thinking because Agile, 20 years in, is still mostly identified around the team, not the business. While most Agile at scale methods throw in references to business Agility, most are still based around the team or team level.
Agile teams based on Scrum plan around two week increments or, in SAFe’s case, about 3 months of work. The focus is on what can be done within a particular amount of time. This still leaves open the viewpoint of “we’d get more done if the development teams would be more efficient.” Hence, old habits of pressuring teams to get more done should still apply (even if they never really did). What’s needed is to change the focus from the development teams building in iterations to a focus on the value being delivered.
Two concepts are needed to facilitate this change:
- The concept of the Minimum Business Increment
- The science of Flow
Flow tells us that we will be more efficient if we reduce delays in our workflow. MBIs provide a focus on what’s the most important thing to deliver.
The concept of the MBI enables us to ask the question: “What’s the most important thing to deliver next?” The science of Flow would provide the rationale as to why you don’t want to overload people working on the next most important MBI. In the context of understanding Flow, adding the next most important thing to a team to do while they are working on the most important thing will clearly just slow things down. The focus is no longer on “how can we get developers to do more” but rather “how can we get developers to build the most important MBI faster?” This is an important shift.
Adoption and Where to Use Scrum
Scrum was designed for a cross-functional team to building new product incrementally. Using it everywhere follows the mantra “when all you have is a hammer, everything looks like a nail.”
Scrum ignores the potential adverse consequences (e.g., resistance) that forced adoption of a new, predetermined way of working will entail.
Scrum provides no guidance on where it should be used other than to solve complex problems and that people should want to improve things. Of course, nothing works when no one wants to improve things. The statement basically says if a team wants to improve then Scrum will work, implying that when it doesn’t work people weren’t committed enough.
“Scrum would work if people would use it” is circular reasoning. When it’s not enough people will have a tougher time using it and they will fail in their endeavors. But it may have more to do with the lack of fit for purpose than their commitment.
Lack of Guidance and Theory
When Scrum is used outside of where its practices were designed for (cross-functional teams and incremental implantation is straightforward) it provides no guidance on how to achieve these.
Provides no guidance on where it should be used and ignores the issue of fit for purpose
Scrum provides no guidance on skills needed. The preposition that people will figure out what’s missing in scrum is invalided by reality.
The statement that Scrum is intentionally simple and incomplete should not imply that this conscious decision was a good one.
The implication by Scrum practitioners that incomplete makes it easier to understand ignores the possibility that there are ways to design approaches that are easy to understand yet provides information as needed. Simple to use does not imply incompleteness. In fact, the opposite is often true.
While it’s true that nothing is complete, that does not argue for extreme incompleteness.
Difficulty of Scrum Due to Lack of Guidance and Theory
Scrum is both easy to understand and easy to master. It’s using Scrum to master Agile that’s difficult.
The belief that Scrum is easy to understand but difficult to master comes from conflating Scrum with Agile. They are two different things. One is a way of being and doing (Agile) and the other is a framework for developing, delivering, and sustaining complex products.
When the immutable aspects of Scrum are not present, Scrum provides no guidance on how to create them.
The lack of choices in Scrum requires you to re-invent the wheel in many places.
The lack of theory often leads to Scrum But (stopping a Scrum practice in a way that keeps the impediment in place) because there is no way to determine is another known practice is appropriate..
Scrum provides no guidance in how to work in situations where cross-functionality or iterative development are difficult to achieve. Nor does it provide any guidance on how to achieve these.
Because Scrum provides no theory as to why it works (e.g., Flow, Lean, ToC) practitioners doing Scrum must keep trying to do it – whether it is the correct course of action.
Scrum requires its roles, events, artifacts and rules to be immutable because there is no theory presented to explain how to change them. The mindset underneath this is just do Scrum as it is and things will work. But this conflates Scrum with the result (Agile) you want to achieve.
The Risk of Scrum Certification
Because Scrum is based on values and practices and provides no theory as to why it works, those certified in Scrum Guide based Scrum feel compelled to follow these values and practices. However, changing people’s values is difficult and the practices may not be applicable. If the Scrum Master only knows Scrum, dogma in the form of an insistence on particular practices is the likely result. In any event, they will likely not be able to derive a more appropriate practice.
Changing Scrum is risky because there is no theory to tell you if the change you make is a good one. It is psychologically hard to make the change as well if you are only trained in Scrum since you have to go outside of the definition of what Scrum is.
The fact that it is risky to customize Scrum speaks to its poor design/mindset. When one is trained only in Scrum it is often difficult to see better ways to achieve the goals that people adopted Scrum for.
The iron triangle discusses the relationship between scope, cost and time.
The assumption is that these three interrelate in an adverse way with each other – that is, increasing one will increase the others. Quality suffers when all are fixed. But this ignores the fact that few value streams are effective. In fact, by focusing on principles of flow and lean we can deliver value in a shorter period of time, thereby reducing cost.
The essence of lean is to decrease waste by eliminating delays in the workflow. This requires preventing the need for:
Removing these delays not only shortens the time required to deliver value directly, but eliminates the work they create (see Why Looking at Delays In the Value Stream is so important). We can increase value without requiring additional work by focusing on those items that will deliver the greatest amount of value in the shortest amount of time. This is the definition of the Minimum Business Increment.
This combination of eliminating delays while focusing on the most important work provides a way to use the constraints of the iron triangle as a guide – not a limitation. We can get more value delivered in a shorter time and with less cost by attending to them.