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
- By Ricardo Semler:
- By Kerry Patterson et al.
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.