"I work in a relatively conservative company, and often come to the point that in large projects Scrum teams and waterfall teams need to work together. This gives us many problems with coordination, the "change processes" and the cultures. I need some material so that I can work in the direction that we use only one PM framework in the same project. What other problems can we expect if we use different frameworks and what are the antidotes to them? I would be very happy if you give me some literature hints which could illuminate the problem "Scrum Waterfall Hybrid."
There are a lot of hurdles. The biggest challenge is the understanding of the common approach. The core of many project management processes is the assumption that the development takes place in the IT - and thus the exchange of a development process has no effect on anything around. Once this is understood by Business respectively Product Management and IT divisions, the next steps often result already from the premise of cooperation. Of course there are preliminary considerations of professional and technical nature. Of course one must first collect the gross requirements - for example create a vision, design a rough roadmap. But by that time at the latest the development belongs to the team. And from that point, the product management is not "left out". This is precisely the fundamental difference. So you can also revitalize the existent quality gates by thinking together about what you want to say at what time. Here there are three premises for you:
- An estimate over a certain delivery date always requires at least three sprints
- The requirements are never "finished", each Product Backlog Item is like a Change Request
- We want to minimize work that lies between development completion and putting into operation.
My colleagues have to deal with this problem for some time already. First of all I would name "New New Product Development Game" and the waterfall process itself. In the latter Winston Royce criticized the model itself - which seems to have been overlooked by many readers. Additionally I’ll give you some more articles which may help.
- The new new product development game
- Managing the development of large software systems
- Overcoming Waterfallacies and Agilephobias
Last but not least, pitfalls during the introduction of Scrum:
- Scrum in "parts" - we like to call it "ScrumBut" - Rowan Bunning / Kicking ScrumBut
- Do's and Don'ts - Problems and how to deal with them? - Bas Vodde / Top 10 Organizational Impediments
- Arguments in favor of Scrum? Felix Rüssel has a few good ideas for dealing with the management at the beginning of a Scrum implementation: Scrum für Schlipsträger (German)
The antidote to the problems that arise during the transition of the PM framework is called "collaboration". Make everyone smarter, evaluate, discuss, find a way which appears fairly reasonable - and improve yourselves together!
About the author
Andreas Schliep is a founding member and executive partner of DasScrumTeam. He is a Scrum coach and trainer. He studied at the technical university of Bremerhaven, and worked as a software developer, project manager, team lead and group lead. Andreas has worked with Scrum since 2003. He became a full-time Scrummer in 2006.
Since then, he has helped to introduce and improve Scrum and agile practices in numerous companies all over the world. His favorite topics are quality management and scaling.
- Experienced ScrumMaster, Product Owner, Coach and Trainer
- Introduced Scrum at WEB.DE
- Coaching of internationally distributed teams
- Transition from RUP to Scrum at UOL Brazil
- Scrum Trainings and Coaching in Germany, Switzerland and Austria
Always up to date with the DasScrumTeam newsletter.
The best in terms of Scrum. Once a month. Every month.