The Myth of Scrum Team

The myth of scrum team

The traditional descriptions of the scrum team say: it is dedicated to a product, crossfunctional, and has three scrum roles: product owner, scrum master, and team members. Scrum introduces the timed team interaction structure: sprints, sprint meetings, and standups.

The core of good planning is product backlog refinement, user story analysis, definitions of ‘done’, stakeholder involvement, continuous improvement through reflection and retrospects, etc. Beyond that, scrum does not quite tell you what to do. It says the teams are ‘self-organizing’ without being specific on what it means: scrum is agnostic to any actual process, design, or development methods, which are outside of scrum and left to the self-organizing team or the parts of the organization outside of the team to choose and manage.

The good read, Dave Nicolette, Limits of a self-organising team, demonstrates how vague the meaning of “self-organising” is and gives an overview of what is and what is not up to the team itself. The combination of vague term and belief that imposing scrum onto a team would work on its own. Then, in large organisations, the team self-organisation often quickly becomes the thinly veiled old relationships, and in small young startups, the original chaotic lack of structure prevails.

The Myth of scrum team: if an organisation adopts scrum, the effective product team will emerge, given proper coaching and organisational support.

What does self-organization mean?

Clearly, scrum does not cover all the software process: design methods, continuous integration, etc, let alone specific software skills. Scrum’s purpose is timing, planning, and minimalistic structured team interaction. However, it is a mystery how the ongoing communication inside of the classical scrum team of up to a dozen of people is vaguely described as “self-organization”. Even a couple of software engineers notoriously and quickly go out of sync with each other, often in the matter of hours.

Therefore, what does scrum team self-organization means at all? One could say: self-organization is what is up to you (with the understanding what is not). That’s the angle from which Dave Nicolette’s article mostly treats the subject.

Let’s step back a bit in establishing what self-organization means in the scrum context. In software (or maybe even generally in commercial enterprise), self-organization is not a goal in itself. Unless it serves a purpose, why bother. Thus, the meaning of self-organization in the scrum context is established through its use.

Both theory and practice of scrum show that in principle, if you have up to a dozen of diligent engineers, with a hyper-active product owner and scrum master, you totally can run very well-planned, flexible, satisfying, and successful projects. The problem is that, depending on the team size, the product owner and scrum master would need to spend half or most of their time to make sure the process is followed, definitions of ‘done’ are satisfied, backlog refined, etc.

In the team of 3–4 people with a good project owner and scrum master, one could afford to worry very little about the team self-organization, but in the teams closer to a dozen, the time and context switching of the owner and master become a productivity bottlenecks, a blockage in the lean value flow.

Team self-organization (apart from the lateral benefits) is meant to unblock it. That’s the usage and meaning of it in the scrum context. It all is about the mechanisms of team interaction, of which, apart from the scrum rituals, scrum seems to be silent.

Is scrum agnostic about team self-organization?

This silence creates an impression that scrum is agnostic about self-organization: it is up to the team, as long as the team has the capability to tell what is and what is not up to them.

However, I do not think scrum is silent on the matter. Instead, it stays lean, permissive, and minimalistic. Additionally to looking for the answer outside of scrum and adding other methodologies (e.g. kanban, or XP) into the mix, the question is whether more specific team interaction structures could be deduced from the scrum process itself.

Artefacts, user stories, implementation stories, users and owners

User story combined with its definition of done is the value-producing dimension of scrum (and arguably of any agile or lean approach) along which informs all of its other practices. User story expresses a deliverable in user’s vocabulary, while the definition of done is the companion “implementation story”: what is it that needs to be done so that the user would be able to say “as … I want to … so that I can do …” (see Modeling bias for more). User story + implementation story represent deliverable artefact.

A common distortion of scrum is activity bias: the definition of done replaced with action items, e.g. “unit test” as a part of the deliverable replaced with “write tests of such and such”, seemingly the same statement, which nevertheless subtly shifts the ownership from owning the unit test to owning the action of writing the unit test, which loses the view of user-owner relationship: The user story has nothing to do with the action (“write unit test”), unlike the unit test itself, which represents a kind of “standard” user story: “As a pilot of the plane, I want to be able to meaningfully report software malfunctioning, so that its cause is quickly identified and fixed.” (Sometimes, it is reasonable to cut corners there: “As a player of this cool online game, I give no damn if it malfunctions, as long as reload button in my browser fixes it.”)

