Development Teams, Write Your Own Rulebook

All software development, no matter how flexible or open-ended it is, is governed by rules. Even agile development is built with rules in mind: design, define, build, test, release. Agile builds on the idea of iterative improvements and emphasizes responsiveness and interaction.

That’s not easy to do with centrally managed tools and processes. If the buck stops at some higher authority, individual teams lack the tools and motivation they need to constantly hone and refine how they work. So, thriving in Agile isn’t so much about getting rid of rules as changing where they get made — decentralizing the decision-making process.

The value of decentralized decision-making is becoming more and more obvious. The growing prevalence of Web3 and of Distributed Autonomous Organizations (DAO) is proof-positive that autonomy and transparency are no longer simply philosophical positions: they are practical principles.

And to be agile in a decentralized environment, development teams need tools that give them control over their own processes. Those tools must provide:

• The ability to make local changes
• The information to inform those changes
• Autonomous processes to link individual teams together cohesively

Local modularity encourages iteration

Obviously, every development team is different. The number of possible differences is near infinite: teams can include different numbers of people, people of different ages, with different levels of experience, with greater experience in different programming languages, with different experience working in teams, with different skillsets, etc. All of these factors (and the bajillions I didn’t mention) will affect what rules work best for that team.

So, while the broad strokes of development may be the same, trying to paint every team with the same brush is a mistake. But that’s what happens when processes are centrally managed.

Everyone marches to the beat of the same drum. That works well enough in a marching band, but in the ever-changing world of software, it just discourages teams from the iteration that’s so critical to Agile. And trying to blanketly apply changes across teams is self-defeating. Changes that benefit one team may hinder another.

But if individual teams can tweak their own processes, they’re encouraged to constantly iterate and tweak to improve those processes. They’ll see the results every cycle, and by making their work more efficient, they’ll be constantly making their lives easier by playing to their strengths and compensating for their weaknesses.

Of course, not every team has leaped into Agile with both feet. That’s fine. If the tools available enable teams to adjust their processes as they go, teams can incorporate Agile principles and practices as it makes sense for them. Trying to shoehorn in Agile practices more aggressively than teams are ready to handle can backfire.

That’s why we designed Zenhub with customizable workflows, boards, and pipelines. We built it in line with light-touch Agile principles but gave teams the power to iterate as they see fit.

Local information ensures intelligent iteration

To effectively iterate, teams also need access to information on how well things are working. After all, if you want your teams to make intelligent changes, they need intelligence about the processes they are using.

But in a centrally managed system, individualized information will take a long time to make its way back to the teams that need it. Most of the time, it’ll probably be averaged across teams. This leaves teams facing two unfortunate possibilities:

• Having to wait a very long time for actionable data on their processes (if they can even act on that data)
• Getting an average of multiple teams’ data

The problem with the first scenario is that by the time the information comes back, it may not even be relevant. Processes may have been changed already.

In the second scenario, teams may receive a muddied picture. The averaged data may not accurately reflect the situation for any one team. Teams are unable to identify either strengths or weaknesses.

To effectively iterate, teams need access to accurate information, in real-time. Therefore, tools must provide local information. This makes the information more relevant in both timing (since it comes back quickly enough to still be usable) and in accuracy, providing teams with what they need to evaluate their processes and implement improvements.

Zenhub’s productivity insights are designed to put this information front and center so that teams have what they need to evaluate and improve their processes. For example, productivity insights will let you know how long issues are in cycle on average, both in development and review. It will then let you know whether your team is on track based on this data so that you’ll know if your team needs to streamline its review process. Similarly, productivity insights can identify anomaly issues that took much longer than the average cycle time to complete. Your team can evaluate these issues and determine where the bottlenecks are so that they don’t happen in the future.

Workflow automation keeps individualized teams coordinated

Hybrid and remote work are facts of life today. Developers, especially in the open-source world, are working asynchronously and in different geographies and time zones. In this environment, coordinating everyone on a single team, let alone multiple teams working together, has become that much more complicated. The solution? Giving developers the choice to decide how they want to work.

To make it work, development teams need tools that make their lives simpler. Development is a complex enough job on its own: trying to manage the logistics of a half-dozen different time zones in one team, and handoffs between teams with different processes and workflows, practically requires a graduate degree (not to mention the cost on your time and sanity).

This is where automation with carefully designed features can play a role. Zenhub planning poker is a great example. It enables teams to asynchronously evaluate issues before sprints begin. It can shorten or even eliminate meetings, sparing everyone the tedium of even just trying to get the meeting organized. Having this option is a core part of giving development teams the autonomy to decide what meetings they do and don’t want to have.

And the automated handoffs built into Zenhub allow for tasks to shift seamlessly between teams. By setting up linked pipelines, teams can be sure that a project only changes hands when it’s supposed to. This means that teams can independently, however they want to work, without having to worry about other teams. By auto-propagating the information, teams can eliminate the tedious copy-pasting work that can introduce errors and confusion.

Zenhub gives your team the tools to succeed

Ultimately, Zenhub gives development teams what they need to be agile in a decentralized environment: control over their own processes.

Built to align with Agile principles of decentralized autonomy and local decision-making, Zenhub provides the tools development teams need to constantly iterate and improve without oversight. Working in GitHub, developers can eliminate busy work and focus on the work that matters. They can eliminate meetings and leverage automation to work together more seamlessly than ever, even if the team is fully remote.

Try a free trial with Zenhub, or check out our blog on keeping dispersed teams aligned and productive.