Know the Scrum Basics: Get Your Velocity Right

This month, Scrum Inc.’s monthly webinar focuses on fundamentals and correcting bad Scrum habits. While a majority of us feel like we get the basics right, Scrum Inc. surveys and independent polls find that while most Teams understand the basics, many skip at least one key practice.

Most commonly, respondents indicate that their teams don’t calculate Velocity. Without Velocity, there is no way to measure improvement, have transparency and visibility into your process or properly plan a Sprint or a release.

How it Works

Break work into small tasks. Give these tasks, called User Stories, a point value by estimating their relative sizes. (Relative size is important because studies show that humans are incredibly poor at estimating jobs in hours.)

During Sprint Planning, the Scrum Master plays dealer in a game of planning poker. The Scrum Master starts the game by taking a User Story and having all members of Team chose a card with a number they believe relates the relative size of the task. The Scrum Master counts to three and all Team members reveal their cards simultaneously. The Team members with the lowest and highest cards debate the reasons for their choices and then the team plays another round. The process repeats until a consensus is reached. Continue the game until the all tasks have a point value.  

During the Sprint, as each task is moved to done, the Scrum Master can plot the points over the length of the Sprint. At the end of the Sprint all the points added together is the Velocity.

As the Team completes more and more Sprints, the Scrum Master can compare how much the Team has improved. Although velocity tends to oscillate over time, as a rule it should trend upwards about 10% per Sprint.

Remember, just because the team has gotten better at implementing any given story, the point value you should remain the same. If the Team starts to estimate stories at lower values because they have incurred substantially more experience and the stories seem easier, Velocity will never seem to improve. This is one big reason why estimating in hours doesn’t work. 

Teams shouldn’t obsess about how many points something is worth. Estimating points is just an exercise to help quickly evaluate relative effort. The important thing is that you are consistent and that the entire team has a common understanding of their system for sizing.

Whether you are new to Scrum or a long time practitioner, getting the basics right will definitely improve your Velocity. On Tuesday, March 26^th we will be exploring Velocity, Retrospectives, Backlog Grooming and the rest of the Scrum Fundamentals. Please join us.

-- Joel Riddle & Christine Hegarty

Be Critical, Scrum and Feedback

There was an interesting radio piece on American Public Media’s Market Place the other day. Host Kai Ryssdal talked with Stephan J. Dubnar of Freakonomics fame about what the latest academic research on feedback tells us. 

Here’s how it breaks down: to get people to commit, positive feedback is shown to be really helpful. So if you have a new Team member, the Team and the Scrum Master should see substantial improvement in that new member’s commitment by focusing comments on what that team member is doing well.

However, once that Team member is fully on board, a Scrum Master would see diminishing returns from continued positive feedback. To get increased performance at this point, critical feedback is the only game in town. Basically, if you want improvement out of a committed Team, you have to point out what they are doing wrong and help them find a better way to complete their tasks.

The other interesting finding is that the more expertise someone has, the more they tend to filter out positive feedback. So if you have a great coder with 20 years experience, giving him or her props isn’t going to do much.

You can read all the research the story was based on here.

-- Joel Riddle

Call for Papers: Agile and Lean Organizations, HICSS 2014

Now in its 47th year, the Hawaii International Conference on System Sciences (HICSS) is one of the longest-standing continuously running scientific conferences. This conference brings together researchers in an aloha-friendly atmosphere conducive to free exchange of scientific ideas. The next conference will be held January 6 through 9, 2014 at the Hilton Waikoloa Village on the Big Island.

 
If you've been doing innovative work or research on agile methods, here's an opportunity to present and collaborate with like-minded agilists, in a tropical setting. Submit your paper to the HICSS 2014 Agile and Lean Organizations minitrack by June 15, 2013.
Agile development methods promote iterative product releases and drive risk-reduction earlier in product development. Characteristics include: cross-functional teams, automated testing, continuous builds and deployment, pair-programming, bias-avoiding estimation, process improvement and short feedback loops. Advocates claim agile development produces greater staff resiliency, better release forecasting, fewer product failures and more sustainable work pace.
Lean product management methods test hypotheses and rapidly adapt to discoveries. Characteristics include: set-based design, A-B testing, unmoderated user-experience testing, direct market experimentation, customer validation and pivoting. Advocates claim lean product management produces greater market satisfaction and customer engagement, earlier discovery of hidden market opportunities, higher revenues and more efficient use of development staff.
In this minitrack, we seek research papers and experience reports that describe how agile development and lean product management interact with organizations, their structures, cultures and products:

