« June 2006 | Main | August 2006 »

July 26, 2006

No Posts for Ten Days...

I'm in Beijing with limited connectivity. I'll be back to posting new material in early August. Thanks!

Posted by Mishkin Berteig at 07:24 AM | |

July 18, 2006

Affiliates Program Announcement

Berteig Consulting Inc. has set up an affiliates program similar to the Amazon Associates program. This allows people who sign up for the program to earn money on referrals to public courses that Berteig Consulting Inc. offers. You help promote Agile and earn some cash by putting an affiliate link to the public courses offered by Berteig Consulting Inc. (includes the ScrumMaster Certification course). Sign up for the affiliates program or read the details.

Posted by Mishkin Berteig at 09:31 AM | |

July 17, 2006

Personal Scrum - Another Story of Applying Agile to Personal Life

Early today, Pete Deemer (who presented at the May 2005 Scrum Gathering - notes from his presentation are about 3/4 of the way down the entry), posted his experiences of using the Scrum framework, with adaptations to manage his personal life. He has graciously consented to sharing his story here.

Pete Deemer wrote:

I wanted to share with you an experiment I've been running for the last several months, in hopes that it might spark some interesting conversation. It's the use of a modified version of Scrum for managing my life, and through trial and error it's become quite useful in helping me to do a better job accomplishing goals and filling my life with things that make me happy.

It started several months ago when I realized that my life bore some striking similarities to a dysfunctional software development project. Which is to say it was filled with a lot of unclear direction, goals that weren't being met, responsibilities and obligations going unfulfilled, and important "maintenance" that was being put off again and again – with a net result that "the product" (in other words, the experience of being me) was not all that it could be.

So I set about seeing how Scrum could be applied to improve matters. Here's what over several months I've found worked well for me.
Sprints last one week, and Sprint Planning takes place Sunday nights. I begin by making an estimate of the time I will have available to put toward my goals of the week – typically, this is about 10 hours (or about 1 hour per day during the week, and 2 hours each weekend day). My life backlog has at the top of it a recurring list of items that I consider "must-haves" every week – these are the things that I consider necessary for "the good life" for myself or those around me. I actually have them grouped according to the various personae that comprise "me" – husband, father, son, citizen, learner, body, and so forth. Organizing it this way helps me ensure I don't overlook an important part of who I am, as I think about what I wish to do in the week; it also allows me to aim for a balance among these different directions. So, for example, under "body", my standing backlog items might include "take vitamins on 5 mornings", "do yoga on 3 mornings", "get 8 hours of sleep on 4 nights", etc.

