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.


Self-Inflicted Scope Creep


Self-inflicted scope creep happens when a team increases the scope of their project without their customers actually asking for anything new. It’s painful to watch because it can mess up your plan, create fear and anxiety, and undermine the trust you’ve worked hard to gain with your client.

In this article I’ll show what self-inflicted scope creep looks like, and what you can do to stop it from happening on your project.

The Incomplete Story

When a team takes a story to work on during an iteration, the intent is that they’ll finish it. That’s why we like our stories to be small (something that can be done in a couple of days).

Sometimes, however, a story is bigger or more complex than we think. And despite our best efforts, we aren’t able to finish it during an iteration.

Not finishing a story once in a while isn’t a big deal. It happens. Where things can go awry is how we handle it.

One team I coached (that was of course under a lot of pressure) got into the habit of taking unfinished stories and splitting them into new stories at the end of an iteration.

They would break the old story (5 points) and break it into two parts. One part they would claim as done (say 3 points). The other part they would say was not done (say 4 points).

So now they have two stories (7 points) instead of one (5 points).

On its own, this isn’t that big a deal. What’s 2 points?

But if you keep doing this long enough something strange starts to happen. The team noticed that their burn down chart started to look something like this:

This is what I call self-inflicted scope creep. It’s not real scope creep, as there is no new work. But it’s malicious because it creates confusion in planning and leads to uncomfortable conversations with your client.

Agile planning works when stories are sized relative to one another. The fact that as humans we are pretty good at sizing things relative to each other is powerful. So long as we size things relatively and track how fast we are going, we’re in good shape.

But if we keep taking stories and slowly increasing their individual sizes over time it messes things up. When our stories stop being sized relative to one another we lose the ability to predict when we are going to be done.

Let’s now take a look at how we should handle unfinished stories, and how to treat new ones we discover along the way.

Don’t Count It Till It’s Done

New stories are easy. If you discover a new story, simply write it down and move on. Esimate it and prioritize it like the others but don’t sweat it. We knew we’d discover new stories along the way so it’s no big deal.

Unfinished stories, however, are different.

The first rule of thumb is to simply carry the unfinished story over. Agile is pretty binary about stories being done—either it’s done or it’s not. There is no 90% done.

So it’s usually simplest to just leave the estimate the same and carry it over to the next iteration (and for every story that’s a few points over there are always a few under so it all comes out in the wash).

If your story is a lot bigger than you originally thought, just re-size it relative to the others.

If your story truly is epic, you can also split it. But this should be the exception rather than the rule. We are trying to get working software out the door after all, and if you find yourself continuously splitting stories, they may be a little bit big to begin with.

But usually the best thing you can do is simply carry it over. It keeps things simple, accurately reflects how long things are taking, and it’s telling you something. If it’s taking this long to do this story it’s probably going to take that long to do others similarly sized—which is what we want.

The Flip Side

Now not all scope creep is bad. In fact it can be very good—nowhere more so than if you are in a startup.

Sometimes you build the wrong thing. It’s not what your customer wants and to continue down the original path you set out is crazy. The startup community recently started calling this a “pivot,” and it happens all the time. (Did you know Flickr started out as an online game? People didn’t really like the game but they discovered that their players sure liked sharing photos.)

This doesn’t happen as much with corporate project work but it still happens. Your customers are going to change their minds, and you are going to have ideas for how they could improve their product. It’s your duty to share that with them (new scope be damned) and quite frankly most enterprises could use a dose of startup, so do share your new ideas.

So as my friend Andy Hunt says, context matters, and yes some self-inflicted scope creep can be good. But the kind I am focusing on here is related to messing up your planning and estimates, and a simple reminder for how to handled unfinished stories at the end of an iteration (don’t count them).

Keep It Simple

Agile planning isn’t rocket science. At the end of the day how you manage expectations on your project is totally up to you. Everyone has their own style, and it’s more art than science. So if you feel compelled to create a new story to manage expectations in a certain way, it’s not a big deal.

The point of this article was just to make you aware of a trap that new teams (and old) sometimes fall into.

If you are new to agile, my advice is to start simple and do it by the book—simply carry unfinished stories over to the next iteration and call them done when they’re done.

If you’ve been doing agile for a while, have built some rapport with your customer, and have earned their trust, you’ll have a lot more leeway in how you track and report progress. Eventually, you won’t need estimates at all and they will just trust you to get the work done.

Speaking at Agile 2011

Leave a comment

agile 2011

I’ll be giving two talks this year at Agile 2011 in Salt Lake City Aug 8-12.

