Archive for January 2009

Short into long: long-term planning in agile processes

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.

21 ways to hate pair programming

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?

      Doing too much: worse than too little

      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.

      Clicky Web Analytics