Image by Sprezzatura.

Agendas are so 20th Century.

Los Angeles’ Hollywood Hills are known for their exclusive neighborhoods, sprawling estates, and the people who inhabit them. They aren’t (but should be) known for their perilous and serpentine roadways. Among the most treacherous is Laurel Canyon Boulevard. Those familiar with the area don’t seem to give the twisting roads a second thought. They maneuver down snug stretches of this automotive obstacle course at 60 mph, because it’s become second nature to them. In contrast, newcomers to the area – sweat beading up on their temples – cautiously crawl along at a snail’s pace, at once in awe at the glorious homes around them and terrified they’ll veer off the road and through a gilded gate at the very next bend.

When you are familiar with something, you take it for granted. You aren’t critical of it and so you tend to blast right through it. Just consider what happens when we call a meeting. Are we looking for what we are already familiar with? Are we basing the meeting on our assumptions and expectations that come from past experiences? Are we just going to “blast through it?” Or are we taking it slow – as a learning opportunity – in an attempt to expose hidden insights that can actually help us achieve our goals?

“The most dangerous kind of waste is the waste we do not recognize.”
- Shigeo Shingo (Toyota)

When you set an agenda, you control the conversation. In essence, you define your own road. When you control the agenda, you control the lessons learned. Since we enter a meeting with only our assumptions to guide us, agendas follow our assumptions. Our assumptions are based on what we already know. But what about the things we don’t know? Quite often, it’s the conversations we don’t plan on that give us the most insight. Why not instead run our meetings to learn or to discover?

About a year ago, Jeremy Lightsmith and I discussed starting a professional organization around Lean management. We figured that if we controlled the agenda, we’d control the thought. If we controlled the thought, we’d never get beyond our own thinking. Jeremy and I wanted to grow a community – starting in Seattle – but we also wanted to grow as individuals.

So we set up Lean Coffee. This popular, agenda-less weekly meeting has taken us in directions we never anticipated. Held in a local coffee shop, and with a totally open format, we begin each gathering by setting up a table-top Personal Kanban. Participants vary from week to week, but whoever shows up is free to grab some sticky notes, and populate the backlog with items they’d like to discuss.  Everyone gets two votes for which topics they want to discuss first. This builds the prioritization. The agenda and the order are both popularly devised.

It’s that simple. A kanban for a Lean Coffee might look like this:

Lean Coffee has spawned an active community in Seattle and increasingly in other cities like Stockholm, Toronto and San Francisco. More are coming. The best thing about Lean Coffee is that it has already outgrown its founders. Since we never set the agenda in the first place, Jeremy and I could start the ball rolling and step back.

Lean Coffee takes place every week at 8:30 am in Seattle whether we are there or not. It is now truly an open forum for learning.

Learning from a Meeting

“Time waste differs from material waste in that there can be no salvage.  The easiest of all wastes and the hardest to correct is the waste of time, because wasted time does not litter the floor like wasted material.”  ~Henry Ford

Conventional wisdom suggests that businesses hold far too many meetings attendees deem a waste of their time. Among the most common complaints are how certain individuals hold the floor too long, that the information being disseminated is worthless, and more often than not, the meeting is held merely to satisfy egos or fulfill political requirements.

To combat this, some call for meetings with rigid agendas. They want to know in advance exactly what they’ll get in exchange for their time, and so they assume that having a control in place will prevent the meeting from wandering off-track. That sounds like a pretty good idea.

Or does it?

Suppose for a second that there is more than one reason for a bad meeting. Certainly poor planning is an easy culprit, but perhaps the bigger issue is that we assume etched-in-stone agendas lead to better results. We assume we know what we need ahead of time, we also assume that we know what the attendees need ahead of time. What is more likely is that we know what we need to discuss, which is different than an agenda.

An agenda is your personal, politicized reason for gathering people, while the discussion of a stated topic is a conversation. In fact, the entire reason we are calling the meeting is to have a conversation.

Why then, if we feel it is inappropriate – rude, even – to dominate the conversation in every other aspect of our lives, would we codify dominating the conversation in a meeting?

Perhaps the reason meetings go off track is that the agenda doesn’t actually address topics of concern to the attendees. People come to your meeting and – becoming bored or frustrated with the content or the direction the meeting takes, or feeling their input is not valued or that they can’t be fully engaged – they switch topics to something that interests them or initiate side conversations. Since there is no established mechanism for discussion in the meeting, a power struggle ensues between the person who called the meeting and the people in attendance. This is not good.

