
When it comes to strategies for working with many different agile development teams, there are often two chains of thought – full independence and autonomy or chained interdependence that requires some amount of process and tool centralization. And while there are merits to justify both approaches, the truth is that there is no one approach and it’s often the nature and size of the business that will determine which one will work for you.
The push for independent teams
The idea behind independent agile teams stems from the desire to remove any form of overarching process and ensure teams can be focused on delivery and doing whatever it takes to perform their jobs. While it certain makes accountability for team performance clear and frees them up to focus on delivery, it doesn’t work well for companies where accountability and governance is crucial (financial industry) or large companies where having independent teams potentially redoing the same tasks is actually quite crucial.
Still there is space for this model where teams are left unburdened by any form of costly governance and bureaucracy with an easy, unrestrained development cycle and clear accountability. The team succeeds or falls by their work and there is little else to blame. This is a very popular model for start-ups where they want to be able to get functionality and features out quickly and small companies especially where this type of independence can still be easily achieved. It also great for R&D work in larger companies where these processes are not quite set.
Why Interdependence is still better for many companies though
However, much of the above is based on a few assumptions – the work teams are doing has little relevance to other teams and that process and bureaucracy is the enemy of progress. In a sizable organization (plus 4-5 development teams) the chances are that these assumptions are false. Firstly, the more teams you have, the less likely they are able to be completely silo-d and therefore it makes sense to have some common approaches, tooling and processes to ensure team operate effectively together. Secondly, it’s not governance that is the enemy of efficiency, but simply inefficient bureaucracy. Companies should look to reduce fat in their processes, but not try and cut them out entirely.
As I publish this I can imagine many people who strongly believe that autonomy is the best approach to microservice and agile software development are likely filling with rage, but allow me to elaborate further on why interdependence and process will actually benefit companies.
1) It’s actually cheaper – Having teams do their own things all the time, even if they’re already sharing tools, is expensive. Whether it’s duplicating frameworks, or worse, creating multiple different frameworks because each team is trying to do their own thing, you are creating a long term maintenance nightmare. If you’re doing R&D work where the life-span for the type of work you are doing is short, then this is fine, but outside of this, it’s going to cause long-term headaches.
2) It creates flexibility and is easier to scale – Moving team members around will always have a learning curve to it as people need to ramp-up up and get used to their new teams and products. If processes and approaches are not aligned though, this is increased greatly. For small teams it might not seem like a big deal, but in a large organization, those lost hours do not scale well.
3) It’s easier to audit – As mentioned earlier, this is critical for companies where quality and security is of utmost importance. Having process and governance are not just a good idea, but an actual necessity in these cases. What’s more, as companies grow, regardless of industry, they are going to likely to encounter some security or regulatory hurdles where this will become necessary.
So, it seems apparent that interdependence is definitely the better approach and there is a need for process and tool governance in the software development world. The important question then is how can companies ensure that they have the necessary bureaucratic oversight without creating development bottlenecks? The below pointers should be helpful for companies to think about as they go about shaping their different processes:
- Reduce any admin or meetings. Process work if they’re automated, the moment you turn them into manual activities, you are creating those expensive bottlenecks. Same applies to meetings which are often a big waste of time. Often not everyone is required for reviews and retrospectives and it’s important to minimize the waste that meetings have on productivity.
- Re-evaluate regularly. Like with anything – embrace the spirit of agility. Do you really need the process and does it add value? You’ll be amazed, at what you can trim when you apply a critical eye to it. Some process are good for certain phases of a company, but not for latter phases of a company, so don’t be complacent with what you have implemented.
- Don’t tie yourself to tools. A lot of process is often a result of tools and teams needing to work within the constraints of the teams. While this is often simpler and cheaper than changing the tool itself, it can lead to unnecessary bureaucracy down the line. This is especially costly if the tools have licenses attached to them. Don’t get me wrong, making use of tools is vital in your governance efforts, just make the tool fit you and not the other way around.
A lot of people want to work for start-ups and smaller companies to escape the bureaucracy of larger companies, but it’s important that engineers understand that there is reason to the madness and it is definitely needed. At the same time, companies need to be pragmatic in their approach to their governance structure and embrace the spirit of Agile in finding ways to streamline their many inefficiencies.
Comments