The Agile Mindset

Agile has been around for over a decade, a lot of people are doing it, and that’s great.

But I see a lot of organizations struggling. Not so much with the tools and practices. But mostly in the mind – the head.

Here are a list of thoughts and attitudes companies need to get if they are going to truly adopt Agile as a means of delivery.

The plan is going to change

Plan the work, work the plan. That’s the mantra traditional project management has been teaching PMs for years. Except that it doesn’t work. Companies that expect software projects to be straight lines. But they look a lot more like this:

and it’s this unwillingness to change the plan that kills them – Agile or not.

Everyones has a plan until they get punched in the face. – Mike Tyson

Software projects are a bit like getting in the ring with Mike Tyson. They punch you in the face. And if you can’t take a hit, or are so tightly boxed in a corner that you have no room to maneuver, you are going to get knocked out.

Adaptive planning enables Agile teams to roll with the punches, take advantage of opportunities when things don’t go their way, and avoid much of the drama and dysfunction traditionally seen on projects that refuse to adapt.

So get used to changing the plan.

You don’t have all the requirements

Accept it. You don’t.

You might think you’ve got them all. You may read books telling you to gather them all before you start. But you can’t. Why? Because like Kent Beck once said:

The act of delivering software, changes the requirements.

Which means no matter how hard you try, you’re not going to have them all before you start. And the ones you do have are going to change. Just accept it and plan accordingly.

There is no change control board

This concept is so foreign to Agile delivery I almost cringe in bringing it up.

On an Agile project the only person who decides whether a feature gets implemented is the customer. They don’t need to seek anyones permission or approval. It’s their money. They can spend however they like.

Agile sides with the customer. If the customer wants a change, they can have it. Agilists believe this leads to better decisions, better products, and puts the responsibility for deciding how to spend the money where it belongs – in the hands of the customer, not the PM.

The cost of change isn’t high

Traditional thinking is that the cost of change on projects is high. That’s why this picture is still printed and promoted in modern project management bodies of knowledge.

This used to be true in software. But not anymore.

With the advent of the personal computer, just-in-time compilers, and phones with more processing power than older mainframes, we can make changes to software at extremely low cost.

We’ve also gotten a lot smarter. We have software engineering practices today that allow us to make changes with confidence at speed. That changes the game.

Instead of fearing and resisting change, you are now free to embrace it. And use it to your customers advantage.

There are no predefined titles or roles

Roles blur on Agile projects.

I know you have narrow, clearly defined, titles, roles, and responsibilities. Agile teams don’t care about any of that. What they do care about is doing a good job and removing anything that gets in the way.

So don’t get discouraged when your developers want to test, your testers what to be involved upfront in the analysis, and your Project Managers what to contribute and program. You are going to have happier people, most engaged teams, if you don’t limit them with a formal title or narrowly defined role.

You are going to fail

There’s a price to pay for all this progressive, initiative, risk taking way of working. You are going to periodically fail. It happens.

You can’t build innovative software or create great products without periodically going over the edge. Good companies will forgive you. The bad ones won’t. The good news is you get to choose which you would rather work for.

They are not requirements

Let’s think about this word. Requirement. It rings of something completely necessary. Something we absolutely must have.

So if we can deliver 80% of the business value from 20% of the requirements, what are the the other 80%? They’re not requirements. We didn’t need them.

Drop the word requirements from your software project vocabulary. It’s the wrong word. Instead use features, and treat them as things your software project may or may not have. Not requirements.

They are estimates

You know what an estimate is right? It’s a guess.

Guess how long it would take you to roll ones with a pair of dice. How long would it take you to find a missing card in a deck of cards.

Guess. Try it out. And then compare your actuals to your estimates. Think you are going to be within 10%. Care to make a wager on that?

The way we size software projects isn’t all that different. We estimate, or guess.

Except instead of treating these estimates as guesses, we treat them as commitments (and that’s where we get into trouble).

Agile estimates aren’t commitments. They are best guesses based on limited knowledge.

We turn them into commitments the only way we know how. By building something, seeing how long that takes, and then extrapolating that for the rest of the project (it’s not rocket science, but it works).

Working software is the definition of success

For a lot of companies getting projects in on time and on budget is the overriding definition of success. And Agile would agree that projects have to work within their means.

But rather put so much attention on the plan (which by itself does nothing) Agile takes that time and energy and puts it back in the one thing that does add value – the software itself.

That may sound obvious, but we deliver a lot of projects that are on time, and on budget, but deliver no value. It’s gotta stop.

Chaos is the norm

In 2004 Doug Decarlo wrote an article I really liked contrasting the different mindsets between the traditional and extreme (Agile) project manager.

Newtonian – Stability is the norm	Quantum – Chaos is the norm
The world is linear and predictable	Uncertainty reigns
It is controllable	Expect surprises
We can minimize change	We should welcome change
Add rigor to the process to increase the feeling of security	Relax controls to increase the feeling of security
Deliver on the planned result	Deliver to the desired result
Use the plan to drive results	Use results to drive the plan
Aim, air, fire	Fire, then redirect the bullet
Keep tight control on the process	Keep the process loose
Manage to the baseline	Manage to what’s possible
Get it right the first time	Get it right the last time

I think this hits it bang on. You either believe everything can be planned, controlled, and thought of ahead of time, or you don’t.

Agilists think Quantum. And their practices, management and expectation setting techniques reflect that.

Three simple truths

Once you accept these three simple truths, leading agile projects becomes a lot easier.

You don’t stress as much about schedules (we know we’re already late!) You stop trying to own problems that are outside your sphere of control. And you just accept that there is always going to be more to do than time and money allow.

You stop taking things personally.

And software is personal. You put a lot of yourself into a software project, and it’s easy to take feedback, criticism, and things like schedule pressure personally.

But accepting these simple truths frees you from all that. It allows you to see that which is clearly, and to not try and change something that can’t be changed.

OK. That’s it for now. I plan on referring back to this article in the future, but I wanted to get some stuff out there on paper, so when when helping companies get better at software delivery, I can direct them here for a conversation starter, and then get to work.

OK – let’s talk.

Advertisement