Archives for August 2013

As you can see in these posts, I’ve been refreshing my detailed knowledge of Scrum, which came both from practice and from the 280 Group’s Agile Product Management Excellence class. As I was doing this, I realized that the methodology I had learned, and the scrum masters I had worked with were, respectively, created and trained by Mike Cohn. I already had two books from Mike Cohn’s series, and had just ordered Essential Scrum: A Practical Guide to the Most Popular Agile Process; I heartily recommend the book. Since people make this information available on the web today, in summary form, I found an overview of Scrum on the Mountain Goat Software website. I recommend that you read all of the topics. An outline of the topics follow. Of course, there are also any number of articles on the Mountain Goat Software site.

But, if youwant the overview, go to the slide deck, or read the set of pages linked to below. They will give you an overview of the entire process.

Topics in Scrum

• Overview
• Daily Scrum
• Product Backlog
• Product Backlog Example
• Product Owner
• Release Burndown
• ScrumMaster
• ScrumMaster Requirements
• Scrum Team
• Sprint Backlog
• Sprint Planning Meeting
• Sprint Retrospective
• Sprint Review Meeting
• Task Boards
• Scrum Illustrations and Wallpapers
• Alternative Burndown Chart
• A Reusable Scrum Presentation

I’ve been  practicing agile for years, but always with the lead of a strong scrum master or one in training with a good mentor.  There are things that I just simply assumed were “the way things were done.”   As a product manager  and the product owner, my main concerns were that there was a well groomed backlog, joint understanding of the stories and the overall team velocity.  I left the rest to the scrum master and the team, and I cared about the burndown.

Besides  Explaining Scrum in less than 120 seconds from the previous post, I also found a Simple Cheat Sheet to Sprint Planning Meeting. That post doesn’t talk much about the units of capacity, but I’d always seen it as hours. You then estimate hours available, counting vacations and known reasons for being unavailable beyond the work of the sprint.

What I found was that the team was estimating tasks in story points, and working to make sure that the sum of the points for the tasks matched the number of points for the overall story. This led to large tasks and the lack of numerically measurable and perceptible progress. There was no burndown or burnup chart.

Mike Cohn describes this well in his posts “Why I Don’t Use Story Points for Sprint Planning” and in his description of the sprint backlog. This page and others in the series do a great job with the concepts of agile. Mike also has a Powerpoint presentation  Introduction to Scrum available on Mountain Goat Software’s site. I especially recommend slide 24 on sprint planning and slide 30-39 on the product and sprint backlog. I’ve put thumbnails of these slides on the right. Thank you, Mike, for your very clear presentations, graphics and examples of Scrum.

I now know why the recommendation is to move from points to hours in sprint planning. The process always needs to be concrete, and mapping the work to the people and their schedules and availability is key.

Addendum: People pointed out a blog by Jeff Sutherland on this topic, titled “Story Points: Why are they better than hours.”  Any blog entry with 75 comments has got to be interesting. In the comments, Jeff points out three ways that a team can work

1. Backlog in story point and no tasking (hyperproductive teams)
2. Backlog in story points and tasks in story points (best current practice as teams are getting better)
3. Backlog in story points and tasks in hours (the old way)

In other words, you start at #3 and work up. I’d also believe that the effectiveness of #1 is proportional to the size of the stories (smaller stories makes this more possible).

Bruce gives an overview of Agile, starting about three minutes into this video. While many talks on agile get caught up in the details of implementation, this video makes the tenets of agile approachable.  I suggest that you watch it, and feel free to share it with your family so that they can understand what you do at work.  My kids are a bit too old (Claire, 28 and Peter, 30) to apply this at home, so I’ve got to apply the principles at work.

If you want a deeper view of Scrum, look at the Scrum Guide, available on the web and just recently revised. There are a large number of videos on Scrum on Youtube. One, Explaining Scrum in less than 120 seconds is a great introduction.  A more detailed view and history can be found, from Ken Schwaber in 2006, as a Google Tech Talk; the video runs about an hour.

I’ve identified myself with Datalogics for decades.  It’s where I got my start as a software developer just out of school, just starting a new product line for the PDP-11, where we grew the business to a $17M annual revenue company until we were acquired by Frame as SGML experts, and then a long journey to California, Adobe, eBooks, PDF and server software.  I’ve been working with Datalogics as a consultant since the summer of 2012, and just signed on as Director of Product Management to bring some new business ideas to market, as well as refining the product process. I started back there on a full-time basis on July 29.

I picked the title “Sweet Home Chicago” for this post, little realizing the subtleties. In 1995, my theme song was Burt Bacharach’s “Do you know the way to San Jose,” as much as I dislike Burt. Coming back now, while still living in California, made me think of “Sweet Home Chicago” as popularized by the Blues Brothers.  A quick read of Wikipedia shows the tension between California and Chicago, with the lines
“But I’m cryin’ hey baby, Honey don’t you want to go
Back to the land of California, To my sweet home Chicago.”

I’m back, looking to apply agile methodologies, to the extent that they make sense, and the best of product and customer understanding, to make new ideas and profitable ventures blossom at Datalogics. And, even though I’ve “done agile” at multiple places in the past, beginning with Adobe, this will be my first time bringing it in (along with engineering) rather than having it imposed. I’ll be blogging about my experiences and sharing pearls of wisdom from others with the team as we go down this agile journey together.

This blog has been sitting around in a semi-finished state since November of last year. It’s not perfect now, but I’ll work to make it better over the coming weeks. At some point, you just need to get it out there, and this agile product management thread seems like the best reason for this.