Beyond Agile: Tales of Continuous Improvement Published

After two years of hard work by Maritza van den Heuvel and Joanne Ho, we are excited to announce the Kindle publication of Beyond Agile: Tales of Continuous Improvement. Beyond Agile is:

• Case Studies in Lean/Agile teams involved in continuous improvement
• Examinations in the use of visual controls like kanban for knowledge workers
• Truthful and sometimes painful stories of teams and organizations working for better process

Presented through 10 case studies spread over four continents, Beyond Agile shows that process improvement is owned by no single process, no single school of thought, and no single culture. Whether in India, Spain, South Africa, or the United States, these teams of knowledge workers faced very similar problems, but in very different political, economic, and social environments. Their path of continuous improvement, however, was universal.

These teams saw problems and attempted to fix them. Sometimes with great success, sometimes requiring they go back and try again. But they did not simply complain or ignore the issues.

Many of these stories build on Corey Ladas' book, Scrumban.

The print version of this book is due out in April 2013.

Personal note from Jim Benson:

Maritza and Joanne poured a lot of effort into getting this book to publication. I want to personally thank them and congratulate them, but also ...

Please! From you two things:

(1) Tweet the heck out of this post (see twitter link below)

(2) Congratulate Joanne and Maritza in the comments here.

.. and, of course, check out the book.

The Client Management A3: Modus Cooperandi White Paper #2

Lean thinkers seek systemic causes to workplace or project issues. The goal is to find procedural or functional root causes to unpopular behaviors or outcomes. Psychologists warn us of Fundamental Attribution Error, a common human bias that leads us to blame before we analyze.

Lean uses the A3 as a tool to examine problems, hypothesize solutions, and then run experiments to test those hypotheses.

But sometimes, people might actually be the system we want to fix.

In software development, there is the notion of the Persona - which helps software developers build empathy and understanding for those unlucky enough to use their software. At a recent client engagement, we combined Personas with an A3 to some interesting results.

This paper is the result of that endeavor.

The Client Management A3 White Paper is available from Amazon.

In Progress v In Process

After a recent webinar with SwiftKanban, I received an email from a manager in Sweden with several teams that had workflows difficult to tame. He said:

I help teams getting started with Kanban and have some teams that are very similar to the architect example you showed in the webinar. These teams typically struggle with having many tasks and tasks that take a long time. Hence as you mentioned in the talk a "normal" WIP limit is not all that useful. We have tried various approaches such as priority columns or date columns combined with people rows. To some extent it works, but we still struggle to get enough information on the board for it to be really operational.

After some e-mails were exchanged, it became clear to me that we tend to treat the phrases “work-in-process” and “work-in-progress” as interchangeable. But, especially for teams with a great deal of churn, like QC or other external influences to their cycle. This WIP distinction is key to a flowing kanban.

Work-in-process is all work that is on our kanban and is actively flowing through our process.

Work-in-progress is work that we are actively working on right this minute.

These two competing types of WIP have been overlooked or under appreciated because the concept of WIP came from manufacturing - a much more controlled environment than knowledge work. Manufacturing has less churn and less complexity than knowledge work.

So, we can deal with theory later, let’s talk practicalities.

Recursive Work and WIP

If you have a request / revise / revise / revise / revise / release cycle, what is actually your personal WIP?

Let’s say that your value stream looks like this:

Receive Work Request -> Work -> Review -> Work -> Review -> Work -> Final Review -> Final Work -> Release

WIP can get pretty confusing, especially if work items dwell in a review state for an extended period. This, in turn, can be exacerbated by demanding clients who take a long time to review, then demand updated product from you immediately after they finally return their review. (Sound familiar?)

So, your kanban would look something like this (click to enlarge):

The issue here is that a team that is waiting on external tasks, but has a predictable work cycle, can easily lose track of the difference between being responsible for a task and actively working on that task.

It’s easy to conceptualize that we throw the work over the wall into review and then they throw it back - but life doesn't work like that. We’re still responsible for completion for all the work that we have in process, even if it isn't - for us personally - in progress.

So, we can be happy that we’re maintaining our personal WIP limits by not having too many tasks active. We are focusing, completing, and keeping quality high.

But! .. But!

The Review columns still have their own limits. If they are exceeded - that becomes your personal WIP. You are responsible for keeping those lanes flowing.

