Where: Twitter
Hashtag: #pkflow
Save the date because Modus Cooperandi is hosting a "Tweet-a-ban." Whether you're a Personal Kanban practitioner or just have an interest in improving your productivity, join in on the asynchronous, 24 hour long global conversation.
For details click here.
Last week I had the good fortune to conduct a one-day seminar on Enterprise 2.0 for the Finance Industry in Zurich. I attended Somesso 09 as an instructor with Dion Hinchcliffe’s Web 2.0 University. Somesso is an Enterprise 2.0 / business social media firm based in Switzerland. They host information-packed conferences directed at specific verticals. Whereas this conference focused on finance, Somesso brought in a range of highly relevant trend setters and trusted names in the industry.
While I went armed with a well-stocked arsenal of slides describing every nuance of E20, my primary goal was to ensure attendees - a healthy mix of curious novices and experienced practitioners - left not only with a clear understanding of techniques and technologies, but also having had the opportunity to learn from the collected wisdom in the room.
The first half of the seminar focused on covering the nuts and bolts of E20 as quickly as possible. To be sure this is a challenge, given that E20 can be employed in nearly every aspect of a business to include business intelligence, customer support, production, advertising...the list goes on.
With the groundwork firmly established, the afternoon shifted towards conversation and workshopping. I was blessed to have people like Marilyn Pratt (SAP’s community evangelist), Anu Elmer (Swiss Re’s internal community manager) and David Terrar (CEO of Wordframe) in the group. Having them share their experience and expertise with the room meant that exploration could then be handled by means of a lively discussion – rather than by merely having just another question and answer exchange.
Through the course of the afternoon the conversation centered around two main issues: rewards and hosting communities.
Rewards: The group expressed interest in how to attract participation to internal or external E2 communities. Why would people participate? Why would they help manage?
We discussed how most communities are gameable systems, and the construction of the community (its rules, attributions, and rewards) would guide how people used the system. In most active communities "super-users" often appear, helping to manage the community and (as it often works out) provide much of the content. Business management software provider SAP refers to these individuals as "ambassadors." Superusers tend to share copious amounts of information, proving to be invaluable resources subsequently gaining prestige and expanding their network. The larger one's network, the more opportunities result.
Hosting Communities: During our discussions, the power of communities for business became clear. When other organizations recognized Swiss Re and SAP's success in hosting their own communities, they wanted to host them too. This led to a lengthy discussion about the financial and opportunity costs of hosting a community, the staff it would necessitate, and the finesse that becomes indispensable when managing an open community.
Most interesting was seeing the realization that an organization didn’t necessarily need to "own" the community to derive value from it. From a marketing standpoint, the company's natural inclination was to "own" the community, to make it an extension of its brand. However, as our discussion of community progressed, some came to the realization that they may actually be better served working with existing communities elsewhere rather than trying to host their own. Some communities were already active elsewhere, and some felt that their customers were more comfortable being in an environment not specifically focused on their money.
--
Somesso hosted a lovely event at the Swiss Re Centre for Global Dialogue. The location overlooking Lake Zurich and the Alps was perfect for eliciting contemplation and provoking thoughtful conversation. My thanks to Arjen Stryker and Judith Koch for bringing me in to work with such fantastic people.
I’ve managed a lot of projects. I tried to count them – I can’t. As I’ve progressed in my career, I’ve embraced a succession of methodologies that cumulatively represent a rather predictable evolution away from zero sum game management towards non-zero sum game management.
What does this mean?
As the science of project management evolves, we are clearly learning that managing based on guess work is a recipe for consistent failure. Traditionally, we managed projects based on the trusted opinion of a project manager who estimated the length, scope, cost, and resources required for a project. These project managers have a natural tendency to underestimate, and their guesses are vetted through a process designed to save money, rather than arrive at an accurate estimate.
While well-intentioned, agile methodologies have not appreciably changed this process. In the end, agile projects still obtain their backlogs in bulk and gather up-front estimates prone to error. For all of agile’s intentions, agile projects seldom break out of this pattern, even if they are well managed at the team level.
The top five reasons I see projects fail are (1) No slack in the system (2) Managing for the knowns (3) Not limiting work-in-progress (4) Political promises and (5) Sloppy communication. Let’s examine these:
1. No Slack
Every system requires slack in order to work correctly. Old reel-to-reel tape recorders needed an extra bit of tape fed into the mechanics to ensure that the tape wouldn’t rip. Roadways operate best at 65 to 70% capacity – they bog down over 80 and are at a dead stop at 100. In mills, grain is fed into the stones at about 70% capacity – anything over that gums up the works and makes the mill grind to a halt.
Why, then, is slack so foreign to project management? Because we negotiate it away every time. Why do we do this? Because we estimate at the individual task and not at the project level.
It’s like saying “Yes, my Porsche can go 185 miles an hour” and estimating a 90 mile drive at 30 minutes. Then we’re surprised when there are other cars on the freeway.
“Contingency” funds rarely work to abate this problem because contingency is not real. It is arbitrary and has no basis in reality. It is a lie. Without understanding our throughput, we cannot adequately estimate a project.
Successful project managers understand how long tasks usually take, what role variability plays, and what types of tasks slow their processes down.
2. Managing for Knowns
We manage for knowns. When we estimate, we use our history to '”know” when the project will be completed. We manage for people doing what we know they will and when they know we will.
That’s not a good idea.
Human systems are complicated. Yes, we can finish that task in 3 days provided no one gets sick, there isn’t a power outage, there isn’t a blizzard. Well, there are colds and blackouts and blizzards.
Successful project managers worry less about making sure their Gantt chart is religiously adhered to or if their two-week iteration goes unhindered and more about how to elegantly deal with the unexpected.
3. Not Limiting WIP
Again, people and teams have a capacity. If you exceed a certain percentage of that capacity, people become stressed, distracted, and increasingly ineffective. If a Freeway at 100% capacity is at a stand-still, its throughput is 0%. If your people are at 100% capacity, their throughput is likewise seriously impaired.
Limiting work-in-progress (WIP) is vital for maintaining throughput. Intentionally limiting WIP frees people to maximize their effectiveness by ensuring they work at an adequate percentage of their capacity. In turn, WIP is used to limit the number of features the organization can feed a team at a time. This helps the organization appreciate the true opportunitiy costs of new features. WIP limits communicate that employees are a limited resource and helps upper management understand the true cost of labor.
Successful project managers understand the capacity of the individuals working under them and can regulate the flow of work to optimize their throughput.
4. Political Promises
Politics are stressful and are often no-win situations. Project managers are often placed in political situations that force them to promise to produce more with less resources. (“Can’t you just add this one additional feature?”) Project managers cannot win these political situations because they don’t understand their true throughput. Project managers need to concretely show true productivity statistics to weather these confrontations.
Being able to say with firm evidence, “It takes us 21 days to release one new feature” diffuses political pressures and opens the door to real discussions.
Armed with a firm understanding of their operations, successful project managers can avoid overpromising due to ignorance.
5. Sloppy Communication
Teams run on information. In my experience, most delays and waste can be traced back to communications. Do people know why they are doing what they are doing? Does the team know what their co-workers are doing? Are recent developments rapidly disseminated so workers feel at-ease? Are the actions of the team being communicated up the management chain? Is the value of people’s actions understood by all? Are improvements to the development system being quickly discussed and acted upon? Is waste being spotted and dealt with?
Now that we have a multitude of tools to communicate with, poor communication simply can no longer be tolerated. The increasing commoditization of goods and services leaves profit margins too slim to tolerate that waste.
Successful project managers build social systems designed to rapidly disseminate information, keep team members informed, provide a pipeline to other areas of the enterprise, and improve operations.
Closing
Agile methodologies are great, I’ve been using them since 1997 when William Rowden and I first built our TreePro product. They went a long way to solving some of these tensions. Prior to that, as an urban planner, I managed multi-million dollar planning and engineering projects. As we move forward into the 21st century we need to understand that all knowledge work (which includes both software development and urban planning) requires a more adept type of project manager: a project manager that manages for the unknown because they understand the knowns very well – and those knowns include what were previously unknown: variability, waste, and politics.
Disclaimer: This is a blog post. It is short. Food for thought. Just think about it.
As software as a service becomes mainstreamed, I’ve been watching how startups monetize their applications. The straight subscription model is the default. However, the recurring costs of a subscription model seem to annoy people as time goes on. If you aren’t using too many SaaS products, one or two subscriptions are tolerable. When you move up to 5 or 6 products you begin to get subscription fatigue.
In-game economies is one answer to subscription fatigue. Evony is a massively multiplayer real time strategy game that’s made a quiet entrance, but has amassed an impressive user base. It’s “always free” motto promises complete game play, but monetizes objects in the game. This gives the game player the freedom to buy into the game as much or as little as they wish. For Evony, the price can be free to whatever they’d like to spend.
Individual players in the game can join alliances which provide mutual support, protection and reinforcement in battle. As the communities solidify, Evony has made several game elements exchangeable, but several others are not. This creates an internal economy of need. If your team needs your participation and that requires an object you might be able to find, that puts creates a social need for that object.
Playing alone, the gamer might wait for a few days or even weeks until they find that object. The social need becomes a powerful element in the Evony business model. In light of this, it seems that Evony would benefit from creating functional groups of their buyable objects.
For example, when starting a new city in Evony, players need to quickly establish a lot of easily constructed structures and populate the city. Some of the things you can buy are “guidelines” that hasten construction and “boxes” or “packages” that can have people or resources. A “new city” package that included people, resources and guidelines would be what I’d expect to come next.
The communities grow quickly in Evony and can determine whether someone will make it in the game at all. They should be the first aspect of the game to leverage for Evony success. So, the next area I’d go for if I were Evony would be to provide community discounts. So if you are part of an alliance that spent a certain amount on Evony, the entire alliance gets either a kickback of game currency, a discount or a package of some type.
The next thing I’d do is monetize game participation. If you have a 100 member alliance but only 10 of them actually participate, that’s not worth much. But 100 members where 80 regularly participate is impressive and should be rewarded.
SaaS products outside the gaming world can learn from this as well. It’s not necessarily the software that is being monetized, it’s the performance of the user. Counter-intuitively the product becomes more valuable to the individual as their usage increases. This value increases exponentially as the network of users increases (Reed’s Law).
We’ve seen that networks don’t make an application sticky, but the activity of a network does. Evony has been interesting to watch as the activity of the alliances have brought people back to the game. This makes it “coopertainment” – entertainment that required cooperation in order to enjoy (and monetize) fully.
PAY NO ATTENTION TO THE MAN BEHIND THE CURTAIN!
What is the curtain?
The enterprise is the curtain.
In concurrent posts, SocialText’s Michael Idinopulos discusses killing pilot projects and the true nature of Enterprise 2.0. He explains:
Enterprise social software isn't one application. It's a range of collaborative modes that includes blogs, wikis, micromessaging, personal dashboards, collaborative spreadsheeting, and social bookmarking.
When Michael discusses killing pilot projects (small rollouts as proofs of concept), he is spot-on in saying that the real value inherent to those types of projects is borne of network effects, not in the efficacy of the technology. So pilot projects = proving the tech and not realizing the business value. It would be like if I told you I wanted to know what University life was like, and you suggested I speak to a professor for a day to “try it out.”
Today, Dion Hinchcliffe compiled a list of Web OS trends. His first one is perhaps the most important:
Innovation is one of the easiest and least risky areas that can be tapped by most organizations.
Michael and Dion's quotations complement each other beautifully, and can be restated as:
Enterprise social software isn’t one application. It’s the realization that innovation has become the easiest and least risky way to solve problems within an organization.
Perhaps most important here is the word "enterprise." I submit that the term has fundamentally shifted from a consolidated model to a distributed one. The enterprise is no longer a central node with dependent groups hanging off of it. Rather, it has evolved into a network with greater nodal autonomy, faster communication, and improved decision making power.
This nodal structure was there all along. We see it in the human circulatory system, we see it in the layout of ant colonies, we see it in flora and fauna.
The hierarchic enterprise is the curtain. We have been fooled into believing that there is, or even should be, one central corporate OZ qualified to make all decisions. Over time, centralization has created costly information and decision making bottlenecks. Does this mean hierarchy is dead? Obviously not.
Enterprise 2.0 is not a panacea, it is a tool to allow corporate structures - congested by unnecessary bottlenecks - become leaner organizations. By redistributing information and decision making, companies limit waste, reduce costs, and are afforded the freedom to innovate. Microenterprises joined as nodes to a larger enterprise have the simultaneous ability to function both independently and as part of a cohesive whole.
What this means for Enterprise 2.0 is not that it becomes the next ERP, but that it becomes a host of spot-applications or, as Michael says, collaborative modes that allow us to realize Dion’s inexpensive and relatively painless innovations.
P.S. I really appreciate Michael’s “collaborative modes” – it re-orients the conversation from one of techno-miracles to one of business process. Not what are we going to use, but what are we going do?
Blogged at Ebeneezer’s Coffee House in Washington DC.
Photo by Tonianne
When I began to write a succession of posts on personal kanban back in July, I thought a few people might benefit from the idea. I never expected that the series would attract tens of thousands of viewers to my blog, Evolving Web.
Less than two months later, there is a growing and enthusiastic personal kanban community which has been posting photos, discussing innovations, and advancing the meme. In a few short weeks, the community grew large enough to support a dedicated web site.
So I am pleased to formally announce the launch of personalkanban.com, a blog and resource for personal kanban. Already, about a dozen guest posters and regular contributors have stepped forward to take the meme and run with it.
Those of you who have been reading Evolving Web for a while know I’m all about community, process, and collaboration. Seeing this community form, that it’s based on a lightweight personal process, and that collaboration is already taking place is therefore an awesome birthday present for me this year.
Please give the personalkanban.com a visit and subscribe to the feed. If you have personal kanaban stories to tell, please e-mail me at jim !at! soundbag !dot! com. The community would greatly benefit from your experiences and writing.
Integration is Enterprise 2.0.
This week my friend and colleague Dion Hinchcliffe posted an article on ZD Net describing 14 Reasons Why Enterprise 2.0 Projects Fail. In it he paints a picture of valiant workers surreptitiously cyber-skulking on dank distributed web sites, efficiently working and making money for their companies – all the while keeping an eye out for dagger-wielding IT staff looking to keep their security models and networks digitally pure.
He’s right, this absolutely happens. I’ve seen it in small companies, government agencies, and Fortune 10 behemoths. It is beautiful.
These localized projects are the seeds of true Enterprise 2.0.
Dion’s list of 14 reasons is long, so I’ll let him tell that story (read his post). Here however, we can discuss how those "failures" might fail outright or undervalue success, but our collective definition of success may need some rethinking.
Several of Dion’s 14 (2, 3, 8, 10, 13 and 14) revolve around building Enterprise 2.0 environments that people will use and in the provision of a corporate culture in which they can be used. Another group (4, 5, 6, 7 and 11) call for a coordinated social management plan. Political buy-in is covered in 9 and 12.
Dion’s #1 reason is that solutions can end up being departmental successes, yet not work their way into the rest of the organization.
I believe in the loosely coupled aesthetic.
Those departmental successes that don’t spread to the organization (Dion’s #1 type of failure) may be the real definition of Enterprise 2.0 success.
Corporate Social Management Plans should lay out flexible and forgiving models where workers can select any application they want, and IT should provide simple APIs to connect to any relevant central data hubs. Corporate cultures should back up these plans by rewarding the active seeking out and usage of tools to solve specific problems. Workers should be empowered to use the best tool for the job at the time.
Dion is absolutely correct, Enterprise 2.0 should be about flexibility and solving problems and not about the pervasive use of specific apps across an organization. Why? Because there is a tipping point between what is a popular application and what becomes an institutionalized application. Once we hit that tipping point, it’s no longer Enterprise 2.0.
To sum up
Enterprise 2.0 should be a structure that allows great flexibility in the choice and use of applications throughout an organization, supporting the applications with APIs to allow data to be taken from and deposited into central data stores.
And
Enterprise 2.0 currently “fails” because we are attempting 1.0 deployments of 2.0 applications.
Photo by Certified Su
In the previous post, we discussed why you would want to measure your performance in Personal Kanban. Today I’ll begin with the most powerful - but perhaps most intimidating - technique. In upcoming posts we’ll look as some less intense methods, so don’t let this post scare you.
In kanban for software design, a "cumulative flow diagram" is used to track performance. A big part of the cumulative flow diagram is its ability to visualize how close you are to completion of a large project, and where bottlenecks or waste appears in the process. It’s a very powerful and descriptive tool.
Above is the cumulative flow diagram for the Modus Cooperandi Personal Kanban. The diagram illustrates how many tasks we have in a given part of our workflow. This is our workflow, so you don’t need to emulate it. The components are as follows:
Backlog: Items that have yet to make it into the workflow.
Priority 3: Items that are coming up in importance.
Priority 2: Items that are important.
Priority 1: Items that need to be done soon.
Working: Items in the process of being done.
The Pen: Items that are waiting for external input.
Complete: Items we’ve done today.
Archive: Items we’ve completed in the past.
On this particular day, we completed 96 things in the past, accomplished 2 that day, sequestered 3 in the pen, and so forth. Of course, as time goes on, your archive is going to become bigger and bigger. In a directed project with a finite number of tasks, this is a very important part of the diagram. For personal kanban however, where tasks will build up forever, it shows us how much we’ve done or are capable of doing.
Simply from a flow perspective though, we might want to eliminate that part of the diagram.
So here, with no archive, we can discern some interesting patterns.
First, we see where we complete some serious work. We also notice where we gain a lot more work. So on days where there is a tremendous dip in the number of tasks, in the above chart (but no dip in the first), we know that we moved a tremendous amount to the archive.
We can also see where we build up backlog again. So, essentially what we have here are two graphs that show us (1) we are completing work and the number of tasks completed is continuing a fairly uniform rise, and (2) we see the actual variations in our work and when we take work on.
Since the chart is a time slice taken daily at midnight, the parts of the kanban with a WIP limit should be uniform, and represented by fairly flat bands, with the only variation coming from “The Pen,” “working,” and “done.” If we have work in the backlog, we should be maintaining a fairly even amount of work in the queue. The diagram illustrates that we've been working to achieve this, and as we’ve worked more closely, the uniformity is starting to manifest itself.
What we want to avoid is having the backlog band grow at an alarming rate. We want work there to feed the queue, but if it gets too overwhelming, we then know we have to start saying no to tasks.
The time it takes to move a task from backlog to completion is called “lead time.” The time it takes to complete a task when you start working on it is called “cycle time.” “Work time" is how long tasks were on your board, and active. “Wait time” is how long a task sits idle in a queue, while waiting to be moved. In a personal kanban, you might move one or even dozens of tasks across your board in a single day, so for you these are the numbers to watch for variation.
If at some point you notice your lead time jumps to 20 days, it’s obvious that you have too much backlog. If your cycle time jumps, something is stopping you from starting work. If your work time jumps, something is stopping you from completing work. If your wait time jumps, something might be stopping you from working at all.
So...how do you measure this? At the end of each day, you can track the information in the cumulative flow diagram by counting the cards in each part of the work flow, and entering them into a spreadsheet. For the “times” you can write start and end dates on the cards, and calculate from there.
Or you can use Agile Zen - which is where these images came from - and leave the tracking up to Nate.
One cannot choose wisely for a life unless he dares to listen to himself, his own self, at each moment of his life.
- Maslow, The Farther Reaches of Human Nature
Okay, so we’ve gone through several ways kanban can look, be used, and operate. We’ve discussed ways to prioritize work. But we have yet to address how to measure (gulp) performance. But what exactly is “performance,” and why do we care?
Toyota’s Taiichi Ohno is credited with the initial deployment of kanban, and the creation of Lean and Just-in-Time management concepts. His goal was to make Toyota the world's leader in automobile production, so he needed some metrics. Ohno understood that simple numbers did not drive performance, but that Toyota's staff and its suppliers needed the will to work better.
Along the way, physicist Eli Goldratt came up with the Theory of Constraints (TOC). (You can hear Goldratt say he needs 4 days to define TOC in this video.) His glowing gem of wisdom is that we conceptually overcomplicate problem solving by identifying way too many constraints to arrive at a solution. When we want to get to a goal, we tend to lose the goal from all the little issues that surround it. But, usually there are one or two big constraints that, if solved, will both provide huge results and often solve a lot of the little constraints or make them irrelevant.
The beauty of both these messages is that small changes make big differences – if they are the right small changes. What do you need to identify the right small changes to increase the will to work better? Awareness.
Personal kanban helps give us that awareness, enabling us to begin to listen to ourselves. A few posts back I discussed retrospectives, how they were vital at the beginning and became less so as we incorporated self-improvement into our normal actions. As you focus less on that massive pile of little nuisance constraints that surround you, and move instead to the high-payoff constraints, you move to what Ohno calls a “kaizen” state. You begin to continuously look for ways to improve your quality of life.
Please notice, I’m not telling you how to improve your life or even suggesting what improvement looks like. That’s totally up to you. If you want to work towards helping to save the rainforests, that’s fine. If your goal is smoking 10 cartons of cigarettes a day while watching cage fighting...well, I guess someone has to do it. Our goals are our own. They’re not for retirement, they are for living. If you want wifi and code, you design your life to allow wifi and code.
If we can clear the big things that Goldratt calls constraints or Ohno calls waste from our plate, what’s left is a clear and open space to do some real living.
Musicians must make music, artists must paint, poets must write if they are to be ultimately at peace with themselves. What human beings can be, they must be. They must be true to their own nature. This need we may call self-actualization.
- Maslow, Maslow on Management
In upcoming posts, I will cover a few ways - some absurdly simple, others a little more complicated - for how your personal kanban can tell you some pretty amazing things about how you work. Hidden in those post-its is some pretty awesome insight.
Image: The Programmer’s Hierarchy of Needs
cc. David Flanders
We’ve started a Facebook group for Personal Kanban, a dedicated web site is on the way, and a book is in development. I’m still tweeting about personal kanban through my personal twitter. If you want to read the existing personal kanban series, just click the link!
We really weren’t expecting personal kanban to take off like this. This inadvertently added to our workload (making our personal kanban even more important!)
As always, if anyone is working with personal kanban, we’d love to see you post your experiences and pictures on twitter, on your blogs, in the facebook group, or contact us and we’ll have you guest-blog on the upcoming personal kanban site! Everyone’s stories are as individual as their work is. The more stories we can gather from different individuals and groups, the more we can punctuate how this is an adaptive tool and *not* a one-size-fits-all personal management pipe dream.
A wiki is a website anyone can edit.
A kanban is a workflow anyone can edit.
A wiki entry is always able to be improved upon.
A kanban card is always able to be refined.
In wikis, there is a constant reification of ideas.
In kanban, there is a constant reification of work.
In wikis, incorrect information is identified by the group and excised.
In kanban, waste is identified by the group and excised.
A wiki stores and displays information to make group effort available to all.
A kanban stores and displays information to make group effort available to all.
A wiki stores and displays information to make personal contribution explicit.
A kanban stores and displays information to make personal contribution explicit.
A wiki draws on the natural human drive to complete a task.
A kanban draws on the natural human drive to complete a task.
A wiki is self healing through social editing.
A kanban is self healing through social management.
A wiki is a fundamentally simple concept with massive social repercussions.
A kanban is a fundamentally simple concept with massive social repercussions.
Kanban is Workipedia.
It has been fascinating to watch the personal kanban meme spread through use and not through pontification. When people see a personal kanban in action, it just makes sense to them.
Parents start with their own kanban and soon their kids have them and then the family shares them. Peter has one, then his girlfriend wants one as well.
There are stories coming in from people who have used personal kanban or something rather like it over the last several years. Educators and therapists have been giving me excellent feedback insofar as why it works for kids. Why it works for adults. And why it has such an instant appeal.
Hearing from practitioners in all sorts of fields is showing me that a visual flow-based self management system is simply how we are wired. That everyone can benefit from it has been shown time and again.
The fact that kanban can move seemlessly from the shop floor to children to development teams to all everyone surely must be telling us something. People aren’t just starting to use a kanban because it’s an alternative to the to-do list. They are using it because it is expressive, fun and makes life easier.
In both Agile and Lean management there are points called "retrospectives," regular and ritualized moments where a team stops to reflect. Checking processes for only a few minutes lets you re-orient the course of your work. These retrospectives allow a team the opportunity not only to celebrate or bemoan accomplishments or setbacks, but likewise to serve as a constructive way to create and direct their course. A retrospective shows us that things either went well or they didn’t, understanding that either way, there is always room for plotting the effectiveness of future work.
Over the past few months, I've spoken with many people who've begun to use personal kanban. During the course of this thread, many of them have shared how they've started to deploy Kanban as a collaborative tool, using it to plan, prioritize, and do work both at home and in their place of business. Now we have to go that last step - we have to think about what we’ve done.
Whether it’s on our own, with our families, or with a team, a retrospective is vital in being able to identify, elucidate, and enact positive change. Retrospectives can take place at whatever intervals you are comfortable with, and for whatever period of time. Again, I’m not writing a how-to manual here, these tools should help you or your group manage tasks in a way that works best for you.
We can - and will - discuss a range of options for what a retrospective might look like. But just like a kanban can reside on a white board, a piece of paper, a computer screen, or even a kitchen appliance, a retrospective is what works at the time. If you are just finishing a project in the garage or on day 4 of hurricane disaster relief, checking your processes for only a few minutes will let you improve what you're doing
You don’t have to fly to Pluto to gain from small course corrections. You want to always be fine-tuning your workflow and your work management. In upcoming posts, I’ll talk about a variety of retrospective styles – some that are thought exercises and others with statistical rigor. Whatever you prefer, there should be one for you and your team.
Note: When Kanban is working really well, and you have an intimate understanding of your work, then you will achieve what Lean calls a "kaizen state," a culture of continuous improvement. At that point, you are constantly doing retrospectives simply because you are so aware of your actions, and a such, a separate retrospective may not be necessary.
See the whole Personal Kanban series.
NewHorizons2015 is NASA’s Pluto Mission – which requires both course corrections and a whole lot of delayed gratification.
Sometimes your relationship to work is initiative based, other times it is reactive. This is simply the nature of work. It is normal, and nothing - not personal kanban, not GTD - is going to change that.
In the game “Go” (“Weiqi” in Chinese) there are balanced strategic concepts for the natural ebbs and flows of taking the initiative or reacting to a change in a situation. “Sente” is the term for the initiative, “Gote” is the term for being reactive.
In English, we’d be tempted to equate these to Offense and Defense. However, there’s a subtle difference here. The word “defense” has a few connotations we’d like to avoid when working. One is that you are on the defensive when you’ve lost control of something. The other is that the goal of your defensive strategy is to quickly regain an offensive strategy.
This comes from the animal brain inside us all. Reaction is the gazelle taking flight when the cheetah springs forth. Reaction, for human beings, naturally caries a fight or flight response.
In Go, Sente and Gote positions are perfectly acceptable at all times. There are Go Masters who can win a game and play almost entirely from a Gote position. The Sensei knows that reaction is itself an action.
Why is this important?
Life comes at you fast. The nature of personal work is that some days are quiet, comfortable, and predictable. They are yard work or cleaning the house. Systematic and reassuring. Other days your water heater explodes and covers your basement in water, steam and destruction.
Some days you are at work, methodically finishing up your report and other days you are surprised to get a report back with particularly nasty comments and an unrealistic deadline to fix it.
On days like this we realize that life doesn’t always respect our personal goals. Mopping up water and pulling down saturated wall board isn’t helping us achieve our goal of learning Spanish. This makes us feel like we are on the English term defensive, and that upsets us. We wanted to learn Spanish by Tuesday and now we have to wait.
Well, this is why most businesses fail. It’s why bosses are cranky. It’s why people don’t feel they get what they want from consultants. It’s why that damn plumber is STILL HERE installing the dishwasher.
Life is, by its very nature, chaotic. We’re lucky that it is predictably so, but it still does not adhere to our plans. Whether you are doing Sente or Gote work, the work needs to be done. The best way to assure rapid and effective completion is to look past the emotions of “defensive” and accept Gote into the attainment of your goals.
What kanban seeks to do is visualize how your work is actually done. It actually accounts for exploding water heaters and other unexpected events because, over time, your throughput will reflect these.
So, say you have 20 projects at home and they have an average cycle time of 4 weeks from conception to completion. The mean time to completion though, might only be 2 weeks. There were a few outliers in there that took 6 or 8 due to unforseen events.
What you know from this is that you have a maximum of 8 weeks to complete a household project, it’ll usually be done around 2 and that 6 is a very safe number to promise completion by, with 8 being virtually guaranteed. As you notice this, you can start to examine why those 8s are happening.
I’d be willing to bet those 8s are projects that developed a defensive posture and were delayed due to emotional reasons. In short, they were shelved because they became too hard to finish. Well, those unfinished projects mount up and procrastination has a price. You now have a 2 to 8 week variance in the time it takes you to finish something around the house.
So we can examine those projects. Are the 8 week ones just more complex? Do they involving cleaning? Yard work? Being outside when the chatty neighbor might want to chew your ear off? Are they perhaps even unimportant?
When you find the commonalities in the outliers, you can then develop Gote strategies. As I said, Go Masters are unphased by adopting a Gote posture because there are deep and tested strategies for achieving victory from Gote maneuvers. Part of this is tactical series of moves that undo an offensive maneuver by your opponent, but the other part is mental. Reaction to events whether on the Go board or in life in general is natural. Acceptance of this natural relationship calms the fight / flight response in our animal brains and allows us to quickly and effectively deal with the unexpected work. This reduces the time to completion, shrinks our cycle time, and eliminates outliers.
Be calm, deal with the issues, reduce variance.
I am famous (perhaps too famous) for hating administrative work. I’ll let it pile up like nobody’s business. So in my personal kanban on Agile Zen, I colored my administrative tasks bright orange. That way if I dynamically deprioritized them because I hated them, I would be confronted daily with them piling up in my backlog.
Being able to visualize them, showed me the weight of their existential overhead until finally I had to give up and just do a bunch of them en masse.
Use a little creativity to call out certain kinds of tasks that may require special attention – either they need to be grouped or you just need a little extra reminder about their importance.
This is the 20th post in my personal kanban series.
I can say with confidence that I am intimately familiar with the complexities of writing a full-length book. Having a life while working on a manuscript is a challenge, ask any author. So much of your self goes into those pages and, as an author, you tend to obsess over every chapter, section, paragraph, and word. There’s a tremendous amount of energy expended on a labor of love such as this.
Many authors I’ve spoken with have shared that during the writing process, there have been times where they've actually hated their book. One explanation for this is that a book is literally millions of individual tasks that are undifferentiated. As I’ve said before, undifferentiated tasks cause stress. For authors, stress detracts from the creative process. I would hazard to guess that thousands of amazing books were never published because they crumbled under their existential overhead.
While writing Instant Karma, Tonianne and I have truly benefitted from having a kanban. The first one (pictured below) was on a white board in my office in Seattle. Note that our workflow is clearly defined on the kanban and what we are moving across are chapters. Each chapter of the book goes through the same overall process.
The items in the work flow are the way Tonianne and I work, not necessarily the way you should work. You can develop your own system. The key is to figure out what that system is, and make it explicit, then to figure out the best logical breakdown of work to visualize and move it through your system.
For us, the best way to visualize value was in the chapters. We have the the following steps:
As always, your kanban should evolve over the course of your writing project. To prove the point, here’s the initial kanban for Instant Karma:
A major point of doing a kanban is seeing how you conceptualize your workflow and reconciling that with what actually happens in real life. There’s almost always a disconnect between what we think is happening and what is actually happening. So first we see our workflow better. Then, once we understand it, we can articulate what is actually happening.
Then, we can make things happen even better.
For smaller writing projects, such as what might happen within a specific chapter, see post #17 on Mission Based Kanban.
The developing brain hungers for knowledge and understanding. The world is filled with bewildering systems that include contexts, value judgments, responsibilities, and outcomes. Systems are fascinating to kids and their developing brains.
Building blocks, board games, and video games are systems that often require a lot of work to master. All of them have outcomes that are cumulative, lots of little achievements that ultimately lead to the big gain. They are systematic; the achievements logically combine to affect a goal. As you work through a systematic game, gathering your achievements, you find there is a flow.
Games that have a flow are fun.
Games - even video games - are also generally tactile. There are specific body movements to make, controllers to hold, buttons to press. This kinesthetic feedback reinforces the conceptual exercise of goal attainment. The kanban has this same kinesthetic feedback. You move a tag to "done," you feel the achievement.
Games are also rewards based. If you do something in a game and get nothing from it in return, you tend not to do it again or, wind up hating that part of the game simply because it is wasting your time. While tangible rewards are up to parents, the marker that you've reached a point of achievement is highly desirable for children. If they move five tasks to "done" and will get allowance / TV time / a rocket sled in return, they will do whatever it takes to move those tickets to "done." Remember, moving tasks 1,2,3 and 4 have a tangible kinesthetic reward because you can actually see your progress.
It therefore came as little surprise to me when I started getting reports that people were using kanban with children.
Patty Jennings Beidleman is using it for her daughter's confirmation coursework:
David Anderson has told me how at his daughter's school they use a kanban to decide who can use what play equipment at what time. There are finite resources and each kid has a card. They can use a card to show which piece of equipment they will use. This limits the WIP of each of the individual toys, and ensures those kids who are playing get the best experience possible.
Others have set up kanbans for tracking chores. I set up "fridgeban" below as an example of how you might do this with ... um ... traditional infrastructure. Chores start on the front of the fridge and are moved to the side when complete. Rock simple, very effective.
Kanban works with a kid's brain. Cause and effect of chores and rewards is clearly laid out. Imagine never having to ask again "did you do your chores?" You may still have to quality check the work, but you won't have to nag them to action. The kanban will do the nagging for you. And, oddly enough, it's fun!
What is waste?
For personal kanban, the Five Somethings of Waste are:
What can you do about it?
Well, that's easy. Except there needs to be a "how" part.
Identify It - Notice the Five Somethings as they occur.
Understand It - Watch for patterns in tasks that satisfy any of the "Five Somethings."
Re-Orient Yourself To It - How do you and that piece of work relate to each other? Is it truly necessary? Do you have to do it? Can it be modified to not be waste? What's causing the waste? Can you do any of the following to it?
Outsource It - Contractors are everywhere. Use them.
Delegate It - Inside your team, find someone else who is better-suited.
Automate It - Spend some time making sure that a machine does it right, and never do it again.
Eliminate It - Find a way to never need to have that work done in the first place.
Your time is sacred, you only have a finite amount of it. I am willing to pay bookkeepers to do even the smallest amount of work simply because I find bookkeeping a fate worse than death. Other people pay me to do things they aren't good at. We all have our strengths and things that fulfill us. Let your personal kanban help you uncover the good, and get rid of the waste.
Photo by: Simen Svale Skogsrud
Some days you get together with a colleague and you need to run through a project quickly. The project is of short duration, and requires the creation of a set of "things." Pictured here is a Mission Kanban I created in about 3 minutes on the 19th of July when my collaborator and I needed to quickly populate the web site for my book with fairly uniform content.
The green list down the side represents specific blog posts that needed to be written. In blue and red across the top are the actions that needed to happen for each post. The blue tasks were mine, the red tasks were hers.
As we worked through each task, we would draw a box to show the one we were currently working on. A line through the box meant the task was completed and could be "pulled" into the next item in the value stream. (The value stream here is Draft -> Edit -> Accept -> Publish). Due to the directed nature of this project and the uniformity of tasks, we had a WIP of one. Each of us worked on one task until it was done, and then we'd move on to the next.
In a very simple pattern, this method establishes a value stream, limits WIP, assigns tasks, and provides a visual control for the project.
By visualizing our workload, we limit work-in-progress and focus our resources. We reduce waste by having a more efficient and effective work experience through understanding and prioritizing our work better, and selecting tasks better.
We're now at the 16th post of this Personal Kanban series. Personal kanban is like the ancient Chinese board game Go. Often caveated with, "a few minutes to learn, and a lifetime to master," Go Masters will tell you they are constantly uncovering strategies and finding new ways of interpreting the patterns on the board. Similarly, while it is simple to track your work and limit what you're doing at any given point-in-time in personal kanban, the implications of tasks and workflow run deep.
One of those implications is waste reduction via pattern recognition, or outlier identification.
Pattern recognition: What tasks or types of tasks repeatedly create waste?
Outlier identification: That weird task took a long time to perform and produced little value. Why?
The human brain is wired for both of these tasks, and the kanban highlights them. Outlier identification is a one-of-these-things-is-not-like-the-other exercise. Outliers are tasks that you either can't seem to get off your board, or ones you become upset by when you move them into "doing" or "done." My choice of the word "upset" is purposeful here. Your work should not upset you, and your visceral response to a task is a valid indicator of whether or not that task is waste. We'll revisit this issue in an upcoming post.
Pattern recognition is a little trickier, and should not be confused with "pattern matching." Pattern matching is the act of noticing objects or events that conform to a rigidly defined pattern. Leaves turning brown in autumn is a normal and predictable pattern. If trees begin to lose their leaves in June, you recognize that something is askew simply because the pattern matching is wrong.
You can then walk amongst the trees and start a process of pattern recognition. You are looking for a pattern that wasn't there before or that exists in relation to the healthy trees. Upon first glance, you don't notice anything out of the ordinary. The trees have been there for years; there's no sign of infestation, what could it be?
Then you notice that tree with brown foliage in a corner of the yard, and then other brown-leaved trees, more-or-less in succession. You recognize the first pattern. You aren't an arborist, you don't know what it might be but still you recognized a pattern that will help you articulate the problem.
Personal work is always going to give us epiphanies. It's going to take a while to notice the patterns and even more time to then understand what to do with them. Outliers can be identified and dealt with, patterns often need to be adapted to.
When we run our work history through some rudimentary filters, we begin to discern patterns such as what actions or what tasks lead us to the greatest success? Sure we may notice patterns and not fully grasp what they mean, but if we are cognizant of those patterns over time, at some point we may see correlations and eventually be able to identify true causalities.
Later on in this series we'll discuss actual measurement tools that can illuminate where waste resides. Tomorrow, we'll address waste discovery and mitigation.
Post 15 in the Personal Kanban Series.
James Mallison shared a bit of insight and I'm passing it along.
In a recent post he discussed issues very close to what I call visualization and flow. He begins with a little story about Jerry Seinfeld:
A couple of years ago there was a little story doing the rounds about a bit of productivity advice from none other than Seinfeld. He said the way to be a better comic was to create better jokes and the way to create better jokes was to write every day, even when you didn’t feel like it. To help achieve this he had a big calendar on his wall and for each day that he did some writing he put a big red cross over that day. After a few days a chain would be created. As the chain gets bigger you’ll not want to break it, so you’ll do what it takes to keep it going.
What Seinfeld did was build the world’s simplest and most effective kanban. It had two polar states. Done / Not Done. It had one metric, completeness. Once writing was achieved, task is complete. Any interruption in flow was immediately visible on his calendar based kanban.
Seinfeld didn’t want to “break the chain.” He didn’t want to interrupt the flow of work.
James has taken this concept and built flow worksheets … or state based kanban that he calls a habit tracker.
James’ Habit tracker looks like this:
In James’ system you create a repetitive task or a “habit” and you simply do it every day. Once it’s done, you can mark it off. For introspection there’s a note field.
This would be an excellent variation on my Sequestering Approach to personal kanban. I can very much see habit trackers on the wall next to the kanban.
James is looking for comments on the Habit Tracker, so please visit his post and leave feedback.
This is post 13 in the Personal Kanban series.
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:
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
Jim Benson is a collaborative management consultant. He is CEO of Modus Cooperandi, a consultancy which combines Lean, Agile Management and Social Media principles to develop sustainable teams.
