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:
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.
Constraints are misleading
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.
The project management triangle of scope, time & cost is often called the "iron triangle." In classic project management, you fix scope while estimating time & cost. Agile “flips” the iron triangle by using iterations to fix time and cost varying the amount of scoe in the iteration.
This could help executives understand why demanding more and more from the development team is something to avoid
Agile folks like to talk about being simple. But “simple” can be “simple” as in design, or “simple” as in easier to use. When it comes to using a framework or process, not being fit for purpose will be less simple than something that does.
There is a certain attraction to being given a predetermined set of practices, such as Scrum or SAFe and using it as is. But there are no universal practices. This means there’s a good chance that any predetermined set of them you are given will not fit your needs.
We want something “simpler” to use, not something that just “simpler in design” but not fit for purpose.
Disciplined Agile is a process for using a toolkit to create a well-defined set of practices that are tailored for your situation. This includes where you are and how fast your organization can change. DA provides a set of goals, each with decisions to make and options to choose. This lowers the tailoring effort to create a starting set of practices that are fit for purpose and therefore “simpler.” Just as importantly, what’s learned during this “choose your way of working” teaches you how to continuously improve and avoid the stagnation beset by adopting so many other approaches.
This is a follow up to yesterday's post "Why You Should Use Disciplined Agile If You Are Motivated to Improve Your Team’s Methods But Are Having Trouble With Scrum”
Step 1: Go beyond empiricism and add a model explaining why Scrum works. Learn the core concepts of Lean (use small batches, remove waste by removing delays, build quality in) and flow (manage queues, focus on time of value delivered)
Step 2: Understand the objectives of Scrum’s practices in light of this theory
Step 3: Identify the practices you’re having trouble with. For each practice, look to see if the theory above provides insights on how to do it better or if it suggests using another practice. Do not just abandon it. Meet the objectives of the practice by doing what works for your team. Don’t worry whether you’re following the Scrum guide
Step 4: If your team can’t reach agreement on a new practice, try an experiment for a sprint. See what happens and adjust
Step 5: If you can't finish stories in a sprint, go to 1 week sprints. While counter-intuitive this helps because 1) it forces a focus on finishing small stories and 2) you don’t waste time analyzing and planning stories you never get to (those that roll over)
Why You Should Use Disciplined Agile If You Are Motivated to Improve Your Team’s Methods But Are Having Trouble With Scrum
Let me be clear, I am not "bashing" Scrum. (See Is it “bashing”, “criticism”, or “negative feedback”? https://bit.ly/3hLVEJK ) I am wanting to provide an alternative to those experiencing challenges in adopting Scrum whose failures are often attributed to being due to their lack of motivation. I have never liked this and I believe it unjustifably demeans the teams. A day rarely goes by where I don't see some consultant asserting this. If we had a professional consultant creed I believe it should include "I will never blame my client for their failure in adopting my approach." Doing so makes it impossible to improve one's approach. I have seen many teams of motivated people struggle with their adoption of Agile because they have been told that Scrum equals Agile. It does not, it's only one way of adopting Agile. If a Scrum proponent disagrees with my assertions, I invite you to have a discussion with me about these points (this does not include a discussion about me). My motivation is to help people struggling. I started talking about these issues in 2005 while I was still promoting Scrum. I am fine that the Scrum community doesn't want to attend to these concepts, but it shouldn't expect me to be quiet about them.