I was recently asked how the team and I plan our projects and said that we work with the product owner making user stories while determining dependencies. The person then asked how that was different from the waterfall approach so I figured this would be a good opportunity to write about the differences between the two planning methods.
My take from our conversation was that this person believed in the myth that agile teams don’t do any planning. That’s not true, in fact, if you add up all the events and ceremonies an agile team does, it adds up to more planning time than a traditional waterfall team. We just don’t plan everything up front at once because we believe in the cone of uncertainty. Like a meteorologist predicting a hurricane, the closer we are to the event to more we know about its direction. We have a release plan and an idea of what and when we’ll create the item, but we are not completely committed to it. We do high-level planning on the project and only do detailed planning on the next sprint or two.
In contrast, a waterfall project has a lot of upfront detail planning done by business analysts and subject matter experts; these planned work items are then assigned to project team members in a command and control style of management.
An agile team meets with the customer or the customer representative (product owner), determines what they want, and then they start planning together as a team. The team focuses on features the customer needs and items that will be of value to them, concentrating on how the application will be used rather than what a business analyst thinks is best. The truth is that only people using the application know what they need and what’s useful to them. I administered a case management system for a law firm but that does not mean I used it the same way the legal staff did. In fact, when we were looking to upgrade it, we worked with the legal staff to create most of our user stories and learned that the way they utilized the program was significantly different than we initially anticipated. Without their input, we would never have been able to deliver value with the update we initially thought to do.
An agile team plans its projects but doesn’t commit to that plan because they understand that they should be willing to respond to change quickly and without all the extra steps that a traditional project would have to go through. We do that by delivering a working product every sprint which we can demo and get user feedback on right away. If a change is needed or the product is not doing exactly what’s expected, we can respond quickly and provide what’s needed in the next sprint. It is also cheaper to make these changes early in the project as compared to the end when there are too many dependencies that’ll also need to be changed.
The way an agile team responds to change is by working collaboratively, we break down silos and get everyone involved. The product owner is part of the team and is involved in every step from creation to completion. They don’t just sit in the office and approve or deny change requests via email. Without that collaboration, completing a project is going to be difficult even if a team gets it done within scope, budget, and time. From my experience the initial scope always changes as people learn more about the product, whether its extra features or ideas that sounded good at the beginning and become useless somewhere in the middle. Without communication the customer winds up with a product that they asked for but not necessarily what they wanted or needed when it product goes live.
Comments