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.
 Wright flyer Model A - early aviation, build by small teams.
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.
The autonomous team
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.
Criteria for an autonomous team:
This group as a whole should be autonomously able to decide on and implement:
- Pricing
- Define the content of the product/ service
- Develop and design the product/ service
- Market and sell the product/ service
- Hire / fire (or add / remove from larger organisation) team members
- Negotiate & sign contracts with service providers
- Way of working, including tools used
In addition the group should have a say in:
- Branding
- Purpose of the product/service
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.
Identify current state
The first step is to figure out who is currently in the autonomous team for a service or product under development:
- Take a deck of small post-its and write down all the people who are involved in creating and delivering the service. One name per post-it. Use a broad definition of involved, we’ll narrow it down later.
- Put a red dot next to the name if that person has responsibilities/tasks outside of this which combined (could) take up more than 50% of their time.
- Next get a big piece of paper or use a whiteboard and draw a circle. Put in the inside the names who form the autonomous team using the criterias above.
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.
Improve the current state
Tools to reduce the size:
- Delegate
- Unless the service is the company, the CEO should not be part of the team. Yet in many organisation the CEO is the only person who can resolve disputes between two departments, which both have some responsibility in delivering the service. Delegating down reduces the team size and makes it easier, faster and cheaper to resolve disputes. Make this delegation explicit, so it is clear to everybody where the boundaries are. You can use delegation poker by management 3.0 to help define the boundries https://management30.com/product/delegation-poker/
- Structure
- related to point one. Try to have the profit and loss responsibility as close to the service as possible so that P&L of that unit = P&L of the service.
- ‘Servicify’ internal products. Change the way of developing shared services/resources so they are more service like. Good digital services for internal use are small, have a well documented api and changes can be made by developers who follow the service’s contribution guidelines. Innersourcing is an emerging practise which can help achieve this https://www.oreilly.com/ideas/using-open-source-methods-for-internal-software-projects, http://paypal.github.io/InnerSourceCommons/
- Dedication
- try to have everybody in the team dedicated to this project. This improves the team’s capability to optimise their way of working, structure and removes the risk of conflicting priorities, which have to be resolved by a line manager outside the autonomous team.
- Remove requirements
- The more restrictions a team has the more people end up in the autonomous team. If there is a requirement to use existing server infrastructure the members of the infra team easily become part of the autonomous team. Same with compliance to branding etc.
Peter TennekesAgile Coach