The Three Stages of Team Effectiveness
If you're on a software development team, think about the work that you do every week. What does the doing of the work look like? How often do you deliver to production? Do you understand the why behind the work you're doing? Can you influence what you do next?
We've found that all of these questions help define where a development team is on a spectrum of effectiveness. Generally, there are three stages a development team can be in on this spectrum:
- Not delivering much value
- Sometimes delivering value
- Delivering the most valuable increment of work, frequently
You may be wondering what the characteristics of each stage of effectiveness look like. Teams in stage one - those not delivering anything of value - are the most stuck. They may be writing code, but units of work are rarely getting finished. Additionally, the units of work are likely not often tied to any value that a user could realize. The team is completely detached from those making decisions about what direction their product should go. The members of the team are likely frustrated and feel unheard by those leading their organization.
Teams in the middle stage sometimes deliver value. The work they do reaches their users, and their users sometimes find value in the changes they make to their product. The work may not get delivered with a regular, frequent cadence such as a weekly deployment to production, but it does get delivered in "big bang" releases a few times a year. Things sometimes go wrong in production, and fixing those problems is a meaningful interruption to the project timeline for the next big release. The units of work that are being delivered occasionally are sliced incorrectly, such as work items to deliver an API call that nothing uses. The feedback loops to find out if the latest big release was a success are very long, or sometimes non-existent. Decisions about product direction are made outside of the team delivering the product with rare team input. There are a lot of teams that are in this middle stage. While that isn't ideal, the good news is that these teams can move to the most effective stage often with some minor tweaks in approach.
Teams in the most mature stage of effectiveness can come in many forms, however, the most important thing is that they operate iteratively. It is easiest for a team to be effective when they deploy to production at least once a sprint, and they are inspecting and adapting on the recently delivered increments to determine what experiments they should run next. The developers may not be driving the direction of the product as individuals, but they understand the why behind the problems they are solving. Additionally, they work with stakeholders collaboratively to provide input and use data to define what recent experiments worked, and what has failed. Units of work delivered almost always value that a user can realize. The team swarms around a business goal and works together to achieve it, instead of worrying about individual efficiency. Things may not always be perfect, but the team holds a growth mindset that they can always improve the things that matter.
There are shades of gray in between these three stages - teams can be in transition between them. Organizational leadership plays a part in enabling teams to be in one of these stages by setting incentives that enable behaviors and characteristics of team members at a certain stage on this spectrum. However, individuals on the teams themselves have a large role to play in defining what stage their team is going to operate in. Organizational tweaks can be iterated over overtime, but it is up to individuals to own making that change occur.
As you finish reading this post, ask yourself: What stage is my team in? And how can I improve it? No matter what stage you're team is in, you can always improve.