As coaches or consultants, we need to listen first, and then listen some more, before deciding on a particular line of “intervention.”

The Minimum Effective Dose is not a new concept. In medicine, a (capable) doctor will make every effort to prescribe the lowest dose of medication (or other treatment) that is still capable of producing the desired outcome for a particular patient. As with many things in life, more is not always better. Too much of a “good thing” can result in unnecessary costs, wasted effort, and unwanted side-effects.

Recently, I’ve noticed that some folks in the development community are pushing back on the need for many practices advocated by XP, Lean IT, or Agile. We all seem to agree that less is more: less process, less documentation, fewer meetings, etc. So why, they ask, do we need to have all this extra stuff like daily meetings, kanban boards, backlogs, sprints, pair programming, retrospectives, etc? Wouldn’t it be better to spend more time just getting things done?

That might sound like heresy to some of us involved in process improvement, but they are making a good point and we should take note. While I believe that there are many practices — whether drawn from XP, Lean IT, Agile, or elsewhere — proven to add value in many organizations, I also believe that coaches and consultants do everyone a disservice when we attempt to apply the same practices to every situation.

Context is very important. What is the organizational culture? What are the priorities of the business? What are the skills and backgrounds of the team members? Is everyone located together in the same room or spread across continents? How satisfied are they with their current process?

All these variables and many others will have an impact on the “diagnosis” and “treatment” of an organization. As coaches or consultants, we need to listen first, and then listen some more, before deciding on a particular line of “intervention.” To continue the medical metaphor, we should remember that our first mandate is to “do no harm.” And when intervention is warranted, change should be applied gradually and incrementally. (Yes, this is also the basis of Kaizen.) This approach might not sound exciting, but it isolates individual changes so that their effects, intended or not, can be measured.

Finally, we have to be willing to periodically review practices already in place and ask ourselves if we are still getting value out of them. Perhaps the team or organization has matured to a level where certain practices are no longer required. Or perhaps certain practices have lost their value because the team is only going through the motions. Regular “checkups” help keep everyone honest about what is really working and what isn’t.

Lean IT Consulting

the volume and complexity of what we know had exceeded our individual ability to deliver its benefits correctly, safely, or reliably.
– Atul Gawande

I’ve just finished reading The Checklist Manifesto by Atul Gawande. In it, he provides compelling evidence that something as simple as checklists can have a very significant impact in any field where there is complexity and where there are serious consequences when mistakes are made. Does this sound like any field you know?

Gawande is a surgeon, so he spends a lot of time discussing the impact of using checklists in the operating room, but in the process of learning more about how checklists are already being used, he also takes a closer look at how skyscrapers are built, airplanes flown, investments screened, and food prepared. It turns out that the best practitioners in all of these fields rely heavily upon checklists to consistently deliver safe, reliable results.

Nonetheless, Gawande also notes that many, otherwise capable, people still choose to ignore the evidence and avoid using checklists. Why? One simple reason is that there is nothing sexy about a checklist. It’s much easier to get excited about the latest technology, whether that be a surgical robot or project management software. Another reason is that some people feel that a checklist takes the “art” and the “individuality” out of what they do. After all, if their job could be simplified into a mere checklist, then anyone could do it. And a third reason is that they claim that it will take too much time to stop what they are doing and run through a checklist.

Well, it’s hard to argue with the first excuse that checklists aren’t sexy, but they are certainly effective, and they cost very little to create. As for the argument that they “dumb down” skilled work, I think those folks are missing the point of a checklist. It’s not intended to replace expert judgement. A checklist is more like a safety net. It helps prevent simple mistakes so that experts can focus on what they do best. It works because there are limits to how much the mind can remember at one time. And finally, a well designed checklist takes very little time to review and, in practice, saves time that would otherwise be spent correcting simple mistakes.

Aviation is perhaps the field most committed to the use of checklists. Inside every cockpit is a flight manual which contains clear, concise procedures for almost any contingency, and it is used by even the most experienced pilots. Some of these pilots have flown thousands of flights, but they still follow procedural protocol to the letter. Familiarity can lead to overconfidence and complacency, and they know that it could also lead them to overlook the obvious. Alternatively, when there is an emergency, they turn to the flight manual for the proven best method of handling the condition. It helps to them to act quickly and maintain focus.

