Pomodoro is the workout: Personal Kanban is the trainer.
Starting Is Easy, Finishing Is Hard
post-it
A wise man once told me, "starting is easy, finishing is hard."This has been my struggle my entire professional career, but I would argue it started as far back as grade school. I've always had projects and tasks to complete and deadlines to meet. I've tried multitasking. I've tried listing A, B, C tasks in a Franklin Covey Day Planner. It has been a lifelong struggle to find a tool or process that provides clarity to my chaotic, goal-driven life.As the manager of software engineering and project management teams, I've used kanbans in the past. In those applications, I referred to kanbans as "information radiators." Large billboards were strategically placed around the office so anyone could passively see the status of the current project. Anyone could see what the highest priority was, what was currently being completed, and what was being delayed. I believe the key to our successes was the ability to visualize our work. Everyone knew exactly what they needed to complete and everyone else knew if it was getting done. People were not allowed to go on to ancillary activities until their assigned tasks were completed. This constant feedback loop was very powerful.You would think if it worked so well for my teams, for business purposes, I would use it for myself for personal purposes. It took some time but I finally started using a personal kanban and I kick myself for not doing it earlier.In order to communicate my kanban to collocated teammates, I use a product called Zen by Enkari, Ltd. It is a web-based kanban and does an excellent job. It's simple, clean, affordable, and very scalable. Having a web-based tool like this also allows me to review my kanban at home and not upset my wife by having a large whiteboard covered with post-it notes in the sitting room. The other step I've taken is having a physical kanban at work. It looks exactly like my web-based kanban, right down to the color of the post-it notes. Anyone can see what work I have on my backlog, what I'm currently working on, or what I have recently completed.Despite my best intentions, I've always made managing personal tasks WAY too complicated. To the contrary, using a kanban is simple and it allows me to focus on what is important. I no longer multitask and get nothing done. I now limit my work in progress, focus on the task at hand, and finish.
The "Man, That Was Awful" Approach to Personal Kanban
Kanban is meant to be epiphany heavy, but process light. These approaches are meant to provide simple means to visualize how your work actually flows. Some tasks are going to be horrible. They are going to take longer than you expect, be harder to complete than anticipated, or even just really annoy you.In life, you want to do things that make you happy and not do things that don't. So why not start noticing what you don't like to do or what takes you away from doing the things you like?The MAN THAT WAS AWFUL approach is simple. When you finish a task and it was in anyway unpleasant - set it aside. Then, later, take a look at the tasks that were unpleasant and look for patterns. Were the people involved the same? Was it a resource issue? Do you just hate doing those kinds of things?After you see the patterns you can make choices like:
when to delegate
when to refuse work
what processes you might want to recreate
if you want a new career
to cry
Again, the point here is to make what you are doing explicit. Hopefully bad things will initially fall into some patterns that you can consider and reshape. Awful tasks should become less and less common as you can spot them coming and learn ways to deflect them.Photo by _Boris
GTD & Kanban: Similarities, Differences & Synergies Between The Two
flower_bee
In this article in the "GTD & Personal Kanban Series" we will explore the why? behind bringing GTD & Personal Kanban together.
What is Getting Things Done (GTD)?
GTD emerged as a highly effective and popular personal productivity approach in the early two thousands. The approach consists of a five stage process, a workflow to guide that process and a couple of techniques for handling choice around what to do at any given moment, what should be progressed as soon as possible or someday/maybe, and also, how to handle life and work's various horizons - from now at this moment, all the way through to what is important to you in life as a whole.
This article isn't a '101' on GTD, for that there are plenty of resources available, which are linked to here. On a personal note, I find that GTD frees my mind enabling me to focus totally on the tasks at hand, and also represents a concrete approach to help achieve Stephen Covey's first three habits of his famous: The Seven Habits of highly Effective People.
What is Kanban?
This whole site is about Kanban in the context of solving personal and group problems around the home and workplace, for a great 101 head over to here.Kanban has allowed me to increase the throughput of things getting done.SimilaritiesThough targeted at different problems, there are similarities between Kanban & GTD.
The breaking down of "stuff" into discrete items to be processed - With GTD this happens as part of taking each item from the physical and/or electronic inboxes and asking if it is actionable, and if so, what is the next physical action. With Kanban, we create stories which form the Kanbans themselves, to then be placed on a backlog.
Inboxes & Backlogs - These are both areas where potential work is collected, and represents the start of either a GTD process with inboxes, or a Kanban process with backlogs. The similarity here will differ based on context, and it's fair to say that with a backlog, some initial processing of the material onto the backlog may have taken place. With GTD, raw material is added to the physical or electronic inboxes.
Lists, lists & more lists - Both GTD & Kanban utilise lists. In GTD's case it can take any form as the process is not prescriptive in it's concrete implementation. In Kanban's case, there are lists, though they are split into dimensions, such as stage/state/work station the story is at, and there is additional process related information, like WIP limits and checklists.
Contexts - Kanban & GTD are very flexible in their applications. Both can be shaped to fit various situations. For example, manufacturing cars, or managing your reading list in the case of Kanban. GTD can have a "context list" for pretty much anything you can imagine, from a specific location to a situation you find yourself in, where certain work makes sense.
With both GTD & Kanban granularity is important - For GTD, it's not about writing lists of goals: "buy milk", "fill in tax return", but rather, GTD is concerned with determining the next action required and given the right context or time, just performing that action without having to constantly figure out the next step each time. In Kanban's case, it favours work items that are discrete, unambiguous and ideally of a similar "size" to reduce variance.
Support for levels of granularity - Kanban can achieve this with a kind of nesting of Kanbans and horizontal swim-lanes. Or, multiple Kanbans, one representing a higher level of granularity than the other, whereby the items in the "Kanban in the large" are related to those being processed in the "Kanban in the small". I use an approach like this with my current projects and their related current actions being processed. GTD achieves multiple levels of granularity with lists. There is: purpose, vision, goals, focus, projects and plenty of contexts, for example "At work" & "At home".
Addressing Waste - Kanban addresses waste explicitly as does GTD. Kanban using WIP limiting and "stop the line" techniques with a general attitude of continuous improvement. GTD insists that any piece of "stuff" that enters your world should be processed once and once only, by using techniques like a 'Zero Inbox' policy and the 'Two-Minute Rule'.
Pull - At the most abstract level, both approaches exist to process work to fulfill a demand. Both approaches pull work through a process to achieve the goal of getting valuable stuff done.
This is encouraging, it would appear that we have a lot to work with in terms of bringing these ideas together.
Differences between GTD and Kanban
There are obvious differences in the two approaches, given they are aimed at different problems. However, I find little that is polarised or in conflict but rather the differences are complementary in enhancing areas of non-existence or weakness in the other, when applied to personal productivity.
Reduced backlog size versus a clear head - Kanban comes from the world of Lean Manufacturing, where the Theory of Constraints philosophy is pervasive. Large backlogs are considered to be wasteful as the cost of maintaining them and the friction they cause impacts the value that will be generated. A backlog that is sized so that it is processed rapidly and renewed with new stories regularly is considered ideal. GTD is different to this, there are no caps, implied or artificial. GTD encourages a clear head, to reduce stress and allow complete focus on the task at hand. Obviously, there is a conflict there on face value. In the past I had GTD action lists with hundreds of action items on them, and project and someday/maybe lists with 10s of items.
Kanban allows for Work In Progress (WIP) limiting - GTD doesn't explicitly try to limit that which is being worked on in any hard manner, rather a softer approach which asks if something is relevant against focus, goals, vision, purpose or just plain want to do it now. Sadly, GTD can lead to thrashing, when the total number of options for doing is enormous. Kanban is all about focus, and if used well can seriously reduce the chance, let alone the act of context switching.
Visual control - Although I'm sure there are ways this could be addressed currently, as a whole, most GTD implementations seem to be light on visualisation of WIP. Kanban is all about visualisation.
Process definition - GTD has a definite default process, which is not prescriptive in so far it's not all or nothing. Kanban doesn't define a default, but rather provides tools to be used in a greater or lesser extent to get the right result in a context.
Prioritisation - In GTD there is no prioritisation as such. By virtue of the fact something is actionable, it will either appear in a context action list, calendar, waiting for (delegation) or may appear project list. With Kanban there are all kinds of ways priorities can be defined.
Time critical actions - Kanban is about flow, so specific times and dates aren't catered for. GTD does use calendars and possibly tickle files to cater for those things that do need attending to at a specific time and date.
I am certain there are more differences here, so please do highlight any to better our understanding.
Synergise
Lots of similarities and lots of differences, generally of a non-conflicting nature. The question is, where can we benefit from bringing these powerful approaches together? Lets see...Kanban can help GTD a lot! The problem I have had with GTD is flow, thrashing and WIP limiting at all stages in particular contexts, especially the backlog. I know there is waste there, given the number of times I have conducted a review and found:
It takes ages because of the size of the backlog.
I find out-of-date actions/projects, again due to the size of the backlog.
Feel like i should be getting some of the value of the review just by doing, instead of waiting for the end of the week review.
I have also struggled with pulling projects from the someday/maybe into current projects lists.
GTD can help Kanban in a personal productivity context by:
Providing a way for people to clear their heads to focus on what is at hand.
Excellent techniques for identifying what should be done or not.
Doing actions not goals, by forcing the right questions at the beginning of processing "stuff", instead of constantly asking what do I need to with this?
Handle work that needs to be on the calendar and most importantly some simple rules to motivate doing! The Two Minute Rule being a great example.
Delegation.
Levels of focus in life and work. Kanban doesn't address what it is you are flowing toward.
Over the coming posts in this series I will try to illustrate the above synergies with examples. Again, please do comment, I'm keen to explore this more myself.
Recursive Kanban – A Visual Control for Rapid Knowledge Work
Recursive Kanban in Action
Recursive Kanban for Small Groups
A visual control is anything that allows a group to see their progress, and understand its relative importance. To be sure, a kanban is a visual control, but there are nevertheless some limitations to it. The biggest limitation to a kanban is that it is linear. Work, especially knowledge work, is not always linear.At a recent WriteShop Tonianne and I ran at the World Bank, we set out to run the process with a kanban. It quickly became apparent that the linear flow of the kanban was not going to work with the rapid and recursive iterations of this particular project.This project set out initially to create a document in five days that was made up of several modules. When we started, each module was in a different state of completion. The original assumption was that there would be a workflow that went something like “concept,” “components,” “outline,” “draft,” and “final,” and we’d make a mission-based kanban for each module.What ended up happening was very different. Scientists from around the world sat down on Monday and, fully aware they were not ready to write, instead began to talk. Those discussions redefined what exactly was needed for each module. That was good.What was even better was the evolution – the discussion became a product development discussion. Who was the client? What did they really need? What could this group produce by the deadline?And suddenly we had a spreadsheet model the clients could use for doing the analysis described in the document. That model, in turn, drove an entire, organic, and rapid rethinking of the layout of the entire document. Suddenly we had coherence.Then … it was time to write. We set up a visual control that was deceptively simple. The control has 4 columns: “Module,” “Outline,” “Text,” and “Draft.” This was because we knew that the workflow was not going to be linear. As text was written in the document, it informed what else needed to be in the document. Therefore, some outline would be written, then some text, then the outline augmented, then more text, then some discussion, then more outline, and so on.This means there was no “pull” from outline to text. So we used numbers to mark a 1 to 10 level for “complete” and checked back a couple times a day, crossing out the old numbers and entering new ones.The “Draft” column quickly changed to an “Issues” column. This allowed us to have very detailed stand-up meetings (short 10 to 20 minute discussions) about status twice daily.At each stand-up, the numbers would be entered for each stage. Sometimes they would go down. If you look closely, you can see 8s go to 7s. The group found that amusing, but what was happening was they were learning more and more about what “Complete” in this particular context meant. Clarity for the deliverable was rising on a daily basis, even if the estimation of complete was falling.Some days the “text” ranking would go up, even as the ranking for the same module’s outline fell. People were writing text, discovering new needs, then noting that they weren’t yet incorporated in the outline.The visual control allowed us to build a type of kanban that we might call a “recursive kanban” - a visual control that allowed for the productive loops in knowledge work. Linear kanban has a hard time dealing with productive loops like this.