Agile Values: Individuals and Interactions over Process and Tools

In 2001, 17 software developers met at a ski resort in Utah to discuss a new way of developing software.  This assembly culminated in the formulation of the Agile Manifesto, a succinct compilation of values and principles prioritizing individuals and interactions, practical solutions, and customer collaboration over inflexible processes and tools. This manifesto served as the cornerstone for a paradigm shift in software development.

The Manifesto consists of 4 Agile Values:

1. Individuals and Interactions over Processes and Tools

2. Working Software over Comprehensive Documentation

3. Customer Collaboration over Contract Negotiation

4. Responding to Change over Following a Plan

Today I’m going to focus on the first value: Individuals and Interactions over Processes and Tools.

The idea here is that while we care about process and tools, when the process and tools break down or don’t work, we fall back to working as individuals and using direct interactions.

I see this often when using Slack.  Slack is great for asynchronous communication.    

However, using it to discuss nuanced or complex ideas is often a recipe for wasting a lot of time and breeding resentment.  This happens because team members will often end up talking past each other.

It often goes something like this: person A will ask a simple-seeming question and then person B will respond with a big block of text.  Person A feels that person B didn’t completely address the question and will ask a clarifying question back to person B.  Person B is now annoyed, feels that person A didn’t read their initial response, and responds by writing a new big block of text.  Then, person C jumps in to try to clarify what person B wrote. Five minutes later, the thread is 20 responses deep with everyone talking past each other.

This value says don’t do that!

Slack is great - it’s a great way to get answers to simple questions and document and share decisions.  But it is not great for driving group consensus and decision making around complex ideas.

My rule of thumb is to ask the question and if I get a direct response I understand, great!  Or if I need to ask one clarifying question and then I fully understand, perfect!  

But… if I find myself asking more than two questions or I feel like someone “just doesn’t understand”, it’s time for a quick meeting.  

Even if we’re in very different timezones - it’s better to wait a day and find a time we can all quickly chat live, resolve the question, and then document the decision in Slack.

I see a similar situation happen  frequently in the comments section of Jira tickets. In this case, I follow the same principle.  I’ll answer a question in Jira once, and if there’s a clarifying question on that, I’ll answer that too – but if I feel like the developer just isn’t understanding me or there’s more than two follow up questions, I’ll schedule a quick meeting to talk through their questions and then document the results of the discussion in Jira.

In cases where I’ve worked with developers in timezones without much overlap in working hours, I’ve used Loom [OR jam.dev!] to record screen interactions with a voiceover to help provide additional context that’s missing from a Slack message or Jira comment.

This principle applies around Agile processes as well.  I worked at a company where we did our backlog refinement at 11 am every other Tuesday.  And it was awful… the team would get snippy with each other, scope would balloon, and they often would take over an hour for us just to talk through the user stories for the upcoming sprint.

Then one week we had an engineering all-hands at 11 am and so we moved our backlog refinement to 1 pm.  It was as if I was working with a different team.  Suddenly everyone was amenable to talking through alternative approaches, thinking about how we could do the work more iteratively, and we finished up in 45 minutes!

What happened?  Lunch happened!  And the team of usually grumpy and hangry engineers was instead a well fed, clear thinking, and cheery team.  So we moved our standing backlog refinement from 11 am to 1 pm on Tuesdays.

We were still doing the process and having a backlog refinement ceremony but we were also thinking about the individuals attending and how to have the most productive time together.

Tools and processes are great; however, at the end of the day we’re people working with other people. When a tool or process isn’t working, we need to fall back to understanding the human perspective and talk with each other to find a better solution.