Gawande also found that checklists can actually help to increase communication across teams by making it an explicit part of how work gets done. For example, the checklist used in operating room procedures included a step in which each member of the team introduces themselves to the others. It also included a step for anyone to express concerns about the specific procedure or patient. At first, some teams members, mostly surgeons, felt awkward using the checklist, but polls taken at the end of operating procedures showed that most people rated collaboration much higher than before the checklist had been put into place. And, most importantly, many unnecessary complications, including deaths, were avoided.

So, could checklists have a place in IT? In the past, I’ve seen many ineffective attempts to add checklists in IT. Often, these checklists were simply governance in disguise. They were created somewhere else in the organization, or by external experts, and then imposed upon the team. Not surprisingly, they were seen as just more busywork, not something that added any real value. Consequently, they were either ignored or completed as an afterthought. It should be obvious, but it’s important that the checklists add real, measurable value, and are perceived as doing so by the people having to use them. Therefore, it should also be obvious that the people using them should be part of developing them and they should be encouraged to continuously adapt them to their needs. They are, after all, the experts.

So, where should we begin? Begin where there is the most risk of something being overlooked or not communicated. What are the types of activities that we do repeatedly (absent-mindedly), or the ones that we don’t do often, but when we do there is likely to be pressure (urgency) to get it done fast. Developers might benefit from running through a quick checklist before checking in their code. The operations folks might benefit from a series of checklists to run through before, during, and after releases to production. Finally, it might be helpful to have a repository of checklists for responding to specific events, especially outages and other emergencies. I say “might” because there are no hard and fast rules that apply to every team and every situation. You have to use your own judgement, run your own experiments, and measure the results. Over time, each checklist should be reviewed and updated according to what’s been learned.

Perhaps it will become commonplace someday for IT folks to receive a “flight manual” specific to their job when they are hired. I’d love to hear your experiences, good or bad, using checklists.

Lean IT Consulting

Lean Project Portfolio Management

Kanban is great for managing software development projects, but how about managing a whole portfolio of projects? Well, Kanban can be used for that, too. A kanban board (physical or electronic) can be used to track the flow of entire projects all the way from conception through execution and (post-deployment) evaluation. Just as the work capacity of a particular team is limited, so is the capacity of the organization to handle many projects at once. By limiting the number of projects-in-process at each stage, it’s possible to reduce wasted effort and improve project throughput. Fewer projects-in-process should also reduce project overhead (effort spent coordinating a large portfolio of active projects), and understanding the actual project capacity of the organization enables management to make more informed decisions about staffing and/or outsourcing.

Using A3 Reports to Summarize Projects

Ultimately, though, some projects are better off not being done at all. Before beginning any significant project effort, it should be clear what we hope to achieve. Creating an A3 Report for each project provides a concise, consistent format for evaluating and documenting projects. The specific format can be adjusted to the needs of the organization, but it should fit onto one sheet of A3-sized paper and it should answer the following questions:

1. Problem Statement – What is the exact problem we are trying to solve?
2. Current Condition – What does the current state of affairs look like?
3. Root-Cause Analysis – What do we believe is the root cause of the problem?
4. Goals – What are the (business) objectives of this project?
5. Plan – How do we plan to achieve these objectives?
6. Results – Did we succeed in meeting our planned objectives?

At first, this may seem like a lot of information to fit on one page, but keep in mind that A3 is a really large piece of paper. Of course, there will be lots of information that is not included directly on the A3 Report, but part of the value of creating an A3 Report is the discipline of including only what is truly important and necessary. Too often, important project details are buried inside a large report that few people actually read. This wastes a lot of time and a lot of paper. Using a concise, consistent format enables projects to be quickly evaluated and prioritized based on their urgency, risk, and potential to add value to the organization. In addition, the success of a completed project can be quickly evaluated against its stated (business) objectives.

The following graphic shows how using Kanban to manage the project portfolio can be integrated with the use of Kanban to manage project execution. The A3 Report is used as a concise, consistent format for presenting, discussing, and evaluating projects.

