top of page
Munk

Can "Agile Teams" Reform Healthcare Systems?

I recently had lunch with an experienced physician executive from a large academic medical center.  He told me that his organization was trying to migrate from fee-for-service to risk, and that management had appointed a bunch of large committees to oversee everything from a new cost accounting system to the development of multiple external partnerships.  

The going was slow.  The large committees were cumbersome.  Nobody felt empowered to make hard decisions.  Twenty major initiatives were all 10% complete one year into the migration. The problem, he said with a sigh, seemed to be the way that the change initiative was structured.  There were too many people moving incrementally.   I've spent a lot of time considering the massive challenge that large health systems face in taking on risk contracts.   The cultural, technical and structural challenges facing legacy healthcare players are enormous.  (I've previously written about the corporate structure and changes to the back office that are going to be needed when companies are paid for value). Is there a more nimble way to approach reform? _________ This month's Atlantic Magazine has a fascinating piece on the rescue of the Healthcare.gov website.  In short, version 1.0 of the website was a disaster, attributed in large part to the large number of massive and poorly supervised contractors building the site on a “cost-plus-fixed-fee” basis.  In response to this embarrassing rollout, the Obama administration appointed a group of Silicon Valley leaders who took over development of the website. A small group of coders called the Marketplace Lite (MPL) quickly set up shop. The small group worked in hotel rooms, and then a rented suburban house in Maryland furnished with Ikea tables and mattresses.  Over sixteen months the team turned the Healthcare.gov site around.   What was the key to MPL's success?  How could a small group of coders working on cardboard boxes and folding chairs fix one of the most complicated web interfaces in America? The Atlantic attributes it to "agile" teams and work processes. It's a concept that has been around software circles for over a decade, but it's something new to me. What is "agile"?  The Lookback In Respect blog, written by a software project manager nicely describes the approach:

In comparison to more formal and structured "Gantt-chart" type project management techniques, agile is apparently the

best way to approach an engineering issue where the problem and solutions aren't well understood, 

creating a new product, troubleshooting a complex system, etc.  The rapidly iterative process is perfect for handling uncertainty.  More formal project management processes can be used when a project is better understood. The agile manifesto, created by a group of software designers in 2001 describes agile's core principles.  They are:

Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

Compact multidisciplnary teams are key to this approach.  Teams that are too large require too many interactions for the work to get done.  Ownership of the problem was key. Robinson Meyer, writing in the Atlantic about MPL notes:

What are the lessons for healthcare?  

I'm quite struck with the idea of using nimble multi-disciplinary groups to work in rapid and iterative cycles to get complex work accomplished.

 Agile seems like a promising approach for healthcare systems that are trying to restructure themselves in the face of healthcare reform,

especially given the vast uncertainty around what's required

 for systems to thrive in risk. I've previously argued that the massive internal inter-dependencies in risk-bearing healthcare systems

are going to require systems to seriously rethink their corporate structures

.  The M-Form corporate structures that we see in most large integrated healthcare systems aren't well suited for risk. Beyond this, how will the actual work of building risk-bearing systems occur?  For large healthcare systems I could envision, say, multidisciplinary project teams which tackle the infrastructure, accounting and systems overhauls that are needed to thrive in risk.  At the same time, having spent enough time working in large healthcare systems, I can also appreciate that

technical change is only a small part of the equation

. As I've written about before, cultural transformation is often 90% of the battle in big companies.  Nimble, iterative and multidisciplinary teams can come up with the best technical solutions in the world.  Winning hearts and minds is another matter.

Photo:  Atlantic Magazine and 
Julien Harneis
 Flikr, cc license. 

Comments


bottom of page