What Is “Basic Agile”?

I often hear that people who are new to Agile need to start with “basic Agile.” But what is that?

The most common training course on “basic Agile” is a course that focuses on Scrum. That is not basic Agile though: Scrum is actually not very Agile (see here , here , here , here , and here ). Indeed, teaching Agile “newbies” what is often taught as “basic Agile” is potentially harmful , because it creates a confused view of agility. So what should a course in “basic Agile” encompass?

Courses in “basic Agile” usually teach the wrong things

You might say that it should focus on the Agile Manifesto. But the problem with that approach is that Agile has grown to be much more than the Manifesto; and also, a strong argument can be made that Agile has changed , and that the Manifesto no longer defines the movement. This is because if you read recent books that are lauded by the Agile community, they often say very different things than what early books about Agile said, and even from what the Agile Manifesto says.

So what is “basic Agile” today? I would actually phrase it differently: With regard to organizational behavior that leads to business agility, what are the basics?—the basics in terms of theory and practice?

The Basics

As one of the authors of Agile 2 , I personally would start with a summary of the Agile 2 principles . But I would not stop there, because those are just principles, and one also needs techniques to consider and examples. Imagine a book about Geometry that only had theorems and did not have any instruction on performing calculations or examples. The theorems are important: without them, you don’t have a theoretical framework for interpreting anything, but they are not sufficient.

When one is learning something new, they need some reference points that are easy to learn and easy to remember. I propose that examples and stories can provide such reference points.

For behaviors that lead to agility, the Agile 2 team concluded that the key behavior is leadership style. As Agile 2 says, “The most impactful success factor is the leadership paradigm that the organization exhibits and incentivizes.”

The Agile community has long been talking about the need for “servant leadership” within a development team. Servant leadership is indeed a compelling pattern, but it is not applicable to all situations, and it is entirely inward focused. For a team to be effective, it needs many kinds of leadership. As Peter Drucker said, you need “an inside person, an outside person, and someone to get things done.”

Note that when I say “leadership” I am not talking about a job role. I am talking about de facto leadership, regardless of how it arrives. It can emerge on its own, it can be nurtured and grown, or it can be moved into position. How leadership arrives where it is needed is an entirely separate issue. Here I am talking about the kinds of leadership that tend to be needed, regardless of how each of the needed forms of leadership manifests: as a proactive individual in a team, as someone who has been selected from among the team, or as a non-team member who is assigned to provide some form of leadership to the team.

When I say “leadership” I am not talking about a job role

Also, leadership does not necessarily mean one individual: it merely means that there is a person or persons who are moving things forward. If a group of individuals are able to collectively make decisions, then their leadership is collective.

In product development settings, there is usually a need for leadership in several domains:

• Technology—the underlying technologies on which the product depends in order to work.
• Delivery—how the product is made and maintained.
• Business model—how the product delivers what the organization recognizes as “value”.
• Product discovery—determining what users actually need.
• Employee development—helping people to develop to their potential.
• Others…

The relative importance of each of these varies with the organization and its products’ users.

These are domains—recurring dominant categories of issues—for which leadership is needed. For example, consider a company that makes and sells toasters. Today a toaster relies on technology: modern toasters have computerized features. There needs to be leadership with regard to the application of technology in creating the technical design for the toaster—otherwise, the technical design will be an ad hoc mess. That leadership can emerge from effective collaboration within a self organizing engineering team, or it can come from an experienced engineer who oversees the technical designs being created by the engineering team. However leadership comes to be present, it must be present.

If you don’t think that leadership is present within a self organizing team, think again. Leadership almost always emerges. Consider a group of people discussing an issue. Some members of the group do most of the talking, and the rest follow along. That is typical and normal. Leaders emerge. There is always a leader. In fact, sometimes more than one leader emerges, and that can be a recipe for conflict.

There is always a leader. In fact, sometimes more than one leader emerges, and that can be a recipe for conflict.

What about delivery of the toaster? Today most toasters are made by large manufacturing companies that make thousands of different products. A low manufacturing cost is essential because toasters are somewhat of a commodity. For that reason, the engineering team will have several manufacturing engineers. Their goal is to find the optimal balance between design excellence and low manufacturing cost.

Thus, there are competing goals, which leads to debate and disagreement. Leadership is needed to move such discussions along in an effective manner, achieving resolution in a timely way. A for-profit company cannot afford to have issues languish: decisions need to be made promptly, and decisions need to be good. For that reason, agility must support high quality and timely decision-making. If it does not, then one merely has an agile path to ultimate permanent failure.

Leadership Is Not Confined to Management

Managers are important: managers are leaders who have business accountability, for resources, people, or for outcomes. But notice that none of the forms of leadership in the toaster example are examples of management: the leadership is not over people—rather, it is over categories of issues. That is a common situation in business today. There needs to be leadership for every category of the many issues that arise, and these issues often cut across hierarchies in the organization. There definitely needs to be accountable leadership—managers—for the product and for the people and money spent. But there also needs to be leadership over the many issues that arise over time. And remember that leadership does not mean a boss: by “leadership,” I am talking about people who move things forward.

The categories of issues that arise are domains of leadership, but I have said nothing about how the leadership operates—the leadership “style”. Some leaders have a very autocratic style. I once had a boss who had been out for six weeks for personal reasons, and I held things together while he was away. When he returned, he popped his head in my office, issued a set of commands, and disappeared—never even asking me what had been happening while he was away. He was the worst manager or leader I have ever experienced.

