By Mark W. Randolph
Importance
Important
Symptoms
These are symptoms that a Scrum team is not being protected from outside influences:
- External stakeholders talk in the daily Scrums
- Features are selected or priorities switched outside of sprint planning meetings
- The team cannot make purely technical decisions without an outsider’s blessing
- Status reports are required outside sprint planning meetings
- Team managers or executives who sponsor the team receive requests to influence the team
- Product backlog languishes or is ignored
There are many different types of outside influences. Only one example of outside influence is examined here: talking chickens.
Discussion
To explain the difference between a Scrum member living the pain of a bad technical decision and outsiders who feel compelled to make decisions for a team, Ken Schwaber [1] talks about a pig and a chicken opening a restaurant. The chicken suggests the restaurant be named Ham and Eggs. The pig suddenly realizes the difference between being an interested stakeholder and full commitment. After all, it is easier to contribute eggs than to be the entrée.
Scrum teams work best as self-organizing teams protected from incompletely informed decisions imposed by external stakeholders. An external stakeholder is someone who does not directly participate in development and is not a member of the Scrum. Typically, external stakeholders:
- Use or benefit from the use of the product, or are affected by product use;
- Contribute resources or pay for a product’s development; and/or
- Set priorities, budgets or schedules; and/or
- Do not suffer the full pain of bad technical choices (late nights, lost weekends, etc.).
In the context of Scrum, external stakeholders are chickens. Scrum team members are pigs.
While inappropriate outside influence can be exerted at any point in a sprint cycle, it is most visible when external stakeholders overparticipate in daily project activities, especially the daily Scrum, which explains the rule, “Chickens don’t talk at the daily Scrum.”
Note that external stakeholders have a legitimate interest in the success of the team and that the team cannot succeed without their contributions. That is the irony. Even if developers know best how to define and deliver valuable features, deeply useful products cannot emerge without the cooperation of the executives, customers, managers, and the others that the team serves. Chickens and pigs must collaborate to deliver a meal because, in the end, it is everyone’s bacon.
Why are the chickens clucking? Is it:
Ignorance? Maybe the chicken is an ignorant chicken. Have the rules been explained?
Weak enforcement? Is the no-talking-chicken rule consistently followed? If it is not, what is preventing the ScrumMaster from enforcing the rules?
Failure of support? Are the attempts of the ScrumMaster to enforce the no-talking-chicken rule undermined by team members or team sponsors?
Habit? Are chickens fighting old habits of immediate unimpeded access to developers? Do they lack experience with the rhythms of sprint and release planning?
Lack of faith? Do the chickens lack faith that Scrum can deliver what they need? Has the team done something, for example ignored priorities or been late, that has undermined their credibility so that chickens feel compelled to intervene?
Contention for control? If two or more groups are contending for development resources or priorities, that competition may manifest itself in efforts to direct the work of the Scrum.
Legitimate input? Did the team invite the chicken and ask for their contribution? Maybe the chicken ought to be brought into the Scrum.
Remedies
While it is tempting to offer a talking chicken a rubber band for their beak, or a chopping block for their neck, tact and discretion might compel you to consider other alternatives:
- Consistently enforce the no talking rule
- Conduct training as part of project start
- Negotiate rules at project start
- Use retrospectives to reinforce expectations
- Move chickens away from the pig pen
- Change the meeting time and place and don’t tell the offender (just kidding)
- Maybe the chicken can lay an egg
- Become a barnyard dog
Additional explanation follows.
Be consistent
Habit is your ally. Consistent enforcement develops habit. Mike Cohn tells this story [2]:
A few months ago I took my young daughters to a local fair. On one ride, the line led up to a short flight of stairs at the base of the ride. No one was allowed on those stairs, but many of the young kids wanted to sit on the stairs while waiting. The ride operator, though, held firm to her rule of no one on the stairs. She told them, “If I let you sit on the first step soon you’ll be on the second step and then the third step.” Clearly sitting on the first step would not have endangered any riders but the stairs were an obvious delineation and the ride operator used this as her simple rule. Not allowing chickens to talk during the daily meeting is one of Scrum’s simple rules. Of course one comment from a chicken may not hurt—but it will lead to others and then there will be no easy place to draw the line.
Never allow a violation that can be avoided. When a violation occurs, take action. If everyone is already familiar with the rule, a reminder during the meeting is appropriate. If the chicken might not be aware of the rule, speak to them privately immediately following the Scrum. If there is a single consistent violator, find out what the root issue is (“My priorities are being ignored”), and deal with that directly (“You have to start attending sprint planning meetings”). Bump the violation to the individual’s supervisor or the team sponsors and ask them to intervene.
Conduct training
Prevention is easier than correction. Make training a routine part of every project start and include potential chickens. Explain the rationale of the “no-talking-chickens” rule, and solicit a public commitment from everyone to cooperate.
Have a contract
As part of project start, help the group—Scrum members and stakeholders together—negotiate a set of rules of how to work together. One rule should always be, “Chickens can observe daily Scrums but may not participate.” As part of the discussion, talk through alternatives to attending and speaking at a daily Scrum. For example, “On this project, if a chicken has an urgent request that cannot wait for sprint planning, they can take it to the ScrumMaster and the ScrumMaster is obligated to act on the appeal.”
Use the retrospective pro-actively
Every sprint includes a period of retrospection during which the sins of the past are remembered, and pledges are made not to pass that way again. Relive incidents where the no talking rule was violated, explore the reasons for the violation, and discuss the consequences or potential consequences of the violation. At the very least, if it has been a problem, remind everyone of the no talking rule. This will help forestall reoccurrences.Move chickens away from the pig pen
Shamelessly exploit unconscious human behavior! In group settings, the next person to speak is frequently the last person to make eye contact with the group leader or the last speaker. Arrange the room so that chickens are outside the circle of the Scrum and behind the ScrumMaster. They can’t make eye contact and are less likely to participate.
Bring the chicken into the Scrum
If the chicken is attending because they must be consulted or have valuable input related to development (clarification of requirements qualifies as development), maybe the chicken ought to be brought into the Scrum. Maybe the chicken can lay an egg.
Become a barnyard dog
It is the ScrumMaster’s job to protect the team from interference. A properly empowered ScrumMaster has the authority to exclude chickens from the Scrum entirely.
Case history
We had an executive notorious for micro-management. True to form, the executive attended the first daily of the first sprint of the first Scrum project and peppered the team with questions. Afterwards, the ScrumMaster—with great trepidation—explained that while observers were welcome, the meetings were for coordinating work, not problem solving. The executive’s response was, “Oh. Right. OK.” Seizing the opportunity, the ScrumMaster then urged the executive to come to sprint planning instead, offering these arguments specifically tailored for this particular executive:
- We’ll have a working demo ready
- The daily meetings are low level and technical, whereas the Sprint meeting is at the business level, and you can see what your customer is going see
- All your stakeholders will be in one place, the developers will be prepared for questions, and you can get really good information
- The team will be done with one batch of work, and ready for you pick what to work on next
- We have these every Monday (we use one week sprints), so you can arrange your schedule for months in advance
The executive was agreeable, and the idea of a demo was exciting. The executive did attend several more dailies, but within a week, declared them “boring” and stopped coming. After attending only a few sprint planning meetings, the executive was quite enthusiastic about the sprint model. “I like it!”
The lesson? The ScrumMaster took action immediately, and anticipating the needs of the particular stakeholder, offered opportunities other than the daily Scrum to get those needs met.
References
Schwaber, K. 2004. Agile Project Management with Scrum. Microsoft Press.
Cohn, M. 2003. Toward a Catalog of Scrum Smells. www.mountaingoatsoftware.com
