Individuals and interactions over processes and tools
We often refer to processes when talking about managing software development. Setting up processes, improving processes, having the best processes.
In one of the podcasts, Alistair Cockburn defines processes as "mailboxes and checklists". "Mailbox" is a place where you can leave a message for another person to read later; "checklist" is an instruction on how to do something. In the same podcast, Alistair Cockburn says that "processes are the opposite of personal interaction". Somehow I didn't realize that before, although even Agile Manifesto states that: "value interactions over processes".
Processes and individual interactions are two parts of a whole - communication. What's important here is "value one over another", not "replace one with another". Both elements are essential. I interpret this Agile development principle as "start with personal interactions, then introduce processes when needed".
Personal interaction:
- good for in-depth knowledge exchange over a short time;
- encourages cooperation, brings people together;
- consumes time and focus.
Process:
- good for shallow knowledge exchange (notification, status update);
- can be improved with appropriate tools;
- creates boundaries between people.
Here are a few examples of how processes and personal interactions balance each other in Agile development.
Just-A-Small-Thing interruptions
This CommitStrip was published just a couple of years ago, so I assume many people still go through this.
Bad Personal interaction:
When someone comes to your desk and asks to "do this small fix" or "do this tiny change", it would be wrong to simply reject. But these small requests tend to result in hours of unplanned work, stress and loss of motivation. Also, if you let them happen, they will come more and more. Deadlines are missed, plans are destroyed, no one wins.
Good Process:
The Mailbox in Scrum is the backlog. In our case, the Scrum master convinced everyone to send tickets to him. He also initiated meetings for backlog reviews and prioritizing. Our Sprint goals, priorities and dashboards were open to everyone. People stopped coming to developers with requests because the answer always was: "Give it to our Scrum master, and we will handle it".
Feature discussion in emails
Bad process:
We started several feature developments based only on written documentation. Developers had questions, but there was no person to answer them. We only could send an email, leave a comment, or reassign a ticket. The answer could take days. We had to proceed without full understanding, and we implemented things wrongly. We wasted time and effort, and it was frustrating.
Good Personal Interaction:
We insisted on having kick-off meetings and demo meetings. At kick-off meetings with the product owner, we could ask questions and propose solutions. At demo meetings, we showed the current state, got feedback and updated requirements.
We didn't schedule them, they were on demand, for 30 minutes at a developer's desk. We could have a focused discussion, and we also strengthened relationships.
Meeting that could have been an email
Bad Personal Interaction:
I was once at a one-hour long meeting for almost 40 developers of all levels. Even if there are ten people at a 1-hour meeting, each person potentially has 6 minutes to talk and 54 minutes to listen. It's not an effective interaction.
Good Process:
A Jira ticket. An email. Another option is to ask invitees if they want to participate in the discussion or they want to be notified about the results.
Code review problems
Bad Process:
Code reviews have their benefits, but there are also problems tied to them. They slow down the delivery. They are interrupting both for the author and the reviewer. Large developments are hard to review. Reviewer's comments can be insensitive, discouraging or even hurtful.
Personal interactions I do instead:
- If I need to pay attention to psychological safety, I give feedback in personal conversation first. This way, I make sure that my teammate won't misinterpret the tone of my comments.
- If I am not familiar with the business logic, I ask the author to walk me through it. In a discussion, I can restore their picture of abstractions and better understand the code.
- Finally, the complete opposite to code review is pair programming - anything that is written gets immediately reviewed.
Finding balance
It is amazing how processes just balance out excessive personal interactions. It is a control knob, a tool in organizing work.
If you want to bring people closer, to help them share deep expertise, turn it to personal interactions. Help people talk to each other by providing a place, time and opportunity; notice interactions and encourage the effort.
If you want to create better-defined boundaries, to make something more transparent and observable; to reduce interruptions; turn it to processes. Invest in good tools; show people how to use them; track the tool usage and do iterative changes.
Cover image is a frame from the movie "This Is Spinal Tap".
Top comments (1)
Excellent points and good examples thanks.