Manifesting Business Agility

#1: Start with values and practices. Use empiricism to improve. Have a core set of practices (time-boxing, cross functional teams, …) be immutable.

#2: Learn the theory underneath Scrum and why it works. Work with the team on choosing what works best for them.

Scrum Guide Scrum takes the first approach. It's definitely easier to start and if the required practices are present it creates a good framework for product development. But, as they warn you, it is "difficult to master." This is especially true if it you have difficulty following its core practices or if teams have to work together to create features since Scrum provides little guidance here.

The second approach is the essence of Disciplined Agile Scrum. While it may be harder for a DA Scrum Master to get his/her certification, it's easier on your team because they start with something that’s fit for purpose for the team. Just as importantly, if the team has to work with other teams to build a feature, this knowledge provides keen insights on how to do that. Without this understanding it is common to see teams struggle when they have to coordinate with other teams.

Some things are inherently difficult, no doubt. And some take years to master. But an attitude that the work you’re doing is difficult to master is a two edged sword. On one hand, it can teach the virtue of patience as in learning chess. But one can enjoy chess before mastery.

Learning how to improve one’s way of working, however, is an altogether different thing. We do not want to take a long time for this. In any event we should be interested in improving our work, not mastering an approach.

A carpenter wants to master creating great furniture, not his set of tools. An effective carpenter will take an approach that provides continuous improvement. His focus is on his work and his tools are selected to improve that. 

The problem with “difficult to master” applied to knowledge work is twofold. First, we shouldn’t even be focused on the approach but on our work. But more insidious is that it makes settling into a challenged state somehow acceptable. Teams often settle for where they are because it’s difficult to improve. It also lowers the bar for those espousing “difficult to master” to not improve their offerings because “hey, it’s complex and therefore difficult to master.” I don't buy this.

That Depends Upon What You Mean by Agile

Many people in the Agile community consider a 19year old document to be the definition of Agile. While it can still serve as inspiration, I believe something that happened at the midpoint of the PC era to be defining something that is supposed to adapt and change over time to be somewhat oxy-moronic. I am referring, of course to the Manifesto for Agile Software Development (MASD). There are several reasons that I do not believe this is an efficacious approach:

1. The MASD is team and software focused. Agile has expanded well beyond the team and software.
2. The MASD ignored management completely and says nothing on how to do product management when beyond a team
3. The MASD ignored systems thinking and Theory of Constraints
4. Much has been learned over the last 19 years that is not reflected in the MASD

This does not mean Agile is dead. It just means we should use another meaning for Agile. I believe the best vision of Agile is Steve Denning’s Three laws:

1. Law of the small team
2. Law of the customer
3. Law of the network

This essentially means to have small teams working towards the benefit of the customer in a network of semi-autonomous manner.

The Danger of Agile Frameworks

No one size fits all. You may not be able to adopt certain Agile frameworks because they have preset practices that may not fit your context. Also, while many espouse grand sounding values, your company may not manifest these. These frameworks often require these values in order to work. Yet these frameworks tend to assume you have them and don’t provide a path for achieving them.

Preset approaches often lead to a lack of “fit for purpose”

Without a theory explaining why and how to improve delivery of value, one can only attend to practices. This is a slow process. 

"Theory without practices is useless. Practice without theory is expensive” paraphrase of E. Deming

Creating a way to make choices does not need to create complexity in the approach. Those who say otherwise just haven’t figured out a way to do it. Learning how to do this also prepares you to continuously improve.

Since our goal is to shorten the time from request to realization of value, we should attend to the entire value stream.

There is another, more insidious problems with framework. This is that frameworks have us attend to the practices of the framework instead of what these practices are trying to achieve. For example, Scrum is mostly based on cross-functional teams and time-boxing.

This is good and results in:

• Fewer handoffs, handbacks and delays in workflow
• Smaller work items
• Frequent finished work product
• Avoiding workload beyond capacity

These are core principles of flow. This is good because these all help eliminate the creation of waste.

Attending to achieving these results directly is more effective than trying to follow Scrum’s practices because doing so keeps your eye on the target, creates awareness for alternative practices and avoids the risk that the framework's practices are not fit for purpose

Agile as a Thought Process and Not a Framework

There have been many positive lessons of Agile. Many of these were about specific practices some of which work only in particular situations. But along with practices, an understanding of principles that can be applied anywhere has also come forward. These include the following:

• Working on smaller items is often all it takes to bring a situation into control
• Creating visibility of workflows can improve the collaboration between people in the workflow
• Although you may not be able to build iteratively, there are always ways to reduce handoffs, handbacks and delays in the workflow
• Avoiding overloading people in development decreases waste

Each of these insights can be implemented in ways particular to an organization wanting to improve. What’s needed is a way to do Agile without a framework.

Adopting Agile Without a Framework

Disciplined Agile is an approach to adopting Agile without using a framework. The key to this is named in Dan North’s acronym SWARM: Scaling Without A Religious Methodology. In other words, nothing can be sacrosanct – we only do what works in a particular situation. At first this may sound like you have to reinvent everything. But fortunately that’s not true.

There are patterns of successful knowledge work. These patterns help us see when a situation is present and what we can do when it is. The key is to observe the flow of work from start to finish. This is called the value stream. By seeing how the work is being done, who is doing it and how they are organized, a skilled observer can identify a variety of options that can enable the work to be done with fewer delays, lower cost and higher quality. A skilled consultant can create a tailored approach to an organization that provide proven practices that fit the situation present.

While the consultant’s job may be difficult, it creates an approach that is “fit for purpose” and hence easier and more effective to use than a pre-determined one. A consultant will consider the culture and present methods in play while working with those who are going to adopt the new practices. This avoids trying to do too much while also avoiding doing too little which often results in advancements petering out.

If You're Concerned If You're Ready for Agile, Start With a Non-Framework Approach

While Scrum, SAFe and LeSS are very popular, they are also frameworks with preset approaches. Agile based on frameworks requires you to do many things which your organization may resist doing. There are several approaches available that can help you. Check out the Principled Agility group for some of them.

#1. Understand the value stream is the workflow, not the people in the workflow, from concept to consumption of value.
#2. Attend to the entire value stream. If you don't get cooperation of portfolio or product management, make the cost of this visible.
#3. Use Minimum Business Increments (MBIs) when enhancing existing products. Use MVPs for what they were intended for - discovering if you have new products. Don't confuse the two.
#4. Create semi-autonomous teams that have all the skills required to create the MBIs.
#5. Do your PI planning by focusing on removing delays in workflow in the completion of MBIs. This lowers waste while lowering cost of delay. 
#6 Use dependencies identified in PI planning to Improve your organization's value creation structure 

Google unknown terms :)

Many people in the Agile community consider a 19year old document to be the definition of Agile. While it can still serve as inspiration, I believe something that happened at the midpoint of the PC era to be defining something that is supposed to adapt and change over time to be somewhat oxy-moronic. I am referring, of course to the Manifesto for Agile Software Development (MASD). There are several reasons that I do not believe this is an efficacious approach:

1. The MASD is team and software focused. Agile has expanded well beyond the team and software.
2. The MASD ignored management completely and says nothing on how to do product management when beyond a team
3. The MASD ignored systems thinking and Theory of Constraints
4. Much has been learned over the last 19 years that is not reflected in the MASD

This does not mean Agile is dead. It just means we should use another meaning for Agile. I believe the best vision of Agile is Steve Denning’s Three laws:

1. Law of the small team
2. Law of the customer
3. Law of the network

This essentially means to have small teams working towards the benefit of the customer in a network of semi-autonomous manner.