Agile Focus

One of the things I get asked a lot is which meetings a team should have when. The right answer is that it varies for every team, and it changes over time. Still, it can be handy for new teams to have a starting point. In that spirit, here’s a schedule that I’ve assembled based on a few different smooth-running teams:

The schedule

Isn’t that a lot?

For everybody except the product managers, that’s under 5 hours of formal meetings per week. Once a team is running smoothly, I see many people doing it faster than that.

Still, it’s much better to allocate extra time for these meetings, especially at the beginning. Making an agile transition is hard enough without the stress of blowing out time boxes. Instead of squeezing the schedule down, develop the habit of looking to end meetings early. Only once you consistently end early should you shorten the schedule.

Even as scheduled, this doesn’t end up feeling like a lot. The daily stand-up should be fast-paced and energizing. The meetings that developers must attend are all at the beginning or end of the day, yielding large blocks of uninterrupted coding time. And the Monday morning and Friday afternoon meetings come at times when people are normally spinning up and winding down anyhow.

Notes and caveats

For this schedule to make sense, the team must:

• be doing weekly iterations
• have an on-site product manager (aka XP Customer, aka Scrum Product Owner)
• sit all in one room
• use lightweight artifacts (e.g., index cards, not requirements phone books)

You can divide the meetings up into three groups:

• The iteration planning and daily stand-ups cover what we are doing now.
• The product stakeholder, product planning, and estimation meetings figure out what we may be doing soon.
• The product demo and process retrospective look at what we just did.

The notion is that although the team is mainly focused on what’s going on now, product managers (and sometimes designers) need to work a bit ahead, so that the team can move smoothly into the next iteration.

It’s also important to note that plenty of conversation happens outside of these times. That’s why we all sit together. Rather than trying to make a schedule that formalizes every bit of useful discussion, it’s better to schedule only the minimum number of meetings to get everybody in sync.

Feedback wanted

Does this leave you with questions or suggestions? Let me know, and I’ll cover them in a future post!

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.

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.

Upon hearing about the short cycles of agile processes, some people are afraid that long-term planning never happens. They fear that teams could paint themselves into corners. That’s a risk: some teams do get fixated on each upcoming delivery, never sparing a thought for the future. But that’s not necessary, and below I tell you how to avoid it.

The secret

One of the secrets of agile processes is that they don’t tell you precisely what to do. Agile methods create contexts where people learn to do the right thing naturally.

For example, leaving loose ends is bad. You could make rules about exactly what constitutes a loose end and how to get rid of them. Many try.

Instead, you could start each week with a new set of work that you expect to fill the week. Then you release at the end of every week. That leaves no time for last week’s loose ends, which will turn up again as this week’s urgent bug fixes. In that context, teams have a strong incentive to learn how to tidy up all the loose ends that matter.

The secret, applied

So how do we create a context where your team will naturally spend the right amount of time doing long-term planning?

Step 1: Create a strong need for regular short-term plans. The best way to take care of this is through regular, frequent releases. If you are releasing something every week, then you are never more than 7 days from needing to have something to ship.

Step 2: Make a home for the long-term plan. There are always more good ideas than time to do them in. Instead of just throwing away the excess, you should keep them in a backlog. When you get enough of them that you need to organize them, make sure you do: that’s how the plan’s structure will emerge. For maximum effect, your backlog should be publicly visible, easy to update, and visually interesting. I usually use index cards and a rack or board. Do what works best for you, but if your plan becomes stale or gets ignored, try something more obvious and easier for everybody change.

Step 3: Establish feedback loops. It isn’t enough to release. You have to pay attention to what happens when you release. The right way depends on your environment. But observing what happens is the only way you can separate your good notions from your bad ones. The more often you do that, the better you’ll get.

Step 4: Frequently go over the plan. People with varied backgrounds should often walk through the plan together. Regular meetings are one way. But every question that starts with “why” is an opportunity to take a fresh look. As is the arrival of new data from customer feedback, user testing, market analysis, or economic forecasts.

Step 5: Be accountable to each other. A good team is in it to win, and win together. Mutual accountability helps a lot with that. Developers, for example, are responsible for building things that work for the long term, and the whole team should hold them to account for that. Equally, those managing the product are accountable to the team for the decisions they make.

