Common Agile Misconceptions

Agile is talked about in every crevice of the tech world — almost every company seems to be trying to work in agile ways in order to deliver code fast, yet many fall short.

The principles of agile were set out in the Agile Manifesto 20 years ago, but have we strayed from the path of what agile is supposed to be?

We got in touch with internationally recognized software architect and agile-transformation consultant Allen Holub, to better understand how we’ve deviated from the original meaning of agile and to highlight some common misconceptions.

Misconception #1
There is a set agile process

Allen: You don’t need to have a process forcing everybody to march in lockstep in order to coordinate and have a coherent system for getting work done. The company, full of adults, will do that just fine without having to without having to be forced.

If you look at a real agile organization, the teams have huge amounts of autonomy. The teams are in charge of their own composition, they get to decide who’s on the team and who’s not on the team — the teams will do their own hiring.

We need freedom to invent processes; we need freedom to be agile; we need freedom to look at what we’re doing and improve it; we need freedom to make product decisions, and we need that fast feedback loop. 

Practices do not transfer, what does transfer is our values. Teams, to be effective in an agile way, have to develop their own processes.

Misconception #2
There are projects in an agile system

Allen: There aren’t any projects in an agile system, there’s just the product. More and more in the agile world the whole notion of a project is considered a bad idea. Instead of working on projects, we’re working on the entire product. If you look at an agile team that’s working in the proper way, you have a bunch of user stories — which are nothing but very short descriptions of what your users do in the real world to get their own work done, because your users need to accomplish something using your product — you grab one of these user stories and you implement it. You organize the story around the product looking at the product as a whole, keeping this thought in mind: what can the users not do now that they need to do in order to make the product a better product?

The focus is entirely on the product as a whole, not on projects. Individual projects are just a little corner of the product where you can’t see the big picture. With that said, and with there being no projects in agile to manage, there is no inherent need for a project manager.

Misconception #3
Agile teams have project managers

Allen: Agile teams don’t have project managers! Because agile teams are self-organizing, there’s nobody to manage them — they manage themselves, they manage their own work. So if you have somebody that has the role of a project manager, team manager or line manager, that’s taking away from the self-organization which is essential to the way that agile teams have to work.

Agile is centered around people — if you’re not treating your people well, you’re not working in an agile way.

Misconception #4
Agile is about the amount of work you do

Allen: Agile is not about the amount of work you put out — producing twice the garbage in half the time buys nobody anything, so the idea that agile should somehow be doing twice as much work in less time is just craziness.

What agile is about is value and writing software and getting it into our users' hands, and the thing that we’re getting into our users hands is something that they find valuable, it’s something that lets them get something done that they couldn’t get done before.

It’s got nothing to do with how fast we do it. Although we want it quickly, it has to do with how valuable it is to the people who are ultimately buying our software.

Misconception #5
Agile is about speed of work output

Allen: Speed is a factor, but not in the way you think. Agile systems work by getting feedback. Feedback is an essential part of working in an agile way. So we build small things and we deploy them, we then get them to our users hands and get feedback from them, then we use that feedback to make what we just built better. Everything is done in small increments. That feedback loop has to be very tight and in fact in a fully agile shop, you’ll be measuring the feedback loop in minutes or hours, not even in days. You want to be pushing things into production once or twice a day.

The feedback loop is really really really fast, or it has to be, so you need to be working in such a way that you can get feedback in a timely fashion and that speed is a factor there, but the speed at which we generate output is not particularly important from the normal management sense. The idea is not to push more junk out to the users, the idea is to get value to the users in small increments.

Misconception #6
Scrum is agile

Allen: Scrum is a lightweight wrapper around agile, and if you don’t know agile, you can’t do scrum. It’s a wrapper around agile that makes it more palatable to people that don’t actually want to be agile. It provides a structured and controlled environment that appeals to companies that are used to structured and controlled environments, but it has nothing to do with agility.

For agile to be agile, it has to be flexible. The people who are doing it have to have the flexibility to work in ways that they think are effective, and if you start making changes to the way you’re working, you’re not doing scrum anymore. The scrum guide says specifically that scrum is defined by the scrum guide, so it’s a very rigid framework.

It’s a strange problem to go into a company and everybody’s doing scrum — every team in the company is doing exactly the same thing. In the worst possible situation, every team in the company starts their sprint on Wednesday, and the sprints last exactly two weeks, and the teams are just marching in lockstep doing exactly the same thing, and there’s some office making sure that everybody is doing scrum by the book, and that that’s the opposite of being agile.

If everyone in the company is doing scrum, that tells me you’re not an agile company.

Look at Spotify — there are several agile processes scattered across the whole organization, and there are some scrum teams, but there are a lot of teams that aren’t doing scrum. There are a lot of teams that are doing variations on scrum — there are 1-day sprints, there are 1-week sprints, there are 2-week sprints and there are no sprints at all. There are also teams that are using different kinds of processes that are more linear, like kanban. The point here is that if you’re self-organizing, that’s what you expect to see. 

To summarize, here’s what agile is… (according to Allen Holub)

People first

If you’re going to be agile, people have to be first, and self-organization is an indication of that — people get to decide how they work.

Trust

At the center of the notion of agility is the notion of trust. You have to be able to trust people to get the job done. You trust people to work in the way that they need to work. You trust people to spend money in ways that make sense. If you don’t trust the teams to do the work, you can’t move fast enough.

Working software is all that matters

High quality, well-written, well-engineered software with a good architecture in it: that’s what working means to me. The rate at which you can produce working software is the only metric that matters. If you are not delivering, you are not agile.

Work collaboratively

Agile organizations cannot work if people are isolated into little silos working alone. Communication is an essential part of this — if you are not communicating with each other, you cannot be flexible enough. Communication is a constant process — you have to communicate with your customers and with the people you’re working with, constantly getting feedback.

Welcome change

You have to welcome change — learn as you work. We want to incorporate that learning into the way we work and into the things we build as soon as we learn it, not months from now, but right now. All plans fail since we’re constantly learning, and that learning changes the plan.

Technical excellence

If your code is not high quality, you simply can’t be agile because it slows you down too much. If you can’t make a small change very quickly, then you just simply can’t work in an agile way.

Assessment

Regular assessment is an essential part of being agile. You have to be flexible about the way you work, you have to be looking at what is working and what’s not working. You always need to be amplifying the good and phasing out the bad. You always need to be moving things in the direction of being more effective.