Artefact needs a user (or, much better, two users — to express at least two use cases for semantic triangulation) and the owner: the person or a group who satisfy the definition of done. This is essential microstructure defined in scrum, and my point is that exactly this microstructure informs scrum team self-organisation, as much as scrum is concerned. This user-owner relationship at the level of each artefact on the backlog does not necessarily emerge on its own.

It is necessary, but not enough correctly identify the users and owners. The usage of the artefact throghout its life cycle is in continuous negotiation between its users and the owner, which involves (and really is the purpose of) all scrum ceremonies as well as design sessions, code reviews, demos, etc. For example, I always design a product, or a tool, or a utility through its usage, both with the clients and other engineers. When I have a design session with a colleague, we sketch the artefact usage, e.g. — help for a command line utility with usage pattern, not just an “interface”; one of us in fact plays the user role and the other the owner’s.

Nurturing and maintaining this relationship for each backlog item may be the most important skill and duty of the scrum coaches, product owners, and scrum masters. The more continuous, fluid, casual, and distributed in the team the user-owner relationships, the more self-organized the team is in scrum sense.

Users, stakeholders, clients, and owners

Users of artefacts always are stakeholders, but not the other way around. They also are not the ones who tell user story (which may come from marketing or a business analyst — although eventually, direct connection between the actual engineers and actual users is the best). Users are those about whom the user story speaks: “as a plane pilot, I want to …, so that I am able to …”.

The status of the user and the owner of an artefact creates familiar situations with which the product owner and team leads or scrum masters need to deal to distribute the user-owner relationships in the team:

• The owner and user of the artefact are on the same scrum team. For example, a software engineer (owner) puts together a tool for a hardware engineer (user), or a library for another software engineer on the team. The great thing is that the user is as committed as the owner, since often it is hard to engage with the users. The drawback is that since both engineers are on the same team, their user/owner relationships tend to be too informal and unstructured. The product owner and scrum master identify internal users. The daily standups are a good opportunity to trigger the one-on-one usage design, reviews, demos, etc.
• The artefact owner is a team member, the artefact user is outside of the scrum team. Therefore, the artefact is an external deliverable as a part of the product. The product owner identifies the user and organizationally builds the peer-to-peer relationship between the owner and the user. Ideally, they should regularly have face-to-face design and review sessions. Most often, it is a relationship with a slower turnaround. Ideally, the user should be continuously available, but at least the turnaround period should fit into a sprint to be effective.
• The artefact owner is not the team member, while the user is. It is a spectrum where the artefact owner could be in another team (which is against the grain of scrum, but is a typical situation if the team is not completely crossfunctional or, more importantly, there is any degree of reuse in the organization. Also, the owner could be a more or less responsive maintainer of e.g. a commercial or free third-party library. If peer-to-peer relationships with such an owner are limited, the usage needs to be designed around those limitations. Such situations also need to be identified and articulated explicitly.
• When both the owner and the user of the artefact are outside of the team, it means that in respect to that artefact, the team acts as integrator. In this case, to preserve clear owner/user structure, the integration artefact could be devised, by answering the definition-of-done question: “what is it that the team needs to do to take the code from the outside owner and pass it to the user to the latter’s satisfaction?” This would split the user story into two, one with external owner and internal user, the other with the internal owner and external user” (both cases are described above).

Conclusion

Although Scrum does not formally define self-organizing team, it is not agnostic about the meaning and structures of the team self-organization. Scrum is minimalistic and silent on the matter, but its value flow (through user stories) and bottlenecks (product owner’s and scrum master’s overhead) imply that, as Scrum is concerned, the team self-organization means delegating user story treatment to all team members. The form of this delegation is user/owner relationship explicitly articulated and continuously maintained for each user story.

The product owner and scrum master (as well as senior — in terms of experience and initiative — team members) is to continuously build such user/owner relationships as well as watch and repair them, if they start disintegrating, often due to the entropy inside or outside of the team, by means of daily standups, reviews, demos, facilitating peer-to-peer relationships, etc.

This micro-structure replicates Scrum roles in miniature and permeates team work. The team working on a product is composed not of the atoms of individuals with certain roles, but of dynamically formed user/owner molecules. There dynamics rarely occur naturally. If these dynamics are consciously and continuously maintained, you could call the team organised. The more this effort is distributed in the team beyond product owner, the more self-organised is the team. Scrum tells you that it needs to be done, but does not tell how.

Note

The user/owner relationship around the user story and asking the question “having such and such technical capabilities, what is it that we should do for the user to be able to realize his story?” maps into or rather stems from semiotic structures reflected for example in the notion of semantic-pragmatic meaning-use relationship introduced by Robert Brandom; see more on it in: Architectureless design