An unspoken part of your WIP is maintaining what those columns represent, and that’s relationships. Each column is a point of negotiation between your team and whoever is doing the reviewing. Each of those transitions for knowledge work is some things that Lean doesn’t like to admit exists - politics and personalities.

These are intrinsic elements in knowledge work because, whether we like to admit it or not, much of the acceptance criteria of knowledge work is subjective. (Any guess why objective metrics and knowledge work at best have inconsistent results?)

This is a board we describe in our whitepaper Kanban: Diversity and Optimization in Knowledge Working Teams. This board is for a team of systems architects that have several active projects that require some level of consistent monitoring (or at least acknowledgement). However, they also have tasks that are currently requiring a great deal of their attention.

Their active WIP is displayed in the 2x2 matrix on the right in this photo. Their work is on two axes. The vertical axis is time until the project is complete with 4 months at the top and imminent at the bottom. The horizontal axis is the amount of time they are currently spending on the task ranging from a low of almost none to a high of almost all.

As one might guess, this is a subjective view of a domain with extremely high variation. In this case the architects are recognizing the variation in their work and attempting to visualize and manage it.

An Imprecise Closing

Thinking about what WIP means is extremely important if we are going to be honest about the complexities inherent in knowledge work. A dogmatic view of WIP will render Lean and kanban unusable for many teams.

However, the more we open the door for interpretation for what WIP means, the more we are opening the door for people to become lax in limiting WIP in the first place.  In the cases listed here, both work flows will benefit from limiting both types of WIP.

When limiting work-in-progress, we can enact local optimizations that are easy for us to implement and control. When limiting overall work-in-process for a complicated organization, we will have to engage not only mechanistic process measures, but also political ones. Perhaps this is what’s most important. It’s easy to do the former, harder to do the latter - so we optimize ourselves and wish the rest of the organization or our customers would just “get better”.

How We Do Business: Sample After Action Report

When we work with a team for a week, we learn a surprising amount about how the team works, the company’s relationships, the products, and the needs of the organizations. Anyone that’s worked with Modus knows our After Action Reports (AARs) can become quite detailed. Some have been over 50 pages. We thought it might be helpful to show people what a sample AAR might look like. While each AAR is very specific to the needs of the particular client, this one gives a good idea of the range of topics they take on.

Note that this is an actual AAR from an actual week long Launch Ready event. We’ve taken out all the detail that might reveal the client, and left everything else.

Download The Sample After Action Report Here

Modus Cooperandi White Paper: Kanban: Diversity and Optimization of Knowledge Working Teams

Announcing the publication of Kanban: Diversity and Optimization of Knowledge Working Teams – a new Modus Cooperandi White Paper.

Late in 2012, we conducted a Board Walk (a site visit where we meet with teams using kanban or Personal Kanban and help them optimize the board and the team itself) at a client in the United States.  There were 15 individual teams, each of which had its own individually designed boards. Each board had a unique value stream, work item types, policies, and methods for judging completeness and quality.

Both management and the teams were frustrated because they hadn’t yet found a board design that worked for the entire company. They were looking for standardization.

However, each of these boards were, in some way, optimized for each individual team. Each team had its own context and these boards related specifically to that context. Each team was also actively improving their boards on a regular basis – meaning that optimization was continuing.

This white paper contrasts many of these boards, showing the differences in design of each board and the ramifications of those variations.

A PDF of this is available for organizations requiring a bulk purchase. Please write.

Three Questions on Deadlines #2–Jon Moore

We asked our three questions on deadlines of Jon Moore, Technical Fellow and Chief Engineer at Comcast Interactive Media:  

Q1: Do deadlines empower your teams?

I've found that deadlines can cut both ways. On the one hand, an achievable but challenging deadline can really get teams to focus; on the other, a seemingly impossible deadline can crush morale. Having a fixed deadline with variable scope (where the minimum viable product is achievable by the deadline) is a perfectly fine timeboxing mechanism that can line up well with longer lead-time activities that must be coordinated around a big launch--for example, marketing efforts.

Q2: Do your customers expect delivery on deadlines?

Yes, internal customers often expect delivery by negotiated deadlines. In a company with many teams, estimates like ideal hours or story points[1] do not carry well from team to team, but calendar time does. Asking when another team can deliver a dependency serves as a useful unit of exchange.

