Agile 2 Is Not a Framework

Agile 2 is not an Agile practice “framework.” It does not define roles or steps to perform. Rather, like the Agile Manifesto, Agile 2 proposes a set of ideas that the Agile 2 team felt were essential for complex human endeavors, particularly at large scale. These ideas don’t tell you what to do: rather, they are guidance on how to approach things, and serve as reminders for things to consider.

Agile 2 is therefore not analogous to frameworks such as Scrum, SAFe, or other collections of practices that claim to be “Agile”. The dilemma with these frameworks is that people who are new to Agile tend to assume—perhaps rightly so—that if one merely uses these practices, then one will be “doing Agile”.

Agile 2 is not analogous to frameworks such as Scrum, SAFe, or other collections of practices

That does not work: merely using practices does not make one Agile (aligned with the Agile Manifesto), let alone agile (nimble, fast reacting). Using a practice without understanding why you are doing it is merely going through the motions. It is like painting by numbers: no one except your mom would buy the result.

Practices are important though. Frameworks such as Disciplined Agile, SAFe, Scrum, Kanban, and others contain useful practices and can be a rich source of ideas for how to organize and perform the work, as long as you are choosing a practice in order to solve a particular problem or need, rather than merely following practices because you think you are supposed to.

Also, practices often cannot simply be performed as stated: they must be adapted to the situation, but to do that, you need to understand the practice and why you are using it. For example, the practice of going to bed early sounds simple, but in practice there are many considerations. If one simply performs the practice rigidly, like Jim Carrey in the movie Yes Man, in which he decides to use the practice of saying “yes” to everything, the result will not be optimal.

Agile 2 has no practices, but many practices from the Agile community and elsewhere are very useful for applying Agile 2 ideas.

One does not need to use any so-called Agile practices in order to apply Agile 2 ideas. However, I encourage you to consider practices from many sources, including Disciplined Agile, SAFe, Kanban, Scrum, and all the rest. Let’s look at a few well known “Agile practices” to see if—and how—they can be informed by Agile 2.

Consider the practices listed below. These all fall into the category of what one might refer to as “long term planning”.

• Envisioning
• Initiative Charter
• Roadmap
• Epic or Theme
• Business Model Canvas
• Lean Portfolio
• Business Dashboard
• Release Train

Of course, what makes something Agile is not what you do, but how you do it. One can perform envisioning in an autocratic and hierarchical manner. Alternatively, one can inquire throughout the organization, soliciting ideas, which then can inform the vision in a thoughtful way. In most organizations (not all) the senior leadership team needs to define a vision, but that does not mean that they should not solicit ideas.

Similarly, a Roadmap is a high level long term plan. A roadmap is agile (and therefore Agile) when that plan is seen as fluid, and is readily adjusted as circumstances change.

The “business model canvas” is a lightweight (usually single-page) description of a project, its value proposition and goals, how success will be measured, and other critical factors. This is a more agile approach than the traditional “business case” document that is traditionally prepared for internal projects. A business model canvas is purposefully lightweight, under the assumption that the idea will be tried, and then if the model’s predictions do not hold, a modified (or entirely new) model will be created and the organization will pivot by trying the new approach, until it finds an approach that works. Thus, an initiative is treated as an experiment, defined by the business model canvas. If the experiment is successful, the model then becomes the core of how value is delivered to customers, and new models are added to add even more value.

That process is only agile if it is done in a collaborative way, and with low resistance to pivoting if the model’s prediction does not pan out. Merely using a business model canvas does not make you Agile (or agile).

Merely using a business model canvas does not make you Agile (or agile).

The remaining practices above are pretty well known to Agile coaches. The same central idea applies: Agile is not what you do, but how you do it.

For shorter term planning, these practices are potentially useful:

• Backlog
• User Story (at a feature level)
• Technical Story

Rather than delve into each of these, I want to focus on the User Story. Notice it says “at a feature level.” That is because too often teams divide work up into “stories” that don’t actually represent a complete feature that someone can use. If you want to measure tangible progress, then measure completed features. That way you will know that if you completed a story, it will have been completed enough to be deployed. It will have been integration tested and everything else. It won’t be “90% complete”, with the truly hard part still lurking and unseen.

That approach is true to the Agile 2 principle that “The only proof of value is a business outcome.” Working code is good, but it does not tell us as much as a working feature.

Conclusion

Practices are very important to consider, as long as you do so thoughtfully. It sometimes makes sense to mandate certain practices, but if you do that, you should allow people to try them and learn how best to apply them. If you define practices rigidly, people will not be able to apply them well to their own situation. A practice is always at best a pattern for how to approach things, rather than a template that can be simply copied.

Agile 2 provides a set of ideas that can help one to form a mental model of the behavioral norms that enable an organization to be agile. Practices should be seen as patterns for things to try, but the underlying mental model should drive the application of any practice. Without that mental model, you are just trying things blind—like Jim Carrey saying “yes” to everything—and you will not have a way to interpret the outcomes. But if you have a basic mental model for how an organization can be agile, then experience applying practices will help you to refine that model. Eventually you will not need any practices to guide you, because you will be able to create your own.