This section of the portal is for supporting the Disciplined Agile Value Stream Consultant Workshop (DAVSC), currently under development. Discussions on the pages here will take place on the Disciplined Agile LinkedIn group.

The strategies of adoption of current popular methods

There are several approaches to undertaking an Agile transformation. While each approach has its own practices and principles, the strategies of adoption tend to fall into one of two camps:

Take a canned solution and apply it. The rationale here is that people need a set, well-defined start. Scrum and SAFe® follow this approach.
Start where you are. Create visibility on the current situation, set forth some key principles (e.g., explicit workflow, kaizen-small improvements, managing work in process).

The challenges with the first approach is that you are somewhat teaching people to follow an approach instead of thinking for themselves. The larger the organization, particularly when SAFe is used, the greater this effect. The result is that the adoption starts well but tends to stagnate.

To avoid this, DA FLEX takes a third approach based on the idea that people could be provided choices for each major decision that needed to be made.

The adoption philosophy of Scrum

Scrum is based on the philosophy that it represents a framework that, if followed, will work well. Scrum suggests that the way to improve a team’s workflow and the organization within which it works is to remove impediments to its core roles (Product Owner, team, ScrumMaster) and practices (cross-functional teams, daily standups, and using time-boxing for work, demos and building backlogs). It takes an inspect and adapt approach that requires little understanding of the underlying laws of software development other than an acknowledgement that reducing the time for feedback is essential and that small batches are better than large ones.

This is reflected in Ken Schwaber’s words, “Scrum is simple, just follow it as is.” This implies that one must start with Scrum as a whole, since a partial implementation will be an impediment in and of itself. The challenge with this is three fold:

There is no universal one-size-fits-all. Scrum proponents seem to ignore that the article on which Scrum is based – The New New Product Development Game – was providing a method to do product development by an individual team. Scrum’s preset roles, events, artifacts, and roles lend themselves to this type of work. However, Scrum is more often than not, applied to IT where the context for work is quite different.
The practices of Scrum are not necessarily the best practices to be being used. Having to follow them often leads to bad Agile. This is why we have the Disciplined Agile Lean Scrum Master workshop. It is based on Scrum being done under the context of Lean, allowing for changing practices depending upon the context teams are in. Another useful method of doing Scrum is to Scrum as an Example of what is possible.
People may not be ready to change as much as Scrum insists. Also, they may like their titles and HR may not have a growth path ready for the new roles Scrum insists you use. While culture may need to change, making abrupt changes to it may not be the best approach.

There are other factors as well. See the LinkedIn post, Going Beyond Scrum to Scrum as Example.

The adoption philosophy of SAFe®

SAFe® is based on the “all-in, all-the way” philosophy. Train managers, train the teams, get going. Have a pre-defined method for everyone to follow and everyone will know what to do. Many times this is the only way to move forward. And in these cases starting with SAFe is perhaps the best option. This would be for very large organizations (1000+ in technology) in our experience. The challenge with this approach, however, even when it works, is that people tend to follow SAFe because that’s how they started. SAFe doesn’t prescribe this, and even recommends against it, but it typically what happens in any event.

SAFe has different levels: Essential, Large Solution, Portfolio, and Full. Each of these build on top of each other. SAFe Essentials starts at the program level and the others build up. This has SAFe provide a somewhat complete solution for each level being worked on.

Another challenge is that SAFe is so big that people tend to focus on its components with the assumption that getting all the pieces working will create an effective system. But this, unfortunately, is not the case (see What if Russ Ackoff had given a TED Talk?).

What Scrum and SAFe have in common

Both Scrum and SAFe have the philosophy that you need to start with a set, prescribed start. That only after you understand things can you change the practices. The biggest difference between Scrum and SAFe in this philosophy is that Scrum is a framework defined by its practices, events, artifacts and roles. Changing them has you no longer doing Scrum. SAFe is a framework defined by the components it has. Plugging and playing new ones is part of the framework.

Unfortunately, when you teach people to start by following, it’s not always easy to shift them into learning. The challenge then, is that at some point, people will run into challenges with these starting points. Sometimes the starting points were not optimal. Sometimes they are, but removing the impediments is difficult. People don’t know when to remove an impediment to a practice or when to use another practice. Neither Scrum nor SAFe provide a mechanism for making this determination. In fact, Scrum discourages this; see the LinkedIn posting, Going Beyond Scrum to Scrum as Example.

The adoption philosophy of the Kanban Method

The Kanban Method was created by David Anderson as an offshoot of the initial Kanban of which he was one of five co-creators. Kanban itself can be used with many different philosophies of learning. But the Kanban Method specifically prescribes starting where you are, creating visibility, making your workflow explicit, managing with a pull approach and managing your work in process. It believes in continuous improvement through small changes (kaizen). It also does not attend to how people are organized but expects people to attend to that if it is of value. The philosophy is one of change management – starting where you are, not causing disruption and continuous improvement.

The power of this philosophy is that it can be used anywhere. The disadvantage is that sometimes the change necessary for improvement requires a bigger view than what a kaizen approach will entail.

Framework Tunnel Vision

Having a “start here no matter where you are now” and the “start where you are, no matter the opportunity for change” creates what I call Framework tunnel vision.

The adoption philosophy of Shu Ha Ri

Shu Ha Ri as a way of learning based on the martial arts of Akido. Shu Ha Ri proposes three phases of learning:

Shu. One of following, without variation, the practices a master sets forth.
Ha. Only after competency in these basic practices can one vary them based on principles learned
Ri. Go beyond the practices entirely and use one’s own judgment.

This is a very popular idea in the Agile community. However, few people describe how to go from Shu to Ha and even use it as an excuse to provide less guidance than what is needed; see Why Shu Ha Ri and Scrum can make for a dangerous combination and Going Beyond Scrum to Scrum as Example.

The Strategies of Adoption of Current Methods