What techniques are effective for Scrum teams within organizations that do waterfall release planning?

Question

What planning and prioritization techniques are effective for Scrum teams and Product Owners working within an IT organization that uses waterfall planning behaviors at the release level? Are there ways to optimize the Scrum team's experience or otherwise buffer the team from the ensuring challenges?

Answer 1

One of tricks I use in agile teams which are working with old-school highly-formalized teams is mapping. The team should map basically every client's responsibility to some team member. It usually goes to project manager as it is the person who is closest to a client.

Then it is about "building the bridges" - effort aimed at translating whatever client said or wanted to the language and process understandable by the development team. In other words it means translating agile inside to formalized process outside.

It doesn't mean there are specific prioritization techniques PM should use. Actually agile techniques don't really tell you how you should prioritize features - they deal more with reacting for planned features. However it's definitely worth the effort to ask the customer to prioritize the list of features so you all know what to cut when times goes harsh.

UPDATE (basing on comment): An example: we have a couple of teams working internally on the same project for the client who has pretty formalized approach to project management. One of teams (team A) prefers to work agile way and introduces Scrum as their method of choice, while another (team B) prefers to work with the old waterfall-like method. The release planning, we want it or not will follow waterfall-like method. I assume project scope can be split among those teams as they work to some point independently. Now we have a few channels of interactions:

• Team B with the client. In this case it is simple. Both, client and team follow similar process so the team probably just adjusts to the specific schedule proposed by the client.

• Team A with the client. That's where it starts to be different. Client doesn't really care about iterative development, but team works that way. The problem is the team expects feedback from the client on each release. And that's where PM should kick in with their "building the bridges" effort. It's PM who should emulate the client with such tasks, so PM should actually learn, check, verify, etc. what the client really wants and share the feedback with the team. However, generally the scope won't be changing much, as it is BDUF project and the client believes everything was in specs.

• Team A with Team B. This is another tricky one, but since both teams are in the same organization a few approaches may be tried. One is the same as between the Team A and the client -- "building bridges" which means that someone, probably the leader of Team A is translating agile approach to formal one used by another team back and forth. Another idea is to let collaboration happen spontaneously, considering the fact everyone works in the same company. Finally, teams can choose they keep their methods but whenever they need something from others they do respect how others work, e.g. when Team B wants some changes in API built by Team A, they respect that Team A don't make changes in the middle of sprint so they will implemented in another one.

Answer 2

What planning and prioritization techniques are effective for Scrum teams and Product Owners working within an IT organization that uses waterfall planning behaviors at the release level?

If I'm understanding correctly, your situation is similar to mine - i.e., we work in organizations where SDLC/ Waterfall is the norm, but there's been a recent push towards agile in isolated pockets of the company. Even so, we run into road blocks of sorts when it comes time for the code to hit the production environment, because the Release team hasnt embraced the Agile methodology.

In these situations, as pawel mentioned, you can usually get the product owner to prioritize a list of 'stories' that define the release steps for a product. Its ideal to be able to work as an isolated team, but sometimes the red tape doesnt let you deploy code as a stand-alone release.

Depending on how much sway you have over the deployment process, the worst case scenario is that we can continue to develop via Agile in the QA / Beta environments and respond to real changes on this platform. When the official release date comes, all the stories can be deployed into the live environment.

Admittedly, this sort of defeats the purpose of 'Agile', especially if you're working on a product thats already available to the public. Another alternative might be to restrict the product release to a select group of users.

To be honest, I'm grappling with this issue myself, and would love to hear what others have to say as well.

Answer 3

We keep the releases very small -- to 3 months or less. This gives us a reasonable shot at creating a groomed backlog to represent the scope of the release. We actually use a Kanban process to flow the feature requests through research, specification, discussion, review, and approval status while keeping WIP under control. This isn't an ideal mix, but is (for the time being at least) a reasonable compromise between our company's Waterfall and Agile camps.