Agile is employed within Stage-Gate for new-product development by manufacturers with positive performance results; but must be adjusted from the software version of Agile – the result: the emergent Agile-Stage-Gate hybrid model.
Agile Development emerged from the software industry through the 1990s, a time when the industry needed new ways to overcome many deficiencies. By 2013—2015, a few manufacturers of physical products—notably those with software embedded in their products—were applying Agile to their hardware developments. These included firms such as LEGO (Education Division), Honeywell (controls), Volvo Construction (off-highway construction vehicles), and Chamberlain (remote control consumer devices). Many other manufacturers were soon to follow.1
What these firms did was to combine Agile Development methods with their classic gating systems to create an Agile-Stage-Gate hybrid model. Articles began to appear describing Agile-Stage-Gate by 2015, and InnovationManagement published an early article in 2016. But after five years of experience and the early enthusiasm, it’s time for an update and also answers to key questions:
- Does Agile Development really work for manufactured new products? How well?
- What does it mean to adopt Agile Development—do manufacturers really buy into the entire Agile methodology, or only to parts of it? Major differences exist between hardware and software development, which may preclude implementing certain facets of Agile.
Even now, there are still challenges to implementing Agile for hardware development. “Paradigm perplexity” or the incompatibility of agile and classical models has been identified as the greatest obstacle.2 But we now have the experiences from many manufacturers using the new model, results from numerous workshops on the topic, and conclusions from large sample research studies. So, the time is ripe to integrate these findings into a proven consensus, dominant or recommended model—Agile-Stage-Gate as of 2020—and thus help to eliminate paradigm perplexity.
Product Development Systems for Manufacturers
Many manufacturers have relied on a gated process, such as Stage-Gate®,3 for driving new products to market. Stage-Gate is a system in which the product development process—from idea generation to market launch—is broken into discrete stages with defined tasks, best practices built in, and prescribed deliverables.4 Management governance of the project is provided by the gates, which precede each stage, and are the Go/Kill or investment decision points.
Traditional gating systems, however, are no longer suitable for many of today’s development projects.5 Stage-Gate requires extensive up-front homework,6 such as voice-of-customer work, competitive analysis, and technical assessments, tasks which often don’t get done, so there are information gaps on entering the Development stage. Further, when a project is approved for Development, the proposed product is supposedly clearly defined and a plan of action with associated costs is approved. But in many projects, that product definition and action plan both change as development work proceeds: New information is acquired, customers’ needs evolve, and market requirements change, and so plans and the product definition must adapt. This lack of front-end information combined with information fluidity renders traditional Stage-Gate inappropriate for some types of development projects.
Agile-Scrum for Software Development
Agile-Scrum breaks the development process into a series of short, iterative and incremental time-boxed sprints, each typically about two weeks long for software development. Sprints consist of:
- Sprint planning meeting: At the beginning of each sprint, the development team meets to agree on what it can accomplish in the sprint and creates a task plan for the sprint.
- Daily stand-up meetings or scrums: During the sprint, the team meets every morning to ensure that work is on course, share information, and solve problems.
- Demo: At the end of each sprint, software increments or new features, potentially releasable, are demonstrated to stakeholders, both management and customers.
- Retrospective meeting: Finally, the team meets to review how they can improve the way they work and execute the next sprint work better.
The team then plans the next sprint based on customer and management feedback. Product requirements and technical solutions, and even the project plan, thus evolve over the development cycle as new information and feedback becomes available. The development team’s work is visible to all, and monitored via a set of visual tools, often displayed on large charts in the team room.
There is no traditional project leader or project manager in Agile-Scrum. Rather, the new roles are:
- The scrum master, a servant-leader for the team who ensures that the team adheres to Agile theory, practices and rules.
- The product owner, a member of management, typically a senior marketing person, who represents the product’s stakeholders and provides direction to the team (e.g., at the sprint planning meeting).
- The development team, a dedicated team that works 100% on this one project, usually technical people, and physically collocated in one room.
Agile Development for Software Projects
Agile Development methods were developed in the 1990s in the software world to deal with projects facing uncertain and changing information, which was often the case for software projects. While a number of different Agile methods were proposed, the Agile field finally came together in 2001 as a set of principles, outlined in the Agile Manifesto,7 complete with development methodologies with clear rules.8 The Scrum version of Agile is the most popular (and also the version most suited to manufacturers), and is described in the above box, Agile-Scrum for Software Development.
Agile Integrated into Stage-Gate
To address the need for a more fluid, adaptable system, some leading-edge manufacturing companies have adopted the Scrum version of Agile and integrated it into their existing gating system. Danish researchers coined the term “Agile-Stage-Gate hybrid model” in 2015.9 Often the impetus for adopting such a model was that software was built into hardware projects to yield “smart products”, and thus the company needed a method that could accommodate the needs of both software and hardware people… hence the hybrid process.
Developing physical products, however, is clearly different than writing software code. And so Agile has been modified by manufacturers when used within Stage-Gate. For example:
- Hardware projects are not infinitely divisible into small increments as in software development, thus harder to break into small two-week sprints.
- Hardware projects have waiting times (waiting for lab test results; suppliers and components; customer-trials results; and for equipment) not usually found in software developments, which interfere with short, rhythmic sprints.
- Making changes to physical products is more difficult than modifying software code, so pivots are a challenge, especially near the end of development.
- Physical products often cannot be demo’d or trialed on-line with customers as can software.
Agile-Stage-Gate in Practice in Manufacturers
What has emerged is an Agile-Stage-Gate model for manufacturers, with some important differences versus software-Agile—a consensus about what works for physical products.10 Since manufacturers typically rely on a gating system, Agile (the Scrum version) is simply built into the stages of Stage-Gate as the project management method, replacing traditional project management methods (Gantt charts, timelines, milestones, etc.)—see Figure 1.
Each stage of the project broken down into increments, namely sprints, sometimes called “iterations”. These iterations are time-boxed with a defined and consistent time limit, usually longer than for software, about 3—4 weeks. Iterations can be even longer: For example, Honeywell uses eight-week iterations for hardware developments versus two-week sprints for software,11 while Corning employs 60-90-day planning cycles or iterations.12 This longer iteration enables the development team to realistically produce something tangible that they can demonstrate.
In using Agile-Stage-Gate, the development team begins each iteration with a planning meeting. They define what they will achieve in that iteration: their goals (including the definition of done, DoD) and their iteration plan with a list of tasks they will do, often posted on a Kanban Board (see Figure 2). Here, the iteration’s tasks are listed in a column on the left, and move across columns from “To Do,” “In Progress,” “Done,” and “Checked”, thereby showing the status of each of the task to be completed in that iteration. The iteration then begins and the team undertakes their agreed-to tasks. Note that some lengthy tasks span several iterations, such as extended lab tests or doing a Voice-of-Customer (VoC) study.
Stand-up meetings or scrums are held regularly with the entire team present, but not daily as in software-Agile, usually about 2—3 times per week. Here the team reviews progress, syncs their various tasks, and solves problems. Holding scrum meetings every day may not be practical for all manufacturers: For example, in a study of three smaller Danish manufacturing firms, total team participation at the scrums was found to be essential—no team member absent—otherwise much time was wasted bringing the missing team member up to speed later. Thus, holding scrums every morning becomes impractical if 100% attendance is required.13 Volvo Construction simply did not have enough Scrum Masters to spread across all the Agile teams to facilitate daily morning scrums.
At the end of the iteration, the team demonstrates what they have done by presenting the reviewable or visible results of their work. This demo could be an early prototype or “protocept” of the product, or something else they can show, such as design drawings, a model, a simulation, results of lab tests, or the VoC study findings.
When a task spans several sprints, such as product testing, “interim results” are demo’d as “the result of the work done.” For example, at the Coatings Division of a major chemical company, new coatings require months of testing before a final result is available. But interim test results are available sooner and are presented at demos. Further, iterations can be of variable length, especially for the Development and Testing stages (a testing iteration could be extended to 8—12 weeks instead of 3—4 weeks). Note that varying the length of iterations does contravene one of the principles of software-Agile, namely consistent time-boxed sprints—always the same length—designed to establish a rhythm, heartbeat, or takt time.
This demo at the end of each iteration is done for management to seek feedback, advice and validation, as well as continued buy-in. The feedback could signal a course correction, or in rare cases, trigger an emergency gate meeting to reconsider the Go/Kill decision for the project. Also, with some but not all iterations, the demo is to customers or users, again to seek feedback and validation, and to identify corrections needed, notably to the product’s design, features and functionality. The median interval between prototypes demo’d to customers is 17—24 weeks, according to one major German study, which is far less frequent than at the end of each 3-week iteration.14 Note that in some projects, an entire sprint is used to conduct a series of on-site demos to customers.
Although the demo every 3—4 weeks is to senior management, it is not a full gate meeting: One should avoid the additional bureaucracy of adding many additional gates—Gate 3, Gate 3.1, Gate 3.2 and so on. Nonetheless, when management sees the project repeatedly at demos, they usually comment on its progress and prospects. Thus, Sulzer Mixpac in Switzerland (mixing and application systems for dental, industry and healthcare) calls these periodic management reviews “Upgates”. In the earlier stages of the project (Stages 1—3 in Figure 1), management may be unwilling to commit all the resources needed for that stage—there are too many unknowns—but instead commits for several iterations; when these iterations are complete, an Upgate is held—a review of the new information and a decision to continue for a few more iterations—see Figure 3.
Each iteration concludes with a retrospective meeting, where the team analyzes their own behavior and results, and tries to improve how they work together. Then the next iteration begins. Siemens (Motors Division) use the retrospect meeting at the end of each sprint to self-evaluate, and to improve team cooperation and utilization of Agile principles. Their starfish chart (Figure 4) helps to structure the meeting to cover the topics. Using Post-Its, each team member notes their concerns and suggestions on the chart; a dialog ensues on how to self-improve for the next sprint. This retrospect meeting is facilitated by the Scrum Master who ensures adherence to the starfish model and sees that all team members participate. And so, the process moves along—iteration by iteration—until that stage of the project is finished and deliverables are ready for the upcoming gate meeting.
Note that this description of Agile-Stage-Gate in practice is a composite across a number of best-practice firms. Most manufacturers do not adopt all the elements of Agile, as shown in Figure 5. Sadly, some of the most beneficial facets of agile, such as developing prototypes regularly, and with customer feedback, and direct contact with customers, are at the bottom of the list in Figure 5.
Recommendations from experienced users are that one should try to “stay true to the Agile model” and “adopt as many Agile principles and methods as is realistically possible”; if one drops too many, then one is no longer doing Agile, nor reaping its benefits. A second recommendation is that each firm decide on its own version of Agile-Stage-Gate that it will adopt—in effect, design a somewhat customized model that suits that firm’s own projects, products, procedures, people, and culture. This article provides a starting point.
Where Agile-Stage-Gate Is Used
Manufacturers typically use Agile-Scrum for many stages of their gated development process: Ideation, Concept, Development, Validation, and even Commercialization. This stands in contrast to the software world, where Agile is used mostly by code-writers for the technical or development stages. Indeed, physical-product firms report that Agile-Scrum is most useful for the earlier stages, such as Ideation, Concept and Development.15
Firms don’t use the new method for all projects, however: 62% firms are reported to do less than 25% of their projects with the new method.16 Agile-Scrum is usually reserved for larger projects that are more ambiguous and poorly defined (where experimentation is required) with higher uncertainty. For example, Chamberlain cannot deploy dedicated teams for all its development projects, and so reserves the use of Agile-Stage-Gate for 20% of projects, those which are the major revenue generators.
Agile-Stage-Gate is particularly suited to hybrid software/hardware projects—for example, for developing smart physical products with embedded software—where both software and hardware development people must work together.17 Indeed, a recent study of six global firms using Agile methods within Stage-Gate showed that all six firms—from LEGO to Honeywell—had adopted the new model largely to accommodate combined software-hardware projects.18 A common process, such as Agile-Stage-Gate, is preferred, as opposed to splitting the project into two parts and running each part separately, one team using Agile, the other relying on Stage-Gate.19
The Role of Gates in Agile-Stage-Gate
Gates play a vital role in Stage-Gate and also in Agile-Stage-Gate, but sadly are missing from Agile Development. Gates are the key investment or Go/Kill decision points in the new-product process: At gates, senior management, the resource owners, review the results to date, consider the next steps in the project and their costs, and then commit the necessary resources to move forward—see Figure 6. In practice, gates are an irrevocable commitment of resources to a project leader and her team to execute the next stage of the project. Thus, gates play the role of a “quality check” in the process: They ensure that firms do the projects right, and also that they do the right projects. Using Agile without gates means that the project may get done efficiently, but it could be the wrong project!
Tough Gates with teeth is an important facet of an effective new-product process. In too many businesses, including those that claim to have Stage-Gate, the gates are either non-existent or don’t work well. Numerous benchmarking studies show that gates are a very weak area: Saying “yes” to too many projects, no project prioritization, and a lack of resources committed to projects.20 Note that gates are not milestone check-points (where management checks that certain tasks have been completed by a given date); nor are they simply senior management reviews or project updates. Rather, Gates are investment decisions: If the project meets certain clear criteria, resulting in a Go decision, then resources are invested in the project.
Gates are also important for getting rid of poor projects. Many projects are not suitable for continued development, and the firm should cut its losses, like the smart poker player, and kill the project. In the manufacturing world, of all the projects that enter the heavy Development stage, an estimated 75% do not succeed in the marketplace.21 Tougher gates identify the weaker projects and remove them from the portfolio, and reallocate those scarce resources to better projects. The net result is much more productive use of R&D resources. Properly implemented, Agile-Stage-Gate brings with it rigorous gates, and thus better R&D resource allocation decisions.
How Manufacturers Organize their Teams for Agile-Stage-Gate
Unlike physical product development, Agile-Scrum as practiced for software development requires a 100% dedicated development team—working full time on the project—and collocated in the same room. This poses two principal challenges for manufacturers. First, as noted, many R&D projects have significant waiting times, for example for test results, or for equipment arrival. Thus, team members must work on other projects during this waiting period. A second and more difficult challenge is that most manufacturing firms simply have too many projects underway at any one time, spreading players too thinly and across too many projects. This demands better gates and effective portfolio management—finding focus and cutting down the numbers of projects!22
The emergent model is for manufacturers to employ a “focussed team” rather than a 100% dedicated team; that is, a mostly dedicated team with some team members devoting the majority (60-75%) of their time to the project. For a specified number of days per week, core team members work together only on this designated project. Further, for the 2—3 stand-up meetings per week, the entire team is present. Some firms, such as Tetra Pak, a global packaging company, limit the number of “other projects” to one or two, so that for core team members, this new-product project is really their principal job. Thus, the core team is protected from outside disruptions that divert their attention from the project.
Other team models exist. One medium-sized U.S. specialty-chemicals firm, Actega, simply employs a dedicated Agile team, which handles a set of smaller and similar customer-driven projects done in parallel: The team is collocated and together works only on the set of projects, full time. In the study of smaller Danish firms cited above, a producer of modular power-supply equipment revealed a novel solution to the issue of team members having multiple other tasks to do. To accommodate these other tasks, the company modifies the normal sprint rhythm: They use two-week sprints, but add a one-week project moratorium or “interlude” after each sprint with no work done on the project. This interlude allows team members to catch up on their other tasks and also puts a limit on this “other work.” The team can thus maintain a fixed rhythm, yet still handle their other responsibilities.
Cross functional teams are the norm in the emerging model, which is not new to manufacturers but new to software-Scrum users. The requirement for Marketing, Operations and Sales people to be part of the focussed cross-functional team is a challenge, because usually these people only devote a minority of their time to any new-product project…they have their “day jobs” too! One solution is to require that only a handful of people on the team be dedicated, whereas others—from departments outside of R&D—are “part-time players” but with specific time commitments decided at the previous gate. And they must still attend the regular stand-up meetings!
The project team is very much self-managed, self-organizing, and empowered. This is consistent with software-Scrum and also has been a best practice for decades within the manufacturing sector. Once their project is approved at a gate meeting, along with a high-level “go forward” project plan, the team is free to map out their action plan in detail, decide who does what, and has the authority to make decisions. Some senior people worry about a team out of control, leading to chaos. But there are still strong gates in the system, where gatekeepers scrutinize the project, and approve projects and a high-level plan-of-action. And there are still validations with management along the way and between gates, in the form of demos and Upgates. Thus, the team is “self-managed and empowered” but within boundaries.
Most manufacturers maintain the role of a Project Leader or Project Manager, even though software-Scrum eliminates this role. One reason is that Agile projects represent only a minority of projects for the typical manufacturer; thus, one hesitates to create a different organizational structure just for a minority of projects. A second reason is that a cross functional team has differing time and content contributions per team member, and thus needs more coordination, synchronization, and leadership than a fully dedicated software development team.
The Scrum Master is another debated role among manufacturers. Clearly there is a need for a coach to ensure that the team correctly practices the methods and embraces the mindset of Agile-Scrum. But as the team gains experience, a coach in the form of a Scrum Master may be no longer needed, especially a coach dedicated full-time to the one team. The term “agile coach” is used more often among manufacturers: the “transition managers” to the new Agile-Stage-Gate system.
Dealing With New Challenges: Undefined Projects and Changing Timelines
An important difference from the classic Stage-Gate approach, and a challenge for some gatekeepers, is that some gate deliverables are much more variable and less defined than in the past. For example, the product definition may be only 40-70% complete on entering the Development stage, rather than the normal 90% in classic Stage-Gate; and the project plan (e.g., a Gantt chart) and estimates of resource requirements and project costs may also be quite tentative. Both result in highly uncertain project cost and financial estimates.23 Thus, management is faced with a much more ambiguous approval and investment decision. As one frustrated executive exclaimed: “How can one make a Go decision when the product is not defined; there is no reliable time line; and resource needs and the cost of doing the project are uncertain? And once the project is approved, everything will change anyway!”
Newer tools for dealing with investment decisions for ill-defined and ever-changing projects are now being applied in some firms. A recommended financial tool is the ECV (Expected Commercial Value); it breaks the project into small increments (iterations), each iteration with a possible negative and positive outcome, and then applies decision tree analysis to determine the expected value of the project.24 For example LEGO in Denmark is now using a modified version of ECV to evaluate major but highly uncertain projects (new technology and digitization projects).
Constantly-changing project plans also create challenges, but there are solutions. Agile teams normally have a 2—3-week planning horizon—the length of one sprint. Thus, Gantt charts or timelines-with-milestones that map out the entire next stage are a thing of the past in the hybrid model; besides they did not work anyway, because the timeline was always changing, consistent with the adage that “no battle plan survives contact with the enemy.”25 Nonetheless traditional senior managers, when approving a project, do expect a timeline and a high level project plan for the next phase, along with an estimate of execution costs, and an approximate launch date.
The solution is to develop a high-level plan or “schedule” as a deliverable to the gate preceding each stage; that schedule is approved by management, who are fully aware that it will likely be updated many times over the next few months. Figure 7 shows an example of such a high-level plan—it’s been updated at the end of Sprint 5, partway through the Development stage, expected to take 13 sprints. Note that the detailed plans to the left of the current Sprint #5 are the result of the Sprint Planning meetings for Sprints 1-5 (the work in those plans has already been done). But the plan to the right beyond the next sprint is much less granular and detailed—an example of a high-level plan or schedule.
Another change is much leaner deliverables to the gates (fewer templates, shorter templates, and less information required) than many traditional managers expect. Most firms’ classic gating systems require far too much information delivered to each gate and often too early in the process; for example, they ask for detailed NPV-calculations or cost analyses at early gates, when such estimates are highly unreliable, hence almost useless. Using Lean methods, such as value stream analysis, smart firms have removed the non-value-added work and corresponding deliverables. The motto is: “if it does not add value, then get rid of it!” A detailed Gantt chart for the next stage, a NPV calculation done early in the project, or many detailed forms filled out all add no value, so eliminate them! This is consistent with the Agile principle of “maximizing the amount of work not done.” Thus, leaning one’s existing process an important step before moving ahead to implementing Agile within Stage-Gate. For example, Danfoss, a Danish producer of controls, undertook a lean exercise on their Stage-Gate system, and reduced cycle time by a remarkable 50% before moving to Agile!26
Results Achieved and Why It Works
This new Agile-Stage-Gate approach yields three important positive results for manufacturers:27
- Development is faster: The team is focused, partially dedicated, and in good communication. Frequent stand-ups allow problems to be identified and resolved quickly. Because iterations are time-boxed, there is some self-imposed pressure and motivation to get the job done efficiently! The result is higher productivity, closer adherence to the time schedule, and shorter development cycles.
- Gets the product right: Product designs (features, functionality, etc.) are validated by customers (and management) as the project moves along—early, often and cheaply. Changes needed are identified sooner in the process, when making changes is less costly. Customers or users also learn as the project moves ahead—their needs and requirements become clearer with each iteration and demo. Thus, the product’s design evolves in the right direction as development proceeds (rather than being decided, and often incorrectly, at the beginning of Development).
- Team morale is higher: The team is self-managed, self-organizing, and ideally co-located: It defines what it can accomplish and how. The team’s objectives are clear and it has some decision authority.
Specific results when Agile is applied to manufacturers’ projects are in Figure 8 from several large-sample studies, with the greatest impacts being increased flexibility to react to changes, improved team morale, higher customer satisfaction, and a stronger commitment by the people involved in the project.28
Agile-Stage-Gate is a relatively new model, applied to the development of physical products. With five years experience in leading and early-adopter manufacturers, a consensus or dominant model is emerging, one that works for physical products and also yields very positive results. There are still challenges, and most manufacturers do adjust and adapt their new model to suit their own company and industry, but this new model promises to have the most significant impact on new-product development for manufacturers since the introduction of gating systems three decades ago.
About the Authors
Robert G. Cooper
Dr. Robert G. Cooper is one of the most influential innovation thought leaders in the business world today. He pioneered the original research that led to many groundbreaking discoveries including the Stage-Gate® Idea-to-Launch process. He has spent more than 30 years studying the practices and pitfalls of 3,000+ new product projects in thousands of companies and has assembled the world’s most comprehensive research on the topic.
Peter Fürst is Managing Partner of five is innovation consulting and an expert at optimizing innovation systems as Agile Stage-Gate hybrids, Innovation Portfolio Management and the fuzzy front-end. During his 20 years of high-level innovation consulting experience he has worked with companies in various industries, including sectors such as consumer goods, chemistry, mechanical engineering, electronics and services. Peter is also a lecturer in innovation management at the University of Applied Sciences – Vorarlberg.
Email: [email protected]
- Cooper, R.G. & Sommer, A.F. “Agile-Stage-Gate for Manufacturers – Changing the Way New Products are Developed,” Research-Technology Management Mar-Apr 2018, 61:2, pp 17-26. http://www.bobcooper.ca; and: Cooper, R.G. Winning at New Products: Creating Value Through Innovation, 5th edition, New York, NY: Basic Books, Perseus Books Group, 2017. See chapters 1-3 for NPD best practices.
- Atzberger, A., Nicklas, S.J., Schrof, J., Weiss, S. & Paetzold, K. Agile Development of Physical Products: A Study on the Current State of Industrial Practice, Universitat der Bundeswehr Munchen, Neubiberg, Germany, 2020. https://doi.org/10.18726/2020_10
- Stage-Gate® is a legally registered trademark of R.G. Cooper (and Associates Inc.) in the EU and Canada; and of Stage-Gate International in the USA.
- Cooper (2017), reference 1.
- Cooper, R G. “What’s Next? After Stage-Gate,” Research-Technology Management, 157:1, Jan-Feb 2014, pp 20-31; see also: Edwards, K., Cooper, R., Vedsmand, T & Nardelli, G. “Evaluating the Agile-Stage-Gate Hybrid Model: Experiences From Three SME Manufacturing Firms,” International Journal of Innovation and Technology Management, 16:8, 2019, 1950048 pp 1-32.
- Cooper, R. G., “New Products – What Separates the Winners from the Losers and What Drives Success,” in the PDMA Handbook of New Product Development, 3rd Edition, edited by Kenneth B. Kahn, Hoboken, New Jersey: John Wiley & Sons, Inc., 2013, Chapter 1.
- Beck, K., Beedle, M., van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M. et al. Manifesto for Agile Software Development, 2001. http://agilemanifesto.org/
- Scrum Guides. The Scrum Guide, 2017. http://www.scrumguides.org/scrum-guide.html
- Sommer, A.F., Hedegaard, C., Dukovska-Popovska, I. & Steger-Jensen, K. “Improved Product Development Performance Through Agile/Stage-Gate Hybrids – The Next-Generation Stage-Gate Process?” Research-Technology Management Jan-Feb 2015, 58:1, pp 1-10.
- Cooper, R.G., Dreher, A. & Fürst, P. “How Agile Development Works For Manufacturers”, Parts 1 & 2. CIMS (Center for Innovation Management Studies) Management Report, Part 1 in March-April 2019, pp 11-16; & Part 2 in May-June 2019, pp 6-11. http://www.bobcooper.ca
- Cooper, R.G. & Sommer, A.F. “Agile–Stage-Gate for Manufacturers – Changing the Way New Products Are Developed,” Research-Technology Management, 61:2, Mar-Apr 2018, pp 17-26. http://www.bobcooper.ca
- Cooper, R.G. “The Stage-Gate Idea-to-Launch Process – Update, What’s New and NexGen Systems,” Journal of Product Innovation Management, 25:3, May 2008, pp 213-232.
- Edwards et al, reference 5.
- Invention Center, Rheinisch-Westfälische Technische Hochschule Aachen (RWTH), Consortium Benchmarking 2018 “Agile Invention”: Evaluation of the Study Results, 2018.
- Kielgast, S., Vedsmand, T. & Cooper, R.G. “Integrating Agile with Stage-Gate® – How New Agile-Scrum Methods Lead to Faster and Better Innovation,” Innovation Management.SE, Aug 9, 2016, pp 1-15. https://innovationmanagement.se/2016/08/09/integrating-agile-with-stage-gate/
- Invention Center, reference 14.
- Cooper, R.G. & Fürst, P. “Digital Transformation and its Impact on New-Product Development for Manufacturers, InnovationManagement.SE, March 11, 2020. https://innovationmanagement.se/2020/03/11/digital-transformation-and-its-impact-on-new-product-management-for-manufacturers/
- Cooper & Sommer, reference 11.
- Dackhammar, N. & Ek, J. Combining Agile Methods and a Stage-Gate Model Within the Product Development Process. University of Gothenburg, School of Business, Economics & Law, 2017. https://gupea.ub.gu.se/bitstream/2077/53709/1/gupea_2077_53709_1.pdf
- Aberdeen Group, 2006. The Product Portfolio Management Benchmark Report. https://www.plm.automation.siemens.com/zh_cn/Images/aberdeen_portfolio_mgmt_tcm78-5843.pdf
- PDMA Handbook, reference 6.
- Cooper, R.G. & Sommer, A.F. “New-Product Portfolio Management with Agile: Challenges and Solutions for Manufacturers Using Agile Development,” Research-Technology Management, 63:1, 2020, pp 29-36. http://www.bobcooper.ca
- Cooper, R.G. & Sommer, A.F. “Agile-Stage-Gate: New Idea-to-Launch Method for Manufactured New Products is Faster, More Responsive,” Industrial Marketing Management, 59, Nov 2016, pp 167–180. http://www.bobcooper.ca
- See Cooper & Sommer, reference 22.
- Attributed to: Helmuth von Moltke the Elder, Chief of Staff of the Prussian army before World War 1.
- Jørgensen, B.B. “Agile Stage Gate at Danfoss,” GEMBA Agile Stage-Gate Workshop, Copenhagen, DK, April 2018.
- Schmidt, T. S., Weiss, S. & Paetzold, K. Agile Development of Physical Products: An Empirical Study About Motivations, Potentials and Applicability, University of the German Federal Armed Forces, Munich, Germany, 2018. www.unibw.de/produktentwicklung-en; ; and Invention Center, reference 14.
- Atzberger et al, reference 2; and Schmidt et al, reference 27.
Featured image via Unsplash.