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

Why if you are a PMP who understands the value of Agile your next workshop should be the Disciplined Agile Value Stream Consultant

My views (past posts) on cause and effect in complex systems

Transcend the thinking that scope, time and cost are in opposition to each other with Lean-Thinking

What I've found a team approach to Agile must include

A shift in my efforts

Why if you are a PMP who understands the value of Agile your next workshop should be the Disciplined Agile Value Stream Consultant

Although I'm no longer in the PMI, I still have great respect for its products and membership. I joined the PMI a couple of years ago for several reasons. One of the biggest was the clear desire of most PMI members to want to learn. I know many PMIers wondering about what their next steps should be. Agile is decidedly more than a fad, so that makes it more attractive. But it also seems to be anti-management and a bit free-wheeling as well - which goes against many of the principles and philosophies we've seen useful.

 In thinking about this, I believe the choice forward for many PMPs and other PMI members is a combination of the Disciplined Agile Value Stream Consultant workshops as well as some of the new work I am doing with Success Engineering. I'll talk about why the Disciplined Agile Value Stream Consultant workshop in this post. In the next few days I'll follow up with my new efforts with Success Engineering. These products won't be available until early next year.

 What makes the DAVSC appealing to PMPs.

While I have been a believer in Agile from before it began, I have always been troubled by a few things. These are mostly its:

  • Team-centricity
  • Anti-management attitude
  • Lack of discipline
  • Missing a scientific model that explains why it works

 I created the DAVSC as a way to teach consultants how to:

  • look at the entire value stream
  • include management in the Agile transformation process
  • provide clarity on essential practices and why they must be done
  • Understand a scientific model that explains why Agile works and what to do when you venture into new ground

 In a nutshell, it teaches participants how to guide transformations in a manner I found was effective for both me and other top consultants.  I created on the basis of what successful consultants needed to know by observing them (and not so success consultants) for almost 2 decades.

The DAVSC is more focused on teaching you how to think to solve you and your clients' problems than how to adopt someone else's solutions.

I'm co-teaching 3 Disciplined Agile Value Stream Consultant workshops over the next 6 weeks in different times zones. You can see them here.

Each session will be followed by a 45 minute session for additional Q&A that will also include why and how the workshop was created. Although you currently need a DASSM certification to be certified in the workshop, you are more than welcome to attend if you believe that the general concept of Agile is a good one.

 Feel free to contact me for more information

 Al Shalloway




Posted on: October 26, 2021 06:03 PM | Permalink | Comments (7)

My views (past posts) on cause and effect in complex systems

Complexity has become a big topic in the Agile space. I don't agree with much of the conversations about it and thought I'd post a collection of the posts I've made on linkedin here.

The main guide I use in navigating complex systems in knowledge work is starting with the idea that all of our systems are complex. People are involved and we're doing things we've never done before. As a systems thinking all parts of the system typically have aspects that are simple, complicated and complex. I believe the biggest danger is from chaotic events which can be mitigated with quick feedback, decoupling of events and visibility.

I then navigate with Dr Goldratt's Inherent Simplicity. I've made a list of aspects of the value stream which is useful to look at.

I present this before my posts because it creates a context for learning.

Here are my other posts. These were written over the last 2-3 years with the most recent ones first.

There is cause and effect if you know what to look for.

In defense of root cause analysis

Unless you believe in magic, there is cause and effect in complex systems

Cause and Effects to Look For and How to Use Them

What Causes our Problems

Attending to Cause and Effect in Complex systems

In Defense of Cause and Effect

Cause and Effect in a VUCA World -making things worse

Let’s not throw out our ability to see cause and effect with the complexity bathwater

Cause and Effect Does Exist in Complex Adaptive Systems

There is cause and effect between actions and results

Posted on: September 06, 2021 02:38 PM | Permalink | Comments (3)

Transcend the thinking that scope, time and cost are in opposition to each other with Lean-Thinking

Many people tend to look at scope, time and cost as 3 factors for completing a project and that all 3 can't be set. This is the trouble with fixed scope, time & cost projects. Waterfall projects often fix all 3 with at one of these factors being missed. That is, scope is dropped, project is late, and/or we have cost overruns.

Agile attempts to have these work more effectively by fixing time & cost with time-boxing. This is the essence of a Scrum sprint. This is an improvement. The most important work can be accomplished & smaller cycles are a major improvement.

But this line of thinking still has the 3 in conflict with each other. Lean suggests that "scope" is more complex than just "what to do." That we need to focus on actual value delivered, not merely what work is being done. Lean-thinking tells us that our work is composed of work of value (some more valuable than others) as well as waste. This waste is due to rework & working on the wrong items. Instead of being locked into the iron triangle (flipped or otherwise) we want to focus on eliminating this waste.

