Implementing Industrial Agile in Your Organization

Posted June 25, 2020 in Business Agility & Software Engineering Excellence
Implementing Industrial Agile in Your Organization

Software organizations everywhere have embraced Agile’s concepts, practices, and frameworks because they have proven to deliver broad benefits. But why should Agile be limited to the software organization? In a recent on-demand webinar, Cutter Consortium Senior Consultants Hubert Smits and Peter Borsella explored the Industrial Agile Framework and how it can enable continuous adaption throughout the value chain.

The Industrial Agile Framework is a framework for applying Agile to physical product delivery. It pulls together everything that’s needed to design and mass produce a product, beginning with an idea and including design, components, supplier considerations, manufacturing, and everything in between. With Industrial Agile, you can change directions while working on product development and you don’t have to go back to square one. And, as with Agile for software, inspecting early and often means finding and fixing errors before they become excessively costly.

At the end of their webinar, Smits and Borsella responded to some questions that you may be wondering about as well.

Q: Many organizations use a Lean/Agile blend for physical products. How is your framework different or does it blend the elements of both?

Borsella: The blending idea of Lean and Agile is interesting. Lean certainly has some valuable aspects to it. It tends to focus on cost savings. Agile tends to help us understand how to be innovative and solve problems. But it’s not just a simple blending of things. We don’t just cherry-pick the things that we think are the right things to do.

Smits: The Agile principles are dominant. You cannot go from an inspection every two weeks and then go three or four or five or six or seven weeks. You can’t say, “well, let’s first do an inspection every couple of weeks on the design documents” or “let’s just start with the mechanical people in a room doing iterations.” You have to do it right; there is no cherry-picking.

We know that’s hard. We’ve all (including Peter and me) been educated and trained in the waterfall mechanism handoff. It was even a career path: you start as a developer, then if you’re good you could become a designer, and if you’re really good you become an architect. No, we’re all team members and we are working together — and that’s different. It’s a shock to the system, and your “immune system” will kick back at it with the thinking that something is going to go wrong.

Every customer that we have introduced to these principles and has taken the time, has come back after half a year and said that using this method, they can do much better than twice the products in half the time. The effects are amazing.

That’s why we say it’s more than a blending; it’s a principle derived from the Agile principles and practices. Let’s not forget the good things we learned. There are agilists who rave against the PMI, PMP — the professional project management organizations. We are not in that camp. It’s about good people, good skills, and a great toolbox. And we mustn’t forget that it’s all about the people who work with those great toolboxes. So use the techniques, but be careful when blending.

Q: How long does it take to implement and when should I start seeing results?

Borsella: How long it takes to implement will be variable, depending on your organization’s readiness. Some of these things can be implemented in a day, or sometimes it takes a number of days or maybe a number of weeks to prepare people for what’s going to change. But we expect the inverse of this: we expect to see results almost immediately.

We have a checkpoint after about the fifth or sixth cycle, and we inspect all along the way. But after about the fifth or sixth iteration, we expect to see some serious transformations in how the team delivers and how the organization can support that delivery environment. If we don’t see some serious changes taking place by about the fifth or sixth cycle of delivery (and we’re talking about just a couple of weeks here for each cycle), then something’s wrong. There’s some type of disrupter that’s keeping the team from achieving these goals. It could be something disruptive from within the team itself or it could be an external force that’s keeping the team from achieving these short delivery cycles.

Smits: At that point, we know we have a successful implementation because we see that there’s a disrupter. We have our bi-weekly inspections when we can check the mood of the team. We can ask folks what is holding up the work. If the product is not getting out of the door, which is of course what we are going for, we can find out why.

When operations and projects meet daily, we can see results within a week. Operations people can see that a test request would be hitting them in two months, so they know they need to get ready double-quick. In just one week into the implementation, by setting up those communication structures, the effect is that you get results fast.

The lesson learned is that you must be careful with your metrics. Metrics on implementation success are absolutely necessary. We once wrote a metric on on-time delivery as one of the critical points in the implementation. You cannot measure on-time delivery any faster than when the delivery takes place. So, if you have an on-time delivery cycle of about six months, then don’t promise measurements, metrics, and results after two weeks or six weeks because you need to go the full cycle. You can and should measure parts of that on-time delivery cycle, but don’t get too optimistic with your promises of results. Based on what are you promising, know what you have to measure and what you have to improve.

Borsella: Results also include the things that others might consider bad — things that didn’t go well. In fact, I’ve sometimes been criticized for being happy when something “bad” happens (the team misses their iteration delivery, for example). I’m smiling about that because we learned something. I have new information I didn’t have before that. That is a form of result. Of course, we need to get to the point where we’re meeting the organization’s goal-based result objectives, but the learning is part of that — it helps us understand how to get to that end point.

You might have more questions, and we would love to help. You can read our Executive Update, “Twice the Product in Half the Time,” which is the base of the presentation, or view our webinar, here.

Industrial Agile: Accelerating Physical Product Delivery

Industrial Agile: Accelerating Physical Product Delivery

In this on-demand webinar with Hubert Smits and Peter Borsella, you'll learn how the core Industrial Agile Framework concepts — (1) cross-functional team collaboration over specialization, process, and tools; (2) extending development through manufacturing over fixing problems in the field; and (3) useful continuous delivery over a single comprehensive delivery — enable continuous adaption throughout the value chain. Discover why companies that are adopting the Industrial Agile framework are moving from “concept to cash” more efficiently and effectively than ever before. Watch Now.

About The Author
Peter Borsella
Peter Borsella is a Senior Consultant with Cutter Consortium's Business Agility and Software Engineering Excellence Practice and a member of Arthur D. Little's AMP open consulting network. After many years of practical experience successfully delivering projects and creating effective teams, Peter became one of the earlier pioneers of agility, initiating groundbreaking practices that have become normal in the Agile world, such as scaling… Read More
Hubert Smits
Hubert Smits is a Senior Consultant with Cutter Consortium's Business Agility & Software Engineering Excellence practice and a member of Arthur D. Little's AMP open consulting network. He is an innovative, assertive, and goal-oriented Agile consultant, coach, and trainer with a track record of successfully spearheading enterprise-level Agile and Lean enablement efforts. Mr. Smit's work is based on 15 years' experience in the Agile domain,… Read More