Catalyst
... the Development Team has been assembled, and the ScrumMaster has been selected. In order to function at all, the Product Owner, ScrumMaster, and the development team have to learn how to communicate with each other and how to work together. Within the Development Team, the developers need to learn how to work with each other.
✥ ✥ ✥
Scrum depends on high collaboration for its success, but collaboration doesn’t automatically happen.
The relationship between the Development Team and the Product Owner is particularly critical. High collaboration is necessary, but several forces work against it. These include the following:
The Product Owner is a key person in the team, but is not part of the Development Team. In addition, the Product Owner is doing different things than the developers. This slight organizational distance discourages communication.
In addition, while the development team is often co-located, even to the point of sharing a common work area, the Product Owner might be in a separate office. The physical distance also hinders communication.
History may play a role: an organization new to Scrum is likely to place former middle or upper managers in the role of Product Owner. Developers may be reluctant to speak with such Product Owners based on previous superior-subordinate relationships.
On the other hand, the Product Owner and the development team might not even know each other well.
Within the development team, the developers must not only communicate with each other but work together as a single team, having a common focus and helping each other out. We see the following:
Developers tend to be introverted, and are often happy working alone.
Developing is a cerebral activity — it takes time (at least 15 minutes) to get into what DeMarco calls "the flow", a state of highly productive creativity. Interruptions break the flow.
In a new team, developers might not know each other at first.
Developers can learn from developers in other Scrum teams.
Overall, Scrum is hard; beyond the mechanics of meetings and communication. You really need to feel it. Often, you need someone to help you feel it.
Therefore:
Create an environment in which team members want to come together to communicate and collaborate, as well as provide opportunities for them to come together.
✥ ✥ ✥
What is meant by environment? First, it is the physical and organizational conditions that foster communication. Second, it is intellectual conditions that facilitate obtaining information from others. Finally, and probably most important, it is the culture of collaboration, including freely sharing and asking for information.
Who should create this environment? While all team members contribute to it, the ScrumMaster is in a unique position to act as the Catalyst. First of all, the ScrumMaster has one foot in the developer camp, and the other foot in the Product Owner camp. As such, the ScrumMaster is able to understand both, and thus be the catalyst for collaboration with each other. Second, the ScrumMaster's position slightly "above" the developers' trenches enables the ScrumMaster to see opportunities for improved developer communication and collaboration.
With respect to physical conditions, it is naturally important to locate team members as close to each other as possible. (Avoid distributed developments whenever possible.) Beyond this, provide areas where people can naturally congregate, for example a Water Cooler (Coplien and Harrison) and a Snack Shrine (Oyatsu Jinja).
But that’s not enough. It is also necessary to get people motivated to come together. This second part is the main piece, and it’s the difficult and deep one.
One example is with meetings. Scrum has a lot of meetings, and while the Daily Scrum meetings are short, they are by virtue of being meetings, disruptive. It is easy to have the attitude that, “yet another meeting that I have to go to.” With this attitude, we tend to shut off listening and contributing, as we watch the clock. It encourages people to be a few minutes late. To counteract this, work to make the meetings a positive experience. The following can help:
Make sure the Sprint Backlog contains items that can be accomplished in a day, but aren’t trivial. When developers finish a worthy piece of work, they are more eager to come to the Daily Scrum meeting and report their accomplishment to their peers (Small Victories).
Help the Product Owner learn how to give appropriate work, as well as how to avoid micromanaging (see also Coplien and Harrison: Developer Controls Process).
Run the meeting (Yes, it’s pretty simple, but people hate to come to meetings where nobody is in charge of the meeting.)
Run the meeting well (such as efficiently.)
Make the meetings safe. (As opposite examples, I have seen a couple of Scrum processes where the Daily Scrums were used as a hammer to intimidate people into finishing their work regardless of how late they had to stay up.)
Use retrospectives to help the team freely share information (See also Knight of the Mirrors).
But there is a lot more to it than just coming together in meetings. Most of it, in fact, is informal communication and collaboration during the course of the day. This includes the following:
Help people be willing to raise impediments to the Product Owner, if they can’t be resolved internally. Part of this is selecting the right problems, and part is trusting the Product Owner to do their job. And it involves helping the Product Owner know what to expect, and what is expected.
Help people understand the why of the process being followed. Since Developer Controls Process, it involves helping the team base its process on sound principles, and avoiding the “process because it is a Good Thing” trap.
There are some social things here, such as done by the Matron Role (Coplien and Harrison). The ScrumMaster is not necessarily the Matron, but can be the person who makes the Matron aware of his/her Matron-liness.
Providing the collaborative intellectual environment is mostly about helping people get the technical information they need:
Importantly, share information from the Product Owner to the development team and vice versa. Also, encourage direct communication between the Product Owner and developers.
Understand everybody’s skills and preferences, so that if you see somebody is stuck, you can ask them what the problem is, and you can help them talk with the right person. Or maybe you just need to detect that someone is stuck, and you just suggest that they talk to someone else.
Note that a natural consequence of an active ScrumMaster is that the ScrumMaster may be the conduit of information between the Product Owner and the Development Team. While this may be convenient and occasionally expedient, the ScrumMaster should avoid becoming shaped like a pipe! Instead, act as a communication catalyst by initiating communication, then back out and let the people communicate directly.
Fun is a great motivator, and can bring the team together. The ScrumMaster can help with the fun. However, note that ping pong tables in the lounge are really short-term artificial fun. The real "fun" comes from accomplishment and unity. Thus the ScrumMaster should focus on establishing Unity of Purpose and Team Pride (Coplien and Harrison).
These interventions might best be carried out in a subtle and indirect way. Ideally, the team isn’t really aware of how the ScrumMaster helps the team jell; it just appears to happen by magic.
In chemistry, a catalyst operates on another compound and causes it to change, while the catalyst itself remains unchanged. So it is in this case: the ScrumMaster works with the team to change it into a highly collaborative, jelled team. And in the end, the ScrumMaster should not become consumed ("burned out") during the course of the transformation.
Alistair Cockburn defines a “high ceremony process” as one in which the team cannot sustain the activities without explicit process enforcement. If this pattern is applied effectively, it moves the team from “high ceremony” to “high discipline,” where the team itself sustains the discipline of Scrum.