Agile Focus

One of the most popular articles here is 10 Rules For Great Development Spaces, so I thought I’d follow up by explicitly listing signs of bad spaces. These are my top 9, but I’d love to hear what others people have noticed.

1. People wearing headphones. Part of the reason to sit together is to listen to one another. If team members are wearing headphones, they can’t do that. Don’t blame them, though; figure out what noise or distraction drives people to do that and eliminate the root problem. And if they aren’t part of the team, move them elsewhere.
2. Stale artifacts on the walls. Every artifact on the wall should be there for a reason. If there are a lot of stale plans, charts, or lists on the walls and whiteboards, that’s a sign of trouble. Immediately prune the junk!
3. Workspace as information desert. Development teams turn knowledge into software products. Rather than requiring effort to find things out, a good workspace requires effort to avoid knowing what’s going on. Bare walls often indicate low collaboration or high confusion.
4. Minimal interaction. If team members sit near one another and never talk, it’s often a sign of an underlying problem. I’ve seen this caused by bad relationships, code silos, excess division of labor, too-long release cycles, excess schedule pressure, and plain old shyness.
5. Furniture as barrier. Furniture should help you work, not get in the way. Barriers are great to reduce noise and chaos at team boundaries, but true teams should be able to share space and collaborate effectively.
6. Sad or ugly spaces. You will likely spend more waking hours in this room than any other. Shouldn’t it be nice?
7. Seating by job description. Agile approaches require cross-functional teams to make whole products. If people are grouped by job description, that is at least a barrier to collaboration, and often a sign of unhelpful silos. Group people by project instead.
8. Space and furniture as status markers. In some companies, being distant from the action is a sign of status. On Agile teams, that’s a mistake. Instead of using rooms and desks to indicate hierarchy, give people the tools they need to do their jobs.
9. No laughter, no fun. This is a big one for me. Every really productive team I’ve visited enjoys the work and their fellow team members. Money can make people show up, but it’s joy that gets the best results.

That’s my list. What’s yours?

Somebody recently asked me if Agile approaches aren’t essentially reactive, with Waterfall being proactive. It’s a good question, and I’m sure there are a lot of interesting answers. Here’s my take.

Proactively reactive

In terms of product produced, you can be more proactive in an Agile context than you can in a Waterfall context. With Waterfall methods, you just have to hope your designs and plans are correct, reacting massively after each large release. With Agile approaches you can continually test your assumptions and hypotheses, allowing you to eliminate bad ideas early and invest more resources in areas that have been proven to deliver more long-term value.

Some Agile shops may end up stuck in purely reactive cycles, with no long-term plans. (I don’t see that much.) But the good ones are continuously updating their plans based on the new information that you can only gain if you can release frequently. It has been said that Waterfall is plan-driven, while Agile methods are planning-driven. Having tried both, I think frequent plan improvement is much more proactive.

The Agile conversation

Another way to look at it is that Agile approaches proactively take advantage of people’s reactive skills by creating situations where their reactions will be maximally useful.

Conversations are in some sense essentially reactive: you say something, I respond to it, you respond in turn. But we can proactively decide to have a conversation and expect to get something useful, perhaps novel out of it.

Agile approaches have conversations with markets and user communities, using new releases to advance the discussion. We release something and say, “How about this?” People respond: they love X, they hate Y, and how did you miss Z! We release another thing and say, “Is this better for you?” And so the conversation goes, week after week.

Some teams talk as if design is something you can add to software later, saying, “Oh, that interface we built hasn’t been designed yet.” That way of thinking is based on a fundamental error.

The problem

Many real-world teams treat certain kinds of design, including visual design, user interface design, and interaction design, as quantities that you can add later. Often this is done with the best of intentions.

For example, the team’s designer may be unavailable, so the rest of the team will get to work on a story, building an obviously rough interface. If, by the time they’re done, the designer still isn’t available, the product owner might accept the story as complete, making a mental note to come back later, perhaps much later.

When somebody external comments on the ugly interface, the developers might say, “Oh, that hasn’t been designed yet.” They’re wrong.

Software is nothing but design

People often talk about software with an implied analogy to industrial production. One group of people makes up some blueprints, and then an entirely different group of people makes physical objects. That second group is judged not by the utility of the objects, but by conformance to the design. This can sometimes be a useful analogy, but in an important way it’s entirely false.

