[In this series of Advisors, we share a conversation among Cutter colleagues of the Agile Product Management & Software Engineering Excellence practice. In this installment, Practice Director Tom Grant shares his thoughts on Agile frameworks.]

To My Cutter Colleagues,

First, thank you for agreeing to start this dialogue. Given the amount of time we’ve spent talking about Agile frameworks, both with our clients and each other, I thought it would be a good idea to open that discussion to public view. Agile frameworks are a tricky subject, combining several elements all at once. (Which inevitably leads me to talk too fast, trying to cover all these topics, which is never a good thing.) Here are just a few of the questions that Agile frameworks raise:

• What is a framework?

• What does an Agile framework do that Agile by itself does not?

• Is “Agile at scale” the most important dimension of this larger discussion about Agile, or is it just the most popular one at the moment?

• How do you expand the scope of the “unwritten constitution” that exists within an Agile team without doing terrible damage to it?

• How do software innovators decide intelligently among frameworks?

• How do they know that the framework they select is working for them?

• Is there a right time, and by implication, a wrong time, for implementing a framework?

That may not be a complete list (feel free to add to it), which further illustrates how complicated any discussion of Agile frameworks has become.

My goal, with this upcoming series of exchanges among us, is to slow down the discussion so that we can disentangle this snarl, and then deal with each topic separately. I don’t have a strict plan for exactly how this discussion should proceed, just the list of important topics to address by the time we’re done. Disagreement is certainly welcome: I don’t expect that we’ll see everything in exactly the same way.

A good place to start is the notion of what a framework is, and by implication, is not. Figure 1 illustrates David Rico’s definition.

Figure 1 — A definition of Agile software frameworks. (Source: David Rico.)

No matter how good the definition may be, it always seems necessary to add more elaboration to avoid misunderstandings. Therefore, I’ll throw in the points I usually make about frameworks:

• A framework is something beyond team-level principles and practices. The framework incorporates Agile into some larger effort in the organization, but Agile itself is not a framework. Frameworks are more in the realm of ALM strategy, a topic on which I have an opinion or two.

• A framework is less prescriptive than a methodology or a discipline. I vastly prefer the term discipline to describe Agile, since other disciplines, such as the martial arts, scientific research, and medicine depend on a combination of principles and practices for their success. Agile depends on that prescriptive combination of principles and practices. Frameworks are a little looser, usually on the practices side.

• Not all frameworks are scaled frameworks. Scaling Agile may be the current hot topic, but scaling is not the chief concern of every framework. Therefore, while we’re certainly going to wind up talking about scaled frameworks like SAFe, we’ll be interested in other frameworks like DAD and Lean, too.

• An important goal of frameworks is to connect Agile to larger organizational goals. You might never have a discussion about scrums of scrums, program managers, or other aspects of scaled Agile, and still wonder whether Agile is helping to increase customer satisfaction, reduce time to delivery, or achieve some other organizational goal. A framework might steer Agile adoption in that direction.

• Frameworks help make decisions about issues adjacent to Agile. Should an Agile team adopt continuous delivery? The answer is not, ipso facto, yes. A lot depends on the situation, both in the team and the larger organization. A framework helps fit Agile together with other approaches to software innovation.

It’s important to be clear about the definition of frameworks, since many organizations think they’re implementing a framework, but they’re actually pursuing a different sort of beast. Therefore, the definitional question is far more than just the sort of semantic or academic distinction we might make over a beer.

One important conclusion from this exercise in defining frameworks is the importance of discretion. Frameworks help people make better decisions among many competing tactical or operational options, such as, "Should we use Git as our source code repository?" and, "Should we think about a Lean UX approach?" While different organizations might plug different components into the framework, the framework itself helps guide those decisions.

Discretion is also important when using a framework. If you expect the framework to absolve you of responsibility for making decisions, you don’t understand what a framework is supposed to do for you. Frameworks depend on people using their critical faculties, for reasons no doubt we will cover in later parts of this discussion.

That’s enough table-setting for now.

I look forward to your responses,

Tom