Where is Waterfall failing us and can Scrum help us have success in our projects?

Question

Let me explain our situation. We are small company with about 20+ staff and all the while we have been practicing the standard waterfall model with not much success (due to frequent changes of requirements and lack of direction).

So one day our CTO came in and he briefed us about SCRUM and all of us were convinced that this model will work great for a small team like us. Unfortunately all of us do not have any experience practicing SCRUM and we have been relying mostly on online resources and books.

Then we come to a new project that we are about to get started and we are doing something like:

1. Gather requirements from business domain user
2. Prepare a requirement spec with UI and features (this already took us like weeks)
3. Meet up again business domain user to see if there is any changes required
4. Once the business user agrees to the specs we will key in those feature in to product catalog
5. Break those features into tasks and assign to sprint

Should we instead take the more agile approach? like

1. Gather requirements from stakeholders
2. Start to create epic user stories and run through with stake holders
3. Break those epic stories into smaller stories (supported with some ui) and assign to a short sprint(2 weeks)
4. We show them what we have done for the 2 weeks, get their feedback and plan for the next sprint

Given the nature of our projects where we are constantly faced with the challenges of volatile requirements and a lack of direction, where will the above Scrum/Agile points benefit us and why are the above Waterfall methods failing us?

Answer 1

The second approach is much more in the spirit of agile/scrum, but it also requires a commitment from the customer to visit regularly to see the progress and discuss further features.

If the customer is uncomfortable with such a commitment of effort on their side, or if they already have a very good idea of what they want to have, then your first approach might be more constructive.

One of the key points of scrum is that the customer gets a big say in the order in which things are produced, so let them clearly indicate which features they would rather have sooner and which features might end up in the bin if the budget gets too stretched. And don't kick up a fuss if the customer changes his mind on some requirements/stories, especially if they haven't been implemented yet.

---

An alternative approach, in a more scrum-like manner, but similar to the first approach, is like this:

1. Gather requirements
2. Split requirements into stories and put them on a backlog
3. Start first sprint with stories "create architecture" and "UI proposal"
4. During the sprint, discuss your proposals with the customer
5. Refine the backlog
6. As each sprint ends, pick the next top X stories from the backlog to implement.

Answer 2

The main advantage of SCRUM (and agile methods in general) is that you get better and quicker feedback (on implementations, not just specs) from the stakeholders, and thus there is less risk of working weeks and months on something that ends up being not what they wanted. Additionally, you often deliver the most useful features sooner (due to prioritization and the sprint release cycle).

If you all agree that you will benefit from these advantages, and if the stakeholders are willing to do their part (give more frequent feedback), then yes, you should to SCRUM (the second process you describe) instead of waterfall (the first process you describe has nothing to do with SCRUM).

Answer 3

It seems as you were falling back to old/known procedures. One key concept of SCRUM / agile development is that you don't have a big upfront specification. Of course you need to know about the whole view from the beginning, but you must not put every detail into specification. That is what leads to a waterfall process, which is bad because it is not flexible and changes or new insights are expensive.

When starting with Scrum, you should have an expert Scrum-Master - one who does that quite some time. If you don't have one in your team, you should hire one. At least for the first few sprints.

You also should have the support of your management (as you do), AND the support of your customer, because (s)he needs to provide the product owner. This last point (availability of the customer/product owner) is in my experience very often not the case. Agile still could make sense in those cases, because you can change direction more easily and you could get fast feedback to your work.

BTW: usually you don't specify how the UI should look like. This is an implicit requirement that stems from the feature description. Of course there will be a style-guide that covers all basic UI concepts, but you don't do special UI things for different features, unless this is the aim of the feature.