[1] I have even heard of teams from a different company that estimate in kilograms!

Q3: What are you doing to meet customer expectations (in response to or in lieu of deadlines)?

I've seen have success with tried-and-true mechanisms from Scrum: prepare all the user stories, estimate in story points, then project out based on historical velocity. If the scope/date line doesn't pan out well (or is close), manage expectations with the customer as early as possible to discuss scope/date tradeoffs or risk.

Bio: Jon Moore is a Technical Fellow and Chief Engineer at Comcast Interactive Media, a part of Comcast dedicated to building web and mobile customer experiences.

Three Questions on Deadlines–Asking the industry

Deadlines ... we govern by them, talk a lot about them, gripe about them. But do we use them effectively?

Deadlines are grave ... in fact their original use was quite literal:

… And he, the said Wirz, still wickedly pursuing his evil purpose, did establish and cause to be designated within the prison enclosure containing said prisoners a "dead line," being a line around the inner face of the stockade or wall enclosing said prison and about twenty feet distant from and within said stockade; and so established said dead line, which was in many places an imaginary line, in many other places marked by insecure and shifting strips of [boards nailed] upon the tops of small and insecure stakes or posts, he, the said Wirz, instructed the prison guard stationed around the top of said stockade to fire upon and kill any of the prisoners aforesaid who might touch, fall upon, pass over or under [or] across the said "dead line" .... ["Trial of Henry Wirz," Report of the Secretary of War, Oct. 31, 1865]

~

A deadline is negative inspiration. Still, it's better than no inspiration at all. ~ Rita Mae Brown

Deadlines can be deadly serious. They are set to meet key coordination dates and understanding those real business needs can be the line between success or real business death. Deadlines can help us focus – finding the real value of the work to be done and trimming the waste.

Most of the time, however, deadlines are wishes. They are dates we’d like to get something done by, regardless of all else.  Missing these deadlines has little consequences on customer value, but they cause people to work as if the fate of the company were at stake.

Many people use deadlines, inappropriately, to motivate. They often do this because they have no other way to inspire their workforce or they really do believe that deadlines work for this.

We thought it might be a good idea to ask around – and find out how people are using deadlines. Where are they working? Where are people finding other ways to motivate their workforce?

In this series we have:

(these links will go live as we release the interviews over the course of the week)

• Jason Montague – Director of Application Development at R.W. Baird
• Jon Moore – Senior Developer and Technical Fellow at Comcast Interactive Media
• Jabe Bloom – CTO at the Library Corporation

If you would like to be part of a future interview series, please let us know!

Three Questions on Deadlines #1–Jason Montague

As part of our Deadlines Interview Series, We asked Jason Montague, Director of Application Development at R.W. Baird in Milwaukee, three questions about deadlines:  

Q1: Do deadlines empower your teams?

Wow.  You went right for the jugular on this topic, didn’t you.

Unfortunately, the short answer is YES, I do feel deadlines empower our teams, but NOT in the way you might expect.  Deadline empowerment can lead to wildly varying, primarily negative, outcomes.

To begin, most organizations don’t have a good sense of how to manage software developers or “value” in software projects.  So, instead of working on a way to manage more effectively, they use a very handy (and simple) proxy…deadlines.

For most business leaders who don’t have the time, patience, or inclination to learn about software development, understanding the nature of these projects and all the variables at the disposal of project teams is daunting.  In many organizations, much of the complexity is ignored, or worse, dismissed.  In these organizations, software teams and their importance in the business ecosystem is marginalized and quickly become more order-takers and less partners over time.

So then, what do deadlines “empower”?

Development teams, like any team of people, are motivated intrinsically to do a good job.  If “doing a good job” becomes more about WHEN you deliver over WHAT, HOW, or WHY you are delivering, then those teams will move heaven and earth to deliver ON TIME, ignoring some key concerns.

Common missing components in deadline driven projects:

• (WHAT/HOW) The deep complexity and craftsmanship needed to build a sustainable, resilient, manageable product that will grow and thrive over time.
• (WHY) Why are building this?  Is there a better way?  Can we help make this any simpler?  Should we build it all?  Some of it?  None of it?

When teams are faced with a deadline, the typical response is to focus on the deadline and deliver (no matter what).  This is definitely empowering, and seems like a reasonable arrangement, until you realize the incredible cost associated with missing the WHAT, HOW and most importantly the WHY.