In truth, the creation of software is 100% design. The computer does all the work of making things happen in the real world. The software is just the blueprint the computer uses to decide what to do. In the same way that a good manufacturer is one that follows the instructions well, a good computer is one that executes the software faithfully and reliably. All the humans participating in the creation of software are involved in a joint design activity.

“Not designed” is badly designed

So if software is pure design, then what’s going on with the ugly interface? The notion that it is somehow “not designed” is wrong. It’s just badly designed. Why does that matter? Because good design isn’t something you can spray on later like a new coat of paint.

Programmers already know that for the kinds of design they appreciate. Good developers try hard to avoid  spewing out reams of confusing, badly organized code that they hope to clean it up later. They know that’s wasteful, and likely to hide tricky problems. Tactically, they may choose to leave certain things messy for a short period. But experienced developers do that judiciously, painfully aware of how easily a controlled low-quality situation can turn into an uncontrolled one.

Teams should have the same attitude about every kind of design that matters for their project. Each story should be well designed from every perspective before it is declared complete. That sounds like it could be a lot of work, but it needn’t be. As with the software architecture, other sorts of design can be approached incrementally and iteratively.

The only hard part is making sure that you have all key contributors working together. The easy way to do that? Put them all in a room, and have them release something every week. They’ll figure it out.

A team in which everyone works at top capacity has got to be the most productive, right? This article explains why it ain’t necessarily so.

(Note: I didn’t invent the exercise described here. I first saw something like it presented at the Agile2006 conference by Ashley Johnson and Rich Phillips of Valtech Technologies, Inc.)

The assembly line analogy

I recently conducted an exercise with the folks at North Bay Agile in which two teams formed assembly lines for folding paper airplanes. Each assembly line consisted of a number of distinct operations, as follows:

• Operation 1 - Get raw material (a sheet of paper) from stock.
• Operation 2 - Fold inward lengthwise, then unfold.
• Operation 3 - Fold top corners inward.
• Operation 4 - Fold sides inward, fold in half, fold wings down.

In the first shift, every member of each team worked at top capacity. The result: Each team produced about a dozen airplanes in 5 minutes.

But then I had each team fill out a “profit and loss” statement. They got credit for “selling” all planes produced, but they were also debited for the labor and material costs of uncompleted airplanes (which stacked up in front of Operation 4, the bottleneck). The financial news: Both teams incurred a loss.

In the second shift, the teams were instructed to slow down to match the rate of the slowest operation. This was accomplished by creating a “buffer zone” before each operation and following a rule which said, “you can’t pass your work on to the next operation until that operation’s buffer zone is empty.” The result: Each team still produced around a dozen airplanes in 5 minutes.

When the profit and loss statements were filled out a second time, each team showed a profit. This was directly due to the fact that no work-in-process inventory built up, thus reducing the amount spent on materials and labor.

The most obvious difference in the overall activity of the assembly lines from shift to shift was that, in the second shift, the upstream operations were sometimes idle. By slowing the upstream operations to match the rate of the slowest operation, both assembly lines increased their productivity.

Increasing productivity stepwise

After the first shift in the exercise, the inclination of several participants was to try to find ways to improve the performance of the slowest operation. As the second shift demonstrates, however, a simpler first step is to just slow down all of the upstream operations to match the rate of the slowest operation.

The business novel The Goal outlines a process for increasing the productivity of a manufacturing system:

• Step 1 - Identify the system’s bottlenecks.
• Step 2 - Decide how to exploit the bottlenecks (e.g. don’t let a bottleneck be idle).
• Step 3 - Subordinate everything else to the above decision (e.g. throttle back the upstream operations).
• Step 4 - Elevate the system’s bottlenecks (e.g. speed up a slow operation).
• Step 5 - If, in a previous step, a bottleneck has been broken (i.e. a bottleneck is no longer a bottleneck) go back to Step 1.

 As you can see, the recommendation is to slow down all non-bottleneck operations before trying to speed the bottlenecks up.

How does the assembly line exercise relate to software development?

Although software development is not the same as manufacturing, there are situations in development that exhibit the characteristics of an assembly line. Suppose, for example, that you are a developer building components for use by other developers. If you (the upstream operation) produce components at a rate faster than the other developers (the downstream operations) can understand and use them, you can create a bottleneck, causing excess “inventory” to build up.

Software development is about creating and sharing knowledge

