At first, when Scrum and when Waterfall?
When your company is first starting Scrum, how do you decide which projects use Scrum and which ones do it ‘the old way’? (Let’s assume the old way is a form of waterfall. You are waiting to transition them from waterfall, later.) Assuming for now (for a transition period) some projects must remain in waterfall.
So, here are some factors that might tilt a project more toward Scrum:
1. Is the Team willing to try Scrum? The more positive they are toward Scrum, the better. At first it will be new, bumpy. You want a Team willing to work through the bumps to get to some success.
In part, you need a little success in your company to get the more skeptical types to feel comfortable using Scrum.
If the Team starts to be skeptical about Scrum, they may start to make it fail.
2. Will someone help with the Impediments? The more this is positive, the better to choose this work.
3. Good product owner. If you can get a good PO available 80% for Proj#1, and for Proj#2 the PO is weaker and available 40% — choose #1.
4. Reasonable stability of work during the Sprint. If in project 1 ‘they’ will not want to change the work during the Sprint much, and project 2 needs the work more often to change in the Sprint, then choose 1. But this is reason #4.
Allowing some work to change in the Sprint is more advanced: both for the Team and for the broader organization. Avoid it at first.
You want the Team to commit to work in the Sprint Planning Meeting, and start to see the positive momentum of completing it by the end of the Sprint. Fewer changes (zero is even better) increase the chances.
5. Do-able project. It is fine to give a new Scrum Team a challenging project. But do not give them an ‘impossible’ project the first time out. Simply because they are just learning Scrum.
Sometimes you have to anyway.
6. The skill sets within the people on the Team are more fungible. Fungible is a fancy financial term. It means that person A is more likely to be able to do (some of) person B’s work.
We want that with Scrum.
Also we want situations where things can be done more ‘all at once’. For example, we don’t feel that we must finish all of M work before we can do any of N work. We can mix M and N work in the same sprint.
7. More likely to change.
I will use that phrase, but let me explain. Project 1 is more likely to change, meaning that we are likely to have more discovery around the features to deliver for project 1. Project 2 will have less change. And project 2 is a project that we feel confident we know how to do. Many of the people in the team feel they have done similar projects like project 2. And we have high confidence that project 2 will have few major surprises.
In that case, I think Scrum will help project 1 more. Because Scrum will enable the Team to learn faster and adapt faster. For project 2, at least now, it appears that learning and adapting will not have as much value.
Still, I find it hard to say this. I have had too many projects that seemed ‘stable’ at the beginning, and yet when we got into it, all hell broke loose. There was plenty of change and learning. So, watch out for the accuracy of your initial assumptions. You know how the word ‘assume’ works.
I think those are the major factors. I may have left out one or two. I will probably revise this post after a few comments.