Answers to Some Questions About Teams

What about work planning?

In step 7, Decompose each capability into a set of features to be concurrently developed, we explain an approach for decomposing work into smaller grained features. We do not specify a precise process for doing that however. That is intentional, because the best approach depends. But here are some possibilities to consider:

  1. Whenever a new capability is defined, meet soon afterwards with a small group and brainstorm on how to decompose the capability.

  2. If there is a product design team, they can work with a technical lead to decompose a capability into smaller implementable features.

  3. A business domain subject matter expert could “take a stab” at defining a set of features, and then circulate it to the tech leads of the various teams for the product.

You should consider these ideas, as well as ideas from other sources, and craft an approach. Try it, and then adjust, until you have an approach that works well.

One approach that we do not recommend is a comprehensive session that involves everyone. That is wasteful, and most people do not stay engaged in such a session. Too many developers today complain about “backlog planning” sessions taking too much time of their time.

How do multiple teams coordinate?

Ideally teams coordinate on their own. Unfortunately, that does not always happen unless a strong expectation is set, and even then it often does not happen. This is because people are under pressure to get things done, and they might feel that they will make more progress by focusing on what they can do, and leave a blocked issue to languish. They might want to raise the issue to others, but in their business, they put it off. That is why it is important for leaders to be checking in and asking questions.

Regardless of how an issue gets raised, involving leaders is often very helpful, because leaders are often able to get the attention of other groups that are also under pressure. A leader also often is aware of broader implications of an issue. In addition, leaders should always be notified when there are new issues and what is being done to address them.

Teams coordinate when they have a need to. They usually need to at the start of a new type of work. That is so that they can agree on how the work will be done, and how it will be divided up among the teams.

Teams also need to coordinate when new issues arise unexpectedly, which is a frequent occurrence during product development.

There is an ideal in the Agile community called a “self-managing team”, or “self-organizing team”. These are similar concepts. The basic idea is that teams are most effective when the can take care of issues on their own, without having to reach out to other teams, and—especially—not have to wait for other teams.

Unfortunately, for complex products, it is rare that teams can operate with full autonomy. Autonomy is something to strive for; but if you need to coordinate with other teams about things such as testing strategy or how shared microservices will work, then those teams are not fully autonomous. Partial autonomy is the norm.

When teams identify dependencies between their work, it is crucial that they not stop there: they should define strategies for managing those dependencies. An ideal strategy for managing dependencies allows teams to work in parallel without having to wait for each other. That usually entails occasional or frequent synchronization of their work. It also best includes some up-front discussion about the work, so that the separate teams do not unintentionally undertake conflicting approaches.

See the article Managing Dependencies.

What about the team norms?

Teams norms are agreements among the members of a team about how they will work.

People should have agency about how they work. Thus, norms should not exist to impose the personal preference of the majority: rather, norms should be limited to what is needed to enable everyone to coordinate and sync up in an effective manner.

What about Definition of Done?

A definition of done (DOD) is an agreement about what is needed in order to consider something to be fully “done”, in that it can be released for use.

For product development, a DOD is not a team’s decision: it is a product-level decision.

A DOD can apply to a product feature or to an entire product capability. A feature is not done until it has been shown to work in the context of the system. A capability is not done until it has been shown to meet the requirements of the capability, in an actual field test.

A task can be considered done based on any criteria: tasks are things you check off. Features are things you rely on to actually work. Capabilities are things that inform you that the product is effective in some way.

Is there a Product Owner?

Product owner is a role defined by Scrum. Constructive Agility is not Scrum, and we do not encourage having such a role because the role is very problematic:

  • It assumes that there is only one development team: that assumption is often wrong.

  • If there are many teams, and each has a product owner, it is unclear who the product decision-maker is.

  • If there is one product owner overseeing the product for many teams, then the assumption that the product owner can spend a lot of time with each team can be impractical.

  • The product owner role assumes that there is an individual who knows what the product should do.

Agile 2 advocates considering using a product design team, and to include real users in a collaborative process to define what the product should do. It is often more effective to have a product manager overseeing the conceptualization, development, delivery, and marketing of the product.

There needs to be leadership with respect to the overall product. All the usual considerations for leadership apply: one needs advocacy, effective decision-making, inspirational leadership, organizing leadership, Socratic leadership, and so on. And the categories of issues that need leadership include business and technology and perhaps others. See Engineer the Leadership.

What about standups?

A standup is a meeting: it is actually a status meeting, since the common topics of what one worked on the day before, what one plans to work on today, and is anyone blocked are status report-outs. Indeed, it would be hard to more precisely define the agenda of a status meeting.

Our guidance is very much against status meetings. The status components of a standup could be sent in by email, a message tool such as Slack, or other means. And if someone has an impediment, they should not wait for a status meeting to mention it.

But standups also have a motivational value for some people. Some feel that getting everyone together is inspiring.

It is also common that teams use standups for other purposes, such as sharing and discussing issues that have arisen. If the discussion requires a lot of time, it might be wise to hold it for afterwards, but sometimes a brief overview of an issue and resolution of the issue is beneficial for the team.

So it depends. A team should collectively decide if standups are beneficial for them. Some people find the standup extremely disruptive: for some people, the alleged 15 minute duration actually results in 45 minutes of lost focus. But we should not generalize. What we most strongly recommend is to not assume that having a standup is a best practice: rather, determine if it is helpful for the individuals who are on the team, because people vary. Ask them what they think.

Do teams have a Scrum Master?

The Scrum Master role has changed significantly more than seven times. The question then is “which Scrum Master role? - the one defined today or the one defined last week?”

One thing is clear: a Scrum Master is a leader. A leader is someone who has influence, and a Scrum Master is definitely intended to have that. So we need to ask, what kinds of leadership are needed on a team, and does the Scrum Master role provide any of those?

We also need to consider what to do if a team’s Scrum Master provides some of the kinds of leadership needed, but not others: then what? Does the team need an additional leader? Should we just assume that a leader of that kind will arise?

What we recommend is to decide what kinds of leadership are needed on teams, and go from there. Do not adopt the Scrum Master role without considering if it is what you actually need. Having the right kinds of leadership is key: it is the most important thing of all. Read more about leadership styles in the Engineer the Leadership.