Project Management

Manifesting Business Agility

This blog concerns itself with organizations moving to business agility—the quick realization of value predictably and sustainably, and with high quality. It includes all aspects of this—from the business stakeholders through ops and support. Topics will be far-reaching but will mostly discuss FLEX, Flow, Lean-Thinking, Lean-Management, Theory of Constraints, Systems Thinking, Test-First and Agile.

About this Blog


Recent Posts

How to manage complexity - don't

Improving Scrum by Attending to Flow, not Merely Using It

The Difference Between Inspect and Adapt and Plan do Study Act (PDSA)

Random thoughts about Scrum Guide Based Scrum

The Iron Triangle Constraints Are Misleading

Why to Focus on Flow of Value and Not Iterations

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.

Project Management

Constraints are misleading

The iron triangle discusses the relationship between scope, cost and time.

The Iron Triangle

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:

  • rework
  • handoffs
  • handbacks

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.

Posted on: September 24, 2020 09:24 PM | Permalink | Comments (1)

A better way to explain Agile than flipping the Iron Triangle

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.

Unfortunately, this puts the focus on the development cycle, not on value delivered. This may be why executives often think if only the development group could be more effective more would get done, leading to pressure & unrealistic demands.

Consider if we explained Agile in terms of delivering value as quickly as possible. Flow tells us to remove delays from start to finish while Lean tells us to work in small batches. The primary cause of delays and waste is having development teams work beyond capacity. Understanding this would encourage executives to avoid doing this. The value of working with small batches leads to using Minimum Business Increments

This approach to explaining agile would accomplish the following:
* Focus on what should be delivered quickest
* How can the development team be most effective

This could help executives understand why demanding more and more from the development team is something to avoid

Posted on: September 23, 2020 12:31 AM | Permalink | Comments (4)

Why Choosing Your Way of Working Is Simpler Than Taking a Preset Solution

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.

Posted on: September 17, 2020 11:02 AM | Permalink | Comments (2)

How you can use the insights of Disciplined Agile to improve your Scrum practices

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)

Posted on: August 30, 2020 08:20 AM | Permalink | Comments (3)

Why You Should Use Disciplined Agile If You Are Motivated to Improve Your Team’s Methods But Are Having Trouble With Scrum


No approach is foolproof. All require the people using them to be motivated & interested in change. At Disciplined Agile we look at failure of adoption quite deeply. The key is to believe the failure was not caused by a lack of motivation of the adopters but by improperly designed guidance. You cannot learn from failure by blaming someone else.

Highy motivated teams fail in their Agile adoption for many reasons but the ones I see most are:
1-Using pre-set practices which don’t suit the people adopting them
2-no theory explaining why these practices are appropriate
3-No method provided to adjust these practices to help the team improve and even transcend them
4-An insistence that not using these practices means you’re not following the adopted approach – this creates a psychological barrier to adopting more suitable practices

Initial motivation is often destroyed by the frustration that comes from a difficult, even inappropriate start, with little guidance on how to improve what one is doing.

DA believes people are smart enough to decide what works for them when they are provided some core insights. We never blame the adopters for lack of motivation.

Let me be clear, I am not "bashing" Scrum. (See Is it “bashing”, “criticism”, or “negative feedback”? ) 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.

Posted on: August 29, 2020 01:25 PM | Permalink | Comments (3)

"Great souls have wills; feeble ones have only wishes."

- Chinese Proverb



Vendor Events

See all Vendor Events