Lack of rhythm has a variety of odors, all related to inconsistency:
- Daily Scrum ritual is inconsistent or is drifting (subtly changing)
- Daily Scrums are skipped or meeting times vary
- Sprint durations are inconsistent or change arbitrarily mid-sprint
- Sprint planning ritual is inconsistent or drifts
- Sprint planning meetings are skipped
Rhythm helps make routine things routine. Consider the daily Scrum. Intent is communicated, priorities set, plans laid, results delivered. No announcements, no agendas, no minutes, no paper. That daily Scrum rhythm allows teams to avoid daily noise and focus on delivery. Not bad for fifteen minutes a day.
Establishing rhythm is like feeding chickens on a farm. When the chickens learn they get fed in the morning at the porch, you no longer have to go to the coop, they come to you. You have established credibility with the chickens. They trust they will be fed where and when you want to feed them, and they'll eat what you give them.
To use a negative example, when sprint duration varies, teams have a harder time selecting the right amount of work for the sprint backlog. This, in turn, makes predictions less accurate. When promised results are not displayed or results are not proven, then the chickens start to peck. Trust me on that. They will start to peck.
Daily Scrum ritual is the clear responsibility of the ScrumMaster, so why is that responsibility not being met?
- Does the ScrumMaster know what to do? Has the ScrumMaster been trained?
- Has the ScrumMaster set expectations for the daily Scrums? For example:
- Everyone comes every day.
- Scrums always start exactly on-time, and never last longer than fifteen minutes.
- Everyone answers three questions: what has been accomplished since last time, what will be done today, what obstacles were encountered.
- Problem solving occurs outside the daily Scrum.
- External stakeholders may attend but not participate.
- We don’t sit down.
- Are these rules enforced?
- Is ScrumMaster influence being undermined from outside the team, for example:
- Are project managers permitted to appeal for exceptions?
- Are supervisors allowed to make extraneous assignments?
The monthly sprint planning ritual is also the responsibility of the ScrumMaster, but because external stakeholders are involved, it can be harder for a ScrumMaster to control dynamics. Nonetheless, analysis can start with the same questions:
- Has the ScrumMaster been trained? Does the ScrumMaster know what to do?
- Has the ScrumMaster set expectations for sprint planning with the stakeholders?
- Ideas, requirements, even unreasonable demands—they all go on the backlog.
- These things only come off the backlog at sprint planning.
- Sprint planning occur without fail every ___ (pick a period up to, but not beyond, three months).
- Sprint planning always includes evaluation, stakeholder input, retrospection, planning.
- External stakeholders (should, are expected to, are required to—pick the phrase that applies) attend evaluation and stakeholder input portions of sprint planning.
- Retrospection and sprint planning always includes the team and (may/may not) include external stakeholders.
- Does the ScrumMaster (within the ScrumMaster’s limits of authority and influence) work diligently to ensure rules are followed?
- Is the ScrumMaster being undermined from outside the team?
- When the ScrumMaster makes a recommendation, is that recommendation routinely questioned or is it endorsed by project sponsors?
- Are there dynamics within the organization beyond the control of the ScrumMaster that the ScrumMaster can work to make visible or get resolved? For example, if the human resources, finance, and marketing departments fight over whose features get done first, can the ScrumMaster use sprint planning as a forum to mediate a solution? Can an executive be invited to sprint planning to resolve the issue?
There are other things that promote rhythm:
- Clarify expectations
- Conduct training
- Be consistent
- Resort to mommy rules
When rhythms emerge, what do you want them to be? The benefits of setting expectations are cooperation, increased likelihood of success, early visible results, and the rhythm you want.
Adjustment will always be required, but having clarity of purpose and shared understanding reduces confusion, argument, and power struggles. Set expectations for backlog management, sprint planning, and daily Scrums.
Pay special attention to clarifying roles.
- What do you want your ScrumMasters to do? Do they manage the backlogs, or do the product owners?
- If team members cannot make a daily Scrum, are they still expected to report, and if so how and to whom?
- Can stakeholders observe daily Scrums?
To discover what you want, do research. Conduct pilot projects. Invite participation of external stakeholders. Talk to grumblers.
Train ScrumMasters, teams, and external stakeholders. Training does not have to be elaborate: it often doesn’t have to be any more than an explanation to teams or a presentation to stakeholders. However, formal training may be best for ScrumMasters because there is nothing like an overeducated ScrumMaster. They train others.
Never agree to a deviation that can be avoided. When deviation is observed, take action. For dailies, speak to absentees and find out why they did not attend, then remove the obstacle. Is it a misunderstanding? Then explain and train. Were they given a task they could not refuse? Speak to the source. Is it lack of commitment? Advocate, persuade, and sell. Take similar action for other possible disruptions.
For sprints, use sprint planning to look ahead and anticipate possible deviations (vacations, holidays, absences, etc.), and the sprint retrospective to ask how a deviation arose, and what could have been done to prevent it.
Resort to Mommy Rules
Use this one with discretion because it violates the collaborative spirit of agile programming, but sometimes there is nothing quite like a mommy rule to get compliance:
“I’m clean! Why do I have to take a bath?” “Because I’m the mommy.”
“I’m busy! Why do I have to come to every daily Scrum?” “Because I say so.”
Set rules and stick to them (see Clarify Expectations ). Start each project with a review of the rules. Post the rules in the daily Scrum meeting space. Have a checklist, and occasionally take an inventory of compliance.
We had one project manager who blew apart three Scrums. This manager had been trained in classic management techniques, and told us CPM scheduling with Microsoft Project(TM) would be used for planning, not the product backlog. He went on to explain that sprint planning meetings and daily Scrums were a waste of time. Individuals on the project would take direction only from the project manager. When the ScrumMaster tried to clarify the ScrumMaster role, the manager's response was that the ScrumMaster role was redundant and therefore unnecessary.
We tried inviting this manager to daily Scrums to observe, but the manager instead would wait until after the daily Scrum and then make assignments that team members could not easily decline. Sprint planning meetings were a clash of wills and dramatic.
The project manager’s supervisor was sympathetic to anything that might improve our abysmal software delivery performance, and agreed to send the project manager to two days of ScrumMaster training. The supervisor attended also.
We still don’t let this particular project manager attend daily Scrums, but the arguments ended immediately, and the project subsequently developed a very clean rhythm and met its first tight deadline. Educating stakeholders clarified expectations, and consistency emerged.
Agile Alliance website. www.agilealliance.org.
Schwaber, Ken. 2004. Agile Project Management with Scrum. Microsoft Press.