Step 6: Be accountable externally. Almost every team has executives or investors that they are responsible to. On a regular basis (e.g., quarterly) tell them what you will do, what you have done, and how that compares to what you said you’d do. If they don’t ask good questions, get better advisors, even informal ones. As Doug Carlston, founder of Broderbund, has said, “The number one reason for bad software is too much money.” A lack of accountability is a big part of that.

Step 7: Keep time free for idle thought. There are many reasons to avoid being habitually overcommitted. But I think the biggest one is that tired or panicky people underinvest in the long term. We’ve all seen people come back from vacation filled with thoughtful observations and new ideas. Having good ideas once a year isn’t enough!

Some readers may feel like I’ve cheated them a bit. I haven’t told you how to break a project down into features. Or how to calculate value for units of work. There’s nothing about how to prioritize, estimate, organize, evaluate, or execute features. There’s nothing on market penetration or customer satisfaction or pleasing early adopters. Nothing on revenue models or organizational politics.

But that’s ok. I trust that given thoughtful practice, your team will figure all that out. The important thing is to start your practice right away.

Every time I’ve had the chance to talk in detail with people who hate pair programming (where two developers work jointly on the same task, usually sharing one computer, screen, and keyboard), I discovered that they were doing it in a way I too would have hated.

Below is a list of mistakes I’ve heard or seen real people make, including many that I’ve made myself. If you think pairing is not for you, first check to see if you and your team have solved all of these problems.

How to pair badly

1. Hog the keyboard – You’re obviously superior to your partner. Control the action at all times.
2. Ignore your partner – That noise that sounds kinda like useful suggestions? Probably a mosquito.
3. Ignore yourself – Speaking up for your own interests can’t possibly be helpful. Suppress, suppress, suppress!
4. Sit where you can’t see – You’ll be able to read the code when it’s your turn. If you still care then.
5. Sit where you can’t reach – Why be ready to take action? There’s probably not much you can do anyhow.
6. Take a back seat – Don’t sit next to your partner. Sit behind her. Then she doesn’t know when your eyes are closed.
7. Use a regular desk - Desks set up for one person work even better for two. Plus, the furniture police might catch you!
8. Don’t explain – Your partner, who is psychic, can just read your mind. Just keep on typing!
9. Don’t listen – You already know what your partner is thinking. And it’s boring.
10. Don’t ask – No, there isn’t a better way to do it, and your partner never forgets anything. So hush.
11. Interrupt frequently – ZOMG! They made a typo! You’d better tell them right now. They’d never notice otherwise.
12. Get distracted – Look, new mail! Hey, an IM! And check out Slashdot! Wait, there’s coding going on?
13. Daydream - Since you’re not really there to help, it’s ok to figure out exactly how many light bulbs there are in the room.
14. Be a back-seat driver – Your partner always wanted to be a stenographer. Keep telling them just what to type.
15. Don’t take breaks – Everything is better when you’re tired and cranky. Especially teamwork!
16. Work too much – It’s not what you create. It’s how many hours you spend at your desk.
17. Ignore ergonomics – The hunchback look is back in fashion. And who doesn’t like pain?
18. Betray trust – During, taunt about minor knowledge gaps. After, tell everybody how dumb your partner is.
19. Refuse to learn other tools – Emacs is obviously superior to whatever junk your team uses. To pair with you, they should all learn it. Now.
20. Don’t rotate pairing partners - If pairing for two hours is good, then six weeks with the same person must be way better!
21. Be arrogant – Seriously, what could you learn from that other guy? You know already: nothing.

Which ones are your (un)favorites? And what ones are missing from this list?

The last couple of years, I’ve run a big San Francisco race, Bay to Breakers, and it’s coming up again in May. I’m not much of a runner, and I’ve slacked off lately. But if I’m going to survive 12k with hills, now’s the time to start training.

How doing too much hurt me

The first part of my training is pretty simple. For 30 days, every day I do 30 minutes of mixed walking and running. (Want to start yourself? Use Hal Higdon’s plan.) But two days ago, I did too much. I met up with a more fit friend, and I let her set the pace. I did a lot more running than usual, and because it was fun to run with a friend, I did it a lot longer than usual: 60 minutes. I felt great, but like I had run a race, not gotten a workout.

