Agile essentials 7: Own your own process

Everyone on the team should understand and be able to suggest changes to the team processes because developing great processes isn’t the preserve of experts or coaches.

We are often presented with a world of experts. Arguments about some subject or other are perceived to have been won by one side and lost by the other, the losing side being vanquished, the winning side attaining or reinforcing their expert status. In this sort of environment, self-confidence can be a difficult thing to come by.

Let me be clear: there are plenty of things (quite possibly everything) that other people are far more experienced in than I am. There are subjects so complex, and about which I understand so little, like medicine, that I would normally abdicate any decision-making to the nearest expert. If you watched the Feynman video from an earlier post, I am unlikely to offer any useful theories on the nature of the universe and I would not care to venture any guesses.

However, when you practice in a field every day, and when you care about what you do and you work hard at it, you should not feel like you have no right to offer a theory about it, or suggest an improvement, simply because there are more experienced people around. Rather, you should try to understand why you do the things that you do and what benefits they convey. You should feel confident enough to evaluate the performance of your processes and speak up when you think they are falling short.

You may not have any good ideas for how to improve matters. That’s okay. Provided your criticisms are in good faith (no singling people out, avoiding persistent negativity or nihilism, and so on), just pointing out the problem is a good start. Perhaps someone else in the team has an idea? Perhaps you can ask someone else for guidance or read something off the internet that will set you off in a new direction?

The point is, they’re your processes and you should feel confident enough to try to change any of them. Any methodology, or any interpretation of any methodology, that discourages this kind of experimentation and ownership with all aspects of the process by all team members is, in my view, a bad one.

I also mean this in a slightly more radical sense, from the point of view of a CTO or dev team manager. It’s convenient for organisations that employ a lot of developers to have everyone use identical processes, often imposed from above. It means you can move developers between teams and they will already know how everything works. It also means you can easily generate metrics for project progress or team performance because everyone should have the same sorts of things in their projects.

I think this is a terrible idea. Each team, each project, each month on each project, will be different. Every external constraint you place on the team with regard to how they work is a degree of freedom they can’t flex in when flexing is required. For a team to work as well as it can, everyone should share the project goals and everyone should share an understanding of the processes we’re using to achieve those goals and why they exist (which usually means everyone has to have had a hand in defining them).

I’d trade that for smooth transitions between teams any day, but of course you don’t have to. It’s unlikely that people working in the same environment will land upon wildly different processes, particularly if you practice regular cross-pollination between teams. The vital thing, I think, is for cross-pollination and uptake of good ideas to be a voluntary thing on the part of the teams. Otherwise, they don’t really own anything.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s