The Illusion of Control

Just this week, I was invited to speak at a large product group’s annual meeting to inspire an agile mindset to their upcoming roadmap initiatives. As part of the session, we played the Marshmallow Challenge, a well-known exercise developed by Peter Skillman. The game illustrated how too much planning and reliance on assumptions can lead to unexpected failure.

This resonated deeply with the group, as we were able to reflect back on the exercise to dispel some myths about the agile approach vs. the defined processes they have used in the past. The conversation reminded me of a former client who faced a similar challenge when transitioning from a Waterfall approach. I thought I would share that story—modified to protect confidentiality—as a powerful lesson in embracing iterative learning and adapting to complexity.

“MedTech Solutions” has a clear mission: “Equip healthcare organizations to streamline compliance and optimize patient data management, ensuring efficiency in Risk Adjustment and Quality Improvement initiatives.”

In the USA Heartland, MedTech Solutions, a rising healthcare technology company, embarked on an ambitious journey to develop a groundbreaking patient data management system. Given their integration with numerous legacy systems, compliance with HIPAA and countless other regulations, and the necessity for rigorous security protocols, leadership opted for a strict traditional project management approach (in coaching terms, they chose a defined process control model).

Their rationale? The project was too critical, complex, and tightly regulated to risk the “chaos” of “Agile.” Agile is meant for small, low-risk projects, right?

The Plan

The executive team laid a multi-year roadmap, meticulously defining every requirement upfront (top-down, because executives know best, right?).

The process was linear:

1. Requirement Gathering (~6 months): Stakeholders, including doctors, IT teams, and legal advisors, contributed their needs.
2. Design (~9 months): Architects and business analysts translated the requirements into detailed system blueprints.
3. Development (18 months): Engineers built the system according to the precise specifications.
4. Testing (6 months): The QA team verified compliance, performance, and security.
5. Deployment (3 months): The system would be rolled out with great fanfare.

Leadership assured everyone that, by following this structured approach, risks would be minimized, and delivery would be predictable, just as the GANTT chart alluded to for the 300-person organization.

The Reality Check

By the time development began, the industry landscape had already shifted. New privacy regulations have emerged, technology has evolved, and end-user expectations have changed. Yet, the team remained locked into outdated requirements.

When the system was finally tested, significant problems surfaced:

• Compliance Gaps: New GDPR updates rendered parts of the system non-compliant.
• User Frustration: Doctors found the interface cumbersome as their workflows had evolved.
• Integration Failures: Legacy system APIs had been updated, breaking key functionalities.
• Security Vulnerabilities: Threat models from three years earlier were outdated, exposing risks.

Compounding the issue, MedTech Solutions relied on legacy mainframe systems from 1975. Their finance teams consistently applauded the longevity and reliability of these systems, arguing that upgrading was unnecessary.

Developers struggled to demonstrate ROI for modern computing investments, especially when the mainframe had functioned well for nearly 50 years. This resistance to change further entrenched the defined approach, making iterative improvements even more difficult.

Despite months of effort, the product was unusable, requiring a costly overhaul.

A Second Attempt: Agile in Action

Facing a crisis, MedTech Solutions pivoted. They brought in an Agile coach, who proposed an iterative, incremental approach:

1. Cross-functional Teams: Developers, compliance officers, and end-users collaborated from day one.
2. Short Feedback Loops: A working increment was reviewed with doctors and regulators every two weeks.
3. Adaptive Planning: Requirements evolved based on real-world testing and compliance updates.
4. Frequent Testing & Integration: Security and compliance checks were baked into each iteration.

Within four months, they had a testable MVP that was rolled out to smaller offices for iterative feedback and improvement. The complete production system took eleven months to develop. Still, continuous testing and feedback ensured compliance and usability concerns were addressed incrementally, and usable increments were delivered consistently. By continuously inspecting and adapting, they avoided wasted effort and delivered value early.

MedTech Solutions learned the hard way: the illusion of control through the defined process control model (Waterfall) led to failure in complex, evolving environments.

Agile’s empirical approach—embracing uncertainty, adapting to change, and prioritizing feedback—proved the better path.

The lesson? The more unknowns in a project, the less effective rigid plans become. When navigating complexity, iterative learning trumps perfect planning every time. Most people think it is the other way around.

Remember, just because a project is highly regulated, involves many stakeholders, and requires rigorous testing with real-world consequences doesn’t mean it needs a controlled process. These measures can and should be built into an agile “definition of done,” ensuring compliance, security, and reliability while maintaining flexibility and adaptability. We can help!