Having worked with several teams over the years, I dare say less than 10% of the Agile teams I have worked with could be classified as “genuinely self-managed”. However, that does not mean that the goal of becoming a self-managed team is unrealistic. With an organization culture that is conducive to teams feeling empowered, self-managed teams will become a common feature.
Let me now give an idea of what distinguishes self-managed teams from other teams in standard Agile / Scrum ceremonies. This is mostly based on my experience in working with such teams.
Daily stand-up meetings
- Team members address all other members when they give their updates and not the Scrum Master alone. And this happens in a very natural way.
- Every team member is involved in the meeting and intently listening to the others’ updates.
- The team focuses on team goals and commitments so while individuals update what they did and plan to do, they also actively track (as a team) where the team is with respect to fulfilling their iteration commitments to the business.
- If someone is stuck on something, there is a clear intent to cross boundaries to help out. Roles do not become a constraint in this process.
- Teams commit based on their comfort feeling in terms of what they can accomplish – they may break stories into tasks but invariably don’t estimate effort for tasks with the intent of reconciling total estimated effort with capacity. In other words, their planning is commitment driven rather than being capacity driven.
This does not mean estimating effort for tasks and matching with capacity is a wrong thing. On the other hand, it is a highly recommended process for teams that start on Agile. However, as teams become mature they get a sense of what to commit and how much to commit based on what the stories are expected to accomplish and don’t necessarily need a detailed task break down with estimates of effort for the same.
- Past velocity data is used as an input for making the commitment for the current iteration but self-managed teams again don’t feel constrained by this. If the team did 30 points last iteration and they are comfortable committing 35 this time, they go with 35 and don’t adopt safety as a tactic. They know they can pull it off by working together as a team.
Iteration reviews / demos
- Often the demos don’t necessarily happen only at the end of the iteration as with most typical Agile projects. Business or business proxies are involved mid-iteration wherever possible. Team members take ownership for making this happen.
- In the end of iteration demos, the entire team is involved in terms of providing inputs, answering questions and so on. Team members take turn to do the demos making the commitment of the entire team visible to the business.
- Follow-up on demo inputs for incorporating them into subsequent iteration planning as well as updating the product backlog as needed (with the involvement of the PO)
While the general purpose is to reflect on the process in terms of what went well and did not go well, self-managed teams clearly focus on missed commitments and what contributed to that so they don’t have to deal with missed commitments again.
- Team members own up actions, demonstrate accountability and look up to management only when corrective actions are beyond the team and require management attention.
- Even when the team is consistently delivering on commitments, self-managed teams look for actions to achieve higher (stretch) goals – there is focus on process innovation in addition to just incremental improvements
While these are some indicators of how self-managed teams work when it comes to the basic processes, when teams are self-managed they also have more fun than other teams. Team members trust each other and truly enjoy each other’s company. They almost invariably don’t stretch themselves on a day-to-day basis, however, when it comes to meeting tough commitments, they are prepared to stretch and do so on their own (without any push whatsoever from management).