Evolving Web

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.

Innovation for Erratic Meatbags

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.

Why this matters to people and business...

Recently, I had the unique opportunity to see some beauty worked. Simon Marcus and Jabe Bloom at The Library Corporation decided that their staff needed a dose of entrepeneurialism. Why they felt this is not really important right now. What is important was that a large group of computer programmers who had worked their entire careers on legacy systems suddenly found themselves in a situation where they had to invent new products and then discuss those products with potential users.

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.

What was important was that these programmers were ... programmers. They just wanted to code. This was a huge and frustrating distraction from their regular work - which really needed to get done. So they started the first exercises annoyed and angry. Jabe gathered comments along the way - after the first few days of this process he received some extremely negative feedback.

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.

Punch line

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.

Our brains have tendencies, some stronger than others, and many extremely rewritable. When we encounter stimuli, our brains record it and we are changed by it. The more that stimuli is repeated, the more our brains physically and operationally adapt to the new patterns.

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

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

Speaking from Power in an Uncertain World–Collaberwocky Episode 3

Are you a manager trying to get by in a flat or agile company?

Do you find the role of manager repeatedly maligned?

This is more than just “It’s lonely in the middle.” There are significant positive shifts in making the workplace more productive, efficient and effective. However, each of these shifts has been accompanied by changes in roles – and these changes are rarely clearly spelled out.

In Episode 3 of Collaberwocky, Jabe Bloom, Corey Ladas, and I discuss how to speak from power in this new uncertain world.

The Language of Management–Collaberwocky Episode 2

In this episode of Collaberwocky, Jabe Bloom, Corey Ladas and I discuss “The Language of Management.”

It seems that different rungs of the corporate ladder come with different perspectives. None are complete and all have their own biases and areas of focus.

Further, many management theories give rise to a sort of class warfare between the different rungs. “My manager doesn’t understand me.” “The C-Level suite are out of touch.” “The people who work for me are idiots.”

Far too often, this causes the rungs to appear so far apart that people cannot even fathom having productive conversations. Corey, Jabe and I mull over these issues.

We recommend you watch this video full screen.

Reading is (Still) Fundamental

 

I recently tweeted this after mulling over the differences I’ve seen while working with various clients. Some of them have practically been begging people to slow down, finish less with higher quality, and to take time out to read. Others are so scared that they don’t produce enough, that people are running in every direction trying to get something done, while finishing practically nothing, and learning even less than nothing in the process.

Of course, the first tweet I received in response was from JB Brown, at Nordstrom’s Innovation Lab. Since “Innovation” is well, what they do, they like to read a lot and… apparently…are fond of statistics:

To me, the benefits of giving teams the time to read is self-evident. But I thought I’d let the people actually giving their staff the time time to read speak for themselves.

Simon Marcus: COO of the Library Corporation

I encourage people to read at work for the same reason that I encourage them to write things down. Reading and writing give you time and room to think. Mostly at work people think they are supposed to be DOING ALL THE TIME. But if they aren't thinking, the result of all that doing can be a whole lot of nothing.

I love when I am reading and stumble on a word or a phrase that sends me spinning off into one of my own real world problems or opportunities. I love it even more when it happens to other people, but the long range value of reading at work is that it slows people down and makes them more thoughtful and intentional about their work.

Lastly, a word about why we encourage people to read AT work (instead of just expecting them to read on their own time). If I think that something is important enough to ask people to do it, I owe it to them to give them time to attend to it. This is part of the larger effort we make to respect people's time AT work. Reading is Work in Progress (WIP), just like everything else we ask people to do. We try to avoid making work WIP slip over into people's home life. All of that isn't to say that I don't love it when I find out that people have gotten the reading bug and are reading on their own time too. I find that the reading bug can be contagious. Eventually, about one out of three people who we encourage to read at work seem to start reading more on their own time. When I hear that someone who "never reads" has started reading, it makes me smile from ear to ear.

Jabe Bloom - CTO of the Library Corporation:

I have 2 general concepts for why reading is important at work.

1) Technical Knowledge is more valuable the earlier you can apply it. For many of my developers ensuring that they are constantly retooled is one my most critical tasks. Encouraging them to read helps them to maintain a “landscape” view of the technologies they are using so they have a better chance of “finding” the right tool at the right time. Exposing developers to a wide range of new and interesting thoughts is a good way to inoculate them against complacency and “I have a hammer-and-everything-is-a-nail-itus”.

2) I think.. more critically... Having an open environment at work where individuals can be SEEN reading, activates the social space as a learning environment.

More and more studies of cognitive science support a concept of ritualized changes in thinking patterns... transforming from one way of thinking to another.. I think that having people read at work, helps them to think in a “learning activated” mindset.

