Lean-Agile Projects You Will Do Again and Again

How many times have you seen this scenario? Several years ago, someone created a spreadsheet to support the work of a department. They kept tweaking it, adding functionality; maybe even migrated it to Microsoft Access… and now it has become a mission-critical mess! And you can’t afford to let the employee move on to something else.

It is time to bring this application up to date: both to mitigate the risk and to scale it out.

This is the sort of project that crops up all too frequently in the enterprise.

This is the story of how Premier, Inc. used Lean-Agile software development to bring one such project to completion quickly, with less waste and complexity, and started using it quicker than normal. It is an approach you can use again and again.

The Premier healthcare alliance brings nationwide knowledge to improve local healthcare. It does this by providing solutions to collect and analyze clinical and financial data from its more than 2,200 member hospitals and 64,000 non acute-care members.

Ken Tompkins, Sr. Director of Business Analytics for Premier Purchasing Partners, oversees the analytical division, supporting the field force with essential data analysis.

Ten years ago, the sales force needed to document to member hospitals (customers) exactly “what Premier had done for me lately.” Ken’s boss tapped him to put his computer science degree to use to figure out a way to show them the numbers. He created a simple PowerPoint with four quadrants: Goals, Plans, Benchmarks, and Results. The members liked the presentation but wanted the details.

Next year, Ken created an Excel spreadsheet with the four quadrants and a tab of detail for each quadrant. Every project that saved a member (customer) money would get documented in the detail tab. And so it evolved and expanded. Leadership in other regions began to use it in their sales meetings. It became standard operating procedure for all directors, using the tool to document how they were saving members money and improving processes. They added historical data and trend analysis.

Suddenly, what started as a simple PowerPoint had become hundreds of Excel files flying back and forth between the internal analytics department and the field. Ken had two good analysts devoted almost full time to tracking these spreadsheets and keeping them up to date… and fixing them when a sales person would “improve” her own spreadsheet and introduce a bug.

How did they get into this mess?

Lacking funding and resources, Ken got tapped again to bring some rationality to the system: a single database, a single format, traceable business rules, etc. What would you do? He gathered a few people and merged these spreadsheets into an Access database that they could throw out onto the network. It had some rudimentary security and the minimum set of forms, tables, queries, and reports to get it up and running. But it didn’t scale when people from Washington state to Maine to California all wanted to log in to manage and report on 35,000 projects. Certainly, it did not work well for those trying to access it from a PDA on the train.

After two years, leadership recognized they needed to do better. They prioritized a project to use Lean-Agile software development to make a robust, reliable system. And to free Ken from having to support this tool for the rest of his career.

That is the history of the project. Below is a conversation about the project between Ken and Guy Beaver, Vice-President of Net Objectives and a senior consultant in Lean-Agile.

Coach: The demonstration after the first iteration was a little tense. I recall you were late and the team was anxious. What happened?

Ken: I wasn’t able to be with the team much. I had told them a little of the history, showed them a laptop with the database on it and told them to make the system work like it did on my laptop. They did the best that they could with that example. But they didn’t really understand what was going on in the system. They hadn’t anticipated multiple people using the system.

Moreover, they didn’t understand all of the manual work that my staff was doing to maintain the system. For example, the forms in Access used a lot of drop-downs to populate fields. Whenever values had to change, one of my analysts had to edit the database manually. So, the developers made these drop-downs relatively static.

When I saw the first iteration, I said, “Wait! We need to have these be live [not static ] because I can’t have my staff keep going back in there to make changes! The whole purpose is to free up these people!”

I had not done a good job telling them what was required. And I was not really available.

Coach: I like what one developer said. “We had basically coded a work around or didn’t understand the requirements. I’m glad we found out this problem right away – after Sprint 1- and not six months from now!” I think the real success story was that right away, you all recognized the problem and you found a way to make yourself available.

Ken: I told them, “Don’t not proceed just because you can’t meet with me.” I spent a lot of time checking out work from hotel rooms while on the road. I called in when I could. And when I was in town, I was meeting with the team. It helped us have touch points we had never had before. The frequency of interaction, although dispersed and sometimes very short, was key to making it work.