(I can elucidate those costs in another post.)

Q2: Do your customers expect delivery on deadlines?

Yes they do.  And sometimes it is completely rational and unavoidable.  Market pressure, response to regulatory mandates, legal requirements, etc., all require rapid, time bound responses to delivery.

However, in my experience over the last 17 years in (primarily) IT shops in financial services, insurance, banking, and even packaged software products, these deadlines are largely imposed by “managers” as a proxy for leadership.  Customers, and IT managers, simply don’t know what else to do.

Q3: What are you doing to meet customer expectations (in response to or in lieu of deadlines)?

We are attempting to teach a new way of working.  There are a few key steps we’ve taken to help our organization realize that deadlines, although sometimes helpful, can also cause mayhem and colossal long term costs if placed in the center of our work.  These costs can be predominantly avoidable.

Here are some key tenets:

• Ensure your decision makers (the “business”) are engaged and partnering daily, and understand tradeoffs related to their choices.  With good decision making and partnership, we tend to maximize what we don’t build.
• Educate the organization on the virtues of software craftsmanship, and why high quality software is crucial to reduce costs and to go fast.  Architecture is then “baked in” to the process and we find ourselves leveraging our software versus fighting it.
• Teach the organization to “shrink their bets”.  Massive projects take on a life of their own.  And living things tend to create antibodies to change.  With large projects, too much is riding on the vision, plans, and promises of the project and its stakeholders.  When that happens, human nature is to “press on” and achieve project deadlines (even if the project or company is destroyed in the process).
• Teach organizations that learning is the most crucial, and scarce aspect of projects, not money or capacity.  With smaller deliverables, teams can learn how to deliver high quality software extremely fast, and learn a great deal along the way.  Rapid learning allows teams to change course quickly and achieve stunning results in the process, without massive investment in expanded capacity.

When the above conditions are met, customer expectations move away from simplistic models where DATES are the only thing they understand, to active partnership where RESULTS and VALUE once again take center stage.  It’s not that deadlines are all bad.  We understand they will always have a place in our work.  We simply try and make them less important in our daily lives, and treat them as exceptions rather than the rule.

When we do this effectively, we find that deadlines take their rightful place in the background of our work versus in the center of it.  The transition is tough and takes time.  Over the years, we have found it becoming easier and easier to implement due to years of deadline driven management and all the dysfunction and unintended consequences it creates.

Modus Cooperandi Makes Knowledge Work Manageable

Successful organizations need to turn ideas into action. The days where you could hire someone, train them in repetitive tasks, and leave them to repeat those tasks over and over are gone. Today, all employees must have some knowledge of computers, need to react to changes in context, and innovate. Unfortunately, most business practices are from an era where repetitive work was the goal.

We work with clients with very specific goals:

• Help knowledge workers understand how they create value
• Help organizations understand the natural variation in knowledge work
• Define ways to better estimate by measuring true task completion times
• Understand the capacity of work for the individual, the team, and the organization
• Create productive meetings and decrease the need for costly status updates
• Visualize knowledge work using tools like Personal Kanban that help in tracking and management
• Understand why plans routinely go over-budget and over-time
• How to identify and solve problems as they arise

Our aim is to create teams that focus on continuous improvement and, as such, can always communicate what they are creating, what state of development it is in, what impediments to completion they face, and why they are creating that particular product.

Watch the site for case studies, check out the books from Modus Press, and take a look at our client list.

And, of course, contact us if you have any questions.

Kaizen Camp: Seattle–What We Did at Camp

This year’s Seattle Kaizen Camp was awesome.

I loved the range and diversity of the attendees, with people from health care, education, government, software development, and a host of other occupations. We had attendees from college students to C-Level management. We were once again very close to gender parity. And we had people from across the US, as well as Europe and Asia.

All this to discuss our experiences with continuous improvement, Personal Kanban, and lean.

The weather co-operated, so most of our 75+ sessions were held outdoors in the beautiful Seattle summer. Just warm enough to be comfortable.

Sessions included:

• Kanban at Home
• Failing Well
• Lean Contracts
• The Cynefin Framework
• Accelerating Innovation
• Metaphors to Convince Others of Lean Principles
• Resilience with Kanban
• Extreme Self-Organization
• Personal Kanban Experiences

