What phases of a traditional waterfall project should Scrum replace?

Question

My team and I are using Scrum to manage software development projects. In my company there has been a move towards more structure in all IT projects using a waterfall methodology. This is fine by me as there are lots of non-software-development projects which will benefit greatly from this and it is not threatening our use of Scrum.

However, we need to work out how our Scrum processes (which do a great job of taking a Product Owner's requirements and turn them into working software) fit into the broader project process.

Our new waterfall project process includes explicit activities for the following things (not necessarily sequentially and not necessarily in this order):

1. Production and approval of business case.
2. Resourcing.
3. Requirements analysis.
4. Design.
5. Build.
6. Test.
7. Training.
8. Communications.
9. Go live.
10. Risk & Issue Management.
11. Benefits realisation.

Bear in mind that a project may be required to deliver more than just software. It may also include server infrastructure to host the software and network / desktop infrastructure to make it available to users.

I think Scrum will manage 3, 4, 5 & 6 happily but probably only for teams who find it adds value, which is probably only software development...

We could get other teams to use it for the production of infrastructure deliverables, but they don't see the need or benefit and nor do I (Scrum is good for large, risky projects and they are building a bunch of standard PCs).

Likewise we could have a User Story in the Product Backlog for the Project Manager (not typically a member of the Scrum Team) to produce a benefits realisation plan.

Are we approaching this correctly? Is there a better way to integrate these two styles of working or are they exclusive and we should use one or the other?

Answer 1

Scrum is a complete project management methodology that addresses all aspects of the project lifecycle. Unlike projects managed using a sequential process where things generally happen once and then are revisited if necessary as the project progresses, Scrum embraces a more iterative approach - everything is addressed during each iteration.

Of the list of things you identified, the only one that may happen up-front, at the start of the project is the creation of the business case. Some kind of purpose, vision, and scope is likely to be established once, and then only revisited as necessary. Everything else happens in every iteration, with the Scrum Master typically being responsible for ensuring the project has sufficient resources, facilitating communication between internal entities, and managing project risks. The requirements are provided and prioritized through the Product Owner, and the team is responsible for estimating the amount of work required to realize each requirement and then continually refine the design, implementation, test, and documentation work products throughout the project. Every iteration, in theory, results in a product that is ready to be deployed to a customer (a "potentially shippable product").

The process by itself doesn't typically address exactly how training and "go live" or deployment activities happen. Obviously, if your development team is responsible for supporting any of these activities, you'll want to build time for them into each iteration and keep those in mind when you're doing your sprint planning activities. If they are handled by a different team, there's nothing that says they must use Scrum. They should, however, expect a working product that contains new features and/or bug fixes on a regular basis (at the end of every timeboxed iteration), but if they do anything with that working product is up to them.

It might not be appropriate for every project to use the same lifecycle, especially if it doesn't add value or if it would be too difficult or time consuming to transition from their current processes to something new and different. As an example, your team that produces and maintains the infrastructure might not be able to produce all of the hardware within a single software development iteration. You need to plan your new deployments based on the activities - you can't deploy hardware that's not done, nor can you ship incomplete software.

If software development will benefit from using an iterative and incremental methodology, there's nothing wrong with them using it even if everyone else is still using a sequential methodology. As long, of course, as it doesn't negatively impact business - are you still releasing high quality software that adds value to the customer on time, on budget? Are your processes clashing in such a way that leads to people being idle? Consider those, and minimize downtime while maximizing value delivered to your customers.