Coach: Focusing on the feedback loop was key. Another key factor (based on lean principles) was that you worked in a “vertical” slice (user-focused, tab by tab, and continuously integrated) rather than a “horizontal slice (work done in tiers and integrated at the end).” Working through the application one tab at a time, you saw the application emerge quickly from the user’s perspective.

Ken: Working one tab at a time, the team was able to set some of the foundational elements of the whole system. The team learned how directors worked through the forms, the dependencies between one set of drop-down options and the next. The business rules for the forms were not obvious. Working vertically through the system, they discovered the dependencies between all of the modules. Had we worked horizontally, trying to finish each module before going on to the next, we would still not have spotted some of those nuanced dependencies. You really had to go through the entire workflow to spot those.

Coach: And did this help testing iteration to iteration?

Ken: Yes. Effectively, user acceptance testing emerged with each iteration. The functionality that we talked about in one iteration was ready for the next iteration. And that functionality was available for the next. Each iteration, we could do the testing on previous functions and add the new functionality.

Now that it has been released, we are still meeting to talk about new things that would be nice to have because we understand the application better than we did before (and I wrote it!).

Coach: Right, because you learn as you go.

Ken: Another good thing was that the development team could vary over the life of the project. Since we were developing in little pieces, each building on the other, no one had to spend a lot of time catching up. It worked out that they just needed to know what we were talking about that time. Had we done things horizontally, it would have been very complicated. I thought that was new and different and I liked it.

Coach: That is an unexpected benefit. Completing work allows emergent behavior to continue to be emergent. Did you feel like you had good visibility into the sequence of work they were doing? How did you establish that?

Ken: When they originally rolled in the big whiteboard with color-coded sticky notes all over it, it looked a little haphazard, especially since some developers did not have good handwriting. It seemed pretty mediocre and low tech. By the fourth iteration, I loved the concept because it brings issues down to something tangible where you can see it, move it around. It’s not scary. And it is actually very well organized. The whiteboard concept, the frequent meetings, the story telling – it just feels more pleasant.

Coach: How did that work when you’re travelling somewhere?

Ken: We had the stories in our head. When we met over the phone, the team dictated what was going on. I did see the whiteboard much less frequently than everyone else; but I think their willingness to ask questions and my willingness to explain something four different ways, using real examples, helped them understanding the use cases very well and how to adjust them.

Coach: As the Product Champion for this project, is it documented well enough?

Ken: All I care about is that it works. I’m sure there is documentation because every story was documented all along the way and the code is tied to stories. We talk about a story and then the next time I see it is in UAT then it is in production and it works.

Coach: What does your staff think about the application?

Ken: Here is a perfect example of why this process is awesome. When the application was in Access – and I’m not exaggerating – over two years, I just never had time to show my staff how the system worked, the nuances and the logic behind the screens. I did that and what the nuances were or what the logic was behind the scenes. Now, after eight iterations, the staff is comfortable that the product is stable and understand what it s doing. And they aren’t worried.

They are really happy not to be collating hundreds of spreadsheets each month!

Coach: So this was eight iterations… not a huge project.

Ken: Size does not always reflect value. The reporting that comes out of this tool goes to one of Premier’s top corporate goals: cumulative, member-validated savings year-over-year. The members trust the tool to validate the savings. It allows the member and the field sales executive sign off with confidence that “Premier saved us $700 million dollars over the last fiscal year.”

You could easily see where this could’ve been so unsuccessful had a normal team been handed an application and been told “here, just convert it.” And then, six months later, they discover that they did not understand the underlying assumptions.

Beyond this, we eliminated some functionality that was never used but was sort of hanging round from the Excel days. As we worked through the prioritization of features, we focused just on what was required.

Coach: One last thing. You had a fixed date for the release of this project. There is a common perception that Agile approaches cannot operate with a fixed date. What would be your response to that?

We knew that meeting a tight schedule was coming from the very first day that we met: just a few months out.

Starting with the second sprint – when we got a better handle on the use cases and how I would interact better with the team – the team jelled and I felt we would be fine. I’ll put it this way: I never had to send an email asking, “What is the status of this product? I’m kind of scared that we’re not going to hit the date.”