Manifesting Business Agility

Most approaches to adopting Agile at scale involve frameworks. Proponents claim frameworks are flexible, but ignore one of their salient aspects – they have a core set of features that is often difficult to go beyond. Two of the reasons for this are:

1. Frameworks put limits on what is acceptable to add (e.g., Scrum, and its derivatives, require iterative development and cross-functional teams)
2. The well-defined scope of the framework puts a psychological barrier on going beyond it. People certified in a particular approach often feel they lose credibility if they go outside of what they’ve been certified in, even if it's a better to do. A toolkit takes a different approach.

Instead of taking the pre-set starting point most frameworks require, toolkits look at effective practices from all over. In particular, Disciplined Agile teaches people why and how to choose their own way of working by doing some up front assessment and analysis. Arriving at a set of practices which are fit for purpose makes it simpler to adopt. People are also, now better prepared to consider their next steps since they’ve done the process of selecting practices already.

If you want to learn more, watch this webinar I'm doing tomorrow at 9am pacific.

https://www.linkedin.com/feed/update/urn:li:activity:6635670882796781568/

I wrote this blog for those considering what approach they should take to improve their organization’s ability to create value for themselves and their customers. I believe that any approach to improvement has three main objectives:

1. It provides a better than random starting point
2. It helps create a learning approach that facilitates continued improvement
3. It enables making a series of small, validatable, actions that result in continuous improvement

By “better than random” approach, I mean something contextualized for your organization. Since there is no one size fits all, taking an approach with only one size is geared toward the average organization at best, certainly not yours. Your approach needs to both provide a way of assessing what you need and then enabling you to choose your way of working.

Most people learn best when they have frequent experiences that they recognize are opportunities for improvement. Lean’s learning method of explicit workflow and visibility facilitates this.

Finally, the heart of true change is Kaizen which literally means “good change” and is inferred to mean a series of small changes that result in improvement. Steps 2 and 3 work together by providing people with frequent, recognizable opportunities to make continuous improvement.

As a side note I do not mean to imply against doing Kaikaku (radical) or Kakushin (innovative) change.  But most methods tend to ignore Kaizen, which is equally, or even more, important. 

This is, of course, a trick title. There is no "best" framework. Consider some organizations that Stephen Denning's Age of Agile mentions as making a successful adoption of Agile: Barclays, Cerner, Menlo Innovations, Riot Games, Salesforce, and Spotify.

Two things they have in common stand out:

1. They figured out what worked for them
2. They implemented:

• a. focus on the customer
• b. how to have self-organizing teams
• c. how to have these teams work together in a network

Not adopting a pre-existing framework does not mean that they created their way of working from scratch. Most brought in training to learn how teams can work effectively. The real issue, of course, is changing mindsets and how teams can best work with other teams. Both of these are very specific to the organization involved.

The issues that have to be dealt with - product management, planning, DevOps, etc, - are fairly well known with a slew of solutions for different circumstances. Teams can often create something that works for them by merely picking up existing practices and tying them together.

This is the essence of Disciplined Agile's approach to people choosing their own way of working.

Originally published 1/1/2011. I have some additional information at the end to bring it up to date.

Throughout the Agile movement, one acronym that has been used in a derogatory way has been BDUF (Big Design Up Front). The problem with BDUF is that we are laying out our entire plan when we know the least about our actual product. Agile is about doing a little, learning, doing some more, learning some more. It is about being incremental and iterative in our discovery, creation and learning.

The irony of Agile's (currently) most popular method, Scrum, using something comparable to BDUF hit me this morning in responding to a discussion on a user group regarding Scrum roles. The challenge was that the roles of ScrumMaster and Product Owner are pre-defined for Scrum teams. For those that don't have either true teams or these roles, one has to make a Big Change Up Front (BCUF) to start Scrum.

This is not necessarily bad. It presents both opportunities and challenges. But the risk of using pre-determined roles is somewhat overlooked - and it is dangerous to do so. For some, BCUF is wonderful. Creating a team alone solves many of the problems being faced. But for others, this change can be traumatic and can have dire consequences. Which way it goes depends considerably on who is requesting the change and the maturity of the people involved.

