Last week, tech startup Milk, inc shuttered its first and only app, Oink. Stop laughing. Those are the real names. Ok, only in the tech world, right? Jokes aside, deciding to pull the plug on a major project is not easy. Kevin Rose, Milk's founder, and the team have stated they are committed to rapid, agile development. It's an idea we could learn from in healthcare.
The company’s explanation was: “We started Milk Inc. (the company behind Oink) to rapidly build and test out new ideas. Oink was our first test and, in preparing to move onto the next project, we’ve decided to shut it down to help focus our efforts.” - via All Things D
Easy to say, hard to do
The trend of rapid development is gaining traction in tech startups. The basic idea is to continually innovate on products and services - they may never reach a finished state. In some instances, like Milk's, the products may yeild some success, but fail to fully meet expectations. In that case, developers look at lessons learned from the project and move the successful parts into new projects, leaving the failed peices on the cutting room floor. Continue what works, abandon what doesnt.
If the idea of abandoning projects mid-stream sounds challenging, it is. Teams have to ask themselves many questions such as when is the right time to pull the plug? How do we define success vs failure? What are the parts to keep and what should we leave behind? Perhaps that's why tech pundants have lauded Rose and team for their decision to stop Oinc.
Hey, clearly it worked out for them:
Google today confirmed the news we brought you yesterday: Kevin Rose and some of the team from his mobile app incubator Milk will be joining the company. - Via All Things D
Like most established industries, healthcare is steeped in tradition. One of the challenges of our tradition is a cautious approach to change. Largely, and justifibly, that's because rapid change in the practice of medicine has high risks, and we don't want to take risks with peoples lives. But there are some places within healthcare where rapid develipment and risk taking makes sense.
The professional side of healthcare - administration, business development, IT, marketing, management, etc - has historically taken clues from the medical tradition: slow, calculated decisions based on evidence, research, detailed financial plans, etc.
In adopting a rapid development model, professional teams could reduce some of the ramp up time for projects by getting comfortable with failure and change. Not every idea is a home run, sometimes it's just about getting on base. If the idea has some merit, take the positives and apply them to the next iteration.
Practicing rapid development
In the last few weeks, I've had an opportunity to explore rapid development. A team approached me with a clever idea. (It really doesn't matter what team or what their was. Names have been changed to protect the innocent, you get it.) As the innovation guy, it's my job to help them incubate and pilot the idea. So we tried it.
A few days in to the pilot, we hit snags. Part of the process stalled, dependant on another team and other processess. Pretty soon we had a massive reply-all thread going on email and enough differing opinions to make Congress jealous. (I'm here all night, tip your waitress, try the veal).
We were at a crossroads - stall the project, build a larger team and try and compermise on the orignal idea, or rapidly develop the idea into something else. We chose the later.
We did a quick assessment of the orignal idea and looked at the parts we felt worked well. We then discontinued the pilot in its current form. We let the other participants know and told them why and what our next steps were. Right away, we started a new pilot, plan b. Since we had building blocks from the successful parts of the first pilot, we were able to drop those processess and tools into place right away. We again communicated with the larger team.
To pharaphrase: "Hey, were't not perfect, but with your help and support we'll continue to refine this process. Thanks for your patience. Instead of A B and C, would you please start using X Y and Z?"
So far, the team has gone along with us. We understand they will eventually reach a point of change fatigue. To mitigate that risk, we know we cannot be in a state of rapid development forever. However, if we can use the tactic to keep the important parts of the orignal idea moving while we develop a stable process, then it will be a success overall.
What about you - have you practiced some sort of rapid development in healthcare? What are your tips and lessons learned? How have you learned to accept partial success along with partial failure? Does rapid development differ from basic project management skills?