If we want to learn from our meetings, we need to allow the conversation to be set by the very professionals we invited to the meeting in the first place. If they were worth inviting, they must be worth including. If they aren’t, your meeting should serve another purpose: to hand out pink slips.

Allowing the group to have a say in setting the agenda gives them buy-in for the importance of the topics. This helps prevent people running on at the mouth or providing information that goes off topic. Everyone has a stake in an efficient meeting because they all have discussion topics in the backlog. Group ownership means the person who called the meeting no longer serves as the traffic cop directing the conversation.

Instead, as the person who called the meeting, you can now direct the overall topic and even seed a few of the initial sticky notes. Yyou can even set a few “must discuss” stickies at the top of the board and prioritize them the highest. But the group must be able to discuss what their professional direction drives them towards.

The steps for doing this are simple:

1. Framework: Draw a Personal Kanban
2. Personal Agendas: Invite all attendees to write their topics on sticky notes
3. Democratization: Invite all attendees to vote on the topics on the table (each person gets two votes)
4. Group Agenda: Prioritize the sticky notes
5. Discuss

And voila! We have brought democracy to meetings. No longer do we tolerate meeting despots and spontaneous rebellions through filibuster or hijacking. Before these were power plays between the meeting organizer and the person acting now. Now they are interruptions of the group. Let society sort it out.

After the meeting, you can construct your meeting minutes outline by simply gathering up the topics in the order discussed.

(Want more on Lean meetings? Tune in tomorrow for a discussion of flexibility and democratization.)

ASL005 - LIVE with Jim Benson Personal Kanban from Agile Scout on Vimeo.

Planeban - A Quick offline kanban for in-flight work

As a matter of fact, yes.

I boarded the first leg of my flight from Seattle to Hanoi. I had 19 hours of flying ahead of me. I also had a backlog, and no wifi. Agile Zen was not going to be useful for me. So, I opened Open Office Writer and made a quick table.

I had a series of things to do, but with a few constraints. The first was that I was likely to fall asleep at some point, so I wanted to knock out the most important task first. The second was that I had a list of commitments I’d made over the week and needed to make good on them. Fortunately, I have a 17 hour battery and a 4 hour battery as backup, so I had enough juice to cover me.

In no particular order I wrote down my work. I had 14 papers to read for Hanoi, so I began with those.  I knew that not finishing them first would mean I’d read them when I was too tired to retain anything. Then I went to work on the feature sets for the new software projects. Finally I ended with blog posts (of which this is one).

In the end, I had a full accounting of what I’d done – so I could make sure that the files and work completed in-flight made it to the appropriate people and after-action steps were taken.

I want to point out again, you don’t need special hardware or software, you just need to visualize your work, limit your WIP, and prioritize.

That was step one.

Step two is visualizing that FIP. Jessica was concerned because her triathlon regimen included both repetitive and non-repetitive tasks. She needed to consume the right amount of calories, be sure to take her meds, and of course work out. This would equate to three repetitive, monotonous tickets per day in Ready –> Doing –> Done.

Many tickets. Too little real information.

Getting the work done for the triathlon was of course, important, but Personal Kanban is built to be an information radiator. What was the real information she needed?  This turned out to be:

1. what workouts did I do
2. when did I do them
3. did my caloric intake match the workouts
4. did I take my meds and, most important
5. am I being consistent or missing anything?

So here we see Jessica’s board. She just had a little white board, so we worked with the walls in her home. Backlog and Done are both off the board (on the walls where the board hung). Her spontaneous tasks still work through a Ready –> Doing –> Done value stream, those tasks were color coded between work, family, studying and other tasks.  But there’s more here than that.

There are two additional “swim lanes” on this board. A swim lane is another value stream or dedicated horizontal lane on our board for special tasks.

The first swim lane is Triathlon Training. We have several metrics here:

Diet: each day net calories, water, and meds are measured. Calories are a number, meds and water are a checkmark for done.

Workout: Type, severity, and subjective well being are noted here. “20” is a 20 minute cardio. On Wednesday you can see “10 mile ride.” E,M,H are easy, medium and hard workouts. Smilies measure how Jessica subjectively felt about the workout.

She can then take these metrics and not only see adherence and progress, but also plan for future workouts.

The second swim lane is Jessica Studying for her Section 65 Certification. She told me that she studies by creating a study plan for herself, studying, and then testing herself on what she just did. So we set up a swim lane with a WIP of one. At any point, she can only be working on one module.