Agile In a Nutshell
The surprising science behind agile leadership

Agile in a nutshell is an intro for people who have heard the hype and are looking for a clear simple explanation of what agile is and how it works. Perfect for those looking to make the transition from traditional waterfall.

The surprising science behind agile leadership explains how self directed teams work, the science behind why so many choose to work this way, and the impact it’s going to have on you and your organization.

And if you are going, I would love meet. Here are a few sessions I plan on attending:

Coaching Success: Getting People to Take Responsibility & Demonstrate Ownership: Christopher Avery, Ashley Johnson

What do CIO’s *really* think of agile?: Edward Yourdon

Critical Success Factors for Acceptance Test Driven Dev’t: Jennitta Andrea

Design Thinking: Mary Poppendieck

How to design stuff that matters fast: Eewei Chen

Hope to see you there!

The rise of the generalist


People love labels. As soon as you meet someone they instantly want to classify you. Web designer? Gen-Y? Level 50 Shaman? Shffft – you’re labeled.

Same thing happens on software projects. Whenever we form teams we naturally want to know the role each of us is going to play: Developer? Analyst? Tester? PM? Bam – you’re labeled.

Labels are fine, but they can stop you from thinking. ‘It’s not my job’ to worry about how the application works, or that there’s a bug with the print screen. QA or someone else on the team will pick that up.

When you think you are defined by a role or a title you are.

But we all know the most valuable members on our teams are usually those who can where multiple hats.

It’s the developer who has a passion for testing.
The tester who can code.
The analyst who thinks about design.
And the designer who has a passion for the business.

As agile gets more mainstream, I think we are going to see more and more of this style of work.

The rise of the generalist.

Where no single team member is limited by a role or title. Multiple people simultaneously where multiple hats. Much like a startup.

Dan Pink sums it up best in Drive: The Surprising Truth Behind what motivates us.

If we are truly going to empower our people, and let them do whatever it takes, then we better get out of their way and support them in playing whatever role(s) they need to play.

So don’t let a title or role stop you from serving your customer. Use whatever innate skill and ability you’ve got.

And if this subject of how agile teams work is of interest to you, come see me speak at Agile 2011 in Salt Lake city where I will be presenting a talk titled The Surprising Science Behind Agile Leadership and what really motivates us.

Fierce delivery – first working version in two weeks


One of my favorite techniques for building trust and demonstrating intent when starting out with a new client is to build them the first version of their application in two weeks.

No it doesn’t have every bell and whistle, and it definitely wouldn’t when any design awards, but putting that first version of working software in their hands after a single iteration can do wonders for you project.

What this does for your team

For your team it sends a message. We are going to move fast.

No time to sit around and naval gaze. The first version of our shippable product needs to be ready two weeks from now.

  • That means coding.
  • Testing.
  • Analysis.
  • Design.
  • Feedback.

It’s all got to be there for this one thin slice of functionality (usually their most important user story).

That means we are going to have to travel light and drop anything that doesn’t add value.

And if we are going to be adding new features confidently as we go (without paying an exorbitant amount) we are going to need to some practices and discipline around how we change our software.

  • Continuously integration.
  • Automated builds.
  • Automated unit testing.
  • Regular feedback.
  • Aggressive refactoring.
  • Rhythm and ritual.

It’s all got to be there.

This is good because you want your team used to the idea of regularly making changes to a production ready system.

That’s how agile (XP in particular) likes to view systems under development. They are meant to be kept in a state of continuous production readiness. We are simply adding new features every week (starting with the first version after two week).

What this does for your customer

Most customers are blown away when you tell them you are going to delivery the first working version in two weeks.

It gets their attention.

It shows an intent, and fierceness around delivery sorely lacking in our industry.

Regularly producing shippable software changes the game and relationship with your customer. It shows them the importance of their role and highlights the fact they are first class citizens and needed for a successful project.

What this does for you

While I can’t promise you’ll lose weight or it will improve your sex life, I can tell you delivering fiercely will raise your profile and get you noticed where ever you choose to work.

People are going to want to know how you got business to the table.

They are going to want to know how you built a system for them which is exactly what they wanted.

They are going to want to know how you made going live a non-event.

And they are going to want to you do it again, and again, and again.

Look, I get that there may be thousand reasons why may not be practical to deliver your first working version in two weeks.

If this is the case, then think of it more as an attitude.

But you’ll never know unless you take that first step.

Like Henry Ford said: ““Whether you think that you can, or that you can’t, you are usually right.”

%d bloggers like this: