In my work I have the privilege of training people new to Agile. I get to see a lot of recurring patterns, objections, resistance and disbelief as we start people on their journey to realizing there are other ways to manage projects than the traditional waterfall approach some of us have lived with for decades.
I wanted to share one recurring discussion that seems to always come up in Agile Introduction training. It involves the concept that an Agile approach can tell you early on and at a high level the rough cost of the project, the length of the project, how many sprints. What we can't do is guarantee you exactly what you will get and when.
Most people do tend to agree in training sessions that even in waterfall upfront planning we are guessing costs and duration as we really don't know what is around the corner. When stuff happens we will slip the delivery date, increase the size of a phase, introduce more resource, throw some money at the issue.
The words from above that always cause the discussion in training are "What we can't do is guarantee you exactly what you will get and when" This is not about the internal running of the project, this is now about what the end customer is going to get. The first reaction from students is that "this just isn't good enough" and "surely the risk of project failure is higher".
This is coming from their perception of currently run projects or their historical exposure to them. In their current projects it's possible that customers are not getting what they want, and even when they do it's over budget or delivered late and so the business to IT relationship is 'strained'. What customer would ever agree to hand over money to a project where we couldn't tell them what they were going to get?
This is a normal response from students of course. Their reaction is based on what they know. I then explain to the students "Let's imagine that the people who usually give us a hard time about what we deliver, are now the people working along side you, or maybe a representative of those people that we call the Product Owner. Now they work very closely with the team, it's business and IT roles together with high levels of collaboration. And these people are no longer waiting to see what you are going to deliver to them, they are helping you understand what to build next. In fact it's their responsibility to manage the list of work items and re prioritise regularly what the team should build next".
At this point we have the discussion again. We explore the change in the expectation of the Customer. We discuss the fact that they have never worked this way before and then need to imagine working with the customer who now makes weekly decisions on scheduling, prioritizing, complexity of the feature etc. If the person deciding what goes into the iteration is the person representing the business their expectations change. It's not a sling it over the wall scenario anymore. Now is an "everyone work together for success" scenario.
When we are running out of time, the team work with the product owner to manage the expectation of what would generate a successful outcome. When a feature is too complex and expensive the team work with the he product owner to simplify the feature but still deliver the required business benefit.
When the business work directly with IT to produce working solutions everyone's expectations change. Everyone works together to find a successful solution that is acceptable to the business because it's the business who made the decision, along side you, week in week out.
You can see the lightbulb light up for the students as they realize the implications of this approach. I always know they have understood when someone asks "so when are you training the business people too?".
I can't think of a more fun and fulfilling way of building and delivering solutions to business problems than by doing it daily alongside the people who are going to receive the business value.