Most waste is due to delays in workflow and in feedback caused by poor workflows and teams being overloaded. Handoffs, handbacks, mis-communications and more are rampant. Lean-thinking tells us that scope, time and cost are not necessarily opposed to each other but that two other factors need to be attended to - product quality and workflow quality.

Attending to these five factors enable more useful work to be done in less time and with less cost. This happens because as product quality increases, rework for building the wrong thing goes down. As workflow quality increases, rework due to delays in feedback go down. It is also useful to note that risk also goes down as these factors work together.

The issue isn’t to see how to best do trade offs. It’s to understand that these five aspects work together and that true value can be realized in less time. This is the heart of business agility – the ability to realize value quickly, sustainably, predictably and with high quality.

This doesn't, of course, mean schedules don't matter. But it facilitates us focusing on delivering the most important value in an efficient method.

Posted on: September 05, 2021 10:52 AM | Permalink | Comments (1)

What I've found a team approach to Agile must include

This is a rough draft, but looking for what I left out.
Having done Agile at the team level for 22 years, I have come to the conclusion that the following are extremely helpful and should be included in any approach. An approach that misses any of these concepts leaves the team with more work on their part to figure out.
1. Provides objectives to be achieved- when practices are provided, they are done within the context of these objectives
2. Provide the why for the objectives and suggested practices
3. Use double loop learning must be done on a
frequent basis to question all objectives and practices. Nothing is sacrosanct.
4. Has a positive attitude towards management. If they are not cooperating ask what they are not seeing and then provide that to them.
5. Design for incompleteness. No system is complete, but approaches should provide guidance on how to fill in the blanks
6. Attend to the factors for simplicity (e.g., value, batch size, efficiency of value stream, visibility, workload, # of interruptions, rate of feedback, quality, value creation structure)
7.Provide guidance for when cross-functional teams don’t exist or are not achievable, and when iterations are not appropriate
8. Provide insights on how to start with a fit for purpose solution
9. Use these insights to also guide improvement on an ongoing basis
10. The approach must be designed so that no useful practice is outside of its scope (this doesn't mean its included, it means doing it won't take you out of the approach)
11. The amount time to get people started should be relatively short. Either a couple of days if delivered as a workshop but also deliverable by an internal coach over time.
12. Provide a navigable list of practices to choose from so people aren’t required to invent their own
13. Provide a way to learn and improve practices on a continual basis.
 14. Include a way of specifying what should be built next and what capabilities are required to build it

When we talk about “simple” we must keep in mind we are more concerned with “simple to use well” than with “simple in design.” Think of a self-driving car.

Note: Disciplined Agile Scrum achieves all of these. For those of you doing Scrum Guide Scrum I'll let you decide how many it provides.

Posted on: September 03, 2021 11:57 AM | Permalink | Comments (2)

A shift in my efforts

I have often mentioned the failings of Scrum. I have been doing this for almost 2 decades when after initial success with it, I found other approaches more useful. My intentions have been to create some clarity on what would be an effective team approach. Scrum is ubiquitous and, in my mind, seriously flawed in design.

I have long felt that if I could be just clear enough, people would see what I see and other methods would become more widespread. However, I have seen that this has turned into more discussion about Scrum, which I'm trying to get past, than about what's possible. My past approach has been impacted by the reality that these reflections illustrate:

- "if all you have is a hammer, everything looks like a nail" - Abraham Maslow
- "it's hard to get a man to understand something when his salary depends upon his not understanding it" - Upton Sinclair
- All truth passes through three stages. First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident." Arthur Schopenhauer

I have been thinking for a while that I needed to focus more on the future. Create an understanding of what effective Agile would look like and stop focusing on fixing the past. I recently saw the quote in the attached picture. It has pushed me over the edge.

While I will still refer to Scrum and SAFe at times, I am going to focus more on what effective Agile would be. I already know what this is. I'm mostly having to see how to explain it concisely. It is based on the objective of business agility. Taking a scientific, engineering and systems thinking approach. It incorporates theories of Flow, Lean, ToC, complexity thinking (a la Goldratt's inherent simplicity) organizational development, individual psychology and uses pattern to organize it. It will provides methods for team, sub-orgs of a company and full enterprises.

And most importantly, It provides simple starts while providing ways to learn and improve and is not overly complex. This is not new. This is the approach I've been working on for almost 2 decades. I'm just going to be more explicit about how DA FLEX in particular and Disciplined Agile in general, follows this model.

Note that I may post some previously published Linkedin articles here which may refer to Scrum more now than my current efforts.


Posted on: September 02, 2021 10:57 AM | Permalink | Comments (1)

If you can't convince them, confuse them.

- Harry Truman