Evolving Web

Four Things to Remember When "Planning"

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.

State of the Planning Art

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. 

 
  

Focus and Finish

Be like Mark: Ignore Facebook.

Today I have three things to do: write this blog post, format a follow up package for our classes in Iowa last week, and get my cleaning to the cleaners so I have clothes for New York next week.  Oh, and get a ticket to New York.  Okay ... four things.  Five if you count being available for a client call if they schedule it today and not Wednesday.

So .. five things.

Anyway, I sat down about an hour ago to write the blog post. It went all over the place and was deleted ... in about 15 minutes. Then I went for a second to see what reply happened on Facebook and now it is an hour later.

I didn't follow my own rule of not touching an open social media channel until I was done with my focused work.

One thing needs to be clear here ... we give Facebook, Twitter, Pinterest, and that picture thing too much credit - the social media most people are distracted by first thing in the morning is e-mail.  I think most people have given up on inbox zero, but that's not the point ... the point is actually when to inbox at all.

So, your brain starts each day with a certain amount of creative energy.  If you start each day in e-mail or social media, you are likely sending that creative energy (cognitive capacity) in the wrong direction. Yes, sometimes my first task is writing an email or responding to one - but it is a directed task with one recipient for a specific purpose (like a proposal or other "deliverable").

E-mail, Facebook, etc. aren't a problem because of their structure, they are a problem because they are streams of context switching. From personal to political to project A to planning to project B to spam to cats to cats to cats to cats.  Streams are context switching and our brains love it because we are saying "New New New New New!!!"

But what your brain is not doing is creating something of value that will make someone happy, you money, or solve some problem - maybe even all three. 

That stuff ... the good stuff ... comes actually completing things and focusing on them. We don't get sucked into social media and email holes because they build anything ... we get sucked into them because they are high-yield distraction.

So, this pomodoro is done.  Blog post is delivered. Now going to get some coffee and jump into that formatting.  Where is that Illustrator icon?

Putting Some Lean Planning in Lean Startup

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."

What Does Control Really Mean?

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.

(1) Like a dial – a controller

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.

  (2) Controlling action through constraints

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.

(3) Controlled experiments

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.

(4) Communications Control

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.

Kaizen Camp: Seattle 2012

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

1. Great sessions
2. Conversations with other smart people
3. Learning about what is working
4. Strategizing about sticky problems
5. Learning ways to create better working environments, systems, processes, and policies

What you will be spared

1. Boring speakers
2. Bad boxed lunches
3. The inability to speak
4. Canned presentations
5. Sales pitches from consultants pretending to be speakers

See you there!

Long Live the Community

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:

Thing 1: LSSC 2012

This year’s conference felt different. I think we did a few things that gave this year’s LSSC a bit of slack.

Calmer Content

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.

Start Loud

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.

Centralized Vendors in a Fun Location

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.

Thing 2: The LSS Mission Statement

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.

Depth in Progress: of Wine Snobs, Audiophiles, and Agilistas

“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

Collaboration over Process

(This is the first in a Daily Thoughts series. I used to blog every day, but during the writing of the Personal Kanban book and creation of the Personal Kanban website, I fell out of practice. This is getting back to true blogging. Fast, unedited, perhaps a little more politically incorrect here and there.)

 

The agile manifesto said "Individuals and interactions over processes and tools".  For years, I did not question that principle.

Now, however, I would replace this with "Collaboration over process."  Here’s why:

What's happened with agile is that the rhetoric is so team empowering that it transforms teams into heroes. Like individual heroes, this divides them from the rest of the org. It turns them into inward focusing groups that are optimized for their own product and have a well constructed but ill-fitting interface into the rest of the organization. While it was team collaborative and was more collaborative with outside stakeholders, the rhetoric still focused on the teams.

But the teams are made up of individuals. And the team operates within an organization. And the team has outside resources. And the team has clients. There’s a lot going on with those outside interactions that need to be explicit.

I really took the Agile manifesto seriously. Like many, it was pinned on my office wall. I could bludgeon uncooperative employees or clients with it. I could wax eloquent about it. For me, finding its shortcomings was a painful and lengthy process. I slowly came to the realization that, as it had aged, Agile had codified, ossified, solidified into something you could easily do wrong and that was nearly impossible to do right. The words in the manifesto no longer represented what was happening in practice.

So, I began to strip away some of the trappings of over-loaded agile at my company. We replaced sprints with release cycles. We destroyed the product owner for a fully collaborative relationship with clients. When we started with kanban, it was game-on. In 2005, when we ran our first kanban driven project, we had a very different view of kanban - but even then visualization of flow almost immediately started to change how we worked.

Our process evolved rapidly during that project. At every standup people had a suggestion of how to make it better. There was a collaborative spirit not just for creating the software, but also for how the project was managed. We were no longer following a rule-book of best practices. We were building something that worked for that particular team building that particular software for that particular client.

In other words, the team had the freedom to truly optimize.

Don’t let anyone say you are doing a process “wrong" – find what your “right” is.

Image by @gavintech and shared by Venessa Miemis

 

 

 
--

Launching the Personal Kanban Book

 
There are some projects you undertake with the idea that they will be fun and rewarding and, in their course, they become much more. Yesterday Tonianne and I launched the Personal Kanban book. 

The writing process for this book was wonderful, grueling, transformational. I would take up a lot of space listing all the events of the last year. There were floods, illness, strife ... and more. The book was a huge goal for both of us. It pulled us through. Kept us afloat.

Now it's out and being sold. The outpouring of support for us over the last 24 hours has been amazing. It's like we just pushed to get to the end of a double marathon, not even realizing we'd won. Delirious and dehydrated we stumbled across the finishing line - expecting nothing more than to collapse in the grass and fall asleep.

But at the end of the race we found well-wishers. We found a party.

And we are suddenly both energized. 

Where, during the race we both felt beaten and defeated, we felt the exhilaration  of completion and said, "Let's do it again!"

New Personal Kanban Site Launches

The new Personal Kanban site is on line and ready for business. Very special thank you to our friends at Marcus Bloom who are the stealth awesome designers of the year. The Personal Kanban site is much easier to read and information is much easier to find. Please take a look!