Up at 5AM: The 5AM Solutions Blog

Remarks by our CEO, Brent Gendleman, when he introduced a personalized medicine session at today's BIO-IT World Expo...

"10 fingers, 10 toes, that's all that used to matter. Not now. Now, only seconds old, the exact time and cause of my death was already known."

This is from a scene in the great film "Gattaca," which details the narrator's birth. A needle-pick in his heel yields blood for a genetic test, and the results appear instantly in a printout. While the mother cuddles the newborn, a nurse seriously reads out his fate: "Neurological condition, 60% probability. Manic depression, 42% probability. Attention defecit disorder, 89% probability. Heart disease..." (a serious look) "99% probability. Early fatal potential. Life expectancy: 30.2 years."

This is not personalized medicine.

When I think about personalized medicine, these important genetic tests are a key component. They provide my doctor with the ability to know me, and to know people like me. This helps us understand how my behavior impacts my health, and to identify the best medicines for me, and the medicines I should stay away from.

When I think about personalized medicine, I think about my doctor and me being able to take my information and share it with the research community – to serve research, me, and people like me.

Personalized medicine is not only about breaking down the silos we’ve been talking about today – between and among bioinformatics and standards and interoperability and health-it and massive data and researchers and clinicians. It’s about making our work personal.

You know, most of us do incredible work in our silos, and we know that one day we’ll be able to let information flow through from one “track” to another. We work with so many fabulous people at the NCI, developing solutions to help cure cancer. One of our partners, a researcher for whom we’re providing research software, was reporting his results to his contract officer. The contract officer asked if he was meeting his deadlines and deliverables, and he replied “No, we’re not on schedule. We’re trying to lengthen the survival curve for these people.” He said the contract officer was silent, and replied, “I’m sorry. You know, sometimes I forget that what we’re doing can have that kind of impact.”

Personalized medicine is about establishing a cohesive community, where we learn from each other, we take advantage of our respective strengths, to make informed choices and take care of people.

In case you hadn’t picked up on this already, 5AM is an Agile shop. Take a quick glance at our Glassbox Software Development Process and you’ll see the unmistakable scrum methodology featured prominently on the top of our development process diagram. Although Agile-Scrum is now a well-established process in software development, those of us coming from a science/bioinformatics background are not as familiar with the concept. Another thing we believe in here at 5AM is that bringing good science and good engineering together is better than the sum of the parts – the two complement and enable one another. It’s this belief and our commitment to Agile development that led us to ask ourselves, “can our science projects benefit from following an Agile model?” That’s the experiment we’re pursuing now and this is a bit of our story so far.

The first step in the process has been to train almost all of us bioinformatics types in the basics of Scrum. Since it’s not a package in R and has never appeared in an episode of Battlestar Galactica – most of us knew very little about it. I myself took Scrum Master training here in the Bay Area. As exotic as the title “Scrum Master” sounds, I was disappointed to find the training did not involve breaking boards or making a pilgrimage to an ancient monastery in the Himalayas. What it did involve was passing little red balls around as efficiently as possible, measuring the “points” value of everything on my desk and ranking countries by how “fun” they are. To the uninitiated, this might all seem a bit crazy, but the activities were showing us the core elements of Scrum – how to work effectively as a team, how to measure progress and stay agile. Thanks to Lyssa Adkins for leading a great workshop.

Now back in the real world of juggling p-values rather than rubber balls, we have started to map the day to day efforts of our science projects to an Agile process. Some parts fit really well – in fact, they’re things we were doing already. Scrum’s short iterations with a focus on delivering “working software” at the end of each sprint is analogous to the iterative approach that our bioinformatics team takes towards data analysis and other projects in which we frequently share results and calibrate next steps with our clients. Scrum makes this more formal, but it’s easy to imagine tweaking what we do now to fit Scrum. The Scrum roles are also fairly familiar. Typically we have a primary investigator or business development professional (for us, this person is usually a client) who plays the role of Product Owner. Our teams also tend to be small, cross-functional and everyone pulls their own weight – values shared by Scrum.

