In yesterday’s post, you may have noticed that we have a “Slack Card” in our Personal Kanban for the day.

The problem we, like most people, were having was this:

Productivity feels good.

The Zone feels good.

But productivity and the zone can lead to burnout.

Just like Pomodoro includes rests every 25 minutes, we wanted to include a Pomodoro that was nothing but slack.

What we assumed was that we have eight half hour pomodoros in an eight hour work day.

Interruptions, non-focused tasks, and other minutia tend to make pomodoros not start back-to-back.

Of those eight, the slack card is kind of a “get out of jail free” card. It can let you spend a free half hour just resting, it can be spent collaborating on less focused tasks, it can be used to “throw away” if interruptions stop you from being able to do one of your Pomodoro.  Ultimately it’s a visual place holder for an option. You be the judge.

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.

Mixed Wine and Sour Cherry Reduction

I frustrate people when I give cooking classes. They want measures. They want me to tell them what to do. Cooking isn’t like that. Cooking is about flavor, it’s about texture, it’s about the experience. It’s not about tablespoons or grams or whether something is prepared at exactly 375 for 20 minutes.

So when your grandmother gives you her coveted, top-secret recipe for baked boiled squirrel al fresco, it will never taste the same as hers… if you follow the recipe. Because your grandmother doesn’t use the recipe, either.

Whether it is soy sauce or olive oil or even something as universal as sea salt, a tablespoon from one producer will be very different from another.

Just consider the variation among beef:

• USDA select (3rd grade) corn-fed beef from a grocery store that has likely been plumped with water;
• aged, organic, Choice steak (2nd grade) from a natural food market like Whole Foods or Choices;
• a Prime steak (1st grade) from a quality butcher; and
• a super-select Wagyu steak.

All will have flavor profiles and textures that vary wildly. The worst cut of Wagyu will be light years better than even the best cut of choice. So why would you ever expect food to taste the same from mere measurements?

Bone-In Pork Chops with Mixed Wine Sour Cherry Reductions and Asian Pear

Just recently, I picked up a great looking piece of meat at Whole Foods. I decided I wanted to make pot roast in our slow cooker, which I’ve not used in years. I dug it out of storage, cleaned it up, and went to work on the pot roast.

My wife Vivian asked what recipe I’d be using. I looked at her perplexed. What recipe? I simply couldn’t fathom using a recipe. I wanted pot roast. Granted, I’ve never actually prepared a pot roast. But that was besides the point.

Later that evening we had pot roast, and it was quite good. Did I use a recipe?

No.

I used 12 recipes.

The miracle of the Internet means that I don’t have to consult a book and choose one person’s vision of a particular type of food. I can now get 5, 10, even 100 versions of the same dish and see what is the same, what differs, what makes some unique. I learn about what Pot Roast is…not what one person says it is. Then I can begin to cook. I know what types of ingredients I need, what ingredients I have on hand, and what the flavor is I’m shooting for.

Recipes end up being like “best practices.” In business, when a company encounters a problem, they often look for a set series of prescriptive, easily to follow steps that have solved that same problem elsewhere. The clincher here is that most problems are unique.

Like ingredients, people are all different. We interact differently, we deal with change differently. Best practices are often followed as rote guides, and then fail.

Why?

Bison Burgers with Maytag Blue Cheese and Grilled Naan

Because we followed the recipe, but we didn’t actually cook.

We follow what other people say will work, but we don’t find out what the gestalt is of what it is that we are making. We focus on instructions and not on actual goals.

To truly solve problems, we need to be creative. We need to understand the various whys of a problem and then devise solutions. Otherwise we are merely treating symptoms.

Remember, when working with visual controls like Personal Kanban or management processes your goals and the system you have employed to realize them are what’s important. The idea is not to become a slave to your board.  Whether it is building software, finishing a report at work, teaching your daughter the alphabet, or creating a perfect pot roast – other people can offer advice, but you are the chef.

H4M&D is always present in our Personal Kanban

When we wake up in the morning, we have a pretty good idea what we want to get done that day. To make those daily goals explicit, we created the Today (link) column for Personal Kanban.