and more .. about 70 more.

What was most important for Tonianne and me as organizers was the speed at which people created topics and the depth of conversations.

All the topics and conversations were conceived of, led, and participated in by the attendees themselves. There were no official speakers, no lengthy powerpoint presentations, no middle-of-the-day sugar crashes in dark rooms. Kaizen Camp: Seattle was people practicing Lean, Personal Kanban, and Continuous Improvement talking about what they did and how they did it.

We are looking forward to Seattle’s event next year, but in the interim we have several planning across the US.

Coming up later this year (announcements for each will be made soon):

• Kaizen Camp: Boulder
• Kaizen Camp: SoCal
• Kaizen Camp: NYC

Please come to one near you!

Several of the Photos and notes have been posted here.

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

Kaizen Camp is July 24-25, again at the beautiful Center for Urban Horticulture. Yet again, we have award-winning food trucks catering the event (both with vegetarian options), so no boring food! Already the event is nearly half full, with attendees from software, government, health care, manufacturing, education, and more.

The diversity of voices and ideas is unparalleled – which is exactly what we were aiming for. Lean ideals and principles will be discussed. People sharing their success stories as well as their challenges. Different disciplines working together to create new ideas and explore continuous improvement.

Last year we were blessed with great conversation, learning, food, and near gender parity. Judging by the buzz so far, this year promises to be 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. Exploring ways to create better working environments, systems, processes, and policies

What you will be spared:

1. Dull speakers
2. Bad boxed lunches
3. Canned presentations
4. Being silent while others talk at you
5. Sales pitches from consultants pretending to be speakers

Cost and Sponsors

Kaizen Camp: Seattle is $79 early bird and $99 late bird. With all this learning, two awesome meals, a full day of snacks, and a T-shirt from Nordstrom, that’s a steal. We couldn’t do this without our sponsors:

• Nordstrom Innovation Labs
• Modus Cooperandi
• University of Washington
• University of Washington – Bothell
• LeanKit Kanban

See you there!

Lean Coffee–Value Through Flexibility and Democracy

In late 2012, Modus Press will be releasing a book on Lean Meetings.  At the core of this is a tool we use called Lean Coffee.

Where it came from

In 2009, Jeremy Lightsmith and I were sitting at a coffee shop wondering about how to start a new Lean-thinking community of practice in Seattle. This sounded like a great idea, but neither of us had enough time to devote to running yet another professional organization.

So I suggested that we make it self organizing. We find a place, a time, and an open-but directed, format.

Value Through Flexibility

Each Lean Coffee Meeting works like this:

• Framework: Draw a Personal Kanban
• Personal Agendas: Invite attendees to write their topics on sticky notes
• Democratization: Giving them two votes each, ask attendees to vote on the topics on the table
• Group Agenda: Prioritize the sticky notes
• Discuss

There are three main things happening here:

1. There is a tight enough framework for focus
2. There is a loose enough framework for new ideas to appear, and
3. The framework gives everyone ownership.

Why is this important?

In a Lean Coffee style meeting, no one “owns” the agenda – it is created on-the-fly. A meeting is called with a topic and maybe a few item to be discussed. This format allows the good brains you invited to your meeting (I hope you invited good people) to extend the agenda in useful ways. Since the group votes for items discussed, chances that people will drone or or otherwise hijack the meeting are much less.

Where We’ve Used It

Since launching the Seattle Lean Coffee group in Seattle, we’ve brought Lean Coffee style meetings to organizations including, RW Baird, The Library Corporation, Comcast, Nordstrom, and The United Nations (in offices worldwide). In the corporate setting, we’ve found the lean coffee format to greatly lessen the amount of time wasted trying to “get on the same page,” and greatly increase the productivity and effectiveness of the gathered group.

What This Means

Getting On The Same Page – Most meetings waste a lot of time discussing background to issues that everyone already knows. The Lean Coffee format asks people to write what they wish to talk about on sticky notes and place them into a to-discuss area. When everyone sees the gathered topics, they get context of the topics individually and in relationship to other topics. Seeing this, attendees can quickly align around the topics, their meanings, and the goals of the meeting.

And if they can’t? Well, then we’ve just discovered something valuable to discuss.

