The Industrial Agile Framework™

Scrum is best known as a superior framework for delivering software. It may appear Scrum is rarely used elsewhere, but the future looks different. At Big Orange Square, we bring our 30 years of Scrum and agile experience to a new domain — industry, where lean practices, Six Sigma analysis, and decades of experience are established ways to deliver products. A sad point: few industrial organizations get their products to market on time, if at all. Or, they do so very slowly and with many problems. The Tesla saga is well known and a good example. 

 This series on industrial agile opens with an overview:

• Is Scrum4HW really different from Scrum? (spoiler: no, it isn’t)

• What is new in industry when agile principles are applied? And,

• How do the different frameworks of Lean, agile, Scrum, and Six Sigma fit together?

• Is it really different?

Let’s start with Scrum - the heartbeat of the Industrial Agile Framework. At its core, it is no different than the heartbeat of any other Scrum product delivery environment. We both had some sore ears after being lectured by the co-creator of Scrum, Ken Schwaber, when we talked about “next Scrum,” or “special Scrum,” or “Scrum 2.0.” There is only one Scrum framework, and it is defined in the Scrum Guide. Ken was right, and that same Scrum framework is true in an industrial setting.

So what then is new in industry?

Scrum is upheld by two principles: empiricism and teamwork, so let’s hold these principles against industrial products. For example, we are working with a team that builds single board computers. However, it takes well over a year to develop this product. These boards end up in satellites or airplanes, so replacement of a faulty board is not an option. And, thousands of hours of burn-in tests are just one part of development. This is quite different from a software product! But, we can still apply empiricism and teamwork.

Under empiricism, knowledge is derived from experience. When something is too complex to plan in great detail with confidence, we begin with a high-level plan, execute a short cycle of delivery as soon as possible, and use the knowledge gained from that experience to course-correct the plan and determine what to execute next. Does this sound familiar? It should, since this is another way of describing a sprint.

The crux of the definition of empiricism lies in the word “experience.” We learn by “experiencing” the work of the sprint. By the end of the sprint, the customer should “experience” a “potentially releasable product increment." How can the customer possibly experience something releasable in industry, for a single board computer?

 This is where teamwork gets added to the mix. Small, cross-functional teams are responsible to deliver the product increment — the real thing, not a design or a document. If we were building a complex banking software system we’d proceed incrementally, delivering a function at a time: first the mortgage rate calculation, then mortgage risk assessment, etc. If we are building a circuit board, we deliver one piece of functioning product at a time: first the power lines, then the data lines, etc.

A circuit board designer we worked with didn’t understand that a board with just power lines can reveal very important information to colleagues. A board supplying power to a device gave others vital information about part placement, heat displacement, and other important aspects. Delivering something real allows us to learn more about the product as we proceed.

Compared to software, industrial delivery takes longer, is more complex, and requires a broader set of skills. These include: Designing the multiple parts of the machine (electronics, mechanics, enclosure, software, cooling, heating, plumbing, hydraulics); continuously physically integrating the parts; testing the parts andthe whole; order the components (on time for manufacturing); design the manufacturing process; tool up for manufacturing; train people; optimize manufacturing; develop and equip service teams; and, supply them with the right spare parts while managing inventory. This is quite a challenge when thinking of the 7 +/- 2team size recommendation! 

However, by having the right team composition at the right time across the product development timespan, we can ensure empirical teamwork. For example, manufacturing is at the table from the very beginning, and product design is at the table at the very end, even if both are not full-time dedicated team members throughout.

How do existing frameworks fit?

How do you start with implementing the Industrial Agile Framework? Begin with what you know and is working for you — possibly Lean and Six Sigma, and capitalize on that. Lean provides tools like Value Stream Mapping, an excellent way to determine who needs to be on a team. Six Sigma helps us improve quality standards in support of a definition of “done.” Add to this elements of the Scrum framework: work in short cycles, meet daily, establish product owner and ScrumMaster roles., etc. Most important, ensure proper leadership is in place to support the movement forward.

More to come…

So get started! In future columns we’ll be diving deeper into specific topics and present case studies as we proceed on this exciting journey towards industrial agility!