First Needs — Why best practices and golden ways are a myth (often)

Business media is full of it, proposed “golden” ways of working, particularly in the field of IT. Admittedly it is an inviting field, given its collaborative, dynamic nature in the process of building larger structures (software), covering shared goals and the potential for chaos, failure. Wouldn’t it be nice to impose a widely accepted structure to reduce risk?

Job advertisements sometimes even require experience with a particular way of working, one of the most prominent nowadays being agile. The following shall dive into why this is nonsense, why talks about the best process framework is pure marketing while the focus remains on the wrong spot. And we’ll talk about simple adjustments that can bring you on the way to enjoyable, productive processes.

Missing the root

World out there is full of fanboys of particular process frameworks, such as SCRUM, KANBAN, Waterfall or ways of executing units of work, such as pair/mob programming, test-driven development (TDD) and others. So whats wrong about that? In the end they provide structure, potentially reduce chaos and establish some desirable properties. Some even seem indispensable, such as having a proper test-coverage in your code-base. That is a good general rule, yet especially in purely explorational work it can make sense to temporarily loosen the requirements.

What I’m missing in those discussions is the scope. Yes, much of the above can provide some great tools, which work in varying amount of situations and might even work in nearly all of em — any particular way of working might still be sub-optimal to your or your team’s need. Lets soak this in: all of the above are neither gold standards, best ways of working or needed in any way. What they all are is this: a tool. And a tool should never be the focus.

a tool should never be the focus

This also means that you will never get an optimal or near-optimal process if you’re circumventing the work of the social negotiation process in your team, that is finding the best tools for your particular setting.

What to avoid:

• start organization of your processes by setting any framework (whether that is SCRUM, KANBAN, or any other). They are tools, and we dont decide on using a hammer before we decided what were going to build with it and what resources (team) we have available.
• do not make experience with any framework a hiring criterion. Decide based on who fits your team. Mindset and fit is way more important than any knowledge of the above (the latter in doubt can be acquired easily within a few days of working together)
• do not put someone in charge to decide on the processes to follow, especially if focused on tools rather than flexible adjustments to the setting, using tools. That is a team job, usually involvement of other parts of the organization should not be needed. It can be super valuable though to have a process expert in the team (such as open-minded Scrum Masters or similar, ours is great (you know who you are))

Guiding Scope — First Needs

What you’ll often find in accounts how fundamental solutions are found is the concept of first principles. That is: breaking down complicated problems into their basic elements to grasp a problem from its root instead of higher-level assumptions / derivations. The latter is what you will often see in companies when a decision on processes is made. The former has the potential for much better solutions though, spanning from within-team dynamics to across-company meeting culture. I’ll call it first needs.

How does what is often observed translate to the first needs? Lets see some examples:

• “we need dailies to keep up communication” translates to “we need to communicate/align frequently and raise issues early, whenever this applies”
• “we need a big meeting with everyone involved since the topic is very cross-functional” translates to “we need to understand the topic and dependencies better” (and thus a big meeting with everyone is the last thing you and the others need)
• “we need a big meeting to have issues made visible in time” translates to “we need direct, efficient communication channels scoped on involved parties to quickly resolve issues”
• “we need a team-retro to discuss potential issues within the team or company” translates to “we need open, honest, direct communication. We need to celebrate constructive criticism at any time”
• “we need a 2-week sprint” translates to “we need to understand when others expect something from us that we agreed on, what the team agreed on, and with this information we need a clear scope of work to proceed effectively”

Take your team’s first needs to select the tools that fulfill them, not the other way around. You should be open enough to sharpen any tools you use, and this might mean ending up with little leftover of the tool itself. No time for fanboys or conservative rule-enforcers.
If your team feels good, has no unfulfilled first needs, works efficiently, yet replaces all regular ceremonies with bongo-drumming and dancing around the fire, so be it.

“If a man loses pace with his companions, perhaps it is because he hears a different drummer.” — Henry David Thoreau

Summary

There is an awesome lots of great tools out there to guide your team’s way of workings and ensure good quality developing software. I’m thankful how far this has come, making work much more pleasurable and effective. Yet its easy to fall for so-called “gold standards” or “processes marketing” that drives a whole industry of certification providers. Knowledge about available tools is valuable, but worthless without the ability to adapt to the setting and needs at hand.

Identify your first needs, then select the tools, not the other way around.