Increased Productivity and Effectiveness – Meetings tend to waste a lot of time talking about talking. We will go over the agenda, we will discuss how the agenda isn’t perfect, we will rigidly stick to the agenda. People are frustrated with meetings not because they don’t want to work together, but because they view them as ineffective and, therefore, as interruptions in their day.  With a Lean Coffee, groups can create a relevant agenda designed to quickly achieve value.

Failure is an Option-Collaberwocky Episode 4

The Lean Startup movement has focused considerable energy in the message that we learn from failures. Small, easily recoverable, failures can be invaluable in the success of a company. However, many ignore failure and focus on success. Since success is a rarity and failure much more common, we limit our learning opportunities by that success focus.

However, many also do not understand how the scientific process actually works. We therefore tend to build experiments that are invalid.

In Episode 4 of Collaberwocky, Corey Ladas, Jabe Bloom, and I discuss thoughtful failure.

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.

Introducing Collaberwocky – Collaboration Conversations

For years I have been trying to get myself to do an interview show. There was one problem – interviews are not very collaborative. After doing Lean Coffees for a few years and hosting Lean Camp Seattle last year, it became clear to me that conversation creates information – and that was compelling.

So we launched Collaberwocky, a series of conversations about collaboration.

This runs exactly like a Lean Coffee. We get together with a few participants, we build a kanban, vote on what we’d like to discuss, then we discuss.

The first five episodes are with Corey Ladas, author of Scrumban, and Jabe Bloom, CTO of the Library Corporation.

This first Episode is “Intentional Cooperation” in which we discuss creating teams and processes that intentionally foster collaboration.

Why I’m Excited About Lean Camp

JUST LET ME LEARN!

Hallway conversations are almost always what people peg as their favorite parts of conferences. Yet conferences rarely provide ample space and time for people to have these conversations. When we actually converse with our peers or with the speakers, we learn more and, more importantly, we retain more. We are actively engaged in the learning, rather than just being spoken to.

When Jeremy Lightsmith and I sat down to plan a conference, we didn't spend any time on the format at all. We both knew we wanted conversation, learning, and community over talking heads, big names, and locations. The Open Space model was a logical fit for the Lean Camp we wanted to create.

I am very excited about Seattle Lean Camp because it embodies some central ideas.

1. The Future of Work – In the last several years, science has uncovered some startling new truths about how we learn, how we collaborate, how we are motivated, and why we work. Through the intersection of Lean techniques, neurophysiology, and social economics, we are learning that humans respond better to respect than remuneration. Additionally, changes in the way we communicate and the cost of information storage and dissemination has had profound impacts on the workplace. As the workplace becomes more social and more humane, it also is becoming more innovative and less reliant on traditional top-down management.

2. Learning and Creation – Lean Camp is about value creation from the outset. While many attendees have been headliners at other conferences, at Lean Camp they are there to share their wisdom and learn from others – just like everyone else. The potential topics at Lean Camp are as varied as the participants. At Lean Camp we want to find new solutions to old problems in a dynamic, charged environment.

3. Cross-pollination - Conferences that are for one industry and attended by only people in that industry miss the opportunity to really learn from others. At Lean Camp, we already have attendees representing software design, government, manufacturing, medicine, academia, graphic design, engineering, and more.

4. Gender Balance – I have been pleasantly surprised to see something very near gender parity in the people signing up for Lean Camp. After years of putting on conferences in both software development and engineering, this is certainly a first for me. I'm looking forward to asking attendees what drew them to Lean Camp to find out why we are enjoying such remarkable attendance

5. The Fallacy of Work / Life Balance – Work life balance is more than personal and it is more than a choice. Whether we are employers or employees, we need to recognize and respect that “work” is part of life, not some opposing force we balance with life. Studies already show that companies with a strongly collaborative corporate culture have weathered the current economic downturn better. Pre-Lean Camp conversations have drawn focus on this fallacy and toward respect in the workplace.

6. Low Inventory – W. Edwards Deming warned us of keeping inventory in our companies decades ago. Inventory are those things that we create, believing they are value, but then need to maintain and mange those things. For manufacturing, inventory might be the parts you need to make your product, or the products themselves. We want to make just enough and at the right time. For a conference, inventory takes the shape of expensive speakers, venues, large elaborate dinners, and many sponsors with special needs. In creating Lean Camp, we've specifically kept our inventory low. Even though everyone who comes to Lean Camp will receive a free T-Shirt and free food from two of Seattle's premier gourmet food trucks, and will enjoy spending time at the University of Washington's beautiful Center for Urban Horticulture, Lean Camp is only $50.