Here are some simple things to remember when considering whether it is more profitable to work at top capacity or to be idle part of the time:

• Knowledge is the inventory of software development
• People consume knowledge at their own rate
• Creating knowledge faster than it can be consumed causes excess inventory
• Excess inventory reduces profits

In other words, working at your own top capacity may not be the positive thing you think it is. If you’re producing software components at a rate greater than the rate at which they can be put to use, you could be hurting the bottom line.

One of the reasons traditional processes fail is that they are fitted to how people think they think, not how they actually do. Below I link to two interesting articles about how people think, and talk about the software process lesson I draw from them.

Waiting for marshmallows

Ninja programmer Brian Slesinsky recently pointed out to me this great New Yorker article: “Don’t: the secret of self-control.” 40 years ago, a psychologist performed a simple experiment on small children: He told them they could have one marshmallow now, or two if they waited a bit. Unsurprisingly, some children managed to do it; some didn’t.

The interesting part is why, and what happened later. Following up over the decades, it turns out this sort of self-control is powerfully predictive of success in life. One researcher found that the ability to delay gratification was better than IQ scores for predicting grades.

But how did this work? Do some kids just have more willpower than others? Was it just that some didn’t have all the facts about what they’d get when? No, it turns out. Instead, the children best at waiting put the marshmallow out of their minds. They covered their eyes, or sang Sesame Street songs. Focus on the marshmallow and you were guaranteed to lose. In other words, the successful children changed their situations to support the right sort of thinking.

Waiting for foreclosure

In this weekend’s New York Times there was an article “My Personal Credit Crisis”. The writer, Edmund L. Andrews, opens:

If there was anybody who should have avoided the mortgage catastrophe, it was I. As an economics reporter for The New York Times, I have been the paper’s chief eyes and ears on the Federal Reserve for the past six years. [...] I wrote several early-warning articles in 2004 about the spike in go-go mortgages. Before that, I had a hand in covering the Asian financial crisis of 1997, the Russia meltdown in 1998 and the dot-com collapse in 2000. I know a lot about the curveballs that the economy can throw at us. But in 2004, I joined millions of otherwise-sane Americans in what we now know was a catastrophic binge on overpriced real estate and reckless mortgages.

Again, knowing the facts weren’t enough. There were few people on the planet with more information about the topic, and he had unfettered access to people who knew the rest. But when he put himself in a situation where circumstances combined to reinforce his desires, mere knowledge wasn’t enough to save him.

So what’s this have to do with Agile development? I see two related lessons:

Product dreams

Think, for a moment, about the classic waterfall dream:

1. you work hard to make a big plan,
2. you follow the plan for a long time,
3. you produce what you planned,
4. and then you have a big success.

This can go off the rails in a number of ways, but key to many of the failure modes is that it mostly avoids contact with the external world up until the end. People spend most of their time in a context where their focus is on conforming to other people’s notions, rather than the real environment.

On a truly Agile project, you try to avert this through particular practices, like frequent releases, weekly iterations, and energetic engagement with users and stakeholders. Rather than pretending that you can imagine your way to a good product, you put yourself in a situation where the environment pushes you toward a great product.

Technical dreams

This has parallels on the technical side.

All good programmers like to build things. In the wrong context, this can lead to developer gold-plating and infinite infrastructure. I once saw (but, thank goodness, didn’t work on) a system that spent $120 million on years of planning, development, and initial rollout. Many years into the project, it only had 4 working screens, which wasn’t enough to be useful to anybody. But it had plenty of infrastructure.

More insidiously, technical choices tend to be self-reinforcing. Suppose in the first week of a project a team starts out with an SQL database, just because it’s convenient. If you point out to the programmers that they’re making a big technical choice on the basis of minimal data, they will say: of course we can change the design later. But there’s a reason that those programmers work for a paycheck while Oracle’s Larry Ellison has $20 billion in the bank and collects exotic jets. Only Larry understands that very shortly they will have a hard time even conceiving of making that change.

To avoid these perils, it’s important to follow practices like simple design, pair programming, automated testing, merciless refactoring, and YAGNI. But just as important is to think just like great product managers do: treat the project as a series of small bets. Instead of grand architecture visions, it’s more effective to continuously run small experiments that help you decide between different design options.

If you structure your environment to force continuous learning and small, feedback-driven steps, your thinking will come to reflect that. And you’ll be better off for it.