Shorter Project Cycles Encourages Experimentation

Ideally, shorter project lead times and reduced project overhead will encourage internal customers to request smaller, shorter projects. In contrast, when it takes “forever” to get a project approved and started, internal customers are more likely to pile everything they can into one big project. Larger projects also make more sense when there is a relatively large, fixed amount of overhead costs associated with each project. With these obstacles removed, internal customers are free to try lots of small “experiments.” Not all of them will pay off, but the learning cycle is shorter and the risk of failure is reduced.

The following graphic shows how continuous improvement at level of project execution (process improvement) supports continuous improvement at the organizational level (business improvement).

Lean IT Consulting

The Swiss Cheese Model (SCM) was first proposed by James Reason as a way to analyze accidents resulting from systemic failure. Each “slice of cheese” represents a layer of defense against failure. “Holes” represent gaps (potential points of failure) in that layer. Since there are usually several layers of defenses, a couple of holes in each layer may not present an immediate danger, but when the holes “line up” across the layers, they create the potential for systemic failure.

James also distinguished between two types of “holes”: latent conditions and active failures. Latent conditions are accidents waiting to happen. They can go undetected for a long time without causing any specific problems, but they may eventually contribute to a systemic failure. Active failures, on the other hand, will have immediate impact if their effects are not properly mitigated by subsequent layers of the system. Active failures are often the result of human error or deliberate sabotage, but they could also be caused by a natural disaster or other external event.

Of course, like any explanatory model, there are limits to the applications of SCM, but I believe that it could be useful for assessing risks associated with IT security and system reliability. Such assessments require coordination across multiple areas of functional expertise for them to be most effective. The model could serve as a discussion tool for representatives across disciplines, with each group responsible for a particular “slice.” The usefulness of the model lies in its ability to reveal complex patterns of potential failure that might not be evident when each layer is viewed independently.

Some critics have argued that not all risks can be described using a linear model like the SCM. Of course, in high-risk or regulated environments, the SCM should be supplemented by a formal Fault Tree Analysis (FTA) and/or Failure Modes and Effects Analysis (FMEA). These are both powerful techniques for analysing and documenting systemic risks, and they are capable of handling extremely complex dependencies, but they also lack the simplicity and explanatory power of the SCM.

The exact model used will be different for each organization, but it should be possible to create reference models for different industries and different technical implementations. Normally, the outer layers of the model refer to particular aspects of the organization, including its management, procedures, workplace, and culture. The inner layers are usually more focused on specific safeguards in place to mitigate the effects of failure at the organizational levels. When he first proposed the Swiss Cheese Model, Reason believed that most accidents or failures could be traced to systemic failure (rather than just human error). Some critics of the model argue that it does not place enough of the responsibility for failures on the actions of individuals, but does it really make sense for a well-designed system to allow a single individual to cause a catastrophic failure?

Lean IT Consulting

Management by objective works – if you know the objectives. Ninety percent of the time you don’t.
– Peter Drucker

Peter Drucker coined the term Management by Objectives in 1954 and since then its mis(application) has become so embedded in mainstream corporate culture that its validity is rarely questioned today. There’s nothing inherently wrong with MBO, but even Drucker knew that it’s a lot harder to get right than most people think. When objectives are poorly conceived (and employees are evaluated against them), they can create incentives for individuals to behave in ways that are not in best interest of the organization.

As a simple example, I’ll use my local bus service, the 77 line. Anyone who has ever taken a 77 bus knows that the buses arrive very sporadically in groups of two, or even three at a time. They also know that the drivers are stressed out, angry, rude, and drive like maniacs. So, what’s happening here? Well, I could be wrong about this, but it appears that the drivers have an incentive to drive as fast as possible, even if that behavior translates into a terrible experience for the passengers.

From what I can tell, management tried to solve the “problem” of buses arriving late by installing a GPS device in each bus that keeps track of the location of the bus against a completely unrealistic and arbitrary bus “schedule” posted at each stop. Not surprisingly, this device simply displays “late” all the time, creating stress for the driver and encouraging them to go faster still. As a result, buses that actually stop (and, god forbid, wait) for passengers are not nearly as “productive” as those that come up behind them and zip past without stopping.

Contrast this with a system where the drivers are clear that their job is to please the customers, their passengers. In addition, drivers are instructed on how to behave and how to drive in order to make this happen. And finally, technology is used to help the drivers maintain an even and sustainable pace. As a result, the drivers are less stressed, service improves, and the average passenger wait time drops.

Deming saw the dangers of Management by Objectives and, instead, advocated something he called, Management by Planning (MBP). The main difference between MBO and MBP is that with MBP everyone is clear not only about what the objectives (of the organization) are, but also understand how the overall system functions. Therefore, they have a much better understanding of the behaviors that will lead to both their success and the success of the organization. To management, those behaviors, in fact, become more important than the goals themselves. Since individuals have much more direct control over their own actions and behaviors than they do over outcomes, this focus often improves morale and that in turn improves outcomes.

However, you might argue that taking the right actions is nice, but what if that doesn’t result in meeting the organization’s objectives? Well, then management either did not plan sufficiently or it set unrealistic goals. Blaming poor outcomes on workers is like blaming the poor bus service on the drivers. Yes, variation in worker performance has some effect on outcomes, but much less than is commonly believed. (Deming used his Red Bead Game to illustrate this point.) Neither MBO nor MBP should be used as an excuse for management to abdicate its responsibility for outcomes.

Lean IT Consulting

Have nothing in your houses that you do not know
to be useful or believe to be beautiful.
– William Morris

5S refers to a set of five practices (all beginning with ‘s’ in Japanese) for creating and maintaining a clean, safe, and orderly work environment. Of course, it’s easy to see why this type of activity makes sense on a factory floor (where an accident can be fatal), but when it comes to “knowledge work,” that is, work that primarily involves the manipulation of information, we often don’t see the value. In fact, it’s tempting for us to extol the virtues of messiness and disorder. After all, chaos is a sure sign of creativity. Right? Really?

Now I’m not about to advocate that we should all work in a sterile environment devoid of warmth, humour, and sensory stimulation. On the contrary, I believe that those aspects of the work environment can truly enhance creativity, productivity, and well-being. But what does creativity have to do with a pile of unsorted papers, a collection of dirty coffee mugs, a bookcase full of old software manuals, an inbox full of unread emails, or a hard drive full of unorganized files? Let’s face it. None of those things make us more creative. In reality, they just make it harder to focus on what really matters to us. In contrast, an orderly environment is like a blank canvas on which our creative work can stand out.

So what might 5S look like in the context of Lean IT? I’ll go through each of the five practices below. Of course, each of the terms has to begin with “s” in English as well (otherwise it would no longer be 5S, would it?), so they might sound a bit contrived, but the meaning is carried over, more or less, from their Japanese counterparts.

Sorting (and Purging)

The quickest way to create order is to have fewer things to keep track of and maintain. Get rid of anything you don’t really need and/or will never use again, whether it’s analog or digital. This could be old manuals, books you’ll never look at again, old issues of magazines you’ll never get around to reading, anything on a floppy disk, “temporary” copies of code and files, etc.

Then take what’s left and tag it, sort it, or organize it any way that will help you to find it when you need it. Remember, though, that it’s better to purge something once than to have to sort it over and over again. The first purge is always the hardest. If you’re not sure you want to get rid of some stuff, create a real or virtual “holding space” and put it all in there to be reviewed during your next purge. Eventually, you’ll get sick of seeing the same stuff and it will be easier to let it go. Repeat this process monthly or quarterly. Schedule it in advance.

Straightening

Now that you have fewer things to deal with, take what’s left and find the best place for it. A general rule of thumb is to make only the things you use the most highly accessible, while having one or more “tiers” of organized storage for things you use less often. The less likely you are to need something, the less prominence it should have in your environment. This holds true for both analog and digital items. You don’t really need instant access to every file or program you’ve ever created, or every book you’ve ever read. It’s good to know that you can get to them if you ever need them, but you don’t want them slowing down your regular backups or preventing you from walking across the floor.

Shining

This one is pretty straightforward. Keep your stuff clean. This might include regularly wiping down your desk, monitor, keyboard, etc. It might also mean clearing off your virtual desktop or running a disk utility to keep your hard drive running smoothly. If you’re part of a team that shares a common space, you might want to schedule a quick weekly cleanup of the area.

Standardizing

Creating and maintaining standards is an important component of Lean IT. Even if you are working on your own, it can be valuable to document how you perform certain activities. If it’s an activity you do often, maybe publishing a post or checking in code, then it makes sense to understand, and even document, the steps that go into that activity.

Following a consistent process will free your conscious mind for more creative thinking. It will also enable you to make and measure improvements to that process over time. And if it’s an activity you perform only rarely, wouldn’t it be great not to have to remember or re-invent it the next time? In the context of a team, agreed (not imposed) standards will make life much easier for everyone and will produce more consistent results.

Sustaining

This is probably the most difficult practice of all. It takes discipline, especially in the beginning, to get into the habit of staying organized and following standard practices. At first it might seem like it’s slowing you down, or slowing your team down. But think about it. If you or your team has a “best practice” for doing something, then why would you do it any other way? If, in fact, it’s not really the best way of doing something, then change the standard. This is the essence of Kaizen. Start with how you’re doing things now and make incremental improvements over time.

I hope that this post gets you excited about organizing your work space. If you give it a try, let me know how it goes. I’d love to hear your tips and success stories.

Lean IT Consulting

There is no knowledge without theory.
– Deming

Just as Scrum became a byword for Agile, Kanban gets most of the attention when it comes to Lean IT. But, of course, Agile is more than just Scrum and Lean IT is more than just Kanban. So why have they gained so much popularity? Well, for one thing, they both have catchy, unusual names. More importantly, however, each represents a concise, practical, and repeatable manifestation of the core underlying principles of the larger movements that they represent. In plain English, this means that they can be easily packaged and sold.

This is not necessarily a bad thing. The buzz surrounding Scrum and Kanban has fueled much of the interest in Agile and Lean IT, respectively. However, if the organizations that adopt either of these methodologies are to be successful over the long term, they will also need to understand the larger context within which these methodologies were constructed. Without this context, the “why” to go with the “how,” it will be difficult for them to adapt either methodology to fit their particular needs over time and they may, out of frustration, choose to abandon it altogether.

When it comes to Lean IT, Kanban is (often) necessary, but not sufficient on its own as a system of continuous improvement. It’s necessary because it makes the flow of IT-related work visible, enables limits to be set on work-in-process (WIP), and ensures that work is pulled rather than pushed through the system. It’s not sufficient, though, because the long-term, continuous improvement of a complex organization will require many additional practices and tools not included within the (narrowly-defined) scope of Kanban. This is where Lean IT is able to draw upon decades of Lean experience in manufacturing and services, and bring that experience to bear on the unique challenges faced by IT organizations.

Here’s a list of some Lean IT practices and tools that have evolved out of Lean Manufacturing and Lean Services:

• Plan-Do-Check-Act (PDCA)
• A3 Thinking
• Kaizen
• Kaizen Events
• 5S
• Standardized Work
• Statistical Process Control
• Value Stream Mapping
• Root-Cause Analysis
• Hoshin Kanri

Over the next few weeks, I’ll try to discuss each of these in some detail in their own separate posts. Please let me know if there’s a particular Lean topic that you’d like to see examined within the context of Lean IT.

Lean IT Consulting

The leaders who work most effectively, it seems to me, never say “I.” And that’s not because they have trained themselves not to say “I.” They don’t think “I.” They think “we”; they think “team.” They understand their job to be to make the team function. They accept responsibility and don’t sidestep it, but “we” gets the credit. This is what creates trust, what enables you to get the task done. – Peter Drucker

There’s an old Lean saying that “quality pays for itself.” The implication is that effort put into improving quality reduces waste and, therefore, also reduces costs. I believe that the same principle holds true for trust, whether this means trust between management and employees, trust between different departments within the same organization, trust among members of a team, or trust between suppliers and buyers.

Trust reduces the “friction” of business transactions and speeds up an organization’s ability to make decisions. Where there is little or no trust, bureaucracy (paperwork, regulations, committees, approvals) is used to fill the gap. Bureaucracy is a form of waste, and the only parties who gain from bureaucracy are lawyers and professional bureaucrats. Unfortunately, though, bureaucracy is essential without trust.

When I speak of trust, I’m not talking about the naive trust of a child. Real trust develops through experience and must be earned through the consistent actions of both parties over time. And trust is much harder to earn than it is to lose. When management says one thing and does another, it loses the valuable trust of its employees. Without trust, employees are more likely to spend time and effort looking out for their own welfare than the good of the organization. This is why Deming asserted that management “drive out fear, so that everyone may work effectively for the company.”

Of course, it’s easier to build an organization upon a foundation of trust than it is to develop trust within an organization that has been built upon fear, distrust, and bureaucracy. How then can we, as agents of change, begin the process of turning a culture of distrust into one of trust and cooperation? I think that first we need to provide convincing evidence that trust actually “works,” that it reduces waste and creates better results for all parties involved.

On a practical level, we could start with individuals and teams that already work closely together. Discuss how they might work differently together if there were more trust between them. How would these changes affect their work? Are there some clear benefits? What’s the risk of making these changes? Only if the perceived benefits outweigh the perceived risks will they be committed to making the changes. This won’t work everywhere, but it is one way to plant the seeds of trust within an organization and stem the growth of further bureaucracy.

Have you seen trust effectively and sustainably developed within an organization? Where did it start? Who was involved? What lessons did you take away?

Lean IT Consulting

You may never know what results come of your actions, but if you do nothing there will be no result.
– Ghandi

It’s easy to confuse the Lean IT and Lean Startup methodologies. After all, they’ve both evolved from the same underlying principles and practices that have their roots in Lean Manufacturing. In many startups, in fact, the line between the two may be completely blurred because IT and the rest of the organization are, ideally, acting as one cohesive unit. But in larger, more complex organizations I believe that Lean IT and Lean Startup activities fulfill distinct, but complementary roles.

I sometimes use the analogy of a restaurant to describe these different roles. According to this analogy, the Lean Startup activities are taking place mostly in the “dining room” where there is direct contact with the customers. In the dining room, the manager, waiters, and other serving staff are able to gain valuable real-time feedback about the service, food, etc. This feedback can then be used in order to continuously improve the customer experience.

Lean IT activities, on the other hand, are taking place mostly in the “kitchen.” Their goal is to deliver a high-quality product quickly and efficiently. Without this capability, the business will not succeed, but it’s not enough on its own. Successful, high-speed innovation requires the seamless integration of both practices.

Of course, no analogy is perfect, so I’ve included a simple diagram below that provides another way of visualizing the “dynamic” relationship between Lean IT and Lean Startup activities. Both are great on their own, but I think you’ll agree that together they’re an unbeatable combination.

Lean IT Consulting

Man built most nobly when limitations were at their greatest.
– Frank Lloyd Wright

The Lean Startup and Lean IT movements together are starting to change perceptions about what really drives innovation. Nonetheless, it’s still hard for many entrepreneurs and corporate leaders alike to grasp what artists have always known: without constraints (of the medium, the tools, etc.) there is no art, no innovation.

On the other hand, who has never been guilty of thinking that the latest camera will make them a great photographer? Or that a new laptop will make them a great author or developer? So it shouldn’t be a surprise to hear a startup complain that it can’t be successful without a million, or even 10 million, dollars in seed capital. Or that an IT organization needs to spend half a million dollars on a “change initiative” in order to improve the delivery of their services.

It’s also not just about working harder. You can work till you drop, but there will always be someone out there who’ll work harder for less. Real, sustainable advantage is earned through innovation that delivers exceptional value to your customers. Your customers don’t care how much work went into creating and delivering your product. They only care about what’s in it for them. Innovation, therefore, is not about creating more with more. Anyone can do that. It’s about constantly pushing the limits of what can be done with less.

Lean IT Consulting