7. Great Food – Those who know me, know when I’m around food can’t be far away. This year at Lean Camp we have two of Seattle’s premiere gourmet food trucks providing free lunches to all attendees. On Saturday we have Where Ya At Matt? with his awesome Cajun selection. On Sunday we have Pai’s with his highly acclaimed Hawai’ian and Thai works of art.

8. Clothing – Nordstrom’s Innovation Lab is making sure that everyone who attends also leaves warmer and happier with a beautiful Seattle Lean Camp T-Shirt.

9. Value Cascade – So what we have here is a beautiful setting, smart people, an open format in which to think, great food, and a stylin’ t-shirt. All for $50.

This year in Long Beach, California, the LSSC put on a conference that explored Lean and kanban in software development. We had a wonderful turnout and fantastic conversations that resulted. With Lean Camp, we are hoping to take those conversations and combine them with creative minds from other industries. We want to explore the personal, the teams, the governmental, and the corporate views of these emerging ideas.

I am excited about Lean Camp's potential to unlock new ways of thinking about work, about life, and about the future. More than anything, I’m excited to see what community grows from this. We’ve built a strong community of practice for kanban and lean with Seattle Lean Coffee – what comes next?

Thank you for all who have signed up thus far and looking forward to seeing the rest of you there as well.  (And I’m looking forward to the food ….) 

Heroes Are Just Alright With Me

 

It's three o-clock in the morning and you’re awakened by the unwelcome beep of a text message. You don't even have to look at your phone to know what it’s about. Good news always sleeps ‘till noon, as the saying goes, and so you surmise (quite rightly) that somewhere - somehow - something’s gone wrong with the servers and the site is down. Your business is based entirely on global eCommerce. Every minute the site is down customers are annoyed and sales are lost.

You stumble out of bed and make your way to your office downstairs. Your wife sleepily yet pointedly reminds you on your way out that this is the fourth time this month. This is not news to you. And to be honest, her count may even be on the conservative side. For months now, the site has been springing leaks on a weekly basis. The team is disgruntled. Some have left, while the ones who’ve remained are feeling powerless. The issues are too numerous. They simply can't keep up.

You get into your office, boot up your laptop and find two team members chatting about the problem. Dave has already isolated it, and is in the midst of fixing it. That indicates it's a problem with the fulfillment system. Dave knows his way through that code better than anyone. If it were a problem with search, Ryan would be all over it. If it were with transaction processing, Mei would take care of it. As for the other parts of the site, well, they don't break.

For now.

The six other team members no longer bother responding to pre-dawn texts. They assume (quite rightly) that whatever problem’s presented itself relates to one of the three typically problematic systems, and that one of the three aforementioned “heroes” will take care of it.

As the team lead, you just have to wake up and be present – but the heroes will get the job done. Soon it's just you and Dave in IM, though you're not even talking. Then Dave types, “Try it now.”

You run through a quick perhaps even haphazard battery of tests, and everything looks fine. You know Dave’s fixes work.

You close your laptop, and go back to bed.

The next morning at work, everyone’s busy fixing bugs. No one even mentions the problems that arose in the middle of the night. This is the status quo.

~

While it may seem depressing, many on-line businesses will find this scenario familiar. It is not an edge or extreme case. When teams create complex software and a lot of hastily released code, they end up with something called “technical debt.” In essence, technical debt is releasing something (and it can be anything -  from software, to a car, to food in a restaurant) that can work most of the time, but is likely to be returned.

When teams release software with a lot of technical debt, a few things happen. First, the team becomes unhappy, knowing that they've released a questionable product and that bugs are going to come back. Second, if the bugs are numerous and severe (causing outages like those in the story) heroes show up to save the day.

Heroes tend to be armed with razor sharp, double-edged swords.

The Edge that Solves

On one edge, they quickly cut through to the heart of the problem: they fix the code, and get the site up and running. While that's wonderful and everyone can be is relieved for the moment, it’s just that - for the moment.

The Edge that Cuts

