In 1989 I received my degree in Urban Planning. I have studied how to make plans.
In 2007 I received my certification to be part of the American Institute of Certified Planners. I have been recognized for making good plans.
I have planned subway systems, technology rollouts, urban growth patterns, transportation infrastructure, housing needs, freeway travel patterns, business projects, software development, building houses, building buildings, and on and on. I have planned.
I have also learned much. About reality. About complexity. About human nature. About how we plan. About politics. About blizzards. About locust plagues.
I understand, despite or perhaps because of my history, that plans are bunk, but planning is essential. The document (the plan) we create will disappoint us the moment it is completed (if not before). However, the act of planning, can only help us.
Planning is knowing what goal we are trying to achieve or what problem we are trying solve (our reason for doing this), what our current workload is (our capacity, our current level of distraction, our likelihood for being derailed), who the current workload is for (how many conversations we have in flight), what that current workload is going to look like in the future, what the other options for other projects we could be doing are, what the expected size of our new project is going to be (day? week? month? Six months? - protip...the longer your project the more wrong you will be about completion times), who we would be working with, and so on. Planning is knowing, tracking, and fully understanding the evolution of your project.
So, I promised four things to remember:
Thing 1: Your Estimate, Your Schedule, Your Gantt Chart is Always a Lie
I have built schedules for 20 years in Primavera. I have made Microsoft Project files that would make your head spin. Beauty in both complexity and foolishness.
Before you start any project you need to know Hofstadter's Law and the Planning Fallacy.
Do we want to estimate? Absolutely. Without some sort of guess at the amount of time something will take we have much less of an idea of its opportunity cost.
But we need to remember that our estimate is made at the time we know the least amount about our project. We haven't started. We've learned nothing yet. As we begin to work, if we are tracking our work and measuring rates of completion, we can - in the future - forecast completion dates fairly accurately. But we need to start working.
Remember...the longer the schedule, the less accurate your estimate. You schedule will always wishful thinking. Your Gantt chart is always fodder for long meetings and poor discussions.
Thing 2: Your Current Workload is Worse than You Think
If you ever take on a project without understanding your current workload, you are starting at an extreme disadvantage. You must understand your capacity and your current workload before thinking your new plan has a chance. You are likely already overloaded. That means you have existing relationships with customers and colleagues to complete work. Every one of those relationships takes up time and energy. The more you add, the more unpredictability you have added to your day. Unless you are limiting your work in process and understand how much work you have on your plate (perhaps using a Personal Kanban), your new project is going to be as successful as the annual Hades Snowball Fight.
Thing 3: No Plan Survives Contact with Reality
Reality bites. I have seen projects derailed by locust plagues, acts of congress, tornadoes, blizzards, SARS, staff attrition, and...strangely enough...not understanding the complexity of our work. We simply don't know what is truly involved in completing our work. Again, the larger the project, the more likely you will find delays due to the interactions of everything with everything else.
Thing 4: You Forget Tons of Stuff and Remember the Rest Wrong
If you think doing something in the past makes you an expert in how it's going to work in the future, you are right. People who haven't are just guessing when they are wrong. You, the expert, are right about a lot of things...but you are wrong about a lot of other things. This means your schedule will end up looking slightly better than someone who is guessing. Rosy Retrospection and the Zeigarnik Effect combine to create one simple truth we don't remember the past accurately. We remember bad things as better than they were (which might impact both risk assessments and estimates) and we forget that a lot of work occurred at all.
There's a lot of posts floating around the Internet about how to plan your work. There are products to help you make lists or organize your thoughts. That's all great, read them, take wisdom from them. But know this: the larger the project, the larger the margin of error. If you want to plan well, create small projects. Learn fast, adjust often.
If you want to build a real project, engage in planning. Build a system that asserts, acts, learns, and re-learns. Build a system of honest work like this:
Goal - Have one ... know what problem you are trying to solve or value you are going to create. Know why you want to do this and whom it will help. Let this goal and the options around it evolve as you learn.
Options - Create small projects to help you achieve your goal. Each one moves the needle a little. The faster these are completed, the faster you get value realize your goal. This could make it possible to achieve your goal incrementally. These are Options, make them, throw them out, use them like Lego to build value. You can only learn and adjust this way.
(Flag Waving: This is the point of the blog post. Many small adaptable batches beat big plans every day.)
The Work - Do the actual work.
Learning - Ask yourself how the work went. Was it done in the time you thought it would be? Is it the outcome something you are professionally satisfied with? What did the customer think? What did you learn that will make the next Option you pull easier?
If this seems a lot like PDSA ... it is PDSA with a slightly better push towards small batch thinking.
Last word
As always, if you can't describe what you are doing as a system (thanks Dr. Deming) and if you don't visualize your system, you have an assumption, not a system.
The last few weeks have been busy. We’ve launched Kaizen Camp which is bustling with activity. We have three Kaizen Camps scheduled for New York, Los Angeles, and Boulder – with more on the way in Tel Aviv, Sydney, Melbourne, and Ho Chi Minh City.
We started Kaizen Camp here in Seattle in 2011, now we’ve held three and the requests to host these worldwide are like a flood.
A Kaizen Camp discusses continuous improvement – at the office, at home, and anywhere else. No matter which way we approach our work (from process, from waste reduction, from psychology, from economics) the fact is that we create better product when we can improve our processes and enjoy our work.
Past Kaizen Camp topics can be found in this lengthy list. The low-down on Kaizen Camp is also interesting, but deep.
Right now, I’m just looking forward to some great conversations, deep problems to solve, and to meet people actively improving, creating, and innovating.
This was originally an answer I posted in a Quora group, but I thought I would repost it here with some edits. Read the original, in context, here.
After working with and owning several startups, it is clear that startup owners regularly overload themselves with work. It’s part of the startup mythos. The problem is, overwork kills lots of startups. The pace set is unsustainable and the endeavor collapses.
A few very important things where Lean Startup can be informed by Lean Lean.
First - Limiting work in progress is key to finishing things. You can't do more work than you can handle.
Second - Visualize the work - get it out of your head. There are too many variables and too many changes in context. You can better manage what you can see.
Third - Manage the flow, not the tasks - you are a startup, you will always have tasks. Working yourself to death will only result in your death. The flow of work is what is important - what can you produce, at what rate, and of quality.
Fourth - Kill Lists - Lists lack context, they age-out within hours, they leave you with no reasonable record of work done. They are the index of a map - even if read the entire index, you'll never understand the terrain.
Fifth - Prioritize Last - Making a long list and prioritizing up front is un-Lean. Most of your listed items will change in substance and priority as you do your work. With a visualized system, you prioritize / select work on-the-fly.
Sixth - Learn Cynefin - Understand that you will never know which of your tasks are simple, complicated, or complex. Some of them will bite you in the ass. If you outsource a task and think it's simple, but it is complicated or complex, you will end up working harder to manage the contractor than you would have doing the work.
Startup work is inventive - it is creative. Spend your time inventing the product and not reacting to the workload. Again, as Adrian said, this may mean some long days, but don't overdo it. Your brain is the only thing you have to make money from here. If you overwork it, it will underperform for you.
So learn from Lean, set up a Personal Kanban or any other type of kanban, and start visualizing your work.
Steve Blank says "Get Out of the Building."
I say, "Get Out of Your Head."
We say that kanban is a visual control, but we also eschew external control (rules) being placed on us by others. So what does control really mean? We when we look at it, we have a lot of depth here.
We can use our kanban as a controller for our work. We can adjust our WIP limits, the people doing the work, the throughput of various work-item-types, the granularity at which we track our work. We have a number of dials we can tweak to control our work.
The kanban itself places constraints on our work. It enforces policies we have set. The WIP limits, the value stream, what is allowed and when, and so forth are controlled using the board.
When we hypothesize something can be done to alleviate a bottleneck or some other item inhibiting flow, we can run controlled experiments using sour board as the laboratory. We can make small changes and measure their impacts directly.
The board, in real-time, is a control center – communicating status, activity, bottlenecks, completion rates, issues, staff availability, and more. It is the switchboard of your team.
It’s important for us to grasp that “control” means many things. This helps us envision more creative and robust controls.
Following last year’s excellent “Seattle Lean Camp”, we are now nearing Kaizen Camp: Seattle 2012. (We did have a name change, so as not to confuse us with another set of camps with the same name.)
This year, Kaizen Camp is the July 24-25. Again we are at the beautiful Center for Urban Horticulture. We also have award-winning food trucks (with vegetarian options) catering the event. So, no boring food! The event is nearly half full already, with attendees from software, government, health care, manufacturing, education, and more.
The diversity of ideas and voices are unparalleled – which is exactly what we were searching for. Lean ideals and principles will be discussed. People share success stories as well as challenges. Different disciplines work together to create new ideas. Continuous Improvement is explored.
Last year we were blessed with great conversation, learning, food, and near gender parity. This year looks even better.
What to expect
What you will be spared
There’s change in the wind and I like it.
The Lean Software and Systems Consortium (LSSC) has evolved to the Lean Systems Society (LSS). I was never a member of LSSC, but I am a founding fellow of LSS. Why?
LSSC was a very necessary institution to begin talking about Lean in software development. With LSSC, we had several awesome conferences that rapidly increased the level of thought, range of adoption, and inclusion of new groups.
However, LSSC’s mission was very open-ended. Talks with LSSC ranged from setting up free communities to instituting scrum.org style certification for Capital K Kanban. I want to be clear here that I really love the LSSC people – it’s just that my voice was better used from the outside of the organization, always discussing new ideas and ways to expand the community beyond Software.
LSS is an entirely different animal. It is only focused on discussing new ideas and ways to expand the community beyond software. So … it seems to fit me better!
Along with this transition comes two things that I want to talk about:
This year’s conference felt different. I think we did a few things that gave this year’s LSSC a bit of slack.
This is the part where I get to talk about how wrong I was. So, I’m all big into setting up unconferences and putting the people in charge of the content. This year, at LSSC we had a few track chairs (mercifully few!) who were responsible for populating the content in their tracks. The speakers this year were awesome, the quality of the presentations was stellar, and the smaller number of tracks meant that people could focus.
I was initially unhappy with the decision to go this way – but in the end it made for a fantastic conference.
This year we started with a one-day unconference, a community meeting, a special event (Lean Action Kitchen), and a reception. This year just started fun and thoughtful. We built up a great momentum on the first day.
In addition, each day started with a Lean Coffee that went from last year’s one table to three to five tables a day.
Rather than having the vendors off in some removed part of the building, this year they were right at the center of everything. The vendors helped this by becoming “snack central” as well – it seemed like everyone had food. The space was also light and airy – which is something I noticed about the entire conference – the whole thing seemed less cramped and dark.
Here’s the LSS Credo:
The Lean Systems Society believes that excellence in managing complexity requires accepting that complexity and uncertainty are natural to social systems and knowledge work. Effective systems must produce both better economic and sociological outcomes. Their development requires a holistic approach that incorporates the human condition. The Society is committed to exploring valuable ideas from all disciplines, and fostering a community that derives solutions from a common set of values and principles, while embracing specific context and avoiding dogma.
There’s nothing I can’t get behind here. This is an outward facing, humanistic, respectful approach to business, learning, and people.
This year I was lucky enough to win a Brickell Key award, which is given every year to two people in recognition of their work in this community. This meant a lot to me, because my focus has been often beyond software and my style of presentation is sometimes, shall we say, nonchalant.
This award was especially rewarding for me, given that this year I really feel like the community has really come into its own. This has been an exciting movement to be a part of and I look forward to what comes next.
Okay.. Herbert Hoover and Ayn Rand tell us of the rugged individualist. More or less, its a western ideal. We question convention - even conventions WE helped create. We have free will. We make decisions and act accordingly. In our rational hearts, we make only appropriate, moral, and ethical decisions.
We want to control our environment and, in order to do that we must control ourselves - and perhaps even those “less intelligent than us”.
But we've learned a lot recently about the human brain and the psycho soup we call a mind. We now have significant data that leads us to scientifically understand that humans are more like highly suggestive, moody, erratic meatbags. And I understand that I, Jim Benson, fit that bill as much as anyone.
We also understand that we fall into some definable types. Some of us are introverts, some of us are gregarious, some of us are creative, some of us are INTJ, some of us are ADHD, some of us get depressed in the Winter. etc. etc.
And maybe all these deterministic blanket statements describe no one in particular - but rather describe common human states we all find ourselves in from time to time. We do know one thing, that whatever evidence we may find that our will isn’t as free as we’d like it to be - the opposite is also untrue - we are not some B.F. Skinner robots of behavioralism. We are neither John Galt nor walking computers.
We’re something very different. We are neither pre-programmed nor truly rational, we are influenced. We are complex emotional beings striving for clarity. And we go to work in the morning.
And by potential users I mean strangers walking the streets of Washington DC.
TLC’s staff is as varied as anyone’s, and they have their share of introverts. These introverts had to talk to strangers on the street about products they just made up.
Jabe Bloom, TLC's CTO, knew that the coders would literally freak out if asked to do this - so he had to ease them into it. For a week leading up to the DC day, he gave his teams exercises that slowly helped them understand who their clients were, the sensibilities and needs of other people, what problems these people might be having, and then license to invent products that might solve those problems. From this, product ideas would be generated, refined, and then vetted (validated) with these on-the-street interviews.
As the exercises progressed, they began to generate products for the participants. They created personas of their system users, affinity maps of attributes, and most important - real individual and team learning. Feedback became more positive.
By the time the group started generating real, tangible ideas - they had unprecedented clarity, not only into the exercise, but into their own clients and products. Perhaps for the first time ever, they had a deeper understanding of who would use their products and that those people were real. That clarity felt good, it was empowering. I don't mean “empowering” in the harmonically convergent woo-woo babble sense - I mean that in the actual "I now know how to really do my job" sense. They had more real power to write good code.
By the time these people did their exercise in DC, they were so into the game and their ideas, that the previously terrifying prospect of going out on the streets of Washington and talking to strangers was now merely .... terrifying.
Yes, it was still terrifying.
But they did it. Introverts and non-people-persons stormed the nation’s capital and got some real work done.
Because they had clarity and because there was a system that made those actions logical. That made those terrifying actions easier.
Our individual programming obviously runs deep, and circumventing it is not trivial. But we are not hopeless. No one is a trapped.
We can step outside our comfort zones, we can grow. And we can enjoy the experience.
We, as individuals, team members, and managers, all would do well to appreciate that thoughtfully created collaborative systems like TLC's can have radical impacts on the system participants. (Habits take longer to develop, of course).
After all was said and done, at about 10 pm on a Wednesday night we were gathered in TLC’s offices back in Inwood, West Virginia. I ran a retrospective with everyone in attendance. These people were exhausted and euphoric. The most successful applications will be further refined and likely built. People stepped way outside their normal comfort zones to make that happen. It was draining and beautiful to watch.
Simon Marcus, the COO at TLC, who started this whole process rolling, listened to everyone talk about what they enjoyed about the process and what they did not. He made it clear that innovation was everyone's job. And, by and large, everyone knew he was serious. The next morning they were at work, building a new process to harness this new power.
Simon and Jabe could have written off their programmers as stereotypical introvert meatbags and left the innovation to product development experts - but that's the normal way of doing things. Silo'ing innovation where it’s appropriate and turning everything else into a factory.
In the middle of all this, Jabe said to me, "you know, I thought I would get a ton of stupid ideas and maybe two good ones, but I've been overwhelmed by the number of really good - not just good but really good - ideas these guys came up with."
If Jabe and Simon would have silo'ed their innovation, they would have destroyed not only value, but people as well.
Photo of Jim Benson by Jim Benson
Photos of TLC staff by Jabe Bloom
“Wine is to enjoy, not to judge.”
~ Hwi Woong Jeong (웅가) Wine Enthusiast
The gentleman next to me took out his laptop and began typing, he had a large pile of wine labels and a notebook filled with wine notes. He began systematically copying them into his laptop. I figured he was a wine critic.
Other work he went on to do involved software development and airplanes so my curiosity overtook me and we began to talk. It turned out that he was a software developer that worked with airplanes. But … he was also a noted wine critic enthusiast. He had been to the Pacific Northwest of the US on a wine excursion as a guest of the major wineries. He had been all over Washington and Oregon tasting.
When I was in my 20s, I decided I wanted to be a wine snob. So I went and took courses on wines, read books, and started a collection. I became rather good at it. So good, in fact, that I found I wasn’t actually enjoying wine any more. I was always critiquing it. I could always find something not quite right.
I told him this and he smiled and said, “wine is to enjoy, not to judge.”
We will always suffer from snobbery – to this day, I cannot listen to music from laptop speakers. And I know more than my share of agile adherents who actively hate every team they come into contact with because of their flaws.
We tend to fall in love with our ideas and nothing kills romance like familiarity. Richard Dawkins once said, “There is an anaesthetic of familiarity, a sedative of ordinariness which dulls the senses and hides the wonder of existence.”
We do this all the time with our work. We get excited about a task or an idea and we go deep. Too deep. Beneath the layer of effort that separates excitement from boredom. From energizing to draining. From inspiration to drudgery.
We might call this “depth in progress”. Just like we can have too much work in progress, we can also have too much depth. It’s simply doing too much of something. We go beyond what would be an acceptable level of completion and strive for “perfection.”
“The fact of storytelling hints at a fundamental human unease, hints at human imperfection. Where there is perfection there is no story to tell.” ~Ben Okri
At some point on the path to perfection, we pass the point of diminishing returns. After that point, our efforts do not return profit, only waste. In our pursuit of perfection, we identify all the things that cannot be perfect and then strive to perfect them. Yet, the imperfect is always with us. It is where growth resides.
Yet the need for growth, and the imperfection, will always be there. We end up in a doom loop of reductio-ab-absurdum – we manage our products as if the end product were a fine diamond that would last centuries. Well, it took the planet millions of years to make that diamond, and we don’t have that kind of time.
Therefore we need to approach our work by asking, “What is the least amount I can do to make this task successful?” In doing this, we want to move our ticket to DONE and have it stay there. No re-work, no additional tasks created because it was incomplete.
Can that task be improved in the future? Absolutely. But for now, it is complete. We launch it, watch it work, and come back to improve upon it later if necessary.
We want to know what the minimal completed task looks like and then do that. Anything beyond is too much work. Our previous goal of “perfect” is still valid, but now it has an upper boundary. Overly polishing the task does no one any good. Because of this, perfection is no longer gilding the lily - we now recognize the lily is perfect. We want to enjoy our wine, not judge it.
"To gild refined gold, to paint the lily ... is wasteful and ridiculous excess." ~ Shakespeare
Modus Cooperandi - Jim and Toni's Collaborative Management consultancy.
Modus Institute - Online classes for Personal Kanban, Lean Knowledge Work, and the future of work.