It was fun, but I paid a price. The rest of the day I was a little loopy, a little unproductive. And then the next day, I was sore and tired enough that I didn’t work out at all. I knew I was supposed to go, but I just couldn’t bring myself to get out the door. And heck, maybe I should have taken a day off. Maybe my body needed the break. Doing extra seemed like it would be better, but it caused me to break training, and in the end, I got no more running in.

How it hurts teams

All that reminds me of a common novice mistake: overestimates causing productivity crashes.

Imagine a team just getting started with an Agile method like Extreme Programming. The first week, they guess they can do 20 points. However, they only get 10 done. How many should they pick to do the second week?

• 30, because they’re behind and want to catch up;
• 20, because the first week was an anomaly, and now they’re sure they can do 20;
• 10, because the evidence says that’s what they can do in a week; or
• 7, because they bit off too much and want to recover.

The most common answers are 30 and 20. They are wrong.

When people say that they are “behind”, that’s an indicator to me of a non-Agile culture. Their initial guess was just a guess. It is always a mistake to turn guesses into promises or plans, no matter how much stakeholders want promises or plans. A team picking 30, trying to catch up, is prone to spiraling out of control. They will repeatedly up the ante to gain back lost credibility, and repeatedly fail, either by not meeting goals or by producing junk.

Trying again to meet an unrealistic goal, as in 20, is a more insidious mistake. Especially early in an Agile adoption, a team is trying to learn how to do things right. But if they are continuously over-committing, they won’t have time to learn. Failing repeatedly to meet goals will discourage them. Regular over-commitment prevents successful Agile adoption.

The right answer

In the example above, I’d be happy if the team picked either 10 or 7. Why?

Guessing that they’d do next week what they did last week, picking 10, is an agile practice known as Yesterday’s Weather. It’s a realistic, data-driven answer, and assumes that you can get done about what you got done. There’s a risk that the team has still bitten off too much, in which case they’ll miss the goal again, but Yesterday’s Weather will sort that out in an iteration or two.

But what if they pick too little and say 7? Well, too little may not be too little. After blowing an iteration, the team can use a little slack to recover, to figure out what the problem is, and to fix things. But if it really is too little? That’s fine. It sets a team up to exceed the goal by pulling in something extra. That makes everybody happy, and it’s a habit you want your teams to develop.

Until a team has a strong record of regular quality output and consistently meeting goals, always err on the side of biting off too little. Challenging your limits is great, but first be sure you know what those limits are and how to recover from pushing them. When making plans or promises, do it based on a demonstrated track record, not on what you or your employers would like to be true.

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.

One of the most common novice questions about Agile methods is, “When do we do X?”

People always ask this about something important, and I’ve heard it asked about a bunch of things, including design, research, testing, architecture, and optimization. I think that’s a very reasonable question, as other methods have phases for things like that. From the novice perspective, we’ve taken away the phases, so it sure can look like we’ve just discarded everything but the coding.

The agile approach

My answer is that if something is important, you should never stop doing it. Make sure a little of it happens every week, and maybe every day. Close those plan-act-evaluate loops as often as possible:

• Is the user experience important to you? Then have a designer in the room, giving continuous feedback to developers. Do regular user testing. Instrument your production software and release it often, so you can see how well your theories play out.
• Is reliability important to you? Then involve QA as part of the definition of the story. Build your acceptance tests alongside the production code. Write your code test first.
• Is maintainability important to you? Then never stop improving the design of the code through refactoring, promiscuous pairing, and collective ownership of the code.
• Is making the right product important to you? If so, always have a product manager in the room. Make sure people talk about the why of a feature, not just the what.
• Is productivity important to you? Then have the team look back every week and find some way to improve your process. Encourage everybody to always be on the lookout for ways to do things better.

And so on, for everything that you think is important to your project.

The error of phases

A big mistake of phased processes is to think that you can get a great product by ignoring important activities for weeks or months at a time. But people only stay good at things that they do frequently. Even worse, spending months with your back turned on some important facet of your project inevitably harms it. As humans, it’s inescapable that we forget the past and insufficiently understand the future. And new information is always coming in, no matter what phase you’re in.

In truth, creating a cohesive product for an ever-evolving environment and audience requires regular attention to every aspect that matters. Instead of treating some important perspective as in the past or part of the future, bring them all into the present. If some activity really matters to your project, make sure somebody on your team is thinking about it every day.