Alignment and Autonomy in Agile

Both alignment and autonomy are two different things and both are required for agile teams to succeed.
Agile is the right mindset, methodology, or approach to enforcing interactive communication, and continuous improvement. There must be committed and continual engagement from the customer/ client/business. They must be part of the WE. To deliver products/services exactly what customers need, with outstanding quality, usability, and experience. In practice, alignment or autonomy, which one is more important for Agile success?

Both alignment and autonomy are very important. The team should be as autonomous as possible, and the stakeholders should be well aligned. Either failure would create a big problem for the development. Alignment on key things is critical for autonomy at scale. The extremes to both ends are either total chaos, anarchy or dictatorship. This is the similar notions of centralization vs decentralization. While organizations favor decentralization in an Agile world there are cases where economics, need for consistency, and scope of impact may push some decisions to a "higher authority."  And teams that are well aligned on the 'what' and the 'why' are much more able to be very autonomous on the 'how.' It means they can determine which languages, tooling, development approach type decisions such as Scrum or Kanban or something else, etc. are appropriate to use. The disciplined approaches are important for Agile success, but sometimes intuition should take precedence or you fall back into "Best Practice" blindness. if you are aligned with other teams on bigger shared goals, you don't lack autonomy, but you agree to support those goals. You may make them a priority.

It's all about trusting and empowering teams, the nature of the project. For some goals, chaos and varying opinions are a good thing, because new ideas are more likely to come out of chaos and a diversity of people and opinions and more autonomy. This is important in early R&D work and very hard problems. That same chaos would ruin a project if different groups each with their own methods not collaborating with each other, or the project is in crisis mode and acting fast may be more important than choosing the perfect solution. In those cases, having a bunch of people argue the minuscule merits of one option or another will slow things down with little advantage. Sometimes the balance point isn't where we might think, but it's a fair bet that either end of the scale isn't where we want to be, whether anarchy/dictatorship; totally independent/perfectly aligned; chaos/discipline. If there's a contradiction, or if the team must choose between the two, then clearly the organization doesn't have alignment.

There is a need for alignment, consistency and adhering to central norms for architectures, tools, coding norms etc.. So typically to that extent, individual teams are not completely autonomous as they would be in a single team agile set-up. The key is simplicity (or lack of it), especially in ecosystems, it should not be very hard to find competing priorities forcing decisions in favor of one choice over the other. For example, it could be that when architecture becomes too complex, refactoring is neglected even more by some teams (call it someone else's problem). Complexity is one cause for the divergence between alignment and autonomy and there may be others. And in certain situations, we may address only some aspects of autonomy until that advantage is also lost. There is a symbiotic relationship between various teams across the organization which leads to the realization of higher goals (such as keeping the organization alive and growing). It is helpful to visualize concepts and relationships in relative to each other, this way of looking helps to appreciate that autonomy and alignment are not rivals but two faces of the same coin, where there is alignment (as an organization) then autonomous action ought to be possible while still aligning with an organization’s vision.

Agile is a set of processes and methodologies. But in the big scheme of things, it's just another tool to get things done. Agile methodology is first and foremost about delivering early and often delivering the most valuable software soonest. If some agile shops have drifted from this primary value, then it's not a new methodology they need, but perhaps some serious readjustment. To follow accountable agile, one should always work in agile using the requisite structure in an organization, practicing agile requisitely makes it very powerful, It is more accountable and becomes very strong in management.

Posted in: Agile