So with this, we took Jessica’s overwhelming combination of things in progress and goals and made them visible and actionable. Take the time to critically look at the different projects you have in flight. In the end, you want to get the work done, but your real aim is to understand what you’re doing. To get those projects done right, Jessica needed some dedicated swim lanes.

I’m willing to bet she’s not alone.

Life presents us with opportunities, and so we’ve no choice but to take on concurrent projects. Unfortunately they don’t always conform to that simple Ready –> Doing –> Done value stream.

Last month I was in San Francisco giving lectures on Personal Kanban at Stanford and Keller. My host for the trip was my good friend Jessica. Jessica is a single mom. She  has two jobs on opposite ends of the Bay. She  is studying for her financial advisor certification. She is training for a triathlon.

Jessica has a lot to keep track of.

As a mathematician and an expert in intangible assets, it was not a big leap for Jessica to recognize: (1) she had so much on her plate that busting her WIP limit was guaranteed, and (2) making money was only one asset out of many she had to devote time to.

So on a sunny Sunday morning at a coffee shop, the simple question “Do you want to talk a little about your Personal Kanban” quickly turned into a 2.5 hour conversation. We discussed what she valued, what her goals were.

It soon became clear that Jessica is not simply goal-oriented, she’s a goal-collector. So we needed to get that under control. Goals are awesome, but when they start generating more tasks than we can handle – they need to be tamed.

We agreed she needed more than a WIP Limit – she needed a FIP limit. Future In Progress. She had the triathlon, the certification, a book she wanted to write, and more. It made sense to pick two and (no pun intended) run with them. The triathlon enforced health and working out, so we couldn’t say no to that. The certification was immediately necessary for her job and short-term. So that too was obvious. The others, went into the FIP queue.

Jessica now had a FIP limit of two.

Joe edited the conversation into two parts which can be found below:

Part 1

Part 2

A basic Personal Kanban on the iPhone or iPod Touch

You asked for it, and we listened. Today we are proud to announce the launch of the first Personal Kanban iPhone app, iKan.

When we set out to build it, we decided to focus on a few key things:

1. Small Screen Many Tasks -  We wanted to make the best use of the screen real estate on the iPhone, so we built the app vertically.

2. KISS - We wanted the initial release to be extremely basic. In future updates we will respond to YOUR needs, and additional features will be based on YOUR input. So please keep us posted as to the direction you’d like to see iKan take. We already have a long list of upgrades in our pipeline, but are primarily interested in how you are actually using the app.

3. Use Your Data - In the first version, we have   had importation from Zen.  (Zen, unfortunately, never let you write data back from the API. In one of their updates, the import also ceased to function.).

4. Start with Basics then Build to Suit - Each iKan starts with an entry-level Personal Kanban value stream with Ready / Doing / Done sections. You can however, create your own column headings and set your own WIP limits.

In the coming weeks, we’ll have a series of short tutorial videos for iKan – so stay tuned!

Special thanks to Jeremy Lightsmith, Gary Bernhardt and Corey Ladas who were all vital in making iKan a reality.

Get your copy of iKan at the iTunes Store.

NOTE: If you want to help create an Android app, talk to us!

Visual Controls are Reminders

I’ve been surprised lately by the number of people asking me about work/life balance. We feel we are undervaluing our family ties, our personal goals, our community involvement, our hobbies and our art. Oftentimes our work makes us feel isolated – we feel alone and seek meaning in our lives. Amusingly, we feel like we’ve invented this feeling.

When people tell me that their generation is somehow unique in this feeling, I ask them to talk to their parents and their grandparents. Soon they discover it is merely a myth that takes just a few minutes to dispel. When your parents laugh at your hubris for an hour or so, it’s quite a gut-check.

Nonetheless, we can posit that we’ve managed to give ourselves a lot more controllable distractions than were there before. We just don’t control them very well.

So for this third post on Task Types, we’ll do some work/life balance tasks and, like we did with work tasks, we’ll establish some rules around them. Again, let’s use colors.

Let’s say that purple represents family time. Use purple stickies and note real family time – not that trip to Costco but rather, those things that your kids will look back on and remember with a smile.

Next, let’s have blue represent those things that need to be done for the family. These are tasks like, “Fix the leak in the downstairs bathroom” or “Mow the Lawn.”

Finally, let’s use green for aspirations. These are tasks like “Read the complete works of Vonnegut” or “Learn Personal Kanban” or “Get CPR Certificate.”

Sound good? Great! So what happens next?

These colored tasks can appear on your Personal Kanban as task types. You can then set up your balance – literally. Every day you can pull one purple. Every week you can pull two blue and two green. And in your DONE column, you can see where you are with your goals.

