Work in large industrial corporations is defined by processes, roles and standards — centrally planned, elaborated, documented, rolled out, trained and regularly checked for compliance. In return, there are ISO and DIN stamps and everyone is happy. On the paper, anyway. You can and indeed sometimes have to ask yourself whether the actual work happens because of or rather despite the many processes. However, this should only be mentioned in passing. The question rather is whether agile organizations require processes and standards. And if so, how these actually emerge and develop.
A basic principle of agile organizations is decentralization. Small and effective units act independently towards their customers. Buurtzorg does this for example with the nursing teams, FAVI with the mini factories and Spotify with its squads or Amazon with the two-pizza teams. Centrally defined standards and processes restrict the freedom of these teams to make decisions and act independently and thus restrict the agility and the value created for the customer.
But where would we get to if every team worked differently? Isn’t this going to be pretty confusing? How are we supposed to work together like this? A few processes and standards are needed despite all the agility. For example, no sensible software company will allow teams working on a common product to manage their source code in different repositories with different branching strategies. It would be too tedious to continuously integrate all this into an shippable product. Google even goes so far as to store its entire source code of more than 16 years, consisting of billions of lines, in a single repository.
Also one wants to rely on promises of interfaces despite all agility and not to be surprised by a completely different behavior every day. For this reason, it has become common practice in many agile software companies to version and document interfaces and to constantly verify the promised behavior with automated tests. Once published, you have to be able to rely blindly on an interface and there has to be a set of automated test cases to check the interface. Quite a lot of rules and quite rigid processes for the agile teams.
One person’s freedom ends where another person’s freedom begins.
This guideline also facilitates the differentiation here. Whether one team prefers to use Scrum and the other Kanban, or whether they use an electronic taskboard while the others swear on their physical board, how they decorate their team room or which tools they use most productively, this and much more does not affect the freedom of the other teams or only little. Not storing the source code centrally or violating the stability of published interfaces affects the freedom of others, because it inevitably leads to problems in the process of continuous integration and deployment of the common product. And that will slow everyone down.
First and foremost, agile software teams want one thing: to deliver and try out their new feature as quickly as possible. To this end, they have their highly individual working methods within the team and that’s a good thing. But they also rely on rules of collaboration that have proved helpful for everyone. Agility and processes and standards are therefore by no means mutually exclusive. On the contrary, rather rigid rules are required to ensure that each team can act out its agility in the best possible way in cooperation with the others.
So everything remains the same? Not quite. The processes, standards and rules of the collective work are no longer elaborated and described in one central place and then rolled out to all, but rather arise from this collective work and are further developed by the teams together. The main difference is therefore not new processes, standards and rules for the collaboration of agile teams, but rather the fact that these arise from the collaboration and that everyone bears joint responsibility for it instead of being forced upon them as a central guideline. A subtle but essential difference.