The following is an amalgamation of conversations I have been having recently, explaining the world of agile to a team of project managers. Some have worked out well like this, some have not...
Project Manager: "Acme are unhappy again - this is the third project that's overrun but they just cannot see that hold-ups their end are causing the problems. We must have lost six or eight weeks waiting for changes - we've finally completed UAT and gone live but the website missed the start of their peak sales season. They've given us one last chance with the next project or they are going to leave us."
Scrum Master: "So, have you thought any more about the agile approach I told you about?"
PM: "Yes, a little, but I still don't understand why you don't want a requirements document. Tell me again about user stories and epics..."
SM: "OK, a user story is a simple description of what the user is trying to achieve. The product owner works directly with the customer stakeholders to see what the real business need is and write the stories. Epics are bigger bits of functionality that need breaking down into stories in future."
PM: "OK, I get that but where are the full requirements written? Where does the client tell you what to build?"
SM: "First off, the client never tells us what to build - the client tells us what their needs are. We add value by using our own expertise to design a solution. We know that neither the client nor us fully understand the details at this stage so we build small iterations and learn from them, adapting the design as we go".
PM: "Doesn't that result in lots of re-work? Surely a detailed requirement doc would prevent that?"
SM: "There is a little re-work but, as I said, the client doesn't fully understand the details either so chances are a lengthy document frequently would just be describing the wrong thing. If we built from that, we would put a lot of effort into building something that doesn't meet the client's real needs and have far bigger changes to deal with.
"By trying things in small steps we can get customer feedback very quickly so none of the changes ever cost much. In fact, we often find they highlight areas the customer hadn't thought about and help focus on where the real business value lies."
PM: "But a requirements document forces the client to think things through up front, doesn't it?"
SM: "It does, but we know this isn't effective. Take a simple web application: even this is going to have reasonably complex interactions - input validation is a prime example. Without seeing the system working, it is practically impossible to map out all the permutations. In fact, trying to document them up front can make things a lot worse - if the document doesn't match reality, the developers end up making all sorts of compromises to make it fit. You saw that on the last project where we had to roll back that chunk of work because of a bad assumption."
PM: "But that's why we have change control - we should have raised that as an exception before the developers build it so the customer can revise the spec."
SM: "We'd already been through the exception process with the previous issue - you said it yourself: that one must have lost us as much time as rolling back the other thing!"
PM: "Well, if the customer got the spec wrong, that's fine - we have an agreed exception process and if they caused the delay, they have to accept it."
SM: "But Acme are already complaining that we deliver late and are difficult to work with... Just because the client has signed a delay off doesn't mean it isn't late! This is the fundamental problem with detailed up-front specs - there is no room for change and we end up competing to blame any issues on each other. Don't you see that hiding behind a requirements document and contractual terms doesn't benefit anybody?"
PM: (sighs) "Agreed. So, how will using user stories help?"
SM: "User stories allow a collaborative approach where we work in partnership with the customer to solve their needs. We would ideally start off with a workshop with their stakeholders to map out the key user journeys at high level, identify any design constraints and so on. More detail gets added in, but only as it becomes needed.
"Most change requests we get come from the customer seeing how the system works and changing their mind. If the customer can keep the decision open until we are ready to build that bit, we never get far fewer changes. We also get far fewer UAT defects because the customer has seen it early on - ideally, we can avoid UAT completely."
PM: "So, by limiting the detail up front, we get to set the detail as it is needed so we only build what the customer wants?"
PM: "And with the next project, could we also start early by work-shopping the initial user stories and epics with them rather than waiting for them to write the requirements doc?"
SM: "Yep. Now all I need is your support to win the customer round - demonstrating agility is by far the best way to convince people so can you get the initial workshop set up ASAP?"
PM: "Will do."
Does this reflect your experiences? How have you helped traditional software houses struggling to meet customer demands? Any thoughts welcome!