Finding the Right Process

December 31, 2007 by jeremy

Agile teams are often faced with a dilemma: how much process is the right amount of process for us? There's no right answer, of course, and the closest thing to a right answer can change as often as you change your socks, which, for the sake of your teammates, I hope is pretty often.

The amount of process your team needs to succeed is influenced by a variety of factors, such as team size, team skill, honesty and trust, management style, your product domain, your team's understanding of the product domain, access to your customers, and much more. There are too many factors and variables to even consider coming up with a formula, so experiment -- try doing some new things, try not doing some old things, and see what happens.

Processes that add no value detract from those that do.
Every part of your development process should be done for a reason. If no one can explain why you're doing something, stop doing it. Of course, if you stop and it becomes evident that you shouldn't have stopped, start again. Pruning defunct or costly activities (including "busy-work") helps to emphasize the value of activities that are important to your team's success, and your team will be more likely to embrace and excel at those activities.

For example, if your team practices Pair Programming but can't explain why, try an iteration without pairing. If the defect rate triples (barring any other obvious factors), it's probably a good idea to start pairing again to get quality back on track.

However, if your team members submit a weekly status report in addition to daily stand-up meetings, you may find that the weekly status report adds no value other than helping a distrusting middle-manager sleep at night.

Start small and tweak the processes that you already follow.
You don't have to eliminate an activity to understand it or increase its value. Your team probably can't pair program for 8 hours every day, but can they do it 2 hours a day, 2 days a week? If that works, can we try 4 hours a day, 3 days a week? We write a lot of unit tests, but can we try writing tests first? Can we increase our velocity and quality by writing acceptance tests?

Retrospectives are a good time to bring this up. What worked, what didn't? How can we improve?

There are some things that most Agile teams should do.
Automated testing. Continuous integration. Collective ownership. Small, frequent releases. Refactoring. Retrospectives. The vast majority of software development teams benefit immensely from these increasingly common practices. It's hard to imagine a team being successful over a significant period of time without them these days.

That's not to say that you have no flexibility -- it might not be worthwhile for the entire team to be fluent in your most complicated business logic, but buses (often labeled "Exciting New Job") have been known to hit experienced programmers from time to time.

Experiment, experiment, experiment.
You don't know if something will work for your team unless you try it, and you often don't know if your team will fall apart without a process that is considered critical. Don't be afraid to try new things.

Permalink