Don’t be precious with your process

Every few months, after a project retro or a particularly hard week, I come back to the agile manifesto.

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

“Individuals and interactions over processes and tools” always makes me reflect: what is the point of our process? Do we want to be capital-A Agile? Are we tied to our sprints and meetings and Trello and Slack? How do we get where we actually want to go?

Process methodologies argue about the best way to achieve organizational fluidity, but their goals are the same: to help a team respond to problems quickly. It’s easy to let tools and processes get in the way of solving problems — to lose the objective forest for the process trees. Executing on your process becomes the ends rather than the means to a solution.

Our project team started small on a six week prototype — me on design and strategy, Michael Morrissey on design and development, Lennon Rubin on development). For the first four weeks, we relied on in-person discussions, Slack and weekly retros. Two and a half weeks before our deadline, requirements shifted and three more people joined our team adding thoughts and ideas to the project. Our lean process was failing under the weight of new voices.

I rushed to implement sprint planning to get on the same page, Trello to track what everyone was doing, acceptance criteria on every task and daily stand ups. I spent an additional 15 hours on project management that week, time away from product refinement. Was it worth it?

Confusion. Frustration. Anger. That was what followed. No one knew where to look for ‘the truth’. Decisions were made between two people on a side channel. Trello became a dumping ground of half-baked ideas and half-done tasks. We spent an entire Monday just trying to get on the same page.

So we iterated on our methods, we reviewed the one-size-fits-all processes I had put in place. We defined Slack threads as the location for discussion, decided Trello would track any decisions made, and agreed upon a leaner and integrated way to run the project as a team. This took just one hour on a Friday.

With our new approach, we shipped a great prototype in our six week time frame. And there were a few surprises: our team was happier at work. We designed and developed more creative solutions. We worked faster and shipped higher quality work than even we expected.

When I have a hammer every project looks like a nail. So I force myself to step back and look at the project as process-agnostic, asking myself:

• What are the problems facing your team right now?
• What processes are helping you?
• What processes are hurting you?
• What are you doing because “It’s what we do”?

Then we iterate. As a team, we address those problems and find solutions that we can all agree to.

• What is the lightest-weight process we can put in place to fix Problem A?

Finally, we can decide how successful we were and iterate again.

• Are you faster at addressing problems as they arise?
• Are you faster at developing a solution?
• Is your team happier?

Successful team culture is hard to pin down and process can act in service to or can undermine a good team. But from what I have experienced, fluidity is a worthy goal. Wherever your team starts and whatever your team’s expertise, try something and learn from it. Don’t decide in a vacuum! Ask your team, decide as a team, and iterate as a team.

The right methodology for your team is the one that you all agree to share, and that actually increases your collective creativity and capability.

Special thanks to NOBL for jumpstarting lots of these ideas in my head.