Protocol

“What we cannot speak of we must pass over in silence.”

-Ludwig Wittgenstein

• The problem

When I see humans performing repetitive tasks as part of a process in which the desired output is a product of some value, I am struck by how little we tend to challenge this repetition. The Agile framework incorporates continuous improvement as a principle. It encourages actively seeking opportunities to remove inefficiency, hand-offs and by extension, repetition of tasks that could otherwise be automated.

A daily scrum is an example of this. It is at the center of Agile ceremonies as an essential measure of the pulse of a sprint. Yet the repetition is clear, and while the intent is to spot problems and obstacles, the routine of “yesterday I did this, today I do that” often (in my experience) leads to a pattern in which team members are hesitant to call out obstacles, or if they do, they are passed over as part of a daily status report — a routine.

I also question the necessity of the ceremony in the first place. Anyone who has read this brilliant blog post (from 2009, but very relevant still) understands that meetings are a normal part of a manager’s day — they are the productivity. But for makers, a meeting of only a few minutes can devastate an hour of potential productivity.

But I cannot advocate the removal of the ceremony altogether because in the best possible team, it can actually achieve the objective — which is that team members hear each other and follow the meeting with a conversation that leads to resolving problems, or some kind of improvement. The scrum master in this context has little or no interaction — she provides the space, and everyone rises to the occasion. When this actually occurs, my question is: shouldn’t the next logical step be to eliminate the meeting altogether? Isn’t the goal to transcend the meeting and let the team organize how to best communicate around challenges, which may be asynchronously, in a shared chat, or just leaning over to the next cubicle?

No, that does not work, at least not beyond two or three people. There is too much risk of chaotic, interruptive communication.

So the meetings persist. They may be made more efficient. But what I frequently observe is that the routine over time can normalize achievements, obstacles and risks. Then there is what occurs when a scrum master actually has to ask the three questions. This gives way to another anti-pattern: resignation of responsibility due to the belief that someone else is keeping track. Someone else will solve the problem. And in a world in which scrum masters do not actually write code or user stories or test cases, it is very tempting to feel that one’s salary is justified when there are problems to fix, even if at best one is just dispatching problems to people who actually can fix the problems. If we reach the Agile endgame and teams function as perfectly humming self-organized machines, the scrum master would do incredibly little. Try to justify that to a customer who is paying for the role on a project at an hourly rate.

The paradox: a scrum master creates a dependency instead of autonomy in order to be a “good” scrum master, and team members are encouraged to outsource basic communication tasks.

An extreme of this pattern is the scrum master asks for updates as a form of productivity. This leads to status update meetings, which allows the scrum master to update tasks on a board instead of the person who completes the task. This becomes a layer of abstraction away from the work, further from the truth.

What if we actually look at code repositories and find out what is really happening? We can, and there are platforms that try to translate this into something digestible, but they most often err when they bend the truth to fit what we already have in a project plan, task board or other visual tool.

• The Protocol

In 1991, Hypertext Transfer Protocol was first documented as a way to get information on a page from a server. Its roots go back to the coining of the term “hypertext” in 1965, which in turn was influenced by concepts around media retrieval and management from the 1930s . What is intriguing is how simple methods such as GET, POST, PUT, DELETE have endured as a fundamental part of modern system architecture, with error handling known far beyond the domain of programming (404 page not found, for example). The list of methods and standard errors are succinct, intuitive and perform the communication tasks that allow servers, services and browsers to work in harmony. I think it is elegant in its simplicity.

Such is the case that when I interact with people on a development team, I try to keep my communication as standard as possible, and asynchronous as well (just like a RESTful API). Everything necessary to understand and consume my communication should be contained in one post. I do not need a synchronous session with a live audience. We just need to agree on the methods, the syntax.

This agreement is a standard set of messages that will be exchanged by the team, using an agreed upon tool or platform (a Slack channel or channels, for example). I would even extend this into speech: a standard lexicon that could be recognized easily by a machine.

If implemented correctly, it is far more appealing to development teams than the interruption of a meeting which must occur in real time. It removes the ambiguity and improvisation that is both very normal human behavior in verbal communication as well as disruptive to productivity when an answer should be as brief and precise as possible.

Most important, it automates repetitive human behavior that leaves room for error, inefficiency and waste.

Improvised and completely non-productive human conversation is what makes us human. By automating (or at least standardizing) the necessary human conversation related strictly to developing products, we create more space for this human conversation, not less, while achieving greater productivity and precision in our software development teams.

This is part one of three articles related to the foundation of an extremely lean, result-driven methodology: Protocol, Product and Architecture (PPA).

Lucas Hendrich is an ITIL® Foundation certified technology professional and co-founder of gitbetter.io.

Click here to join our mailing list.