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.)
Here are some factors that might tilt a project 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. And 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 in a skeptical a mood about Scrum, they start to make it fail.
2. Will someone help with the Impediments? The more this is positive, the more you choose this work.
3. Good product owner. If for one project you can get a good PO available 80%, and for another the PO is weaker and available 40% -- choose #1.
4. Reasonable stability of work in the Scrum. If project 1 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.
You want the Team to commit to work in 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 of that.
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.
Now, sometimes you have to anyway.
6. The skill sets 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.
And we want it work things can be done more 'all at once'. For example, we don't feel that we must finish all of A before we can do any of B.
7. More likely to change.
I will use that phrase, but let me explain. Project 1 is more likely to change.
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. 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. And there was plenty of change and learning. So, watch out for the accuracy of your initial assumptions. You know about how the word 'assume' works.
***
I think those are the major factors. I may have left out one or two. Probably I will revise this post after a few comments.
Here are some factors that might tilt a project 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. And 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 in a skeptical a mood about Scrum, they start to make it fail.
2. Will someone help with the Impediments? The more this is positive, the more you choose this work.
3. Good product owner. If for one project you can get a good PO available 80%, and for another the PO is weaker and available 40% -- choose #1.
4. Reasonable stability of work in the Scrum. If project 1 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.
You want the Team to commit to work in 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 of that.
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.
Now, sometimes you have to anyway.
6. The skill sets 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.
And we want it work things can be done more 'all at once'. For example, we don't feel that we must finish all of A before we can do any of B.
7. More likely to change.
I will use that phrase, but let me explain. Project 1 is more likely to change.
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. 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. And there was plenty of change and learning. So, watch out for the accuracy of your initial assumptions. You know about how the word 'assume' works.
***
I think those are the major factors. I may have left out one or two. Probably I will revise this post after a few comments.
No comments:
Post a Comment