Other aspects of Scrum are things we don’t do, but probably should. The Product and Sprint Backlogs are prioritized lists of tasks that need to be completed to produce the “product”. We usually have something like this in our science projects, but the prioritization piece is sometimes missing. I think back on all the times that each data analysis led to “just one more” interesting question to answer which drove us on a depth-first search to nowhere. A process that forces you to prioritize every new task and periodically review the list as a whole is a road map towards common sense. Scrum’s focus on measuring progress through points and visualizing progress through Burndown Charts is new, but again, not a bad idea. It might be a challenge to turn open-ended undertakings like “research oligo design tools” into quantifiable tasks, but I’m fairly confident it can be done – and it will be an improvement. And just as important as making tasks measurable is identifying when they’re “done”. This often goes unappreciated in our science projects, but Scrum forces us to address it.

So far, so good - maybe Agile science isn’t such a stretch after all! But before suffering from “premature exubaration” (as my sometimes off-color former boss liked to say), there are a few elements of Scrum that we still haven’t quite figured out. First, there’s the strict timeboxing of tasks. In Scrum, once the team has agreed to what they’re going to accomplish in an iteration, the team is expected to stick to this commitment and deliver. A typical iteration time is two weeks. How many science projects have I been on where priorities and tasks completely change in just days, let alone weeks? What’s the solution: shorter iterations, more discipline/more thoughtful tasks or get rid of the timeboxing altogether? Another issue we run into is the allocation of our team members. Often our team is made up of sub-contractors or 5AM employees who have only a fairly small commitment to the project – say at the 25% level. Can team members truly participate in Scrum with so little time available for the project?

So, our consensus opinion right now is Agile science has promise, but there are still some pieces we need to figure out. Like most things in life, proof will be in the execution. We’ll only really know how well Scrum works for us after using it on a few projects. We will periodically update you on our progress and hope that you’ll share your experiences and insights with us as well.

I made a list this morning of my favorite essays from Rework, the new book from the founders of 37signals. The book has been discussed quite a bit online and around our office. At 5AM, reactions have been all over: violent agreement with some, like "Meetings are toxic"; lively debate about others, such as "Why grow?"; and disagreement with essays like "Pass on great people." My list ended up looking like a small poem:

Planning is guessing
Your estimates suck
Decisions are progress*
Decisions are temporary
Start making something
Launch now

(* "Decisions are progress" is actually "Making the call is making progress," but that's too wordy for me and for them.)

The takeaway from my list: Be myopic. Be intentionally, explicitly, unabashedly myopic.

Planning and estimation are educated guesses, and you almost certainly don't have enough data to make long-term project plans. How many Microsoft project plans have you seen with tasks years into the future with precise annotations "6/12/2012 - 2 days - Kickoff with Site #7"? This is nonsense, and nonsense that takes forever to set up, review, link, and update. People are terrible estimators, and nobody really knows what they want at the outset. A giant project plan doesn't serve the needs of the people doing the project. You have the illusion of control and clarity, when in fact you have neither and are now suffering from software myopia.

Throw it away. Move to processes and tools that mirror how you actually engage your client. Make requirements and estimates clear for needs to be built now, then get progressively less precise about what will be built later. Be explicitly myopic. At 5AM, we have use case models to describe the really big pieces. We create that as one of our first artifacts, often as part of our proposal. The use case model is broken up into more granular tasks, which are added to our backlog. Perhaps 3-8 initial tasks will be created for each item in the use case model. As tasks percolate up the backlog, they are further subdivided until a single task's requirements, acceptance criteria, and estimate fit comfortably into an iteration. We are not suffering.

This is the same message Rework has for decisions. Moving from "let's discuss" to "let's decide" is hard if you think you are deciding for all time. Make the best decision for now, given the information at hand, and move on. Within a project, this applies both to what you are building and how you build it. This is where close feedback cycles matter. Build a little, see what works, learn from your mistakes, and build again. Recognize that you are further along than you were before, and you have a clearer picture of the problems than you did before. Myopia is working in our favor.

Finally, don't let myopia paralyze you. Take what you know right now and build it. It's wrong, but you are better off wrong with working software and lessons learned than you are wrong with no software and no attendant lessons. And the very best lessons are those learned by putting software in the hands of the end users.