At the other extreme, I had a team lead who used to talk to every team member every day, make suggestions, and help people to think through complex issues. He made decisions, but only after getting opinions from us. He also tended to make good decisions. And because of these things, we trusted him. He was the best leader I have ever had: his leadership style was inquisitive, and to use some terms from leadership theory, his style was also authentic, empowering, supportive, participative, achievement-oriented, and directive when it needed to be.

My point is that leadership domain and leadership style are two independent variables with regard to the kind of leader one needs.

Your organization cannot have agility unless you have the right kinds of leaders. Therefore, any theory of organizational agility must begin with a study of leadership types. I would consider that to be the starting point for studying “Agile”—that is, for studying the behaviors that lead to organizational agility.

Leadership domain and leadership style are two independent variables

Besides good leadership, there are patterns that lead to agility. These include Lean and other ideas such as continuous improvement, feedback loops, small teams, incremental delivery, rolling wave planning, and flow.

I also think that individual empowerment and agency is important: letting individuals discover how they, as individuals, work best, and not imposing a work style or location on anyone, unless the nature of the job makes it necessary.

For example, while a bus driver has to be in the bus to drive it, an editor does not need to be in an office with other editors to work, since today we have lots of tools for collaborating remotely.

There are gray areas, such as product design, in which face-to-face brainstorming is an essential part of the job, and in those cases the team should have a say in deciding how much everyone needs to be present; but my point is to default to giving people agency, and add prescriptive behaviors as they are needed, instead of starting with a prescriptive default and loosening it when people complain, or when there is a pandemic that reveals that the former prescriptive rules were actually unnecessary.

So “basic Agile” should not start with Scrum, or with any framework. We’ve been doing it all wrong—misled by proponents of specific frameworks. “Basic Agile” should be phrased as “basic agility,” and it should start with an overview of leadership types, and be followed with various behavioral patterns that tend to lead toward agility.

But What Are Our Processes?

Those who have relied on frameworks might feel uncomfortable about this: a framework provides a feeling of safety in that if you merely go through the motions of the framework, you can feel that you have done your job. But going through the motions does not yield results. Frameworks can be a great source of ideas—I personally like a lot of the ideas in Disciplined Agile. But agility is not achieved by merely adopting certain practices—by merely going through the motions.

That is because agility requires one to be lean and mean and do just enough and no more—Agilists call that “maximizing the amount of work not done” while still meeting quality requirements. But how do you know what is just enough? It depends, and decisions need to be made day-by-day. But if people are just going through the motions, they do not have the judgment needed to know when they need to take additional steps. Instead of the old approach of doing every single step, an agile organization is able to take shortcuts, but intelligently. But that requires a high level of judgment. You won’t ingrain that judgment by going through the motions of a framework.

You won’t ingrain judgment by going through the motions of a framework

Let’s take a tangible example. Suppose a team discovers that it needs to make changes to a core microservice that is used by many different products. In the traditional non-Agile approach, that situation would be handled by escalating the issue to an enterprise architecture team, which would have a quarterly review of all the requirements of the various products. But today we cannot wait for that: the issue needs to be resolved right away. Someone needs to bring all the potentially affected stakeholders together and decide what to do. In fact, someone needs to orchestrate an intelligent exchange about the matter, including many emails and perhaps involving a whitepaper or two, as well as at least one decision-making meeting. A decision will be needed in days—not weeks or months. None of the top-down processes can operate that fast, so it needs to be set up ad hoc. Doing that well yields agility; but it needs to be done intelligently, and with an understanding of how to determine who might be affected, how quality processes might be impacted, and so on. If you are accustomed to just going through the motions, you will not know what to do; and if you are reliant on a framework for all your answers, the answer will not be there.

It comes down to having the right kinds of leadership. If you have the right kinds of leaders in place, they will bring the affected people into the discussions that are needed, and issues will get resolved quickly and resolved well. People will figure things out. It will seem chaotic from the outside, but it is actually like a set of experienced athletes working together.

And just like world class athletes, they have experience with a range of techniques, but would you expect a world class football team to operate according to a “framework”?

This brings me back to the question, What should our processes be? Instead of looking to a framework to tell you, stand back and ask yourself what you think it should be. Use ideas from frameworks: frameworks are a great source of ideas. But then define your own approach. And use Agile basics as a source of ideas to challenge yourself about your processes: How are we making sure that people with the right leadership traits exist and are recognized in our organization, and that they are the ones who end up empowered? How are we making sure that people know agility patterns such as Lean ideas, feedback loops, and incremental delivery? And given that we cannot change things overnight, how are we measuring where we are, including our leadership culture and our behaviors, and nudging things in a positive direction?

Frameworks are a great source of ideas

That is what transformation is about, and indeed it starts with the basics, but they need to be the right basics, and those basics need to be learned at every level of the organization.

Use Stories

Earlier I mentioned that when learning something new, people need reference points that are easy to learn and easy to remember, and I suggested that stories are a good type of reference point. Stories of good leadership are particularly memorable, because they are about people, and situations. Instead of teaching people rigid processes, like Scrum, which don’t help anyone to learn what agility is actually all about, stories of effective leadership, interpreted in the context of theories about positive forms of leadership, are perhaps the best approach for introducing someone to agility, supplemented with situational stories that illustrate patterns for agility.

Stories encourage conversation and sharing. They are a better way to learn about agility than memorizing someone else’s process framework.