Lean-Agile Projects You Will Do Again and Again


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

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.