Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
you may be interested in the term waterscrumfall, its a name given to the idea of using scrum for the software parts of a larger waterfall process. –  Ryathal Jan 9 '13 at 14:08
Why do you say "Our new waterfall project process includes explicit activities for the following things (not necessarily sequentially and not necessarily in this order)"? Your statement is confusing to me because the essence of waterfall is that steps are completed sequentially in a specific order. –  Aaron Kurtzhals Jan 9 '13 at 15:41
@Ryathal - thanks. A quick Google has brought up some interesting reading. –  Nick Jan 9 '13 at 15:56
@AaronKurtzhals - by that statement I only meant that I haven't taken the time to list them specifically in the order in which they occur, not that it isn't a waterfall methodology. Also, things like Risk & Issue Management happen throughout a waterfall project, not just as a single step between two others. –  Nick Jan 9 '13 at 16:06
add comment

1 Answer

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.

share|improve this answer
Are you suggesting having one Product Backlog for all the different teams (server, software, network, desktop, training, project management, communications etc.)? That would be pretty hard to manage. Also, as no one could be expected to be multi-skilled across all those disciplines, each team would end up as a Component Team, which I understood were to be avoided. Alternatively would you recommend a number of Product Backlogs, one for each product? –  Nick Jan 9 '13 at 18:54
@Nick Every team using Scrum would break their requirements down into an appropriate granularity and use sprint backlogs of stories. Teams not using Scrum might handle their task assignments according to some other process. You might have a team for each component, but things like "project management" and "communications" aren't components - they are activities. You would have a team that writes and tests software. Another team that assembles the physical hardware. Another to maintain infrastructure. Each would have its own process. –  Thomas Owens Jan 9 '13 at 19:00
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.