Building a great team development space is tricky. You have to balance a lot of factors: human, social, environmental, economic, and personal. There is no universal solution, but I wanted to share a few lessons I’ve learned over the years.

Note that these only make sense if having a productive team is a high priority. For a lot of organizations, other motivations regrettably win out.

My 10 rules

1. Put everybody vital to the project in one space. Agile methods are built around communication. Having everybody together means that instead of having to work to communicate, they’d have to work not to.
2. Isolate the team from off-topic noise. You want to create a space where people are comfortable listening to the conversation around them. Most of what they hear should be related to the work at hand, at moderate volume, and free of drama.
3. Have plenty of wall and whiteboard space. The workspace should be richly informative, with product plans, task lists, backlogs, charts, and source material obviously present. Make it easy to know what’s going on.
4. Allow room for a daily stand-up. Every morning, I like to have a team get together and spend a few minutes getting back in sync about what’s going on. That will often involve referring to in-room artifacts like task breakdowns, backlogs, and interface sketches. Give them enough room to huddle up!
5. Get collaboration-friendly desks. I’m amazed by the number of companies that talk up collaboration and then buy furniture that is actively hostile to it. Whether or not the team officially practices pair programming, every development station should allow two people to sit comfortably side by side and have equal access to the screen and keyboard.
6. Minimize distractions. For programmers, interruptions are doom, causing lost productivity and decreased product quality. (This doesn’t apply as much to non-programmers, but those folks should still be wary of distractions.) To minimize chaos, I often suggest these rules for development stations:
   • No phones. Some teams avoid individual phones entirely; others just keep them away from development stations.
   • No email or IM. Relegate that to machines out of or at the edge of the main work area. A common solution is shared development stations, with personal laptops for email, IM, and the like.
   • No off-topic conversation. Agree that if even one person is concentrating, off-topic conversation must happen out of the team room.
   • Executives stay muted. Often higher-ups are used to being the center of attention. Some teams have learned to keep working, but that requires the bosses to be quiet and modest in their demeanor. If the execs can’t do that or the team can’t ignore them, keep them out during periods when work is getting done.
   • Control foot traffic. I like to put developers away from the door, with managers, product owners, and designers closer to it. Visitors are very likely to talk to the first person they see; if that’s the person most able to help them, that’s better for everybody.
7. Only direct contributors sit in the room. The people sitting in the room should be focused mainly on the project at hand. A good solution for part-time contributors is to have guest desks, so that they can be present when participating and return elsewhere when they aren’t. People with unrelated work, especially noisy work like sales, should never sit in the room.
8. Have necessary spaces nearby. Making software should be the primary focus of development teams, but make sure to allow space nearby for other important activities. These can be formally designated areas, or informal things like spare offices and nearby coffee shops. Often they are shared with other groups. I like to see:
   • Small meeting areas. These should suit one person who has to take a phone call, or two to three people who have to meet.
   • A large meeting area. This need is usually filled by the classic conference room. Whiteboard space is mandatory.
   • A lounge. Office space should encourage focused activity, but people need rest, and good ideas often come out of more casual conversations.
   • Related projects and staff. Communication patterns tend to mirror spatial patterns. Take advantage of that!
9. Make the space pleasant. I’m not talking about gold-plated faucets here, just about making a space comfortable rather than hostile. Sure, people can work almost anywhere, but you should save their gumption for delivering value. This often includes:
   • Good lighting. Some natural light, supplemented by good room and/or task lighting. For whatever reason, programmers often hate fluorescents, especially the low-grade ones, so I try to avoid those.
   • Decent air. Team rooms often have a higher person density than normal, so it’s especially important to make sure that there’s good ventilation and temperature control. By 3 pm, too many team rooms smell like a packed dance club on an August night.
   • Comfortable, reliable furniture. I’m not talking about deluxe furniture here; often a mid-range Ikea equivalent is fine, and I generally suggest good tables rather than standard desks. But a shaky desk or an uncomfortable chair costs far more in productivity than it saves in cash.
   • Plants and decorations. It takes very little extra to turn a room from adequate into appealing. A little greenery and a couple of framed posters is a good start. Depending on company culture, a couple of toys can be good, especially ones that encourage interaction or collaboration.
   • Snacks. Food and drink is a central part of hospitality in every culture I’ve heard of. Normally I’ll put out some healthy snacks, like a bowl of fruit and some baby carrots, plus a water cooler or a fridge of bottled water. Typically I put more elaborate or less healthy things, like coffee, soft drinks, crackers, and cereal, in a kitchen or lounge area.