3) Encouraging employees to read AT WORK, sends a clear message that we EXPECT and VALUE learning in the work environment. Employees aren’t expected to keep up on changes to the industry on “their own time.”  Our encouragement of reading at work has seen an increase in;

1) Teams’ abilities to communicate internally and with other teams via shared vocabulary

2) Increase in individuals sharing learnings and source materials.

3) Decrease in defect rates, especially escaped defects.

Jason Montague, the Director for Application Development at RW Baird:

As you've stated, a staff that is willing and equipped to read is a staff that understands the need for continuous improvement.  In that regard, reading, reflecting, and learning is crucial.  To understand why, let's simply look at one of the most common reasons given (to me) for why some don't read.

"I learn enough through experience!  Everything I know I've learned through the school of hard knocks.  What could a book *possibly* tell me that I can't get from experience?"

While it's true that experience is likely the most powerful means of learning, the sad truth is that we don't have as much experience as we think we do.  As I've learned (in books no less) most of us rarely have "20 years of experience".  We typically have one year of experience FOR 20 CONSECUTIVE YEARS.  That's right.  If we reflect on our past, occasionally we have brand new experiences that indeed teach us quite a lot.  But for the bulk of our past, we tend to repeat what we know over, and over (and over) again.  In that way, I would argue we need to step outside the boundary of experience-based learning and learn from others collective experiences.  You do that in books, articles, websites, blogs, and yes, tweets.

As you might guess, it's important that your teams are "willing" to read.  Just as important, they need to be "equipped" to read.

As employers, we can help control the second of these two statements.  Our obligation while building learning organizations is to model behavior, challenge assumptions, infuse an attitude of curiosity, and generally create conditions that allow (and encourage) people to read and reflect.  After all, as adults, quiet reflection is critical to our growth.  We are therefore obligated to not only "allow" people to read at work, but to encourage and incentivize them to read at work as well.  In that way, each employee becomes a well spring of "new" ideas, and a potential catalyst for infusing those ideas in our organizations.

 

You Mean I Can’t Even Estimate? The Planning Fallacy in Action

Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.

We like to estimate things. “I’ll be there in 5 minutes!" “I will have that report to you in an hour!” “We can do the entire project in 24 days!”

Yet our estimates always make us nervous. They leave us ill-at-ease. We always know things won’t go exactly as we foresee, there will be things that should go right but don’t, there will be unexpected snafus. We know, the moment we create it, our estimate is wrong.

“Plans never survive contact with the enemy” – von Clausewitz

But we hold on to our estimation as necessary. We hold on to our plans as bibles. We hold on to contracts as … well … contracts. And we are surprised when things don’t go according to plan.

“Plans are useless, planning is indispensible.” – Eisenhower

We are running into two problems here. (1) There is variation is every activity and the world is sure to remind you of that. (2) The Planning Fallacy – which is a cognitive bias that shows that human beings tend to underestimate a given task even if they’ve done that task many times before.

The planning fallacy is one nasty little bugger. Already, we undervalue the role of variation in our work and believe we can ascribe one number to a particular task. Beyond that … we actually are predisposed to underestimate even that erroneous number.

Researchers have tested this many times and find a few things.

• People tend to underestimate their own completion times the most
• People tend to underestimate even more when others are present
• People can deliberately underestimate to garner favor or win contracts

These added together create some shaky ground when asking other people for an estimate of time. Some people glibly say, “Well, when they give me an estimate, I double it and that takes care of it.” But this doesn’t solve the core problem – people honestly did not know the variation in their work to begin with.

At a recent client, they compared their estimates to actual hours across a series of projects.  What they found was, if a task was estimated at one hour, there would be four times that estimate was correct, and three that it was not. The incorrect estimates would range between 2 and 6 hours.

For two hour tasks, it was similar. Three times they were correct, four times not – ranging between 3 and 9 hours.

Three hour tasks, a very similar spread.

When they visualized those tasks – they suddenly were able to see the variation in their work. And they were upset!

“We have to get rid of those major outliers,” they said.

But what they were really seeing was the variation in their work. The uncontrollable variation inherent in knowledge work that makes Hofstadter's Law a law and makes the Planning Fallacy a very common occurrence.

Understanding the variation statistically … that gives the team real power. With that they can choose any number of estimation strategies, based on real numbers with real spreads. There will never be one “right” number – because that is prediction and not estimation.

Combine this with Eisenhower’s advice, and we stop planning up front – when these errors and biases will be the most pronounced because of have the least information -and instead re-evaluate plans throughout a project. We make course corrections. We constantly re-adjust. So Hofstadter will still be right, but he’ll be less right than before.

Photo by Mr. Asthma Helper

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

 

 

 
--