« The Dead Speak| Main | Puns I wish I never heard »

Agile Accelerators

| | Comments (1)

Having seen scads of projects that are agile over the years, quite frankly I'm sick of talking about agile. Who's more agile than whom? Is there such a thing as agile maturity? If so, does it mean something useful? Can I be agile if I like using Microsoft Project?

How about this -- here are the seven factors I have found that make agile teams run faster. They may or may not make you more agile, but they'll definitely let you get your work done faster. So when you're done early, you can talk to the other teams about who is more agile than whom.

  • Co-location - spend most of your work time in direct proximity to each other. There are lots of fancy reasons why this works, and it really doesn't feel like it's working while it is, but trust me, you'll go faster.
  • Daily Stand-ups - another one that seems as much fun as visiting your inlaws for a weekend. Make it a chore. Do it religiously. Actually stand-up. Use a foam football or something. A mature team will find other ways to stay in close touch about work progress, perhaps having 2 or 3 mandatory team lunches every week. But even then, that's after the initial stand-ups start wearing thin. Stand-ups build teams, keep people on-topic, provide daily feedback as to what is broken, and sets a sense of camaraderie. But since you're in the middle of it, you'll very rarely figure out how much it is helping. So suck it up and just do it.
  • Agile Modeling/Doodling/Use of the Whiteboard - This is the numero uno thing fast teams do. Everybody, and I mean everybody, will come to the whiteboard and attempt to draw pictures to explain problems and plans to the group. Any form of visual drawing, from doodling to lightweight UML sketching and refining, passes information at a much higher bandwidth than even conversations do. Modeling accelerates conversations, which accelerate solutions.
  • Re-state the backlog - Bad agile teams are like order-takers: the product owner keeps talking, and everybody just writes furiously in their little books. I keep waiting for somebody to ask "Would you like fries with that?"

    Good agile teams re-organize the backlog, using things like a domain model as a visual dictionary, or bringing forward architectural issues that might need to have a higher priority than business issues (yes Virginia, technology can sometimes trump business needs). If the product owner is talking and somebody isn't drawing and re-arranging what they're saying, we got speed problems. Well-ordered and defined backlogs cook. Bunch of vague-looking noise in a backlog? It's not cooking. More like a simmer.

  • Put the fire out - think of a project as a large burning building. You and your team show up with a bunch of equipment and men. Somewhere, up in the smokey distance, a voice cries out: "My baby! My baby! Can someone save my baby on the third floor?!?"

    The fire is your project. Saving the baby is your current iteration. Do everything humanly possible to get that baby saved, but once the team leaves to grab the kid, don't sit around the fire truck smoking cigarettes and talking about the Mariner's game. Start putting the dang fire out. Yes, you have immediate priorities. But you also have strategic priorities, and you have an important job to do. Put the damn fire out.

  • Have Some Social Skills - You gotta balance speaking and being quiet. You have to be able to negotiate how everybody will work together each day. You have to be able to call somebody's baby ugly without getting into a fistfight. You have to be able to take and put up with random chit-chat. You need to facilitate other people disagreeing so that everybody wins. You need to put the team's vote above your own opinions. These are really tough things to do! And heck, I'm not that good at most of them. But the teams that do this the best are the ones way out there in the distance way ahead of the pack.
  • Shoot the non-performers - It's real simple. You describe what you can do, then you do it. At the end of the iteration you show that it was done. If not? Then they take you out and shoot you. It's a real simple system. I know agile is all about team-empowerment, happiness, and little bunnies running through the forest, but it's also about performance. Knowing what you can and cannot do, and being able to describe and commit to that (and stick to your guns if pressured) is why you get paid. Agile teams work best under stress, either the stress you put on yourself to do better or external stress put on the team to perform.

These probably aren't the most politically correct items, but they work. Want a fast team? Use them.

1 Comment

At last, an explanation with all the impurities boiled out! Yes, this is what it is.
I'm in strong agreement with re-stating the backlog ... we have a pretty systematic way of managing this process (maybe I'll include later when I have time).
I'm tempted to throw one more item out there - about tolerating continuous refactoring of design/implementation at part of the process. This is at par importance with saving the baby on the firey floor above, in the long term.

Leave a comment

About this Entry

This page contains a single entry by Daniel published on September 25, 2008 2:54 PM.

The Dead Speak was the previous entry in this blog.

Puns I wish I never heard is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.

Powered by Movable Type 4.23-en
Daniel Markham