Agile Roundtable Notes: September 3rd, 2009

The Salt Lake Agile Roundtable meets the first Thursday of every month at the Borders bookstore in Murray, UT from 2pm to 5pm. These are my notes from the September, 2009 meeting.


When I arrived, there was a discussion about kanban taking place. The discussion revolved around the idea that the essence of kanban is more than just having a board with tokens on it. The essence of kanban in a manufacturing context is just-in-time manufacturing, or “pulling” from the generative process into the consumptive process. In a software engineering context, I consider this idea in the context of a release plan, an iteration plan and an engineer’s ToDo list. Items are pulled into the release plan by customer demand. Items are pulled into the iteration plan from the release based on delivering the most important value first. Items are pulled into an engineer’s ToDo list from the iteration’s stories. Taking a step back and looking at the organization from a broader perspective than just engineering, we can consider that features are pulled into the organization from customer demand. The organization delivers features by pulling them from the testing team and the testing team pulls them from engineering. See Kay Johansen’s quote below.

There was a round of impressions given from those who attended the Agile 2009 conference that took place last week in Chicago. Zhon Johansen related some thoughts about Arlo Belshee’s concept of “naked planning” that I found interesting. (More on naked planning from Renzo Borgatti.) Zhon talked about using a quadrant approach to categorize work in the backlog. The four quadrants represent the regions bounded by low cost, high cost, low value and high value:


A team might typically take the “easiest” work first (that with the lowest cost), starting with the highly valued work and then implementing diagonal slices across the quadrants favoring the easier work that they can deliver most rapidly:


In naked planning, Arlo proposes that instead of slicing across this space diagonally that we slice across it horizontally from top to bottom:


We always work on delivering the most valuable functionality first, regardless of whether it is cheap or expensive to build. If you are practicing “extreme programming”, then delivering the most valuable features first will sound familiar. Arlo takes this process one step further and discards the development estimates (the cost to develop) in favor only of the estimated “value” a feature provides the customer. The reasoning is that value varies along an exponential scale while development costs vary along a linear scale. Therefore delivering the most valuable features trumps any consideration of whether or not the most valuable feature is cheap or easy to develop — even if its more costly to develop, its the one that has the most value to the customer that should always be built first.

Going even further, Arlo dispenses with the concept of the iteration as a time-boxed span of development. Instead, he concentrates on “minimal marketable features” (MMF) and after each MMF is developed the product is considered shippable. Instead of progressing from iteration to iteration in time-boxed chunks, he progresses from feature to feature, starting with the most valuable features. It was noted that now instead of the challenge of estimating development effort, we’re faced with the challenge of estimating perceived feature value. We may have traded one hard problem for an even harder one…

There was an interesting discussion about command-and-control style management vs. “push down” style management where you push the responsibilities down to the team and let the team own the outcome. It was mentioned that management should not be a parent/child relationship. As an engineer, it can be tempting to err too much on the side of “command and control” style management, but the best way to get results from a team is to empower them with the responsibility of delivering. See Christine’s quote below.

The topic of encouraging time spent on personal ideas was discussed, as in the 20% of time that Google gives employees to pursue their own ideas. A variety of suggestions were made about how to incorporate that into planning so that it is expected and accounted for explicitly. Alistair Cockburn (pronounced “co-burn”) related a story of when he worked at IBM Research and he would work 4 weeks on company projects and then 1 week on his personal project. He found it easier to work in larger chunks this way, than to split an individual week into 4 days on company projects and 1 day on personal projects.

It was generally felt that 1 day on a project just wasn’t enough time to make any significant headway before you had to switch back to another project and that anything less than a single day was so little time that it wasn’t worth the bother of trying to conext switch back and forth. Kay suggested that another way to group the time was to accumulate the personal project time to be spent in a chunk once per quarter. Another suggestion was to use a “gold story card” for such personal projects and allocate them to a team member that has accumulated enough personal project time to be able to spend an entire iteration on a personal project.


“In a pull organization, the development team shouldn’t be creating any features until QA has time to test them.”, Kay Johansen

“Managing is not parenting.”, Christine

Books Mentioned


Andrew Shafer took the time to explain to me his workflow with git and how it compares to Subversion. Thanks, Andrew.

Zhon supplied me with a 40% off coupon at Borders. I used it to buy the 3rd edition of Effective C++: 55 Specific Ways to Improve Your Programs and Designs. I have browsed this book before and have had it recommended many times, but I just never got around to buying it. At a list price of $50, each specific suggestion costs you less than a dollar, which is a bargain, so getting it for 40% off is a steal. Thanks, Zhon.

3 Responses to “Agile Roundtable Notes: September 3rd, 2009”

  1. Allen Maxwell Says:

    Great summary Richard and thanks for the talk after the meeting. Talk to you next week.


  2. “Effective C++”, 3rd edition by Scott Meyers « Legalize Adulthood! Says:

    […] the last agile roundtable, I picked up a copy of Effective C++: 55 Specific Ways to Improve Your Programs and Designs, 3rd […]


  3. Agile Roundtable Notes: October 1st, 2009 « Legalize Adulthood! Says:

    […] This discussion brought up the idea of self-selecting (or self-organizing) teams where people sign up for the projects they want to work on, regardless of whether or not its the same product/technology they’ve worked on before or a new product/technology. It was mentioned that if you have too many people sticking with the same thing for too long, then you may need to do a little manual mixing up of the people and their assignments. This is the “self-disrupting team”. The idea of self-organizing teams is discussed in Ricardo Semler’s book Maverick that was mentioned at last month’s roundtable. […]


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: