By Jim Schiel
“Extremely Simple, But Very Hard”—these five words are the most important in the entire Certified ScrumMaster training course and, indeed, in the entire act of making Scrum part of your organization. Ken Schwaber says that, of all the organizations that take on Scrum, only about 30 percent will succeed. Once most organizations get past the “extremely simple” part and start experiencing the reality of “very hard,” it is challenging to stay the course. Quite simply, the pain caused by transitioning to Scrum can be much worse than the pain caused by the organization’s current software development efforts. The implementation of the cure can be, in effect, worse than the disease.
My organization began its transition to Scrum and agile development in April 2005. At the time, we had ten Scrum teams. As of the beginning of 2006, we have nearly seventy teams simultaneously sprinting on three continents. Over the past year, I have watched our transition to Scrum take on a reality that shook my organization to its roots. Fortunately, we are one of the 30 percent who made it through the hard change to success.
To help you overcome these inevitable growing pains more gracefully, I will be writing four articles, each one focusing on one of the four transitional challenges the CSM training warns you about: the era of opacity, the tyranny of the waterfall, the illusion of command and control, and the belief in magic. This first article will focus on the end of the era of opacity and the transparency in process, status, and team state that Scrum introduces.
End of the Innocence
Opacity appears in many ways in non-Scrum projects, but usually it hides an unreported (or under-reported) lack of progress. Teams and individuals, previously safe from prying eyes, could wait to report issues until the weekly status meeting or the monthly status report. Scrum, with its high degree of daily collaboration and specific reporting in the sprint burndown and the sprint review meeting, removes this opacity and exposes lack of progress in a frequently painful manner.
Sometimes the transparency provided by Scrum requires action to be taken in order to ensure that a small problem doesn’t become worse. For example, when an employee for the third day in a row reports little to no progress on his assigned tasks, it’s up to the team to start asking questions about why. What obstacle is impeding progress that the employee is unwilling to admit to? Is the team member unwilling to get the expertise they need from a particularly difficult expert outside the team? Maybe the team member is getting pulled into too many other things. Maybe the team member doesn’t have the necessary skills to do the job.
In many instances, however, the transparency that Scrum creates is used inappropriately by project management to isolate causes for delays and to level blame. In a Scrum environment, where any given day can illuminate both minor and major issues, management may incorrectly decide to act immediately on each and every negative report. This can cause teams to begin misreporting their progress or even deliberately failing to update or display their burndown chart each day. It will most certainly perpetuate an environment of fear.
While it’s quite simple to put Scrum practices in place, it is very difficult to get Scrum teams and managers to understand that Scrum team progress varies from day to day. You need to carefully consider the state of the sprint each day, and then take appropriate steps. Sometimes that means getting an employee the education they need (remember, not having the appropriate skills is a shared responsibility between management and employees). Sometimes it means removing an employee from a team. And sometimes it means doing nothing at all and re-evaluating the situation at a future time.
Report Health, Not Status
When you are transitioning your organization to Scrum and agile development, you may find it useful to discuss Scrum team condition in terms of “sprint health,” not “sprint status.” Health can be reported in terms that will not necessarily result in action being taken immediately. In addition, “sprint health” removes the accusatory tone that you get when speaking of a “team being behind schedule.” Try these terms, which are all based on the linear projection of the current sprint burndown:
- Excellent—team will complete their sprint goals with at least two days to spare. In this situation, the team might want to consider taking on an additional story from the product backlog.
- Good— team will complete their sprint goals on time; their trend line shows the team completing the sprint on time or as much as one day to spare. The team should not make any changes; they are right on target!
- Poor— team will not complete their sprint goals on time; their trend line shows that between one and two additional days will be necessary to complete the sprint goals. The team should review their obstacles and make sure that they are being addressed. They may also want to review their task assignments. Any changes, however, should be made carefully. Too much change can be more disruptive than none at all.
- Critical— team will not complete their sprint goals on time; their trend line shows that three or more days will be necessary to complete the sprint goals. It’s time to start dropping scope from the sprint goal. The team and the product owner should handle this and should try to return the team to “Good” health.
Offer Support, Not Direction
Educate your managers on the “care and feeding of Scrum teams.” In general, unless a manager is also playing one of the Scrum roles on a team (e.g., ScrumMaster or product owner), they should focus on supporting the team by listening to their issues and offering suggestions for improvement. In this environment, managers should be prepared to offer support, not direction. This is very important because 1) the team already has a product owner to provide prioritization of the backlog; and 2) the team already has themselves to support self-management and self-organization. What they need from experienced managers is support and guidance.
Collaborate & Facilitate
Educate your team members on how to collaborate. Scrum teams do not suffer hermits gladly. Everyone on the team needs to be willing to be held accountable by the rest of the team; they need to be willing to help those on the team that need help; and they need to be willing to be helped when they appear to need it.
Educate at least some of your team members on the finer arts of facilitation. Facilitation, a much overlooked skill, is about making things easier to do. You will give your teams a major advantage by ensuring that there are team members who are practiced at coaxing ideas on the table and then getting the team to elaborate, prioritize, eliminate alternatives, and select the best solutions. Scrum teams engage in group design—by giving the team the skills to do group activities rapidly and effectively, you’ve added an important tool to their toolkit of skills.
Consider all of the time you’ve wasted in the last month in meetings that went nowhere fast. When you left the meeting no better informed than when you walked in. How much time could you save, and how much could the quality of your teams’ decisions be improved, just by learning some very simple facilitation methods? My favorite technique is mind-mapping, where ideas can be generated in any random fashion and can be rapidly linked together on the flip chart or white board as the concepts developed. There are tools on the market today that support mind-mapping, but a fast hand, a marker, and a flip chart are all that’s really needed.
Be Prepared
As Scrum is rolled out in an organization, it naturally removes the opacity usually present in non-Scrum projects. Defects in planning, team make-up, management, and even individual performance can be made painfully obvious in very short order. An organization unprepared for the spotlight that comes with Scrum will be spending a large portion of the first couple months digging deeply and disruptively within every Scrum team to find the rocks under which the obstacles have scurried. On the other hand, an organization prepared for Scrum’s spotlight will be able to immediately use the resulting transparency to identify and remove obstacles while improving productivity and software quality.