10. Get good tools. The one area I think it’s worth spending a little extra is on quality tools, including things like whiteboards, IDEs, screens, keyboards, and build servers. Amortized over thousands of hours of use, even the high-end ones are practically free. Don’t waste time and energy with slow builds and dodgy tools.

But that’s too expensive!

Expense is a common complaint, but I don’t think it makes a lot of sense when you look at cost/benefit trade-offs.

If you add up what you’re already spending on a team for the life of a project, it’s going to be quite a lot of dough. And that’s not even the right number for comparison; any software team should generate a return on investment well above obvious costs. If what I recommend above yields even a modest improvement in productivity or reduction in turnover then it’s well worth it. In my experience, the gains are dramatic, not modest.

But that’s too hard!

Sometimes these things are hard for legitimate reasons. For example, moving offices or rebuilding part of your space is undeniably a lot of work. But some hard work at the beginning of the project is much easier than years of strain trying to compensate for bad working conditions.

Sometimes, though, this is hard because companies value other things more than productivity. Some teams can’t fix workspace issues because of office politics, too-rigid budgeting, control-obsessed furniture police, nonsensical corporate policies, dysfunctional decision-making processes, or the valuing of appearance over results. If that’s your situation, consider explicitly discussing your company’s cultural problems.

If you’re scared to even bring these issues up, it’s worth asking yourself whether you’re working at the right company. Your employer may not share your desire to get things done, but I promise that there are many who do.

For more info

I know of a few good related resources:

• There’s my own An XP Team Room, with photos and detailed explanations of one specific team room.
• Bill Wake has a great Gallery of Team Rooms.
• Dushan Hanuska thoughtfully considers the details of room and desk layout in Pair Programming and Office Layout.
  
• A Software Engineer’s Office, by Karel Thönissen, carefully details the many choices his team made.
• Todd Hoff gives his views on The Ultimate Software Development Office Layout, with a great list of related articles.

Have more? Please mention them in the comments.

Too many people these days seem to think that adopting an Agile method is quick and easy. Not so! It’s definitely worth it, but the road can be long and hard.

In corresponding with a newbie, I gave a list of five ways they could speed up their adoption. Here they are, with a bit of explanation:

1. Have a clear project charter. If you don’t know what your project is supposed to achieve, it will take you a lot longer to get there, and a lot of decisions will be muddled. Write up a clear statement of purpose, post it prominently, and keep it up to date when goals change.
2. Shorten your iterations. An iteration is a regular, fixed-length period where you decide what you’re going to do, go do it, and then measure how much you got done. (By done, I mean 100% done and releasable, what some call “done done”. 98% done equals not done.) Keep iterations as short as possible. I recommend a week. Two weeks can be ok; three or four is risky. Three months is downright nuts.
3. Release more often. As often as you can, get software out to real users. If you think you’re already doing it as often as possible, you’re probably wrong. Many teams release weekly, some daily, and a few ship several times a day.
4. Get more data. You wouldn’t drive a car with the windshield painted over, steering by where you think you are, but that’s how a lot of people drive projects. Increase the volume and clarity of real-world data on product impact. Use that to evaluate what you’ve released, and to shape upcoming work. This can include guerrilla user testing, user surveys, usage analytics, customer surveys, user context research, sales data, and just having people over for a beer.
5. Use an experienced Agile coach. I may be a little biased, but I think a good Agile coach can save a lot of time and trouble. There are a lot of good ways to be Agile, but there are even more bad ways, and it’s hard to tell them apart until you’ve been around the block.

The careful eye will notice a common theme here: improving feedback loops. The more feedback we get, and the faster it comes after our actions, the quicker we learn. That’s the engine that makes Agile approaches superior to plan-driven ones, and we can use that engine to speed up Agile adoption as well.

Numbers are tricky, especially when you want to use them to understand business problems. A book I read a few years ago and several blog posts more recently have highlighted this for me, so I got the urge to write about the challenges inherent in understanding with numbers and a couple of helpful tips I’ve picked up from the Agile community.

