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):
- Production and approval of business case.
- Requirements analysis.
- Go live.
- Risk & Issue Management.
- 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?