Scrum, the most widely used Agile development framework got some major praise recently from outside its software origins from Steve Denning, a thought leader in leadership, management, innovation, and organizational storytelling:
If there was a Nobel Prize for management, and if there was any justice in the world, I believe that the prize would be awarded, among others, to Jeff Sutherland, Ken Schwaber and Mike Cohn for their contributions to the invention of Scrum.
Why such high praise? For Steve, Scrum creates the right environment to combine “rapid innovation with disciplined execution”. Steve rightly points out that the secret to success with Scrum is recognizing that Scrum is about a change in mind shift and culture, not a process that one merely follows. He uses Salesforce’s adoption of Scrum to validate his point:
Unlike many firms that have tried to implement Scrum, the leadership at Salesforce.com saw that Scrum involved not just the adoption of a new business process, or a framework for managing software development, but rather as a fundamental transformation of the way work was managed in the company. They realized that they were introducing a new way of thinking, speaking and acting in the workplace for both managers and workers. They committed to it boldly and the results have been extraordinary.
How would you introduce Agile/Scrum to participants of a Tourism conference in 2 hours? For me, the Tourism Brochure game seemed like a natural fit. Participants get a chance to experience the entire Scrum process, from feature brainstorming and prioritization to product demo and retrospective.
All was well, until I discovered later that there might be 70 participants at the session (note to self: inquire about session size when making proposal). Yikes! I then went to work on ways to scale the game with just one facilitator aka my plan to keep my sanity intact.
Scaling the resort brochure game
Preparation was key. I spent an inordinate amount of time creating supplementary material:
sample brochure to see what the final destination will look like
Provide clear instructions for people to understand concepts, which includes multiple learning methods. This workshop in some ways ran smoother than some smaller ones I’ve facilitated. There was less confusion, increased flow of activity. You can scale much better with the right supports in place.
Keep steps as simple as possible. Each step in the process was kept small and focused, making it easier to follow.
Demonstrate by example. For the product review/demo, I helped one team do their demo while the other groups watched. That gave me a chance to go through what needed to be done and why. It produced several teaching moments, and increased the value of the other group’s product review sessions.
Keep the fun and energy levels up to make everything go smoother. The music and materials added a sense of play and excitement to the game.
8 teams need more than one facilitator. Had there been one more person, teams could have had questions answered more quickly, or gone less astray during an activity. To compensate, I added time to some activities in order to get around to tables.
Sharon Bowman‘s Training from the Back of the Room continues to yield excellent results for me. I had plenty of energy left, even after a hectic two hours because the participants, not me, were the centre of attention. Opening and closing discussions, small table activities kept them busy and learning together, with me as their ‘guide on the side’ as Sharon likes to say.
Secret map unearthed for Dialogue Room at the Scrum Gathering in Orlando, FL in March. If you can’t have fun here, you’re doin’ it wrong. 🙂
The Dialogue Room is the heart beat of the Scrum Gathering. Come experience a lightly structured, free flowing environment where impromptu and spontaneous conversations and activities can take place. It is intended to be a space for those who want to explore Scrum beyond the formal sessions. Anything goes; no formal workshops or talks here. The Dialogue Room coordinators will provide craft materials and games — that will spur the creation of new structure. Explore and contribute to a gallery of questions and other artifacts. Peruse the live Twitter / Flickr wall.
Got a Scrum ailment that needs diagnosis? Come visit the Scrum Clinic at the Dialogue Room. Sign up for a 20 minute session of private 1-on-1 coaching. Doctors wanted.
Are you going to the Scrum Gathering? What do you think of the Dialogue Room? What would you do differently?
A recent study shows that surgical errors are reduced by a whopping 40% by using a simple tool: the checklist. The checklists focus on what to do before, during and after the surgery.
The state of Michigan alone reckons they save 1,500 lives a year and $200 million (in malpractice suits – joke).
I’ve found that teams also forget some of the little but essential steps which creates waste through increased mistakes and delays. Lists are especially helpful for teams and product owners who are transitioning to the Agile process. So today I created some Scrum ceremony reminder lists to help the team I am coaching and I’m making them available for anyone to use under a Creative Commons license. Let me know how they can be made better.
Update Sept 29: Reformatted lists to print on 3 sheets of paper, 0.5″ top and bottom margins. You can print all your check lists for one sprint except for the stand up meeting on one double-sided sheet of paper.
Games are a fun, interactive, effective way to teach. A dose of competition mixed with social interaction keeps people engaged. You learn by doing and reflecting on the experience. Powerpoint, your time is over.
Until recently, I hadn’t had the opportunity to use learning games, since most of my work as an Agile coach is done remotely. In February I tried out the Resort Brochure with The Blog Studio and Thmvmnt with positive results, and then in early March I spent a few days with the Web Collective, all small purpose-driven organizations looking to become more Agile.
Build the backlog. Teams estimate the size of items, and the product owner may re-prioritize based on those estimates, just like in a real project. Some games have pre-determined backlogs, with all items sized and prioritized for you. Seems a little too command-and-control to me, which Scrum isn’t supposed to be.
Multi-team collaboration. Teams work together, not against each other to reach their goal.
Metrics applied to planning process. If you are going to bother estimating, make it useful. Teams estimate the size of their work, compare planned vs. observed velocity (how much they get done each sprint) and see the effect of observed velocity on their release plan.
Leading retrospective at end of game
How it works
This was my first time trying the Lego exercise. The product owner (me) explains to the team the vision for the project, to get everyone inspired and focused. In this case, the team has been hired to build a new city.
The team then estimates the items in the backlog, which includes things like one story buildings, a church, a tow truck and a crane. We used Steve Bochman’s team estimation technique to quickly size up stories. Team estimation turned out to be quicker than planning poker, which is what I had always used in projects. Team estimation and planning poker focus on comparing the relative size of features / stories, which is far easier to do and more accurate than trying to guess the absolute time to build each item. The next day the Air Charity team at Web Collective estimated over 50 stories, averaging between 2-3 minutes per story! Amazing speed given this was their first Agile project.
Task board showing 4 sprints of stories and a velocity chart
Once the items are estimated, the teams have guess how much they can get done in one 5 minute sprint, and that is used to determine their initial velocity. We’ll then count up the number of points at the end of each sprint to adjust that number. In the diagram above, the team estimated 18 points per sprint before starting the work. Each section of stories is a sprint.
Watch the passion, focus and determination for yourselves.
What went well
Teams learned the importance of getting enough information from the Product Owner (client) to deliver what the client wanted. Some Lego creations were rejected because they didn’t pass expected scenarios, like being able to open the door on a building without the wall coming apart. The quick feedback cycles of sprints enabled them to fail fast and get back on track.
Everyone had fun learning about Scrum. They went through most of the Scrum process, from release planning to working in 4 sprints, including a demo / review at the end of each one.
What could have been better
Forgot to update burn down chart at the end of each sprint, and with that, the review of the teams’ overall progress in comparison to the release plan.
Need more Lego. One tow truck hobbled on 3 wheels.
With 8 people, team estimation stalled at times. Need to learn more techniques to keep flow moving. Hank Roark (@hroark on Twitter) pointed me to James Grenning’s Companion games for planning poker.
What I will do differently next time
Use a timer that everyone can see
Tweak the estimation process to make it go faster
Keep a check list of items to do during every sprint
Recently I had the opportunity to share about my work passion, Agile and Scrum at a local IT group luncheon. I was pleasantly surprised at the level of interest and depth of questions. Organizer John Hatherly told me they had about double the normal pre-registrations for a talk.
Perhaps the tough economic times is behind some of the interest. Agile / Scrum is ideal for these conditions, since Agile delivers the highest value early and often to clients:
The product backlog is a list of potential work items prioritized by business value. The highest value items are worked on first.
Working software is released early and often, making it possible to go to market faster.
Continuous feedback helps ensure the team is delivering what the client needs, and helps the client to better understand their own needs. Requirements are always better understood once there is working software to try out.
Regular team retrospectives with actionable items give teams the opportunity to continuously improve.
Proven software engineering practices: test-driven development, collaborative programming, continuous integration and refactoring increase quality and lower the costs of maintaining software. Think of software as a liability to maintain.
My search for a video / slide presentation tool succeeded, so now you can watch it again (nothing else to do?) or catch it for the first time. Total length is about 1 hour 15 minutes due to many excellent questions asked (original presentation is 45 minutes).
Here are useful links for people new to Agile and Scrum:
I’m really looking forward to Plone Conf 2008 for many reasons, one of which is presenting on a topic I am passionate about, namely Agile development, in particular Scrum, an Agile software development framework.
Agile is an iterative and incremental (evolutionary) approach to software development
which is performed in a highly collaborative manner
by self-organizing teams
with “just enough” ceremony
that produces high quality software
in a cost effective and timely manner
which meets the changing needs of its stakeholders.
Scrum, not just for rugby teams
Scrum is a framework that helps teams work in an Agile fashion. Development is time-boxed into iterations lasting 2 – 4 weeks. Each iteration delivers fully working (and tested) software that is “potentially shippable”. Work to be done is defined in a list, or product backlog, prioritized by the client so the most valuable features are done first.
At Agile 2008, I was fortunate to attend Jeff Sutherland’s (co-founder of Scrum) presentation on Agile contracts. His research has shown that teams firing on all Scrum cylinders can generate 400% more revenue than a team using Waterfall methods. (1) That’s some serious competitive advantage. Early retirement, anyone?
45 min goes by quickly so I’m soliciting input on my talk in advance. If you were thinking of catching this one, here is your chance to maximize your time investment. Let me know
if you are currently using Agile and to what degree (see the Nokia Scrum test for a self evaluation)
what you’d like to know in particular about Agile and Scrum
What I am thinking of covering:
Introduction to Agile and Scrum, if most of audience is unfamiliar
How Scrum leads to high performing teams
Quick demonstration of Agile tools built with Plone or built by Plone solution providers using other technologies. Pending list: Plum, XM, Agilito, RoadRunner. Anything else that should be in the list? I may use the tools in the other parts of the presentation to illustrate Agile / Scrum practices
for their contributions to the invention of Scrum.
