I’ve been writing recently about the wholesale abandonment of Gantt-based project management (including critical chain) by software and tech companies. In the software world, the Gantt approach has been wholly supplanted by Agile Project Management. Agile Software Development is a class of new project management techniques that has become standard practice at modern software companies, including Google, Spotify, Amazon and practically every software startup. Agile-based new product development (NPD) leads to products that better meet customer and business needs, with shorter development timelines and with less development investment. What’s not to like?
What is Agile?
I’ve been studying Agile for several years. It’s easy to confuse Agile with scrum and daily stand ups, but those activities are only part of a larger toolset. If you try to apply scrum and stand ups without the rest of the package, you’re unlikely to succeed. Listen up, I’m speaking from experience here.
Agile techniques have primarily been applied software development, and the approach is really optimized for software projects. So, to really understand Agile, you have to start with understanding Agile software development. Start with Ken Schwaber’s books, especially “Agile Project Management with Scrum.” I also really recommend Kent Beck’s classic Extreme Programming Explained.
Agile posits that a team’s overall execution of a project is optimized when the team is always working on the “right tasks,” and that those “right tasks” can only be defined for a relatively short time horizon.
Some key Agile principles include: frequent iterations of “understand-requirements/plan/do/assess” cycles (a/k/a small and frequent product releases), a real commitment of the NPD team to planning tasks and assessing performance, the practice of working tasks sequentially rather than in parallel (thus forcing prioritization), test-driven development, and a product architecture that emerges/evolves rather than being pro-actively designed.
In a high-uncertainty project, the critical path is fundamentally unknowable up front. Agile generally eliminates longer term planning and thus sacrifices longer-term project and product visibility (which is presumed unrealistic anyway). Instead, the Agile approach promises that the product you will get in six months will be better than anything you might have pre-planned, because you have optimized execution and eliminated wasteful efforts on pre-planning that would need to be reworked anyway. Agile thrives in a highly uncertain environment, committing NPD teams to a certain process that navigates uncertainty.
Because Agile was developed for software development, it’s not exactly obvious how to apply the techniques to Medtech projects. For example, Agile makes no provisions for planning the tasks that take time but no effort (such as waiting for products from vendors). For Medtech engineers working in a regulated environment, it’s not clear how the idea of ‘frequent product iterations’ meshes with a phase-gate product development process. It’s hard to reconcile Agile’s use of “user stories” with the need for a comprehensive marketing requirements document. Are hardware product architectures as free to evolve as a software-based product?
Medical device companies need to dramatically improve NPD productivity, which means medical device companies need to rethink their approach to project management. If we can learn the lessons of agile software development, and apply them to the unique circumstances of medical device development, the payoffs could be huge. I think we can. More on this soon.