Getting ‘Agile’ and ‘Lean’ not just for software developers

 (FRANCK FIFE/AFP/Getty Images)
(FRANCK FIFE/AFP/Getty Images)

“Agile” is a term — and approach — that a growing number of companies are having their software developer teams embrace, just like many manufacturers have adopted “Lean” methodologies. Both focus on reducing process time and improving quality.

Lexington-based Lean-Agile Partners, Inc. is helping bring these skills to companies in a wide range of industries including medical, industrial controls, aerospace, as well as financial services, consumer products, and others.

The company consists of three main partners, Nancy Van Schooenderwoert, Joyce Dostale, and Mark Taylor. Van Schooenderwoert has been doing Agile consulting for over a decade; in August 2013, Dostale and Taylor joined her, expanding the company.

I spoke with Dostale, who is managing partner of the operations practice, about Lean-Agile, what it does, and what companies of all types and sizes can gain by learning and applying the types of methodologies they espouse. The following is based on our conversation.

BetaBoston:  What are Agile and Lean?

Dostale: “Agile” is an umbrella term for a set of development principles hammered out by a group of software developers in 2001 to address the high rate of change and “I want it now” demands of the market.  New tools and methods have derived from these principles that are being very effectively used by companies like Google and Facebook.

“Lean” came from Toyota manufacturing processes developed in the 1950s to address inventory management and time waste reduction.

The company was named for both terms because we combine the best of both concepts.

We’ve used Agile and Lean because we believe that when your company is building a tangible product, like, say, a medical device, you have to consider both the physical manufacturing aspects as well as the intangible software ones.

BetaBoston: How are Lean and Agile different from other project/product management approaches?

Dostale: The main philosophy of Lean and Agile is to work with small customer-driven discrete pieces, and put them together — start small and keep building.

For example, in the old days, to build a product, first you did a foundation, like a database, and then the APIs, and then the user interface. With an Agile approach, you build vertical deliverable slices. When you have these small feature sets, you can release them much more rapidly, because you know each feature will work, and that the market wants it.

Agile does this by using “stories.” Instead of, “we need feature X, to do Y,” it’s “because the user needs Y, we are building X.” That provides developers with context they never previously had.

BetaBoston: What’s the value of Lean?

Dostale: Over the past twenty-five years, Lean manufacturing has transformed the way that tangible objects are being built, using very similar principles. Lean goals include reducing waste, having everything there when you want it, catching and correcting errors earlier in the process. This approach was picked up by software developers, and we’re helping organizations apply it in other areas.

The Lean community has a longer history than Agile, and has addressed ways to apply its principles to management functions like HR, budgeting, and portfolio management.

The Lean community also has more experience in showing real companies how to keep all these new changes in balance. It’s not helpful to build far more software than we can test, or to build more product than we can sell, etc.

For example, many companies that adopted Agile practices for software development discovered that as software teams doubled and tripled their productivity, those teams needed far more inputs in the form of decisions about product features, than the organization was prepared to give. Often the result was the wrong things being built quickly and flawlessly.

Asking “how does the product fit in with the customers work flow” often results in different answers than asking “what features does the customer want.”

BetaBoston: What are the results, in general?

Dostale: The main benefits of applying these methodologies are a better fit to market, higher-quality products with fewer bugs, and a faster development cycle, while reducing costs. This breaks the classic “better, faster, cheaper — pick two” cliche.

BetaBoston: What’s distinctive about Lean-Agile’s approach?

Dostale: We target each program to the organization, we use examples from what the company is doing. When we do hands-on exercises, we use actual problems they’re facing in their workplace.

Also, we include coaching for the team, as well as training the individuals. We are getting people to work together the way they will be working together.

Additionally, we apply Lean-Agile to safety-critical work for medical product development, aerospace, industrial controls, and in other regulated work e.g. financial services. We have the depth of experience using these techniques not just in software development, but in hardware, product development, and operations.

BetaBoston: Any advice for companies interested in “getting Agile and Lean”?

Dostale: Your company has to look at Lean-Agile as a cultural and behavioral change. It’s not just acquiring “a new skill.”

This is something you can’t do only halfway. It’s not just adding skills, but also doing culture and behavioral change.

On the other hand, your company can start becoming Lean-Agile in just a few months — we use the Agile mindset, starting with small groups and teams, and growing the number of teams and amount of Agile thinking in the organization over time.

We have links to some helpful white papers and other publications on our web site.

BetaBoston: Can this be applied on a smaller scale, like by a family or individual?

Dostale: Yes. I’ve seen people use Agile for things like wedding planning and other big projects. A classic example is cleaning out the garage — you could spend all summer fretting about finding a weekend and what you’d do… or you could spend an hour every Saturday morning actually working on the project.