Agile Issues

Agile practices do a great job of surfacing issues. It reminds me a bit of user interfaces. A former colleague used to say that the UI always got blamed first. Often the issue was in lower layers, but the UI was the part that surfaced the issue.

In a waterfall environment, issues can hide. If it takes a while for "Bob" to respond to "Stan" on what is really needed, it might go unnoticed. Stan makes his best guess or moves on to something else. But it has an impact. When Bob finally comes back (potentially days or weeks later), Stan has to come back up to speed on the issue and potentially undo or make major changes to work that had been completed. Lots of balls tend to be in the air. This complexity has costs.

In agile, you only have a couple of weeks (give or take) to drive things to conclusion. This urgency brings issues front and center. Bob is now a blocking issue. He'll come up every day until the issue is resolved. The whole team is aware of the issue. That's a lot of pressure for Bob to respond and for him to be more responsive in the future.

Recently, I had a similar issue come up with a team I'm working with. In their case, the issue was that the product owner wasn't involved enough in the iteration planning. It wasn't really a shared goal / commitment. As a result, when the demo came around, this issue came front and center.

In waterfall, the same thing probably happened. There wasn't enough buy in / participation. But, it probably slipped through the cracks in subtle ways. It likely went on for a while, a particular case was noticed and corrected, and it reoccurred. Since this team is now using agile practices, it surfaced quickly and will be resolved (particularly since it was arguably the biggest issue in the iteration).

The retrospective at the end of the iteration helps a lot with this process. Here issues are raised and discussed. Strategies are created to resolve the biggest issues in the future. The team adapts and figures out how to do better next time.