The criteria for an item to appear on the backlog is two-part. First, it must be important for "the good life" (now there's a topic that deserves its own posting if ever there was one). Second, it must be something that might not otherwise happen. So, for example, I don't need to put "brush teeth" or "go to the bathroom" on the list (or at least I haven't yet). I began with things that were chore-like (such as taking my vitamins), or which were enjoyable but required forethought and so I tended to miss them (like organizing an outing for my daughter and me). Over time, though, I found it useful to include anything that met the basic criteria above. For example, I love playing computer games; but I was finding that when life got busy, it would be one of the things that got squeezed out. Now it's an item on the backlog: Play an hour of computer games. It might seem a little odd to in a sense "make a date with oneself to do something that's akin to goofing off", but if it's goofing off that matters, it should be on the backlog.

Each of the recurring items on the backlog has a time estimate associated with it, and these become quite accurate over time, since they come up every week.

Once I've gone through the recurring backlog items, I move onto the non-recurring backlog items. These are either one-off things I need to do ("plan family vacation") or represent small progress against big goals ("complete 1 chapter of mandarin textbook"). I generally only have enough of my budgeted time remaining to commit to one or two of these items, but frankly, that's one or two more than I was committing to before.

Once I've made my commitment, I print up a sheet that lists the tasks and time remaining, and I post it in a very visible place in our house (kitchen wall). I'll sometimes talk through it with my wife for a few minutes, as a way of making the commitment even more visible and "real".

Then, just before bed each night, I'll do my equivalent of the standup meeting -- looking at the task list, marking tasks that have been completed, and mentally orienting myself to what I'd like to do tomorrow.

Then, when Sunday rolls around, there's usually a little scramble to complete some tasks, but Sunday morning is actually a great time to do this. My "Sprint Review" on Sunday evenings consists of looking over the tasks from the week, and giving myself a pat on the back for what I was able to accomplish, and if there are things I wasn't able to accomplish thinking about why. This leads into planning for the week ahead. In thinking about the week that's passed, I can adjust some of the goals for the week ahead. For example: if I've been feeling dragged out, I might adjust several of the items on the recurring portion of the backlog (increasing 8-hour nights of sleep from 3 to 4, and swimming from 2 days to 3); or if I have a busy work week ahead, I'll cut back my time budget, and make some calls about tradeoffs.

One of the things I've found is that for this approach to be successful, unbudgeted time must still be preserved. In other words, the time you allocate to personal scrum must be only a fraction of the free time you have available. Happiness depends in part on being able to decide on the spur of the moment to do nothing, or do something completely silly and unproductive, and do it without any guilt at all.

One of the areas where the approach falls flat is "non-standard" weeks – for example, going on vacation, or having guests visiting, or other situations where budgeting time in this way is undesirable or
difficult to do.

Overall, this approach has had a positive effect on my life, and the experience has been similar to that of teams I've worked with in adopting scrum: greater sense of clarity of direction, repeated satisfaction of accomplishment, greater confidence in setting personal goals, and a greater sense of contentment and peace around living up to one's responsibilities and opportunities.

I'd love to hear about others' experiences with other Scrum- or Agile-based life management techniques.

Posted by Mishkin Berteig at 07:26 PM | |

July 12, 2006

Agile and Loans - a Metaphor

There is a nice comparison that can be made between loans and agile. My father, an agile coach now, describes the metaphor this way:

[7:24:55 PM] Garry Berteig says: I mentioned an example of agile effectiveness in terms of Visa. [7:26:33 PM] Garry Berteig says: The waterfall example is to have to go to the bank for a loan, fill out forms in a meeting, reschedule for approval, and sign off on contract. On the other hand Visa lets the borrower make the decisions about how much and how often within a predetermined limit. [7:27:03 PM] Garry Berteig says: People go for Visa because it allows for iterations that are self determined, and very frequent compared to a bank loan process.

Posted by Mishkin Berteig at 08:05 AM | |

July 10, 2006

Test-Driven Management

An oldie, but a goodie, this short paper about Test-Driven Management is an excellent introduction to the topic. It is phrased in terms of the Extreme Programming practices, but it is generalizable to most types of agile work.

Posted by Mishkin Berteig at 11:26 PM | |

July 08, 2006

Updated Agile Work Cheat Sheets

I have substantially updated the basic Agile Work Cheat Sheet and the Agile Work Cheat Sheet for Process Facilitators. Please check them out at the Berteig Consulting Inc. Agile Work Resources page.

Posted by Mishkin Berteig at 05:40 PM | |

July 07, 2006

Agile Work Artifacts - Delivered Final Results

I've written a few previous entries about the artifacts of Agile Work: the Work Item List (or Backlog), the Iteration Tasks, and the Record of Obstacles. But I've left the most important for last: the actual delivered final results.

No agile process is worth the name if it doesn't deliver valuable results at the end of each iteration. In software, this means delivering running, functional, usable software every iteration. In documentary video, this means delivering a watchable, understandable story that communicates something about the topic every iteration. In construction, this means building a part of an edifice that can actually be used every iteration. In comic book production, this means creating a story told with pictures that is reproducable, comprehensible and engaging every iteration.

The other artifacts are all in support of this critical piece of the method. Only iterative delivery of valuable results allows effective learning and adaptive planning to take place.

Posted by Mishkin Berteig at 07:52 AM | |

July 05, 2006

Groups do Better than Individuals at Problem Solving

It's official. Someone has done a fully-controlled experiment to prove that groups are better at solving problems than even the best individuals working separately. For example, a group of three people, was better than the three best people working independently.

Posted by Mishkin Berteig at 10:17 PM | |

Agile in New York

Interesting entry about Agile Work practices being used in New York.

Posted by Mishkin Berteig at 03:32 PM | |

July 04, 2006

Lean Blog

Check out Panta Rei - Everything Flows, Everything Changes. This blog, by author Jon Miller, has extensive archives well worth poking through.

Posted by Mishkin Berteig at 07:09 AM | |

July 03, 2006

Agile Work Artifacts - Record of Obstacles

The Process Facilitator has only a few key responsibilities. One of those is to remove obstacles that are preventing the team for completing its work quickly, effectively and with high quality. The team's primary tool for tracking this work is the Record of Obstacles. Like the Work Item List, this is a fairly simple artifact.

The Record of Obstacles is a list where each entry in the list has three bits of data: a short description of the obstacle, the date the obstacle was identified, and a checkmark if it has been completed.

This list can be maintained on index cards, a whiteboard or an electronic tool such as a spreadsheet or wiki. The Process Facilitator maintains this list and all additions to the list go through this person. The primary source of items for the Record of Obstacles is the team's status meeting where each team member identifies any obstacles preventing them from doing their work. Additional obstacles may be revealed at the retrospective, or during the regular course of work.

The Process Facilitator should do his or her best to resolve an obstacle immediately. Lean manufacturing has an extreme example of this called "Stop the Line".

Ideally the Record of Obstacles is highly visible to all members of a team. This is so that everyone is aware of the current status of the obstacles listed.

Although this list is not normally prioritized, it is useful to do so if the list of un-resolved obstacles is lengthy. The Process Facilitator is responsible for prioritization of this list.

Posted by Mishkin Berteig at 09:33 AM | |