Agile and Healthcare Data Projects

Sun Tzu once said something like “if you know your enemy and you know yourself, you will win every battle”. I would like to paraphrase…if you know your data and if you know how to use it you will have successful data projects every time. Here is the rub…healthcare data is notoriously “dirty” and relatively inconsistent which makes data projects complex….sometimes our customers know exactly what they want…sometimes we know exactly where to get the data…sometimes people start going in one direction but during the process we end up in a completely different destination. I don’t want to turn this into a healthcare data discussion, so lets imagine for a second…

Imagine you are a baker, and a gentleman contacts you for an order. The customer the details such as occasion for the cake, delivery of the cake the size of the cake and the flavor of the cake. You have a plan, you schedule everything and feel confident that you can achieve your goal by the deadline. You call the customer back on Saturday to confirm the details and you speak to the “real” requestor (the mother of the child) and she mentions the child has a gluten allergy? And really wants cupcakes…with chocolate chips…and doesn’t like yellow frosting…..EVERYTHING HAS TO CHANGE!!!! The entire schedule is a mess and you aren’t sure you can make your deadline!

There are some things you can do to help mitigate your project issues, but there is not one panacea.

Enter Agile Software Development (AGS).

AGS is awesome! AGS can save orgs a ton of time and money! AGS is designed to be fast, iterative and flexible…but many orgs implement AGS using standard and general ideas that work very well outside of healthcare…if we want to enjoy all the benefits of AGS, we are going to have to be a little more flexible…a little more collaborative and a little more..well…agile.

I was introduced to AGS (though I didn’t know it at the time) in 2007 when I was working as a contractor at Canon. I was amazed at the efficiency of the way the projects moved and I was so impressed with the constant success of all the work we were doing! Where traditional “waterfall” projects are performed in linear fashion by siloed people who follow very specific rules AGS is flexible, focuses on iterations, use a collaborative “360” approach to working together and puts the needs of the customers above procedures and working products over documentation.

Healthcare orgs are starting to embrace AGS for their data projects but there is a slight issue…to use AGS in health care data projects we have to make some adjustments.

Collaboration

For decades health care orgs have operated in a siloed fashion. AGS respects that each of us has our own circle of competence that each of us also knows enough to help and work outside of our box. Decades of behavior can’t be changed simply by bringing in a contractor to lead an agile call…so this is going to require a lot of hard work by a lot of different people.

Customer focus

Traditionally, healthcare data projects have been long linear projects that require everyone to “stay in their lane” and that includes the customer. I have seen and participated in projects where there is one conversation with a requestor and the customer isn’t involved until the end. AGS is supposed to include a representative of the customer during the entire process. Many orgs use business analysts to represent the customers and in some orgs and industries that can be successful. In health care, however, there is no one person who can be so knowledgeable of the business process that they can successfully navigate the entire project. This is a great opportunity to look back at the original codex of AGS for advice.

The AGS manifesto discusses having a client or customer representative as part of the team during the entire process, someone who really understands the needs of the business and is able to properly represent the customers. This doesn’t mean we scrap the idea of a business analyst but we should always have a real customer representative involved.

Stories

A story is a request, but its not all the details…an example of a good story might be ‘Mother needs a vanilla birthday cake for her son’s birthday party this Sunday”. There aren’t a lot of details in here, but we get a really good understanding of what success might look like.

Traditional adherents to AGS might push to have the customer write the story….others might want the BA to write the story. Considering the complexity of things, the stories should be written only after detailed conversations occur between the consumer, the stake holders and the data team. This doesn’t have to be a formal conversation, but if you need help knowing what to talk about you can go here or here.

Sprints

I love the idea of sprints! A sprint is a short, defined time frame where one throws every resource against a task with the intent of getting that task done! AGS assumes that the person with the most skills is going to complete the task, but everyone is welcome to help in anyway they can!

But…even if we get the task done in the 10 day sprint, it doesn’t matter if the end result is accurate but it is wrong for the customer. 

Here’s the thing….you have heard me discuss using the right tool to get the right data to the right people at the right time so they can make the right decision….but we can’t really get things done unless the right people are involved.