Agile Development for Healthcare Business Intelligence
by Laura Madsen
Originally published May 25, 2010
Doing more with less should be the tagline for most healthcare organizations today. The pressures of keeping the bottom line stable and regulators/auditors at bay has driven most organizations to do the absolute bare minimum with their business intelligence (BI) deployments. Even the large ones that are growing are still squeezing the turnip. Showing value and tangible deliverables is the name of the game. As a result, agile development is becoming a more appealing option to many of these organizations. Even though as an industry healthcare organizations usually aren’t the first to sign up for a process that actually accepts a certain amount of error and fluctuation, many of them have traded that risk for the opportunity to see incremental value of a larger investment.
Your List of To-Do’sIf you are considering doing this, here are a couple things to keep in mind. First and foremost, pick up your copy of Ralph Hughes’ book Agile Data Warehousing. It is an excellent and pragmatic guide to agile development for data warehousing. I suggest reading it in its entirety prior to embarking on your agile adventure.
Take the time to communicate to all the stakeholders about agile development and what it means for the project. It’s important that they understand before the work begins that the process and deliverables will look and feel different during the life cycle of the project. They don’t necessarily all have to be on board, but they do have to be willing to give it a shot. Ensure that any communication about the agile development concept includes not only the benefits, but also some of the challenges. Painting too rosy of a picture will only get you in trouble in the long run.
The idea of “agility” isn’t to trade off quality, but to reduce turnaround time and re-work. The best way to do that is to make sure you are connecting closely with your end users. Locate your team so that they can easily have conversations with the business users. That will reduce the time it takes for questions (from your team as well as from the business users) to be asked and answered.
Finally, one of the most challenging parts of agile development (for me) is the idea that things will fluctuate over time. I can’t point to one documented set of deliverables with a list of stage-gate deadlines to get me there. What I can tell you is that in two weeks, we will have a piece, and in two more weeks we will have a bigger piece.
I have completed a couple agile projects in healthcare. None of them have turned out the way that I thought they would. What was really positive about all of them was that I learned a lot of project management. The reason for this is because in order to deliver in an abbreviated time frame you have to remove all barriers to productivity as quickly as possible. So, when I played the role of “project manager,” I would spend hours tinkering with my project plan; but when I was a lead on an agile team, I spent time reviewing deliverables and discussing my needs and requested modifications. I actually pulled my head up from my computer screen. Revolutionary.
One recent “revolutionary” agile project comes to mind for me. The organization has had a lot of changes, and they felt that data warehousing (DW) and business intelligence were a cure for what ailed them. Approaching it as a key market differentiator, they were prepared for the bumps that came with a DW/BI deployment; but just when we were about to pull the trigger, the fear of failure took over. So as an antidote to that, we simply said, “Okay, let’s deliver value as quickly as we can…how’s two weeks?” We designed the rest of the project around short sprints with incremental deliverables. I can’t tell you how it turned out; we are still working on it, but the objections to starting the project were removed when the promise of tangible content in weeks, not months, was communicated.
Another project I was a part of a few years ago attempted to undertake an agile development process. We had daily stand-ups, had a Scrum Master in charge of the project, had some method of mapping tasks with sticky notes (he swore it was better than a project plan). About halfway through the project (already late and over-budget), our Scrum Master left the organization, and our project, in absolute chaos because no one else knew the basics of Scrum. Another contingent of project managers took over and created an 86-page Visio diagram of all the steps that needed to occur in order to get a project completed and a release out the door for our data warehouse. We went from agile to docile in a New York minute.
For as many horror stories of agile development, there are also many great success stories. Like the time I spent two weeks in a developer's cube and completely modified our BI tool based on a specific set of focus group feedback. The project was fun and it was completed on time and under-budget.
I highly recommend that if you work in a healthcare organization and you have been pressed with how to do more with less, you consider agile development. Do your homework and walk in with your eyes wide open. In two weeks, you could have the start of your next data warehouse release.
Recent articles by Laura Madsen
Copyright 2004 — 2020. Powell Media, LLC. All rights reserved.
BeyeNETWORK™ is a trademark of Powell Media, LLC