Identify a Scrum Master
Like most developers my experience with project managers has been mixed: some I've been happy to have tending things and others just didn't seem to do much to support the team's efforts. The project manager in the Scrum process is called the Scrum Master. The Scrum Master is the steward and coach (with respect to Scrum and lean-agile techniques) of the team and a protector of the guidelines and practices of the Scrum process.
The Scrum Master is a leadership role and requires some people skills and the ability to confidently interact with your peers. While Scrum teams are intended to be self-managing and self-organizing the Scrum Master needs to be able to step in when team members deviate from the core Scrum practices. Being the sentinel of the Scrum process does have a traffic cop aspect to it but it is really about protecting the team and supporting it to be maximally effective using the process. Therefore, some previous project management or team lead experience is helpful, but depending on your personality, not indispensable. If you're coming from a development role, having actually been a member of a Scrum team is especially helpful because you can use your own experience to inform how you help your team mature in its application of Scrum and Lean-Agile principles.
I knew from the start of my lobbying to implement Scrum that I wanted to take on the challenges of the Scrum Master role. I believed that I had a clear vision of how the role would serve the team and advance the causes of the business. If you're advocating the adoption of Scrum in your organization this is an important point to consider. If you're not prepared or interested in stepping into a leadership role then you ought to be certain there's a good candidate interested and available. The appointment of a Scrum Master is not a requirement that you can ignore, so until you have someone who can fill the role, you aren't ready for Scrum.
"Plans Are Useless But Planning Is Essential" (Dwight Eisenhower)
Because I'd been a participant in the Scrum process and not the Scrum Master I knew I had to do some reading and prepare a formal presentation to make the case for adopting Scrum. I started with Ken Schwaber's "Agile Project Management with Scrum." The book clearly describes the underlying theoretical and practical mechanisms that are the foundations of the Scrum methodology. Moreover, it details realistic scenarios of Scrum in action to help you envision how Scrum might work (or not) in your organization.
|Introducing business people to Scrum and Lean-Agile methods with an emphasis on how Scrum will reduce their pain is more likely to succeed then blasting them with its theoretical attractiveness and how it will assist IT.|
With my Scrum project development experience and some reading under my belt, I felt I had enough information to make a 'What is Scrum' presentation to my colleagues and IT management. But before you start designing your slides, you'll have to make sure you can get an audience with the appropriate decision makers. If your team is struggling or in crisis, getting the right people in your audience probably won't be difficult. If your organization is doing "alright" then advocating that there is "a better way" will likely be a tougher sell. Introducing business people to Scrum and Lean-Agile methods with an emphasis on how Scrum will reduce their pain is more likely to succeed then blasting them with its theoretical attractiveness and how it will assist IT.
The slideshow I presented was a Scrum 101 that detailed how a typical sprint is run. In addition, I focused on the tangible benefits of Scrum for all of the interested parties in attendance, so it's important to know who is going to attend. Management's chief interest is to know how Scrum can be used to identify and plan the workload such that IT can deliver what the business wants in a timely fashion. For example, how does Scrum handle change and complexity? Scrum's biggest sale point with respect to planning is that it increases the visibility of choices and consequences in iterative development. You'll probably find that it takes very little effort to show that by developing smaller, more understandable units of work the development team can estimate more accurately. I emphasized that estimates are still estimates, not guaranteed dates, however, this more granular approach to breaking out work increases the chances communicating a fuller picture of the work effort from the start.
In my presentation I further contended that the shorter development cycles Scrum mandates would afford us the opportunity to change direction more quickly and more smoothly when business priorities changed. Quality could be improved because smaller units of work are generally easier to test. Moreover, in contrast to 'waterfall' style development, the time to write the tests is represented as individually estimated tasks. These tasks are such a visible part of the schedule that they are less likely to be the frequently cut corner that testing can be in waterfall style development schedule crunches. Be sure to emphasize the benefits and overall importance of frequent builds and tests when you communicate about Scrum.
I knew from prior discussions with my colleagues that they understood we weren't adapting well to the rapid changes in our environment. Long weeks were more the norm than the exception and emergencies were part of the routine. Every employee who had the misfortune to live through it told the legendary tale of the hellish month leading up to the product's prior release. We needed not only to boost our quality but also to recognize what we could accomplish within a given timeframe so we didn't get overwhelmed. Scrum delivers this kind of predictability. Don't be shy about exploiting your company's oral tradition in order to remind your audience that they are vulnerable to the very types of dysfunction that Scrum can help solve.
Scrum isn't a silver bullet for preventing the business from needing things at the last minute but I argued that creating a pattern of reliable delivery (in shorter increments) with a solid communication feedback loop to the business when issues arose would inevitably increase the business's confidence that we could and would deliver what they needed when they needed it. Of course, I continued, things don't always go according to plan but if we're all one team, one company, isn't it better for everybody to understand the challenges at hand and figure out how to respond together? In waterfall development, when a crisis arises and the schedule is pushed to the limit there's precious little honest communication about what doesn't get donewhat corners are cut in testing or code quality to "make the date." An honest, empirically controlled process enables IT to work with the business to determine the best course of action for the business as a whole under the circumstances. An argument for this type of transparency should be appreciated by anyone who truly cares about the business.
To support my claims that these lofty Scrum and agile concepts could ease everybody's pain, I presented an example burn down graph of a Scrum project I had worked on (see Figure 1). A burn down graph is a key Scrum artifact that displays the progress of the work for a given sprint. This is the empirical reality of the project and it is the Scrum Master's responsibility to keep this status information up to date.
|Figure 1. A Scrum daily burn-down graph for a 20-day sprint is shown. |
The chart shows the number of days remaining in the sprint on the x-axis, while the y-axis shows the number of days' worth of work remaining to be completed. In Figure 1, the blue line shows the ideal, while the back line depicts actual results. Together, these two plot lines can tell you at a glance how far off the mark your sprint has progressed and whether you are ahead of or behind schedule. The drop down at day 8 indicates that hours of work completed between these days haven't yet been recorded, i.e., this is normal.
The burn-down graph is a tremendously powerful visual aid to see the sprint's progress. If the burn-down bumps briefly above the line there's not much to worry about but if the slope flattens out above the ideal burn-down rate then either new tasks are being added faster than the work is being accomplished or non-sprint work is being performed instead of the work the team committed to complete. This helped the group understand how Scrum can give at-a-glance feedback about your success.
Finally, I described the daily rhythm of Scrum most notably the daily status meetings and the updating of the remaining hours on tasks. My experience with Scrum was to use agile estimating and planning techniques and the manual posting of task-related stickies on the wall. The result is a dashboard that not only displays the team's workload but serves as a powerful demonstration of the activity in the organization. In my experience, both IT and business management are very impressed with the visibility this provides into testing and development activities. This is another opportunity to emphasize that the transparency Scrum provides enables everybody to work together to make the right decisions for the software and the organization; secrecy serves no purpose.