I find it odd that we denigrate BDUF while not even questioning whether BCUF is good. David Anderson created Kanban to avoid BCUF. Odd that Kanban has often been attacked as not good because it's "evolutionary" instead of "revolutionary." I have long contended that an "evolutionary" approach to change is "revolutionary." 

The Lean/Kanban alternative is to first understand your current process and to gradually change it. You do this by creating visibility into it using a Kanban board which represents the value stream. You discuss your policies to make them explicit. You manage your work in progress to do step by step improvements to your work flow.

I am not suggesting that BCUF is always bad. There are times I've used it when there is a well identified problem with a clear solution and almost universal buy-in. However, not looking at whether a BCUF approach should be taken is dangerous. It's one of my complaints about consultants who have only one tool in their arsenal and why at Net Objectives we have several (Lean, Kanban, Scrumban, Scrum, hybrids even).

BCUF can be expanded beyond the team. It is common practice when adopting Agile methods to do a pilot project. But this is also a kind of BCUF. We assume that the change here (at the pilot) is the correct thing to do without understanding the nature of our true challenge. See How Successful Pilots Often Actually Hurt an Organization (blog and 4 minute video).

To me, the question is never if something is bad, but rather when is something bad. This creates more learning. So, next time you start an Agile transition at the team or organizational level, ask yourself, is BCUF appropriate here?

Bringing this blog up to date. 

A few years after this blog was written, the Disciplined Agile approach came into existence. It suggests that we need to look at the current situations companies are in. This includes their culture and what the best approach for the organization at hand​ is. This means not only to choose your way of working but to choose the way of implementing change. 

One could also argue that always doing small change up front is also a problem. Sometimes started starting with a big change is what it takes to ensure the change will stick. Again, one has to have both a flexible approach and not insist on predetermined methods just because it's easier to train consultants to do this. 

First, let me start out with what I mean by “simple.” I view “simple” as being “fit for purpose.” Think about it this way, maybe something has fewer parts, or fewer concepts than something else, but if it isn’t “fit for purpose” then you have to add concepts or actions to make it work. Processes and models and everything else do not live on their own – they always exist in a context. Being “simple” without attending to the context something is in is a meaningless statement.

So how does Lean and Flow Thinking make things more “fit for purpose?” Making things fit for purpose requires making decisions to either change where you are or to change an approach you’re about to undertake. But how can you do this, how can you determine if something is better than something else in the context you are in? Given we’re in complex systems you can’t ever be sure your prediction of a new action will be correct, but you can be guided several Lean and Flow measures. And you can validate whether you achieved an improvement or not. Lean and Flow helps here by providing metrics such as cycle and lead time in addition to guidance such as focusing on quality and reducing delays in workflow and achieving feedback.

While virtually all approaches have accepted that Lean and Flow thinking is useful, most still define themselves around a framework that has a core of immutable roles, events, artifacts and rules. These core concepts can’t be adjusted without going outside of the framework. Although they use Lean and Flow principles, people can only use these to make adjustments that fit into the core framework. Since there are no universal practices, this means that adopting such frameworks means there will be a lack of fit for purpose in many situations.

Nevertheless, many practitioners argue for the universality of their core. For example, it is common in the Scrum community to insist that cross-functional teams can be used everywhere when we should be asking "when are cross-functional teams fit for purpose and when are other structures better?" Scrum’s mantra of being “simple to understand but difficult to master” may be more of an indication that its simplicity is in its definition and not its fit for purpose. This is not necessarily a good thing. This is just an example, I'm not picking on Scrum.  You can substitute any method and any of its required practices here.

This is one of the reasons that, although some people have claimed Disciplined Agile is more complicated than other approaches because it provides options, it is actually simpler from the overall view of what it takes to implement.  Scrum’s mantra of being “simple to understand but difficult to master” may be more of an indication that its simplicity is in its definition and not its fit for purpose. This is not necessarily a good thing.

The bottom line is providing choice when it makes things fit for purpose simplifies things. Forcing people to work a particular way complicates things.