There is a LOT of misleading information about agile development in the form of articles, website messaging, misguided training, and more. This post is intended to clear up misconceptions.

Misconception: Agile is a process or methodology. Agile is not a process, it’s a way-of-working rooted in principles that focus on value while efficiently adapting to change. There are an infinite number of agile process variations that could be implemented. The major benefits of agile come from an organizational mindset shift rather than applying agile methods on teams.

Misconception: New roles such as Product Owner and Scrum Master must be created to support an agile way-of-working. There is no need to create new roles in switching to an agile way-of-working. Only responsibilities must change somewhat to support an agile approach.

Misconception: An agile approach that works for software development will be effective for other functions. Agile methods that work well for software teams will likely not work without modification for other teams – especially teams developing manufactured products. Complex dependencies, lead times, prototyping strategies and other concerns need sequential management tactics that typically aren’t required for software development.

Misconception: Extensive training is needed so the organization understands agile. Agile principles and foundational methods are not difficult to learn, so extensive training isn’t needed. If any training approach seems complicated, it’s probably not right for your organization. Change, however, is difficult, and the right change management approach is much more important than training.

Misconception: An agile way-of-working isn’t beneficial after design freeze. The benefits of agile for manufactured product development continue after design freeze. Agile methods provide an efficient mechanism for adapting to feedback and changes such as DFM tweaks, supply chain issues, quality improvements, etc., which occur through production ramp-up.

Misconception: Agile is Scrum. Scrum is a form of agile, but agile is NOT Scrum! Too many organizations think a Scrum approach for software IS agile and try applying that elsewhere without an understanding of general agile principles and other agile frameworks/methods that would be a better fit.

Misconception: The Agile Manifesto is relevant for all types of work. The Agile Manifesto is not a good guide for general agile principles. It was written over 20 years ago specifically for software development and is still relevant for that purpose. They can be modified to fit other work, but several of the Manifesto’s principles only apply to software development. Here are eight agile principles that apply to manufactured product development.

Misconception: An agile approach must be purely agile or it’s not “agile.” A hybrid sequential/agile approach is necessary for manufactured product development, unless managing lead times, complex dependencies, efficient prototyping and timelines are of no concern. Most agile trainers and coaches don’t have practical experience managing physical product development and the complexities, so the approach they teach is software-centric and lacks the necessary sequential aspects.

Misconception: Project management and agile are incompatible. Many agile advocates (including trainers and coaches mentioned above) don’t believe in “project management.” They don’t seem to realize that roles such as Scrum Master and Product Owner perform project management activities, but for some reason they don’t like to call it that. They don’t address important project management concerns which aren’t included as responsibilities in commonly defined agile roles.

Misconception: Selecting the right framework is the best way to get started with agile. Choosing the right framework is not a good way to start. First be clear about your desired benefits and gain understanding of the agile principles that will help reach your organization’s goals. Then, leverage methods and tools that build those principles into your way-of-working.

Misconception: It’s important to use agile terminology. There is no need to learn or use new terminology. Specific frameworks use terms that might be beneficial, but agile principles can all be described with common language. Don’t be pulled into the trap of framework-specific terms and roles such as “stories,” “story points,” “Scrum Masters,” “Epics,” “ARTs,” “RTEs,” etc. as being necessary for getting agile benefits.

Summary

Think of agile first as a mindset and set of beneficial principles which should then guide your process. Most likely, agile methods and tools will be a key part of your refined way-of-working and ongoing improvements, but methods and tools aren’t the best way to start.

About the Author

Gary Hinkle is founder and principal consultant at Auxilium, a company dedicated since 2002 to helping product development organizations develop leaders, improve processes, build stronger cultures, and increase overall product development performance. You can contact Gary directly here.