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.