PM Articles > Alan S. Koch > The Essence of Agility: Embracing Lean Principles

The Essence of Agility: Embracing Lean Principles

The Essence of Agility
What makes a project "Agile"?
Part 4: Embracing Lean Principles

by Alan S. Koch, PMP

The Essence of Agility consists of those sets of behaviors that distinguish a truly Agile team from a bunch of hackers claiming to be Agile. They are the markers that any concerned stakeholder can use to answer an important question: “Are they being Agile, or just lazy?”

In my last three columns I addressed four of the key behaviors essential to Agility in projects: Learning and adaptation, collaboration, customer focus, and small, self-directed teams. In this article, I will address the next key characteristic: Embracing Lean principles.

Lean Principles

Lean Manufacturing has been around for decades, and has been embraced by companies worldwide as the way to run a manufacturing organization. And as much as those of us who have been fighting the concept of “software factories” might hate the idea, the same principles that underpin Lean Manufacturing are quite useful in software projects. (YIKES!)

So, let’s forget for a few minutes that these principles had their genesis in the manufacturing world, and explore how Agile software projects embrace the seven Lean principles: Eliminate Waste, Amplify Learning, Decide as Late as Possible, Deliver as Fast as Possible, Empower the Team, Build Integrity In, and See the Whole.

Eliminate Waste

A team that is behaving in a truly Agile way will always be examining their own efficiency. They will always be asking questions like, “What value does that activity add?” “Why should we do that?” and “Is there an easier way to achieve the same (or better) end?”

Agile teams define “waste” in terms of their effort. Effort that is spent but does not produce tangible results is deserving of scrutiny. Naturally, some “overhead” activity is necessary on any kind of project, Agile or otherwise. But an Agile team will always look for ways to minimize overhead to only that which is actually necessary.

They may raise questions about documentation or meetings that will challenge our traditional ideas, but troubling questions are good questions. And if we can’t come up with good answers for them, then we should be glad the questions were raised!

Amplify Learning

Projects are, at their heart, learning experiences. When we begin a new project, regardless of how much we know about it, there always remains much we do not know. As we work our way through the project, we learn all of those things that we were ignorant of at the beginning. And at project’s end, we finally know all there is to know (albeit a bit too late to make a difference).

Agile teams embrace this idea. Instead of planning like they already know it all, they plan to only the level of detail they need at the time, and they provide themselves with as many learning opportunities as they possibly can. They build regular and significant feedback loops into their processes, and they plan to capitalize on what they learn from that feedback to adapt their plans.

By amplifying their opportunities to learn (and actually using that information), an Agile team can be sure to build the product that is actually needed by their customer, and do it as efficiently as possible.

Decide as Late as Possible

If we accept that we do not know it all, and that we will be learning as we work through the project, then it stands to reason that we will want to postpone decisions until we have all of the information we need to make good ones.

Of course, the big conundrum is that we are not aware of what it is that we do not know. This can lead to a paralyzing fear of making any decisions at all. And procrastination is just as counterproductive as premature commitment to decisions.

Agile teams seek to postpone making each individual decision until the latest responsible moment—that is, the latest time that the decision can be made without slowing progress or causing problems. When it is time to make a decision, the Agile team will do so based on the best information available at that time from the customer, technical experts, and any other source.

Then …

Deliver as Fast as Possible

After making a decision, an Agile team will drive the resulting work to its conclusion as quickly as possible. Lean organizations always strive to minimize work-in-progress. The reasons for doing so on software projects are different from in manufacturing:

  • Switching tasks is an error-inducing activity. Each time a programmer returns to partially complete work, he or she is likely to introduce defects into the product.
  • Partially complete work is subject to disruption or obsolescence in a rapidly changing environment.
  • Delivering quickly means that you receive feedback on the completed work more quickly (which amplifies learning).
  • Delivering something is gratifying for developers. The more quickly we deliver, the sooner we feel that reward.

Empower the Team

A self-directed team must be empowered by management to make their own decisions (collaboratively with their customer and other relevant people). When a team has been so empowered, they must embrace this authority, exercise it freely, and own their decisions—both the good ones and the bad.

Agility requires self-directed teams, because only such a team can be effective in learning and adapting to what they learn in their pursuit of their goals. An Agile team will seek authority to self-direct, and then exercise that authority with care.

Build Integrity In

Agile teams don’t just sling code. They are strongly focused on providing the product that their customer needs. It goes without saying that the customer needs a product that is high quality. Agile teams embrace a variety of technical practices that are focused on quality:

  • Pair programming is essentially a continuous real-time code review.
  • Test-driven development means that the programmers design and implement tests before beginning to code, then use those tests as their measure of progress.
  • Continuous integration includes continuous regression testing to ensure that as the system is incrementally built, errors are not introduced.
  • Refactoring is a matter of continually re-addressing the design of a program, and making adjustments when needed, instead of continuously force-fitting a bad design.

See the Whole

Finally, Agile teams always keep the big picture in front of themselves. Programming is such detailed work that it is easy to get lost in those details and end up doing the wrong thing. By keeping their customer close and seeking the customer’s feedback on a regular basis, an Agile team assures that they never lose sight of the one team member who is most important: their customer.

Becoming More Agile

We will discuss the last three behaviors of the Essence of Agility (Progressive requirements elaboration, Incremental delivery, and Iterative planning and adaptation) in the remaining installments of this series. But becoming truly Agile can begin today. Examine the seven lean principles, see how close your team comes to each of them, and take steps to make each a normal part of their work.

Embracing Lean principles will take some time. But each of them that you adopt will bring your team one step closer to true Agility.

Related Links
Review Alan’s previous articles in this series, which address Learning and adaptation, collaboration, customer focus, and small, self-directed teams in an agile methodology.

Not all comments are posted. Posted comments are subject to editing for clarity and length.

The comments to this entry are closed.

©Copyright 2000-2017 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail
Terms of Service and Privacy Policy

Stay Connected
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues. Sign Up Now

Got a Question?
Drop us an email or call us toll free:
7am-5pm Pacific
Monday - Friday
We'd love to talk to you.

Learn more about ProjectConnections and who writes our content. Want to learn more? Compare our membership levels.