During the last three decades, a large change has happened in the way that software development organizations are structured. Until around 2010, it was common to have a large IT organization divided into functions and applications. Each application group would be divided into functional silos: Project Management, Development, Quality Assurance, and Operations. This structure was seen as highly efficient.
Workers with similar skills were organized together into a pool. When a new project request arrived requiring someone to work on it, the least busy people in the pool were assigned. When work was completed, other people freed up and became available. The organization was viewed as a set of giant machines which were kept constantly running to maximize utilization and effectiveness.
From Silos to Teams
With the rising story of agility and Scrum in the industry, large pools of heavily utilized developers were replaced by a different organization structure: the product development team. However, because the industry had spent so much time learning how to maximize utilization, these teams are almost always implemented as a scheme to maximize utilization rather than their true purpose. These “teams” were hardly teams at all, but rather subdivisions of the large development pool with a more localized knowledge of particular applications.
What We Gained (But Only Partially)
Problems solved:
- Teams localized around a product domain did not require as much ramp up time to become effective. They knew the application they were working on.
- Top-down management assignment of work within IT organizations was simplified. Massive spreadsheets listing every project assignment across a silo with hundreds of people within it was no longer necessary.
This was progress, and many management teams have stopped here and are convinced that they have implemented agile teams by moving from large pools of people available for utilization to specified teams that are more easily controlled. However, what many have not yet realized is that utilization and management control of work assignment are also problems to solve.
The Real Purpose of Teams
Forming people into teams was intended to created the following effects:
- Collective Intellect. Teams bring together multiple minds to collaborate and generate greater problem-solving intelligence.
- Clarity of priorities and simplified cost. A single business stakeholder knows exactly which team is working on their requests, thus eliminating the need to budget work and allowing instead budgeting to focus on the product and the annual cost of a fixed-size team. Teams eliminate the need to budget work item by item; capacity is managed at the team level.
- Reduction in handoffs and queueing delays and expense. Teams are cross-functional and include all roles needed to deliver software independently.
- IT Management focuses on technology. IT managers shift focus from managing projects to managing technology and people.
- Autonomy, Mastery, Purpose, and Connection. Teams become autonomous, with no single manager controlling performance, which attracts top talent.
- Clear, shared goals. Shared objectives and self-chosen goals increase team buy-in and motivation.
- Reduced utilization and queueing to improve flow. Teams control their own work-in-process limits to maintain sustainable pace and avoid burnout. Lean principles are difficult and complex to activate at scale without discipline. A small team can easily do this if given the autonomy.
- Continuous improvement. Teams use their autonomy to drive continuous improvement, which large management structures struggle to do. People improve what they believe they own. Without owning themselves, their work, and their process, teams do not self-improve. Organization-wide improvements emerge from bottom-up ownership and experimentation by teams.
- From control to performance. The organization shifts from cost-saving at scale to performance optimization at the team level.
- Improvements to architecture. Teams naturally create loosely coupled architectures, reducing interdependencies and increasing resilience.
- Reduction in overhead costs. Teams develop unique identities and working styles, reducing the need for centralized coordination.
Because so many believe that they themselves are supposed to be very busy and that others around them are not providing full value unless they are fully utilized, systems across the globe struggle with the rapid feedback loops produced from short delivery cycles promised by the original idea to embrace agility as a goal.
Like a Sports Team
A software development team should operate like a sports team. It should be small enough that players do not collide with each other on the field. It should have players with different complementary skills so that the team is fully competent to play and win the game. It should be able to operate on the field without the coach slowing everything down by micromanaging everyone’s activities and receiving constant updates of everything happening while plays are in motion. The team wins together or loses together. There is no individual success at team expense possible. Outwardly, the team presents a united front. In the locker room, there are tough, professional conversations about success and failure. Sports teams are not budgeted by the game. They are budgeted by the team.
We Are Not Enjoying the Benefits of Teams
The way teams operate in the industry today is rarely like a sports team. They are a convenient assignment entity to simplify management control. Managers embed themselves in everything the teams do. Companies dictate process, tooling, and often even who is allowed to attend meetings or is assigned work. This is micromanagement, and it kills performance. Leaders have to choose: performance or control. Since control is largely illusory, performance would seem the obvious choice.
It’s great that we have left the large development poll behind, but hesitate before you throw your arms up in victory because you have agile teams.