In The Elegant Solution, Matthew E. May devotes a chapter to talking about the importance of picking the right things to measure for your business (Chapter 11, “Run the Numbers”). The Elegant Solution is one of my two favorite business books (together with The Seven-Day Weekend by Ricardo Semler), filled with Lean principles learned from May’s years teaching for Toyota. But while most of the book is quite practical, its practicality kind of unravels in this chapter.

The problem is, the first several examples he gives show just how darned hard it is to get numbers right. It’s hard enough to decide what you want to measure. But the examples go way further, showing how even math PhDs can get correlations and probabilities horribly wrong. The author doesn’t even seem to be trying to make the point of how hard it is to get the math right. He seems to be trying to merely make the point that it’s important to get the math right. It just turns out that every example is more about getting the math wrong.

The first examples he gives aren’t even from business, starting with the Monty Hall problem. This problem evokes heated debates, with very smart people giving different answers and standing by those different answers insistently. The vast majority of people get it wrong, including people with advanced study in mathematics. I got it wrong at first, and it took several tries to finally accept the right answer. (In my defense, I did figure it out before getting out of college!)

In another example, May arguably gets it wrong himself:

You’re playing a video game that gives you a choice: Fight the alien superwarrior or three human soldiers in a row. The game informs you that your probability of defeating the alien superwarrior is 1 in 7. The probability of defeating a human soldier is 1 in 2. What do you do? Most people would fight the human soldiers. It seems to make intuitive sense. The odds seem to be in your favor. But they’re not. Your probability of winning three battles in a row would be 1/2 X 1/2 X 1/2, or 1/8. You have a better shot at beating the alien superwarrior. It’s a simple problem of probability. [Matthew E. May, The Elegant Solution, page 158]

Here’s the thing: If the chance of beating each human soldier is purely random and independent of beating any other human soldier, then the probability of beating three in a row is indeed 1/8. But if there’s any skill involved in the game, then the chances are not independent. When I’m playing a video game, I typically will grow through levels of skill where certain kinds of opponents become easy to defeat. When I start playing the game, maybe I almost never defeat “human soldiers”, but after some time playing I get to a level of skill where I almost always defeat them. So if I can defeat the first soldier, I will likely defeat all three; if the probability of defeating the first soldier is 1/2, the probably of defeating all three is arguably nearly 1/2 as well, which is clearly better than the 1/7 chance of beating the “alien super-warrior”.

I was reminded of this chapter from The Elegant Solution when I saw a flurry of blog posts on a similar problem recently: See Jeff Atwood’s question, his own answer, Paul Buchheit’s response, and the discussion on Hacker News… The problem is just as simple as the Monty Hall problem, and the response it just as heated. Paul Buchheit points out that the simple English statement of the problem can be parsed two different ways, which result in two completely different answers (both of which I verified myself by Monte Carlo simulation!). In another realm, Semyon Dukach suggests that the current financial crisis is due precisely to the difficulty of numerical intuition.

The examples of success with numbers in The Elegant Solution all come down to identifying very simple metrics underlying the businesses in question. Jim Collins gives similar counsel in Good To Great. But the problems mentioned here show that even given a very simple mathematical statement, you can still get into lots of trouble. In The Goal, Eli Goldratt gives some fascinating advice about how to orient your business toward the true goal of business (I won’t spoil the plot by saying what “the goal” is; it really is worth reading the book). But here again, the whole story line of The Goal shows just how unintuitive those principles are, and how long and painful (though valuable) a process it can be to learn them through real-world experience.

So what do we do? A couple pieces advice I’ve picked up over the years might help:

1. Measure, don’t guess. Specify the problem precisely enough to implement a Monte Carlo simulation, and then run it several times. This is the only way I’ve been able to convince myself of the answers to tricky problems like the Monty Hall problem. The more I think about the problem, the less sure I get about the answer. This principle also applies to optimization of code: Start with the simplest thing that could possibly work, and then measure how it performs under realistic conditions. The thing that needs optimization is often not what I guessed it might be.

2. Measure “up”. Mary and Tom Poppendieck talk about this principle in detail in their Lean Software Development books (the phrase is mentioned on page 40 of Implementing Lean Software Development). It is an antidote to local optimization: The more you focus on localized metrics, the more confused you’ll get. As they write, “The solution is to … raise the measurement one level and decrease the number of measurements. Find a higher-level measurement that will drive the right results for the lower-level metrics and establish a basis for making trade-offs.”

What other advice do you keep in mind when numbers get tricky?

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.