• What evidence-based guidance can we provide to leaders to help motivate, create and sustain agile/lean organizations? How do agile development and lean product management interact with product groups, departments, companies?
• How do organizations restructure to support these philosophies and when they do not restructure, what happens?
• What cultural requirements and/or training are needed for companies to maintain agile behavior?
• How do organizations structure coaching, training, mentoring, Scrum Mastering?
• How do they identify metrics, measure improvement, and improve?
• How do markets respond to rapid iterations and end-user experimentation?"

Submission guidelines are available here. If you are interested in reviewing articles for the Agile and Lean Organizations mini-track, please contact Dan Greening at dan@senexrex.com
We're looking forward to seeing your submission, and seeing you at HICSS 2014 on the Big Island of Hawaii!

Mini-track chair Dan Greening is the Managing Partner of Senex Rex, a management and training firm. He helps international enterprises plan and manage sustainable agile transformations. He currently manages agile coaching at a large international software company. He previously led transformations at Citrix Online and Overstock.com. He developed portfolio management and finance strategies for agile projects. In previous lives, he was Principal Investigator for 3 NSF SBIR grants, created three product startups, worked at IBM Research, and delivered newspapers in the rural Midwest.

The Serenity of Flow

The Certified Scrum Master class attendees were off and running on a self-organization exercise. The drill was simple: plan, build, and test as many paper airplanes as you can in 3 minutes.

I was busily preparing for the next class module when I gradually became aware of what was transpiring:  “Twenty-four”, “Twenty-five”, “Twenty-six”… like the coxswain of an Olympic crew team, the Product Owner called out the production count.  With heartbeat regularity, every two seconds another paper airplane floated gracefully across the room, nosed into the exact same spot on the projection screen and settled gently into a tidy pile on the floor.

Their product design? Standard. Their manufacturing process? Pretty conventional. But for 180 seconds in Munich, aptly-named “Team Front” achieved the perfect state of Flow that we wish for all our Scrum teams.

Congratulations to “Team Front” on their new world record!  Pictured (from left to right) are: Oliver Heerdegen, Chris Holland, Todor Ganebovsky, Karla Korb, Thomas Bohne, Katrin Sulzbacher, Norbert Toth-Gati, and Klaus-Rüdiger Hase.

Flow is that transcendent state where, with very little explicit communication, team members mesh into perfect formation, each contributing equally and to their utmost toward a singularly shared goal. Eight individuals who had been complete strangers only hours before were working in complete unison as if they had trained together for years.

When the clock stopped, the tidy pile of planes had reached 32…shattering the previous Scrum record of 28.

We spend so much of our time in the Scrum community focused on the nuances of running Scrum: How do I manage teams across multiple locations? How do I balance a sustainable pace with Velocity? But sometimes it is important to take a step back and just appreciate the simple joy of achieving Flow.

-- Alex Brown

Wanna take a crack at breaking the record?  Click here to take course with Jeff. 

Is Your Family Agile?

New York Times columnist and author Bruce Feiler has just published a new book titled: The Secrets of Happy Families: Improve Your Mornings, Rethink Family Dinner, Fight Smarter, Go Out and Play, and Much More.  The secret it turns out is applying agile development to your household. 

Every week starts with a family meeting. Kids and parents self-organize and self-manage (kids even help decide on their own incentives and punishments) and every week they have a retrospective to determine what they can do better next Sprint. Turns out that kids think their parent’s stress levels can improve.

Scrum: savior of the modern American family? Watch and decide for yourself. 

You can listen to an NPR review and an interview with Bruce Feiler here and here.

Wanna learn more about Agile and childhood?  Click here for Scrum in schools.

-- Joel Riddle