The second edge of that sword cuts into the team. While the hero gets the site up and running, no one knows what he did or why. His code was never vetted, tested, or“refactored” (a fancy word coders use for “edited”). So in the end, the hero has created undocumented code that no one else can go back and work with. Every time the hero touches the system, they fix the symptom (the outage) and exacerbate the problem (technical debt).

That's not optimal, and everyone knows it. But frequently organizations suffer from so much technical debt that focus is placed on putting out fires at the expense of creating value. More fires equate to more undocumented code. More undocumented code makes it more difficult to fix the root causes of the problem. If the root cause remains, we continue spending time and money responding to it.

In Agile, we've declared hero culture to be a detriment because it creates and perpetuates technical debt and introduces inefficiencies. The Agile solution to team heroes is to cross-train – to make sure that many people on the team have the capability to fix the code. That solution is backed up with coding standards, unit tests, and other practices designed to avoid sloppy code and remove the need for heroes in the first place.

So, we have our solution. Simple! But wait - what about all the technical debt that remains? We still have heroes. We still have not found our coding nirvana.

Why?

Because coding is inherently messy, and it always will be. If it weren't messy, it would be automatically generated by software writing software. If it weren't messy, coders would make $35 an hour. If it weren't messy, we wouldn't need Agile to begin with.

So, technical debt is a fact of life. Heroes are a fact of life.

Should they be?

Nope.

So let's think about this a minute.

We have a group who knows their product. We  have individuals on the team who have hyper-specialized in response to the reality of the system. We have a system that is breaking often and requiring emergency repairs.

Many Agile coaches would put systems into place that removed the heroes from their stations and cross-trained others in the group. Is that the right solution? Maybe.

Maybe not.

The other people on the team are overworked just keeping up with all the technical debt hitting them in the face. Catastrophic failures currently require immediate intervention by someone with specific knowledge. Every minute is worth millions of dollars. This is NOTnot the time for cross-training.

It's hero time.

So, in a traditional system, the hero's tasks would be lost in the shuffle. The code enters the system, patches the problem, and people go on about their work. That's not good either. Hero time cannot be blind-faith time.

But what if we're using a kanban on this team. For the non-heroes, we have a simple value stream of:

And that works fine, because those coders are doing things by the book. Their code has unit tests, it meets coding standards, they are pairing, have code reviews, and so on. The legitimately generated new code has ample safeguards for quality.

The heroes, however, are responding to a threat-in-progress. Their task is to code it and forget it; get the site up and running at all costs. To make matters worse, these heroes are brilliant problem solvers. This means that their code is not only undocumented, it's completely confusing to read. It works, but no one can tell how it works. They saved the day, but left this nugget of ingenious-yet-impenetrable code gristle for people to chew on later.

At the time though, and this is important, they successfully got the system up and running immediately. They routinely save the company from ruin. And that's a good thing.

So let's rationally solve this problem. Let them be heroes, but give them a different value stream that gets the fix in and then responsibly refactors and integrates that fix with the rest of the system.

The new hero-embracing value stream might look like this:

So we extend our hero metaphor a bit with some familiar characteristics.

1. Above The Law: The hero is uniquely gifted with the ability to release production code without any testing. The goal for the hero, when invoked, is to fix the problem and get the system running asap, no questions asked.
2. Jimmy Olsen is Needed: Immediately upon release, the hero teams with a normal human being to refactor their genius code into something that is maintainable, readable, and avoids future technical debt.
3. Bat Caves & Arctic Fortresses: Heroes need to be introspective. “With great power comes great responsibility,” says the Batman. After a situation where a hero action is invoked, the team or even part of the team should meet and discuss the issue, why it happened, and how to strike at its root cause and ensure it does not reoccur. This gives the crime fighter the ability to stop the next crime before it starts - really taking advantage of their gifts.

Number 1 in this list ensures that mission-critical problems are dealt with immediately and decisively. Number 2 ensures that the hack is not the final solution. Number 3 ensures that the team learns and quickly sets out to improve the system to avoid future calls to the hero.

Ultimately, we'd like to build systems with no technical debt. Our processes are, of course, aimed at that lofty goal. But like it or not, we do have emergencies that necessitate rapid fixes. We have but two choices – boldly stand up and face reality, or continue to solve technical debt with more technical debt until the software implodes.

Which do you choose?

("Superhero Down-Time" Photo by Jason Stanley)