January 15, 2014
I'm committed to limiting my Work In Process (WIP) and to "stop starting / start finishing" but some stories/tasks just need to be put aside. I'm not talking about tasks that are blocked, waiting on someone else. Those I'll either flag or move to a Waiting/Blocked column. Rather, this post is about stuff that I need to stew on or need to come back to when my mind is ready. What do you do with those? Herein I'll tell you what I do, but I'm really interested in what you do. Please post your thoughts and ideas in the comments.
I don't have a HOLD column on my personal kanban wall. Hold seems to be a misnomer for me. It's a kind of lie. The work really still is in progress. It's WIP. I'm going to come back to it this week, maybe tomorrow, maybe even today. It ain't done.
I could split my task or story each time I feel the need to set one aside, putting part of it in DONE and part of it back in a ready column, but I kind of like my definition of what is a story, what is a task and what is a next-action (or sub-task). I don't want to monkey with that. Anyway, splitting stories is a kanban hazard.
PROJECTS, STORIES, TASKS, NEXT-ACTIONS & SUB-TASKS
For the following discussion you need to understand my context:
Getting Things Done (GTD), I note the next-action, or next several actions, on the Story stickie. Often, each one of these next-actions might take 5 minutes or less, so they don't seem to be a Story deserving of a stickie of their own.
So here's what I do for those tasks in that nebulous state of not done but not active either. I'd love for you to add your thoughts in the comments.
Some of my to-dos need time to stew, such as writing a blog post. I have lots of outlines and rough drafts. I create drafts quickly when the idea comes to me. Such activity never enters my personal kanban. In the spirit of GTD, if it takes less than a couple minutes to do, just do it. I very rarely create a Task or Story for such activity.
I'm pretty satisfied with how I do that.
IT'S DONE FOR TODAY AND A TODO FOR TOMORROW
I don't usually leave those in DOING for the week. If I've done it for today, I don't like leaving it in the DOING column. I usually move them back to some ready column each day. But it's still in progress for the week.
I'm not completely satisfied with how I do that. Sometimes I've left such a story in DOING.
What do you think about this? Do me a favor and post your thoughts in the comments before you go.
June 10, 2013
I recommend each team come to agreement on what's an acceptable maximum size for a spike. I recommend a day, or maybe two. If it will take more time than that, split it, just like you would for a story. Spikes need to have a clear acceptance criteria, a very specific question to answer. When the time-box is over, share the results with the team.
Often, such larger spikes are related to a user story and typically must be resolved before the story can be estimated. But for the spikes themselves, I recommend NOT estimating them. We want velocity to represent value added stories -- we want to measure the rate at which we add value. Either way, when using your velocity, when making release plans, you must understand your system and take into consideration when and how you come up with spikes and when you solve them. Do you find them late? Do you know about them but implement them late? If so, that represents unknown schedule risk.
I used to say that a consistent stream of day-sized spikes is good, but when I said that I would often forget to explain my context and assumptions. Having a continuous stream of new spikes that you solve almost as you create them makes sense if you are also doing continuous planning (without batching into large releases or without release commitments). Solving small spikes regularly keeps this activity from making velocity unstable.
Conversely, if you batch requirements into releases greater than, say, a couple months and if your organization is making release commitments, then in that case spikes represent risk in your backlog. Might want to knock out all spikes for the release right off the bat.
Wow, this is just my first post this year. I've been very busy with my LeadingAgile clients. It's time to get back to my writing!
November 15, 2012
Here are the sketchnotes from my November Agile Immersion workshop.
These sketchnotes were done by a business partner of mine, Jenny Trautman of evenview. Sketchnotes aren't the main thing evenview does -- sketchnotes are an artifact. What evenview does is help people bring innovative strategies into focus. They lead fun, high-energy meetings using interactive visuals that draw a team together. With their support, groups collaborate to develop a shared vision, create a plan for action, and implement their ideas. Use them for your next strategy meeting or kickoff.
By the way, this workshop is designed for everyone. No agile experience or programming skills required. All types of roles have found it benefical: product managers, marketers, managers, office managers, business development executives, developers, testers, CFOs, and etc. Check out this interesting blog post from a recent non-developer attendee.
October 29, 2012
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
Most Successful / Least Successful
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.
October 24, 2012
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.
October 2, 2012
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.
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.
Too bad this is a fallacy. The fallacy is that for each desired outcome B there must exist a cause A.
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...
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:
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.
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.
September 22, 2012
The Distance Theory
The likelihood of a team voluntarily using an agile space...
- is indirectly proportional to their proximity to each other.
Teammates are unlikely to use the shared space if their cubes are only three steps apart.
- is directly proportional to the sum of the distances between the cubes of the team members.
The more scattered the members are, the more likely they are to meet in a common location. Therefore, the likelihood of a team using the space may be proportional to the team size. This rule holds as long as that aforementioned sum of the distances is greater than the sum of the distances from the cubes to the agile space.
- is directly proportional to their proximity to it relative to their proximity to each other.
No one will use an agile space that is much further away than whichever cube is most central.
The Equipment Theory
The likelihood of an individual voluntarily using an agile space...
- is directly proportional to the computer speed and display size of the team computers relative to that of the computers in their cubes.
Equip the agile space with the most powerful PCs and beautiful monitors, and keep it that way.
The People Theory
The likelihood of a team voluntarily using an agile space...
- is directly proportional to likelihood that the team-lead (or some core, key individual(s)) can usually be found the lab.
Social aspects and the exchange of info/ideas matter.
- is directly proportional to the cohesiveness of their tasks.
Programmers working on disjoint tasks are less likely to use a shared space.
- is indirectly proportional to the number of teams using that space.
I can easily listen in or tune out discussions between my team members. Discussions between members of other teams are not easily tuned out. (Cognitive dissonance.)
The Environment Theory
The likelihood of an individual voluntarily using an agile space...
- is directly proportional to the positiveness of daylight.
Daylight is a positive and negative factor.
- Daylight good.
- Glare bad.
- Looking at distant objects good. Reduces eye strain.
- Heat bad.
- Working shades are good.
- Dysfunctional shades are bad.
September 10, 2012
The point here is that they were innovative in coming up with a BVC that radiates status and helps them communicate. Too many teams get stuck in a rut, using the same old ineffective ways of doing their standup. And often abandon the practice altogether.
The ToursIt was neat to see the Kanban being used by one of the teams and to talk about how they were using it and what they were getting out of it. It was cool to talk about their facilities and compromises they made and how the layout impacts pairing and team size. And we had good discussions about estimating tasks and stories. And other stuff too.
We've had prior tours as well and in each the host has had surprising candor, discussing the honest state of their agile practice including their current struggles.
Alex Kell wrote a nice post about the earlier Agile Tour @ Allure.
And the RedPrairie Agile Tour was neat because we got to sit in on an end of iteration innovation demo, a kind of a technical show and tell across several teams of some neat new technologies they've experimented with or put into place.
I'm planning other tours as well. Follow me on twitter and subscribe to the Agile Atlanta yahoo group to make sure you don't miss the next one.
Each company that has hosted a tour has gotten something out of these tours as well. Let's set one up at your company. Give me a call or drop me an email today.
September 5, 2012
Writings about the Kanban Method eschew story estimation as being both waste and inaccurate. Even relative estimation. So instead, they recommend understanding your system well and gathering the metrics on average lead time. With that data you can compute how long it would take to complete a backlog of work. Even some Scrum teams are beginning to use this approach. I like this method.
But to use this approach you must truly understand your system. I'm talking about understanding the behavior of the system and in particular the actors in the system.
For example, it's common to split stories once they get higher in priority and closer to development. That's a good thing and it happens in Scrum and in Kanban. This refinement may happen many times to a story during it's lifetime. I guess that most teams are completely unaware of just how many times stories are split along the way. Often I see stories indirectly split; Setting out to rewrite a set of stories, the set will be thrown away and a new set written, with no one noticing that there are more, and finer grained, stories in the new set.
A similar effect happens in Scrum when teams estimate defects and include those points in their velocity. They most often have no estimate for defects that have yet to be discovered (neither in quantity nor magnitude of effort). If a significant number of new defects are coming in all the time, then such teams are inflating their velocity and underestimating the magnitude of their backlog. This is a recipe for disaster. Such teams wonder why they never hit their dates. Others blame it on a quality problem.
As an aside, any commitments regarding the completion of the backlog have to be in concert with the stability of the backlog. You need to compute a new end date whenever the backlog changes. But that's the same whether you are using lead time or relative estimates with velocity.
August 14, 2012
First, I reversed the board to flow right to left. This feels more like pull to me. I'm pulling work from the right rather than pushing work to the right. I think this will feel more like pull whenever the board is directly in front of me, or a little off to the right. If I could position the board out to the left of my desk, moving stickies left to right might feel like pull.
I prettied up the headers. The others were ugly. I was tired of looking at a sloppy wall. I don't mind the transient stuff to be sloppy, but I wanted the headers to be a little more neat. I could have done a decent job if I took my time, but I decided to ask my awesome wife, Laura, to make new headers for me.
As part of that, I cut the header stickies down to about a third of the size of the stickie. This, plus writing them with a sharpie, makes them look more like headers and also not take up so much space. This allowed me to feel free to move the header below the window muntin. When I first put the headers above the muntin I thought the muntin would feel like a heavy underline separating the header row from the other rows in a table. I think the muntin was too big for that to look right. Didn't achieve the desired effect.
I used to have "This Week" and "Today" columns. I really liked the "Today" column. I have been making a fair attempt to plan a day and a good attempt to do today's stuff today. But "Today" didn't always mean today. Sometimes it means "today or tomorrow but don't wait until the end of the week". Really, it meant something more like "Important and/or Urgent, don't let it slide".
Compared to how I planned and executed my days, I have been making a better attempt to plan a week but I didn't stick to the plan as much as I thought I would. For the most part, that's okay. I adapted as priorities shifted and as opportunities presented themselves. But I also let important stuff slide. "This Week" really meant something more like "Important and it might become Urgent if you let it slide".
Not sure how it will turn out, but I've now got Important, Urgent, and Important-and-Urgent columns. I can already see that I have lots of Important stuff. I couldn't really see that before. At least I'm not buried in Urgent stuff.
I also used to have lots of todos stuck over on the window stile. It was clear that I needed more room for my backlog. In addition to the stuff I had planned for Today and This-Week, I had all kinds of other stuff that I thought I should make a stickie for. There was stuff I wanted to do, but I just wasn't ready to do them. There was stuff that wasn't ripe; the timing wasn't right or there was another task to do first. All these things aren't exactly the same as Waiting. For me, Waiting is waiting for someone else. So I created the "Not Ready" column.
I had been putting recurring tasks above the header. That's stuff I wanted to do each week. I may still do that.
The new Maybe column is for stuff that is ready to pull but that isn't quite that Important yet. These tasks are things I can do if the mood strikes me. If I have the energy and focus to do a Maybe task but not the energy and focus to do something Important, then why not pull a Maybe task? This is a concept from Getting Things Done (GTD). There is a lot of overlap between GTD and personal kanban:
I've been stacking my Done stickies starting at the BOTTOM of the Done column, each one slightly higher than the one below it. This keeps the sticky part of the stickie on the glass so they don't fall off, but takes up less room on my kanban wall. This obscures the title of the done tasks underneath the top one, but that hasn't bothered me.
I clean off my done column each week, record my velocity (which I haven't really done anything with yet), have a retrospective, recycle the old stickies, plan my next week, and plan my day. I didn't make any changes to that.
DID YOU GET ANY IDEAS?
I hope you got some good ideas from this post for improving your own GTD or Personal Kanban. Would love to hear about any changes you plan to make after having read this. Before you go away, please post your immediate thoughts in the comments.