Agile Focus

There seems to be a lot of confusion these days about whether something or other is really Agile, and what that means. Here’s my take on how to sort that out.

Growing up, I lived in a city called Grand Rapids. As you’d expect, there’s a river running through it. Does the river actually have rapids, and if so, are they truly grand? Do other rivers have rapids more rapid, or perhaps more grand? Those questions are interesting, but from the perspective of the name, it doesn’t matter. A long time ago, somebody thought that was a good name for the place, and it stuck.

Capital-A Agile

A decade ago and more, a bunch of people were working on new software processes. They were very different than what had come before, but they all had something in common. It was hard to put a finger on exactly what that was, but eventually they got together and came up with four value statements and twelve principles. And they came up with a single word: Agile. As in “Agile Manifesto” and “Agile Software Development”.

Was this perfect? No. Was it meant to explain everything about software development for all time? No. Was it a software development process on its own? Definitely not. But it was a declaration of common purpose, a list of things they could agree on.

That’s what capital-A Agile is: a bunch of people seeing that they had something in common, and attempting to say what that common thing was. They gave it a name and a partial definition. And most importantly, they formed a community that is still working out what that means and how best to do it.

Small-a agile

It’s important to note that they weren’t saying that they had an exclusive lock on agility, or even what made software development agile. As with the naming of Grand Rapids, they were pointing at a particular spot in the landscape of ideas and naming it. The word agile has a variety of meanings, and there are a lot of aspects to software development to which you could apply those meanings. They weren’t trying to lay claim to agility as a whole, any more than Grand Rapids is claiming all the rapids in the world, especially the grand ones.

That also means that there are plenty of ways to develop software that aren’t Agile. After all, software got made long before the Agile Manifesto was written. And there are surely ways of being agile that aren’t included in either the Manifesto or in the current practices of the Agile community. Heck, that’s part of why we get together every year, and talk so extensively on line. Processes based on continuous improvement gives you a real taste for continuously improving that process.

Saying “that’s not Agile”

So given this, what does it mean when somebody says “that’s not Agile”? To me, it just means that the thing they’re pointing at is a different spot in the landscape of ideas.

Some people get upset when they hear that, because they believe they’re doing well at making software, or because they think they’re being pretty small-a agile. They may or may not be right, but that doesn’t matter. If people in the Agile community say that something isn’t Agile, then it probably isn’t, the same way the city of Grand Rapids gets to decide where the city limits are.

If it bothers you to get told that something isn’t Agile, you have three basic choices:

• Find out more about what we mean about Agile. We’re generally a friendly bunch, glad to show you around. Join a mailing list, come to an event, or even ask in the comment box below.
• Persuade us we’re wrong. If Agile is the city we’ve built on the landscape of ideas, it’s a city that’s grown a lot over the years. It in effect started with a number of different little towns growing together. More recently came Lean, but these days it’s getting hard to even tell where the boundaries used to be. We’re very open to new construction, and your idea might be the next big development.
• Start your own thing. Agile may be the big thing of the moment, but it will eventually be as obsolete as the cavalry charge. Just because we say that something isn’t Agile doesn’t mean that it’s not a good idea. If you’re sure of yourself, do what the Agile founders did: stake out your own territory in the landscape of ideas and give it a name.

Regardless, there’s no need to get upset. Having different approaches or coming from different schools of thought doesn’t mean we don’t share the same goals in the end.

I just read George Dinwiddie’s interesting take on developer productivity, and I wanted to throw in my own two cents.

You can’t measure it

I agree with a number of others who say that there’s no good measure for developer productivity. There are several basic approaches people use, and all of them have flaws:

• time spent - This is a classic way to measure productivity. How long did people work? If the number is large, things must be good, right?
• apparent effort - Although this is even more flawed, it’s very popular. The “if you ain’t sweatin’, you ain’t workin’” metric is a favorite of seagull managers. But it’s easy to manipulate, and even when people are honest, it’s terribly misleading.
• technical output - This includes things like keystrokes or lines of code produced. As Bill Gates says, “Measuring programming progress by lines of code is like measuring aircraft building progress by weight.”
• functional output - Instead of counting lines of code, you can count features, through mechanisms like function points. Counting fields and data elements is a lot more work than counting lines of code, but it’s not clear the results are much better.
• business value - That’s what we’re after, so it seems like it would be great to track this. And you should. But it’s incredibly difficult to assign that value to individual bits of work, and especially to individual players.

Over the years, I have seen a lot of places try to numerically measure how productive their developers are. I’ve never seen anybody have much success, butI have seen a lot of wasted effort. And worse, I’ve seen a lot of harm. Try to measure individual productivity, for example, and you create a disincentive to help others. Since some of your most productive developers are the ones who mentor others and keep them from wasting time or making messes, it’s easy to drastically reduce productivity just by trying to measure it.

But everybody knows

Does this mean that it’s impossible to know how well a team is doing, or who the top performers are? Not at all.

The team knows

On agile projects, it isn’t individuals who are responsible for delivering. It’s teams. If your team is working together in a room, has tight feedback loops, and delivers frequently to end users, everybody will be forced to work together and interact frequently. Every team member will have a good idea of who is a top performer and whether somebody isn’t pulling their weight. They can’t not know. Whether they’ll tell anybody else is a different thing, which leads to my next point.

Embed reporters and distribute power

There are many advantages to having business people, like product managers and business analysts, in the room with developers. Your products will be better designed, better built, and more efficient. But a side benefit is that there will be somebody management trusts to give them an honest opinion on developer productivity. For this to work well, the business representative should be — both culturally and organizationally — not part of the engineering organization.

It’s also important to give the team matched responsibilities and power relating to this. Involve the team extensively in interviewing and hiring — and also in firing. Make sure they know they’re responsible for total productivity, and give them the authority to make changes they need in that regard. Hint: if they’re not allowed to change the furniture or order new RAM for their machines, they sure won’t think they can pressure or fire a poor performer.

Focus on delivering value

The key though, is to get the whole team focused on whatever purpose the team exists for. As frequently as possible, measure key indicators, like sales, usage, or customer satisfaction. And don’t automatically measure some numbers that go on a web page nobody looks at. Metrics don’t matter unless somebody cares about them. In an Agile context, caring about something is contagious. You should visibly care about the numbers that matter, possibly through a hand-drawn big visible chart. Others will pick up the habit.

If people really care about achieving shared goals, then you won’t have to worry about their performance. They’ll be doing it themselves.