Contents
Manufacturing and Supply Chain Agility
Agility’s Birthplace
The BMW plant in Spartanburg, S.C., USA, is fascinating for anyone interested in business processes. I took the tour expecting what I had seen in old films of car plants, each assembly line producing the same model over and over. Instead, at BMW the same line produced different customizations one after the other, meeting the exact demands of each customer. The synchronization required with suppliers was more impressive to me than the amazing robots. One vendor supplied the doors in racks in the same order that the customized cars came down the line.
Techniques now considered part of Agile were being used in manufacturing long before the Agile Manifesto was written. In this field “agility” is still a lower-case word for most, yet as I read through scientific journal articles on manufacturing and supply chain, I was struck by the degree to which the issues and responses directly parallel those in organizations choosing between waterfall and agile project management:
- “Agility is a business-wide capability that embraces organizational structures, information systems, logistics processes, and, in particular, mindsets,” a marketing and logistics professor cited by other experts explained.[1]
- An agile manufacturing company “is capable not only of responding to changes reactively, but also creating actively further changes to the environment, and taking advantage of the new opportunities. Such capabilities are in general enabled by mutually enforcing flexible people, processes and technologies,” wrote a Nokia engineer comparing manufacturing and software agility.[2]
- Three Indian researchers wrote, “Agility means using market knowledge and (a) virtual corporation to exploit profitable opportunities in a volatile marketplace.” [3]
- After leading a panel of supply chain veterans through a structured approach to identify the factors, those researchers concluded, “supply chain agility depends on customer satisfaction, quality improvement, cost minimization, delivery speed, new product introduction, service level improvement, and lead-time reduction.”
Sound familiar?
Around the time the Agile Manifesto was being created, supply chain experts were determining when to focus on “Lean” and when agility was more important. Some argue there is no difference. Lean principles originated in the same environment and time frame as methods now called “Agile.” As a journal article explained, “The primary focus and guiding principle of lean is the identification and elimination of waste from the process with respect to customer value.” Those familiar with Lean may already have recognized a lot of overlap between its practices and those described in this site.
The article goes on to say, “In the domain of software development, the types of waste can be interpreted as: extra features, waiting, task switching, extra processes, partially done work, movement, defects and unused employee creativity.” Given that list, I would go so far as to say Full Scale agile™ not only complements Lean practices, it is a Lean practice! However, other Lean practices can be applied to both the implementation and improvement of your FuSca™ processes.
Different types of supply chains probably would have different points where Lean or agility would be more important within the same chain. For example, a company that uses a standardized set of parts with fairly steady pull rates to build a range of products on demand would leverage Lean more for the parts, and agility more for the final assembly. Perhaps more likely are scenarios where some portion of a multi-company supply chain lean more Lean while others are more agile.
A 2011 study of plant and operations managers provided a concrete example of the demarcation line. It found that Just-in-Time purchasing, a Lean element that provides parts as-needed to minimize inventory costs, is likely a precursor to manufacturing agility. However Just-in-Time production was part of agility, and in fact might be an element of both Lean and agility. By the way, the study provided support for others that found manufacturing agility improved financial and marketing performance (sales, market share, etc.).[4]
I bring up the parallels between manufacturing, supply chain, and software agility for a simple reason. No manufacturer should claim it cannot use Agile principles, because thousands already are!
Techniques in the Plant
Manufacturing and supply chain agility, so closely interrelated that I will follow researchers to lump them together as agile manufacturing (AMf), relies on a range of larger environmental strategies:
- Modularity—By designing products built from interchangeable parts, a new variant can quickly be customized by hardware, software, and firmware engineers iteratively in close coordination with supply chain and manufacturing professionals.
- Extended Enterprises—When a Fuji-Xerox joint venture created a new copier in the 1980s, the self-organizing program team introduced high levels of collaboration with suppliers. “The FX-3500 team invited them to join the project at the very start (they eventually produced 90% of the parts for the model),” says the seminal Scrum article I’ve cited several times on this site.[5] “Each side regularly visited the other’s plants and kept the information channel open at all times.” In effect, AMf firms treat suppliers and delivery vendors as units of the same company, with high levels of joint planning and design, development coordination, and progress tracking. Depending on the complexity of design, this may include either deeply interrelated functions with a sole-source supplier, or connections with multiple sources all of whom practice AMf themselves.
- Anticipation of Change—AMf places a far higher emphasis on predicting future customer needs (market requirements) than software firms typically do, because of the longer development cycles. Firms with high AMf employ a number of techniques to specify and prepare for coming changes before these can impact them.
- Physical Flexibility—Assembly line layouts can be quickly reconfigured, and tools are versatile, allowing the firm to shift among product variants as often as needed with minimal cost.
- Workforce Flexibility—Hiring and training practices emphasize broad skill sets that allow workers to shift roles as needed. Whether a matter of people being out on a critical day, or a quick turnaround to produce a different product variant, lack of people with the right skills would translate directly to lost revenue. Often in AMf compensation is based not on tasks accomplished but on skills learned. For example, a minimal base salary may be supplemented by taking formal or cross-training within and across prescribed verticals and tiers to become more versatile.[6]
- Continuous Improvement—I think it fair to say all of the best-known business process and quality improvement methods you can think of originated in the manufacturing world. Lean, Total Quality Management, Six Sigma, quality circles… I could go on and on, and do a bit under “Other Recommended Practices” below.
- Local Control and Empowerment—Decisions to determine what is best for the customers they serve are pushed down to local plants, and those plants are “full-stack” in the sense of having dedicated personnel in the roles needed to make and implement those decisions. The plant doesn’t have to wait to make the moves it needs while a centralized procurement department prioritizes those needs against every other plant. It just makes them. Another element is empowered teams similar or identical to those I have described on this site. Indeed, a significant percentage of the field studies I read for my old teamwork book The SuddenTeams™ Program were conducted in manufacturing settings.
- Integrated Information Systems—Information tools transparently link sales, purchasing, finance, development, manufacturing, shipping, and other relevant departments to enable quick identification of, and response to, coming change. Each function can learn information it needs from others by looking at a screen instead of hunting down individuals, wasting productive time for seeker and provider both.
Each of these strategies directly match, or fit perfectly with, the Agile Manifesto principles. Companies that produce tangible products certainly can spread agile through the rest of the enterprise without harming their manufacturing processes, whether those are more Lean or more agile. In the latter case, they already have internal examples to use and more reasons to make the change in their R&D and administrative functions. In the former (Lean-leaning) case, a chat with a consultant on manufacturing and supply chain agility should lead to a better bottom line.
Other Recommended Agile Enterprise Practices
There are so many technical techniques that complement Full Scale agile, engineers can attend “Agile technical conferences” dedicated to those topics. These are outside my area of expertise, but I have been involved in their establishment at various clients. After you have FuSca up and running, any of these applicable to your deliverables would be logical next steps in your continuous improvement efforts:
- Six Sigma, ISO, and related quality or process improvement methods—Given the emphasis in FuSca on quality, I obviously support almost any relevant system for formally measuring and improving that quality. I say “almost” because some of those methods violate the “self-organizing” principles, which in turn can cause them to lower customer satisfaction by emphasizing standardized processes too highly. For example, after reading through online debates about Capability Maturity Model Integration (CMMI) and speaking with experts, I remain unconvinced that its two highest levels are compatible with team self-organization.
Temporary work groups like quality circles, kaizen teams, or action teams are great ways to address specific problems affecting FuSca organizations. Representatives from the FuSCA teams can either create stories to set aside time, or merely remove the hours for the temporary team from their individual Capacities if using Scrum.
- Continuous builds and automated testing—After software code is written, it must be compiled into a cohesive functional set in language a computer can understand, called a “build.” Once a manual process, this now can be done automatically, as hinted at elsewhere on the site. After the builds reach a predetermined level of maturity, a version traditionally was turned over to a team of quality assurance (QA) engineers. More complex systems with various teams contributing often still do this. The QA team runs a large range of tests to ensure the new functionality is working as claimed and that all the pre-existing features are still working. In earlier days most testing was manual, done by people at keyboards, so this required a “code freeze” where new development was finished on a build that might be released to customers, followed by weeks or months of testing and bug fixing. Meanwhile development began on the next version. (In my experience, the process was never this clean: the “code freeze” was mushy, with new functionality sneaking into builds that were only supposed to fix bugs the testers were finding.)
Today applications can create the builds, and all testing that does not require hardware changes can be done by applications using “automated test scripts” based on test cases. There is no better way of ensuring defects are captured and fixed prior to release to customers than doing a build every night, and running every system-wide test every night. In part this is because problems are found soon after they were created, reducing time for cause analysis. It also prevents small problems from combining into much larger ones, or creating cascade effects farther down the chain of computer actions. With traditional testers freed from that burden, also, more “exploratory” testing can be completed in which they try things your Customers do not expect, preventing end users from finding them first, and identifying potential improvements.
- Dev/Ops—Most companies split their engineers into development teams and operations teams. The former create new functionality; the latter install it and support customers. The Dev/Ops movement is trying to at least get these teams working more closely together (in addition to the behaviors in the previous bullet). That way the development teams create fewer problems for Ops, and the knowledge that Ops gains about the system and customer needs is efficiently fed back into improvements in the system. In extreme cases the line is blurred to where one team does both. Dev/Ops conference topics largely overlap agile technical topics—in fact, the movement grew out of an Agile conference—and combined Dev/Ops teams are a logical “full-stack” form.
- Behavior- and Test-Driven Development (BDD and TDD)—Different from ATDD, TDD can be seen as an approach to actual writing of software code. (There is debate among software thinkers as to what levels TDD applies to, and the line between BDD and TDD.) At its most basic level: Just as Agile takes a small piece of functionality and delivers it “fully tested,” programmers using TDD write very small pieces of the larger functionality at a time, pieces requiring as little as five lines of code. They first write a technical version of a test case for that functionality, and then a rough draft of code that in most cases fails to pass the test the first time the programmer runs it. The coder fixes the code until it passes, and in an important final step, edits the code to make it as simple and easy for other programmers to understand as possible. The process is repeated until the entire functionality is implemented—in FuSca terms, until the related user story’s Acceptance Criteria are met. The method is well-proven to significantly reduce defects and improve overall productivity.
BDD goes a step farther by asking what the code should accomplish, usually applied across multiple units of code. That may be a user-level behavior, or could be a technical behavior (again, there is some debate). Regardless, both BDD and TDD drive the kind of built-in quality agility requires.
I often get asked how to “make time” to implement techniques like these. Simple: Write technical stories or epics to do so, and set aside a portion of every sprint for the effort. In more than one organization, I have gotten backing from executives to create a “Continuous Improvement” program in the portfolio hierarchy, and tell Customers that 10% of our effort would be delegated to such work—no arguments allowed. Each of the bullet points above could become a project within that program.
When Customers gripe, and some do, I ask whether they put money away for retirement or for college for their kids. They all do. You already believe in investing a small part of current resources toward improving the future, then, I tell them. That usually ends the argument, and if not, I refer them to the aforementioned executives.
↑ Agile across Enterprise | ← Financial Agility | → Agile Transformation Process
Full references are in the Agility Bibliography.
[1] Christopher 2000.
[2] Kettune 2009.
[3] Agarwal, Shankar & Tiwari 2007.
[4] Inman, Sale, Green & Whitten 2011.
[5] Takeuchi & Nonaka 1986.
[6] Zhang 2011.