Our Personal Kanban serves many functions:

• It tracks our current work;
• It shows what we’re excelling at;
• It shows where we may be falling behind;
• It gives us an appreciation for our context;
• It lets us know when we’re overloaded and could use help; and
• It shows the status of our projects.

But our Personal Kanban can also inspire us. For me, there is one major goal I have that drives almost everything else I do. It’s very personal and important to me, so we put it in the Modus Cooperandi Personal Kanban as a reminder. That’s what I’m working for. It’s that yellow task up there, cryptically labeled “H4M&D.”

For me, H4M&D gets a little closer every day. Even though the ticket doesn’t move, if I can close out my day with the understanding that I truly am a little closer to that goal, then the day has been a success. Granted, some days I move only the tiniest bit closer, but closer is still closer.

I would recommend that you be judicious when putting anything like this in your Personal Kanban – make sure it is that important. You don’t want to clutter your board with 20 bits of inspiration that  get in the way of your work.

Use your Personal Kanban to inspire. Make your inspiration visible and begin to work towards it. Like mine, some of your goals can be audacious. Keeping them visual is keeping them relevant. It helps you pull the right tasks, slog through the hard ones, enjoy the easy ones, and see them all in the context of your greater goals.

For many companies, hiring is something that happens in spurts rather than every day, week, or even month. At this very moment, many firms may be going through a hiring process, significantly staffing up as the recession appears to ease. If you are involved in this effort and are like me, you are probably banging your head against your desk as you try to keep track of all the job candidates and what phase of the hiring process they are in, while simultaneously trying to attend to your regular job.

In smaller businesses that have limited to no HR resources, this process can be a daunting endeavor. To hire for just 6 to 10 developer positions, there are often hundreds, if not more, applicants to sort through, review resumes, conduct phone and in-house interviews with, and offer jobs. Frequently, company participants have forgotten the steps and effort involved from the last time this process was enacted and therefore feel foolish as they stumble through it again. Executives and participants generally have little insight into what is going on and end up constantly emailing back and forth to check on the progress of the effort, to find out who was rejected and why, or to find out who has made it through and requires a formal offer. Interviewers must always report results back to a single point of contact (or more likely a single point of failure) who is tasked with keeping track of every candidate’s application “state.” Finally, anyone other than the single point of contact is usually clueless when a potential candidate calls in to check on the status of their application. After going through a full on hiring process, most people, other than  seasoned HR professionals, are loathe to attempt it again.

To combat the organizational nightmare that is inherent in intensive short term one-off projects, a group at our company took a stab at visualizing our hiring process workflow on a Kanban board. Our CTO made the suggestion, as our company is currently in the process of making a heavy transition to Kanban (facilitated by Jim Benson’s amazing consultancy) and we all have “Kanban on the brain.” My first reaction to this suggestion was, “haha, thats a good one” but after a moment of contemplation, I realized this was truly a great idea. Our team used Kanban Tool (kanbantool.com), as we have multiple remote users, but this could just as easily be done on a traditional white board, with Agile Zen, or even Google Draw.

I worked with our office manager Judy, the CTO Jabe, and the developers responsible for interviewing candidates to come up with a Kanban board reflecting our ideal hiring workflow, accompanied by a document laying out roles and responsibilities associated with each column on the board. We held a  30 minute kickoff meeting to describe the process to all involved and get feedback and then we were off the races. Our company has a good amount of experience with “Agile” after working within Scrum parameters for the last 3 years so everyone understood that the Kanban board and hiring process might start off imperfectly but the goal would be to adapt and improve along the way.

This is the document which was shared with all hiring process participants, containing roles and responsibilities:

Interview Process Document

Here is a screen grab of our Kanban board (click to see full size):

If you read the Roles and responsibility document I linked to, you’ll understand the hiring process we proposed and some of the changes and suggestions for improvement that happened along the way. However, even if you didn’t read the document, the beauty of using a Kanban board is its self explanatory nature. This was especially apparent when few participants had questions during the kickoff meeting. In my experience, even the best laid plans are often confusing and require multiple explanations when presented in a list or outline format. Outlines and text just aren’t the most effective way for people to process or remember initiatives requiring multiple pieces to be pulled through multiple phases. Kanban made this easy.

