I recently was helping one of our customers with the development of a new and innovative service. The setup was agile with scrum master and all. The organisation was, unfortunately, unable take full advantage of agile development due to the organisational structure surrounding the agile team. As an example, the team’s work was across multiple business units. Resolving fairly simple issues required a meeting with very important, valuable and busy senior managers. This meant long delays and a huge pile of frustration with no clear benefits, the senior manager having little or no first hand knowledge on the topics. This is unfortunately not unique, but avoidable. I hope this article helps you to see your organisation in a new light and adapt it to take more advantage of doing things agile.
One of the biggest differences between a startup and an established enterprise developing a new service is the size of the team doing this. In a startup the amount of people is only increased if the current team cannot do the job. In an established organisation you start with a group of people who are assigned to work on a new service. In addition there are management and organisational structures already in place in which the new service development is embedded.
The net result is that a startup develops a service typically with less people than an enterprise, even if the service for both organisations would be identical. And this is where it gets critical - the size does matter. More people means more complexity, less ownership, more coordination, resulting in reduced ability to respond to change and make decisions. This in turn translate in longer time to market, less time to find a product-market fit and a lower amount of innovations your organisations can do.
Read more on the benefits of small teams.
I hope you agree with me that there is value in trying to decrease the team size developing a new service. Lets now talk about how to go about the task of reducing the team size.
To do this, it is useful to introduce the concept of the autonomous team. The autonomous team is the group of people who can, without depending on people outside that team, create the service or product. Below is a list a more detailed list of criteria.
This group as a whole should be autonomously able to decide on and implement:
In addition the group should have a say in:
Dependent services: People working to deliver services/products which are used ‘as-is’ by the team are not part of the autonomous team. As long as the service can be used as-is and could be exchanged for another provider.
Of course there are grey areas and exceptions, just use common sense.
The first step is to figure out who is currently in the autonomous team for a service or product under development:
You now have a visualization of the current autonomous team.
Your job as an organisation is to make this group of people as small as possible and have no people with a red dot in that group.
Tools to reduce the size: