lean

Similarities Between Lean and Agile

It is said that the difference between theory and practice is greater in practice than in theory. Although I believe this is true of a lot of things, one area that eludes this old saying is the practice of Lean and Agile.

Practicality

The theoretical differences between Lean and Agile are the frequent subject of heated debates, even though their practical implementations often solve many of the same problems. I think those differences aren’t nearly as pronounced as they are often thought to be, and that far too much energy is expended on their account. I suggest we focus instead on getting to the business outcomes we all crave by cherry-picking the best arguments and techniques from each. Let me elaborate:

Origins

Of all the differences I hear about, the most prevalent seems to be that Lean seeks to reduce variability in the work so that the system can be optimized, whereas Agile accepts that variability as inevitable and attempts to adapt for it. This description is not without merit from a historical standpoint. Lean was first popular in traditional large scale manufacturing environments, and Agile sprouted in software development where each unit of work is unique.  Though this analysis may be historically accurate, it is also far too shallow for us to conclude that Lean and Agile are fundamentally different.

Practices

The similarities strike me as far more numerous. Both Lean and Agile seek to deliver value to the customer through building the right thing. Both promote a culture of continuous improvement: Lean has kaizen, and Agile has the retrospective. Furthermore, Lean has poka-yoke to mistake-proof problem areas, and Agile similarly promotes the management of technical debt. Both focus on reducing delays. Lean most frequently uses the value stream map as the main tool, while Agile methods often use short iterations for much of the same purpose. Both emphasize the importance of quality. Lean has quality standards, and Agile frequently has a “definition of done.” Both promote resolving blocking issues quickly through all-hands-on-deck approaches. Lean has its andon cord, and Agile often has an impediment identification and removal process. Both promote a reduction of Work In Progress (WIP) for the purpose of accelerating flow. Lean emphasizes single-piece flow; Agile urges people to swarm on a common work increments. The list goes on and on.

Values

The parallels between Lean and Agile are actually not surprising. Indeed, a quick examination of the fundamentals reveals similar values. If one compares the principles that underpin the well-known Agile manifesto with the expression of Lean found in the Shingo Model, one notices a common philosophy.

I think the Shingo Model cornerstones of respect and humility are just a highly condensed expression of the Agile manifesto. What I mean by this is simply that the Agile values (and principles) can be traced back to respect, humility or both. For example, humility is implied in the desire to replace planning with a discovery approach. To arrive at that desire, we must first humbly admit the limits of our knowledge and prediction abilities. Similarly, respect is implied in the belief that people are intrinsically motivated, trustworthy and able of self-organization.

Put another way, Shingo’s respect and humility are to Agile what the Maxwell equation is to the inner workings of electric car propulsion systems. All the information is there, but it has to be unpacked.

Fig. 1. “Maxwell-Faraday equation”

Bottom Line

In summary, I believe Lean and Agile are rooted in many of the same principles and values. The challenge of articulating the differences is probably best left to the academics. The doers should focus on taking action instead, because while the differences may be smaller in practice than in theory, practice still makes perfect. I’d love to hear from you if you think this is an oversimplification that obscures some important practical differences.

Works cited

“Maxwell-Faraday equation”, Maxwell’s equations, Wikimedia, 24 Nov. 2015. Web. 1 Dec. 2015.

Where to Start a Transformation?

So you’ve decided to go ahead with a transformation. How should you go about it? Where should you start? And whom should you start with? Does it matter? I suggest that it does indeed matter, and a lot.

For me anyway, one method has worked so much more successfully than the others that in my mind it is a “no-brainer.” That method is to cultivate fully the most fertile plot first. I call this the depth-first approach. Let me explain that. One of the first decisions that need to be made is whether the transformation will be attempted by moving everyone in lockstep, or whether there will be some form of staggered rollout and whom to start it with.

False Choice

Forgetting for a second the irony of using a big batch approach to lead a Lean or Agile transformation, we find that even the lockstep method ultimately devolves in a gradated approach. I’ve never seen a sizable group of people in which everyone is subject to identical constraints or internalizes new concepts at the same rate. Thus, even when the big batch method is attempted, you end up with pockets where certain concepts are applied ahead of others. Therefore, in no time at all some individuals and teams require a different kind of coaching. Whatever economies of scale are hoped for with the big batch approach, they quickly evaporate due to the now differentiated demand for coaching. Since coaching and mentoring capacity is usually limited, the change agents have to prioritize the opportunities for assistance.

The Who

Perhaps you pick the toughest critics and attempt to convert them first, figuring that if you can move them, you can move anybody in your organization. Or perhaps you are better off aligning with like-minded people and equipping them to evangelize on your behalf so that you can magnify your influence.

The Where

Space-wise, you could identify some of the organization’s biggest problems and attempt to solve those with the Agile mindset. If you crack one of those nuts, the likelihood that the others can be cracked too increases. On the other hand, maybe you should be wary of what is likely to be a tougher slug and instead pick a space where success is both more likely and less distant.

Mind Your Credibility

If you work in an organization that looks anything like the ones I’ve worked in, you know that people are more swayed by results they can see than unverifiable tall tales of riches. I try to never forget that as the change agent, I’m also perceived as the salesman. Increasingly tangible evidence of success may be required to move the transformation through the typical phases of adoption. This is where native stories are so important, and why I set out to create and record them as soon as possible.

Selecting the Right Investment

Every bit of transformational success is akin to making a payment to the bank. With that payment usually comes a deadline extension and an increase in credit score. Over time, as a portfolio of native successes is built, there are fewer resistors. Success begets success.  That’s why I choose to cultivate deeply the most fertile organizational plot I can find.

I’d sincerely love to hear from those who have experienced success with the breadth-first approach. I’m curious to know what conditions had to be true to make it work.

What Are The Benefits Of Agile?

. . . or Lean, or whatever one may wish to call the discovery mindset? My thoughts on the benefits an organization stands to gain by going through an Agile transformation have evolved over time. I’ve come to believe there are benefits on multiple levels. Awareness of them helps me focus on the prize and become a more effective participant, coach, and leader. Here are some of the benefits I have witnessed first-hand.

Effectiveness

When I first experienced Agile, I was a participant in a Scrum team. My initial reaction was that we were going to be a lot more effective at our job. With better communication, a focus on a common goal, and more frequent validation of our wares, there would be less wasted time and fewer self-inflicted reworks. And so it was.

Money

Over time, the organization got better and faster at cranking out products and services through a more flexible, more collaborative workforce, and I concluded that the transformation was about more money for the corporation. We were operating with a higher level of quality, so better financial results were indeed part of the equation.

Customer Intimacy

After better internalizing the “customer collaboration” aspect of the manifesto, we developed outstanding relationships with customers. We had a stretch of more than a year when we did an end-of-sprint demonstration to one or more customers without exception (See this post for tips on making demonstrations happen). At one such demonstration, a customer asked if she could purchase the product right then, about three months prior to our expected release date, because it met her needs! It then dawned on me: this new mindset is really about delivering customer value. Better financial results are just a trailing consequence.

Fun

Later still, as the rest of the leadership team and I evolved our main management paradigm, I started to piece together a different picture. There was a lot more energy in the office. Employees had taken control of their physical space, work tools, and organization. People from far-flung divisions wanted to join us just for the sheer fun of it. It felt like a much happier place, driven by intrinsic motivation. And since plenty of research suggests that happier employees lead to more successful organizations, I began to think that a perfectly valid reason to pursue such transformation is the pursuit of happiness.

Effectiveness, financial rewards, customer value, and happiness all seem like valid reasons to start down the path of a transformation. In fact, I think they all co-exist to some degree. Have you found something else? What is driving your transformation?