When we created the board, we used color coding for the type of job the candidate was applying for and we implemented the following columns:

• Candidate Backlog (candidates who submitted resumes)
• Contact Candidate (candidate placed here when it was determined he/she was qualified from resume)
• Candidate Contacted (candidates who had been contacted)
• Phone Interview Scheduled (candidates who had a phone interview scheduled with a developer)
• Phone Interview (phone interview in progress between candidate and developer)
• Schedule in-house interview (candidates who passed phone interview phase and should be scheduled for in-house interview and test)
• In-House Interview scheduled (candidates who had in-house interview scheduled with product owner and developers)
• In-House Interview (in house interview and code test in progress between candidate, po’s and developers)
• Candidate Rejected (candidates who were rejected after phone or in-house interview  *this column was later changed)
• Simon Interview (candidates who passed all interviews and would be called by COO for final discussion)
• Candidate for Offer (candidates who were receiving formal offer letter).

After some experience with the process, participants asked us to add the job type in actual text to each card (the color coding was considered a bit too confusing on its own). We also split the “Candidate Rejected” column into “Candidate Rejected – No Interview” and “Candidate Rejected – After Interview” and added a column for “Candidate On Hold.”

The nice thing about using something like Kanban Tool is the ability to add candidate information, such as a link to each candidates resume in Google Docs, to each Kanban card. This information is readily accessible when a card is clicked. This makes it easy for interviewers to find documents and information associated with each candidate in a timely and efficient manner.

There is also an area for interviewer comments so executives and anyone else can effortlessly check in on why a candidate was rejected or passed on to the next stage:

Finally, Kanban Tool records each step along the way, allowing us to know exactly who made which decision, in case we ever need to trackback (although this feature, along with comments, is just a perk of the tool we used – not something completely necessary to visualize the workflow).

Using Kanban to visualize this intense short term effort resulted in many positives compared to using traditional project management approaches. Here are some of the things we saw:

• Rather than relying on single point of contact for all information, participants and interested observers could get just about everything they needed from the board.
• Participants were empowered to make the hiring decisions themselves because they readily understood and could act on the goal. The Kanban board visually facilitates this type of understanding.
• Executives, who often worry about efforts which are extremely important to the company, were able to see the plan was being followed, the rate at which the process was progressing, and the status of each candidate at a glance. This meant less questions from above, and therefore smoother day to day operations.
• There was little confusion concerning the process at kickoff because of the visual nature of Kanban.
• Participants felt free to make change suggestions to improve the process on the fly. Those changes could be made and disseminated quickly. This is crucial to a short term project where oftentimes if change can’t be made extremely fast, it’s not worth making.
• We now have an easily accessible and quick to read “living” document of how this process should work for future reference.
• For some reason, this process just felt much more effortless than times in the past when I’ve gone through something like this. I believe this is because, by empowering all participants, a “team” mentality was fostered which led to cooperation and a culture of improvement centered around a short term process (unheard of!). This was good for everyone involved and good for the company.

One thing to note: Seasoned Kanban practitioners might wonder how we dealt with WIP. We did discuss WIP limits in the beginning but as this was for a hiring process and not development, we decided not to set any and to see what happened. The WIP for this process seemed to work itself out and stay low as each phone interviewer could only obviously handle one phone interview at a time, and each in-house interview group could also only interview one candidate at a time. It may also have been the superb scheduling abilities of our office manager but it never became an issue and there were very few bottlenecks, the worst being “phone tag” moments. This is not to say we would not have immediately imposed WIP limits if flow or end results were poor.

Finally, a word of warning: As with anything, someone still needs to “own” the process, watch the board, and make sure the gears keep turning. Our office manager Judy assumed this role. She made sure busy developers had the interviews scheduled on their calendar and if a responsible party let candidates stack up or sit too long in a column Judy would make sure to poke at them until they took action.

So that, in a nutshell, is how we used Kanban to keep ourselves sane and productive during a massive (for us) hiring effort with no HR staff. It would be interesting to see comments on how our process could be improved!

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.

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