Work/life balance now has a shape and a color palette.

Having said this, I consider my work and my life as indiscrete parts of a continuum. I love what I’m doing at Modus and the people I’m doing it with. So for me, the balance comes from not becoming so enamored with Modus work that I forsake all other activities.  And, yes, I do need to work on this.

But, I will venture a guess that if you actively dislike what you do professionally, work/life balance will be unapproachable. You simply cannot dislike that much of your life and expect to achieve a healthy balance.

Photo by Robotography

Some things are hard to maintain

Yesterday we were introduced to Richard, who is juggling the demands of several clients trying to keep each of them happy. His largest project entails working alone on a client’s mission-critical legacy system. So in the last blog post we discussed his tasks and task types. As we discovered, outlining those task types proved invaluable to him when needing to communicate how he was working to meet his client’s requests.

In addition to needing to distinguish task types, Richard explained one of his biggest problems he faces is getting mired down in tasks where the solution was difficult to find. (Remember, the system he’s working on is undocumented, complex and the work of several coders – so interpreting what he’s reading is kind of like solving the DaVinci code every day.)

Interesting work perhaps, but it can eat into your personal life when tasks routinely cause you to work late.

When I asked him out of 20 tasks, how many are likely to go afield, he responded with a tentative “15.”

Holy moly – FIFTEEN!

Needless to say, 75% of something impacts process. You can plan for 75%. 75% is not an error, it is status quo.

Then I asked, “Does your client understand the miracles you are working?”

“Not really,” was his reply.

When the client doesn’t understand status quo, that’s also a problem.

So I explained how we needed to make these issues explicit for two reasons:

1. To Stop Richard from Becoming Mired Down We want to give Richard the ability to note a task as blocked, to identify the type of blockage, and to explore some options for action. (Note: the task may be blocked, right now that’s miring Richard down. We want to give him permission to move around.)

2. To Communicate Status on Specific Tasks We want the client know at all times, what’s going on.

First, we examine what the major blockage types are:

• Interaction Blockages – These tasks have begun and require help from an outside party, and
• Slogs – Tasks Richard has to slog through, alone.

So, just as we did with the task types in the previous post, a useful way to visualize these blockages is also with color.

Task types were specific to, and travel with, the tasks. If these types of blockages are rare, then they would also be task-specific. But at 75% they are actually part of the workflow. They are likely events in Richard’s regular working.

His workflow would go from this:

Personal Kanban with Stuck Work Taking up WIP

To this:

Personal Kanban with Stuck Columns

Richard allows himself an overall WIP limit of 2. But “Stucks” get so stuck that the only way he can move forward is to do other work until something happens that will unstuck a stuck. (release a stuck?) This results in exceeding his WIP limit because incomplete tasks wind up littering his value stream.

The new “stuck” columns are WIP-exempt and allow Richard to put active tasks in Coding, Testing, etc. while the stuck tasks are allowed – at least momentarily – to languish in the stuck areas.

Admittedly, this is totally not a preferred way of working. If Richard were anything other than a lone actor, I would do everything in my power not to suggest this. I would be looking for ways to bring teamwork to bare to solve these stuck tasks. But historically Richard has had no team to rely on, and it serves little purpose to have him try to force solutions when they are slow to come by design.

Again, with a full 3/4 of Richard’s tasks being put into a holding state due to complexity or the need for additional input, that activity needs to be visualized before it can be dealt with. We need to see the procedural breakdown to refine our understanding of it and then, and only then, can we hopefully deal with it.

Perhaps 70% of these stuck tasks deal with a few, identifiable areas of the system. Richard could then add up the time he’s spent working with those specific areas and approach his client with a suggestion that he actually re-write those areas from scratch. As Richard did so, he could document his code and adhere to a coding standard that was higher than the one the original authors adhered to. This in turn would make the code more maintainable and, in the end, remove 70% of future blockages, saving his client money and Richard future heartache.

I can’t stress this point enough – the goal here is to visualize what is really happening, and then do something about it. Without the assistance of visualization in this and the previous post, neither Richard nor his client could gain clarity into the complexity of Richard’s work load. Now that both he and his client have work types and are visualizing the tasks that are mired down, they can at long last make decisions that free Richard from long work hours and difficulties in estimation.

Now Richard can better schedule his work time and attempt to achieve the coveted albeit elusive work / life balance. Not surprisingly, tomorrow’s post will address this very topic.

Photo by Steve Jurvetson