Being Agile vs. Doing Agile

If you’ve been in IT for any part of the last decade, you know that agile is all the rage.

If you’ve been in corporate IT for any part of the last decade, you know that the corporate version of agile often falls far short of what the books talk about.

The reason is simple. Most people in big organizations who attempt an agile transition don’t understand the difference between being and doing. Nothing illustrates this better than the phrase “doing an agile project.”

Do people in your organization talk about “doing an agile project”? Maybe you’ve heard that. Maybe you’ve said it. Let’s all stop.

Agile paradoxically isn’t about software development. It’s really about building highly effective software creation teams. And that is precisely why “doing an agile project” makes no sense.

Agile isn’t something you do. It’s something you are.

Yes, there are agile practices, which are things you do. Stand-up meetings, test driven development (TDD), and all the rest. Doing those things doesn’t make you agile, any more than eating good food makes you a chef.

Agile is more than waterfall with user stories. Unfortunately, that’s how many large IT departments try to handle it. That’s why they talk about agile projects so much.

We wouldn’t call this breaking news, but there is no such thing as an agile project. There are only agile teams.
When somebody in charge starts talking about an agile project, he really means a project where the people involved pick and choose a few Scrum practices and call it agile.

It’s not.

The problem is that this so-called agile project starts as a project, which means it was probably born in a waterfall budgeting and planning cycle, and ended up being a few agile practices crammed into a decidedly non-agile container.

That’s doing agile. It generally produces failure. Then those involved claim agile doesn’t work.

Poppycock. Agile works fine when you take the step to be agile. When you don’t, and you try to do agile instead, agile will indeed fail, exactly like you should expect it to.

Being agile is an entirely different animal. It’s harder, potentially risky, and sometimes terrifying. Anybody who says otherwise is selling something. (Maybe that’s why the corporate IT agile experience stinks.)

Being agile requires everybody in an organization to think and act differently, from the start. You don’t have to be perfect from the opening buzzer. In fact, not being perfect and learning as you go is part of any healthy agile transition. But you do have to be different.

An agile transition with a shot at success looks like this:

• Executives fund long-lived teams who own complete product value chains (an entire software stack focused on a delivering a slice of business value to the customer).
• All levels of management refuse to force agile teams to manage themselves by waterfall metrics and development phases. Design isn’t ever “done,” so stop trying to make it so.
• Nobody anywhere in the organization thinks BRDs and WBSs are useful tools for agile teams, so nobody uses them. They rely on increased communication with practices like Scrum of Scrums meetings instead.
• Technical managers don’t submit to the typical pizza slicing of each programmer’s time. They dedicate their people entirely to single teams, then let them work.
• Programmers pursue craftsmanship with an eagerness approaching zeal. If they don’t, they’ll poop out when the going gets tough, as it always does.
• The business understands that the role of Product Owner isn’t something people do in their spare time. It’s their entire job. Teams will need them at a moment’s notice, and they need to be available. Pony up.
• The user community (or proxies for users) buy into the idea that they must help programmers know what software to create, or the programmers will create whatever they think makes sense. Which usually doesn’t.
• Everybody realizes that agile planning is a team sport, and it’s the only way the team can resist the urge to try to predict the future months in advance. That’s foolish. It’s also the basis for waterfall, and it hasn’t ever worked very well for software creation.

Sounds good, right? Then you take the ice water reality shower. Most organizations can’t get within a hundred miles of that, which is why our advice to most organizations is…

Be waterfall and be proud.

Seriously, if you aren’t going to create the environment necessary for agile to succeed, then bag it. It goes like this:

• Mr. Programmer, when a business person says, “Everything is critical!”, do you have the guts to tell him he’s (usually) wrong, and then work with him to prioritize the list?
• Mr. Programmer, will you politely refuse to write code for a given user story until the Product Owner gives you acceptance criteria for it, then work with him to create what you need?
• Mr. Product Owner, when a programmer does that, are you willing to set priorities, specify what you want, and do your job guiding the team?
• Mr. Executive, are you ready to budget for agile teams by understanding the team cost per iteration, allocating funds for the next release (or releases), and letting scope vary within that release container?
• Mr. Executive, are you ready to stop promising features to your higher ups, and then beat your teams senseless so they can make good on your over-commitment?

If folks in your organization can’t answer yes to each of those and other similar questions, attempting an agile transition is like giving whiskey and car keys to teenage boys (hat tip PJ O’Rourke).

If you do have general agreement that an agile transition is an organization-wide change of attitude, expectations, and behaviors, then you’ve got a chance.