Personal Kanban Retrospectives

At the end of each week I do a quick retrospective on my use of Personal Kanban, the tasks I've completed, and the week in general. I don't do anything elaborate or time consuming. Just a simple evaluation of how I'm doing.

I use two particular approaches to my personal kanban retrospectives more than any other.

+s and Δs

With Pluses and Deltas I think more about what worked well and what I want to change going forwards. Sometimes I use 'Regrets' instead of 'Deltas'. I do look at the tasks I accomplished, but with this approach my mind considers more than the tasks. For example, some of my notes from prior retros include things like: relaxed, haven't been inbox-zero for a while, did I forget to plan?, someone important linked to my blog post, got a great lead from someone, so-and-so is unreliable, such-and-such didn't pan out, well prepared for next course, successful partnership with so and so, good blogging this week, etc. I use index cards for this style retrospective.

Most Successful / Least Successful

The other approach I use lots is to simply arrange my completed tasks by how I feel about them. Some I feel really good about. Some weren't so successful. Maybe some are neutral.

I'll take notes, again on an index card, on these high points and low points.

Not a Commitment

What I don't do is compare my actual achievement against a plan. I do "plan" my week, but it's not a commitment to specific tasks. It's more of a re-prioritizing of the backlog and preparation for the days ahead. I use that time to make sure I don't miss any commitments or fail to prepare appropriately.

I hope you found this useful. What kind of Personal Kanban Retrospectives do you do?

---

Register now for my 11/5/12 Agile Immersion Workshop. This low cost day-long hands-on workshop will guide you through an agile project, from inception through the first couple iterations. Through this immersion, you'll understand agile 1st hand. Lunch is included.

What I Discovered About Personal Kanban and Getting Things Done

Not long ago I wrote about some changes I made to my personal kanban. Today I'm writing about why I do this. Much has been written about the benefits of using Personal Kanban and Getting Things Done (GTD) so I'm going to stick to what I personally get out of it.

I get uneasy when I have lots of unfinished projects around the house, half-read books languishing, things I've started and have forgotten about. ADD runs in the family so I'm likely an undiagnosed sufferer. When I rediscover something I once thought was important and have since forgotten, I remember why I thought it was important and feel bad for having not finished it. I feel stressed about needing to put one thing aside and finish the newly rediscovered badger. It's a little stressful. Not "I can't take it anymore!" stressful. Just a nagging background stress. There are plenty of stressors in my life so I don't want to add more if I can help it. And I can help it.

When I first started using them, GTD and Personal Kanban made matters worse. And better. It made me feel worse because now everything is visible -- all the half finished projects and incomplete initiatives. Yet it made me feel better, knowing that I won't forget anything. It also helped me prioritize my work explicitly and stick with that prioritization for as long as that prioritization made sense. My kanban helps me remember why things are in the state they are in, being intentional about what I choose to do.

After a while, GTD and kanban helped me reduce the backlog of partially completed work. It helps me focus on work already started. It helps me not start new activities that are of equal or lower priority -- or things that have a lower Cost of Delay. Seeing how much I have in process helps me to stop starting new work and to start finishing what I've already got going on.

I also discovered how much longer it takes me to finish tasks than I thought. Oh, yeah, "blog post"; I'll just typety type, a little proof reading, maybe a picture and I'll be done in half an hour. Heh. No, not really. Takes me a bit longer than that for the type of posts I do and the care I put into them. And there are all the other things: tweet it, email it to the person who requested I write about it, put a notice about it on some appropriate LinkedIn group, get interrupted for dinner, go to an Agile Atlanta meetup, decide to finish it tomorrow after work, and ultimately edit this post again because I thought of something else that should go in, like this paragraph. Anyway, kanban helps me understand that I'm an overly optimistic estimator. Understanding that helps me put stuff in the backlog instead of just starting it.

Now I feel much better. Sure, there are new things that come along that are Important, Urgent or have a High Cost of Delay, and I'll increase my WIP for a while. And that can be stressful. But it's a different kind of stress. No more is it "I have all this work and it's out of control". Now it's "I have some important work to do, but I know what it is, what state it's in, where it is stored, when it's due, and I feel in control." I still have a lot I want to do. But I'm in control.

Sprint "Commitments" are an Amortized Death March

Matt's tweet is provocative: Sprint "commitments" are an amortized death march.

If sprint commitments lead to a death march, something is wrong in your organization. Sprint commitments could be used by poor managers to browbeat the team.

Hey, you guys committed to this. I expect it to be done!

Not good.

The risk of a death march, however, is not the reason to not have a strong sprint commitment. You can (possibly) fix that problem. You can (possibly) have good, enlightened managers. Besides, there are many ways to use Scrum poorly. Should we throw out every misused practice?

No. But sprint commitments are dubious.

It's not the sprint commitment we are after. It's not what we really want in the end. It has no value on its own. What we're after is that thing we hope to get from having the sprint commitment. What we hope to get is a team that is committed to each other, working together to finish what they set out to do. We hope everyone works on what we agree to work on rather than whatever darn thing anyone wants to do. We hope to not have unfinished work at the end of the sprint.

Sprint commitments → no unfinished work at the end

Too bad this is a fallacy. The fallacy is that for each desired outcome B there must exist a cause A.

A → B

In complex adaptive systems it doesn't always work out that way. I might even say it rarely works that way. Whether the sprint goes well or poorly, there are side effects of such policies. But this post isn't about the side effects. For the manager, though, when the sprint goes poorly the best possible outcome is...

Darn, this is harder than anticipated. But I committed to getting it done. Guess I'll put in some overtime.

If what is committed to is generally kept low (appropriate), pace should be sustainable over the long run even with some rare overtime. When appropriate overtime does happen:

That stunk! Not doing that again. Let's commit to less and plan better.

In this way, sprint commitment should drive careful planning.

But is careful planning in batch necessary or is it waste? It can be useful in some contexts, but bogus in others. What's the point of a sprint commitment if you are committing to something very small, knowing that you are going to add more work to the sprint? If we plan less work to meet a strong sprint commitment, and also plan to add more work to the sprint later, then we are approaching continuous planning and might as well make the jump to iteration-less flow (e.g. and use Kanban).

We want a stable velocity. We want teams to be predictable. But requiring a strong sprint commitment is neither necessary nor sufficient. It's other stuff that makes us predictable, namely: finishing sprints cleanly every time; good backlog grooming practices; good story estimation practices (if using Scrum); limiting WIP; not starting work you can't finish in time; the "keep it working" principle; refactoring and SOLID design principles; good release planning and intelligent use of spikes; and so forth.

Just work directly on that stuff.

Truthfully, I've used sprint commitments and have also gone without them. They are useful in certain context, and dangerous in others. I consider the leadership, the managers and scrum masters, the team's agile experience, and how much time I'll have to coach the team before making the call on sprint commitments.

Related Articles:

Matt Barcomb wrote a nice article on good and bad commitments. Go read that and the very thoughtful comments posted in reply.

I briefly touched on sprint commitments in my post on unstable velocity.