The real question sent to me was: What are some tips for integrating our SCRUM model with non-Scrum groups who will not be adopting the process?
One can go many places with this question, and there could be other questions within this questions.
For now, let me answer two questions.
1. In general the culture and the management systems (eg, metrics) is used to waterfall. With a Scrum team(s), what should we do about this?
The finding is that this will remain a small-ish and firm and increasingly annoying impediment until you fix it.
Fixing it entails, ultimately, changing the whole company culture in a pretty significant way. Which, for a large company, takes a long time. Sometimes, you can select out a major group within the larger company, and just change that culture.
Doing this is hard work and takes time. It must be balanced against fixing more immediate and pressing impediments now.
How to do it?
Gather a small group of change agents. Regularly. Identify the changes you want to put into effect...how you want to go about changing the culture, at least in some ways.
Fearless Change by Manns & Rising and A Sense of Urgency by Kotter are two places to get ideas about how to effect the change.
For metrics, I would initially get the Scrum teams exempted as pilot efforts. Then I would suggest that the basic Scrum metrics (velocity, Sprint burndown, Release burndown, etc, etc) be used in place of the old metrics. You will win some of these discussions and lose others. Typically, this means the team must do "extra" metrics, typically for no good reason except that "they are there." Make clear the extra cost to the team in doing the extra metrics. Over time, you will likely win more and more of these discussions as people become less afraid of the Scrum teams.
2. A Scrum team must work with other groups that are used to waterfall. What should we do about this?
The main advice is: use common sense and do just barely enough to make it work.
In general, different people will react differently to an agile-scrum team. So, your response will depend in part on how the other people react and perform.
In simple terms, there are two situations:
(a) they provide deliverables to the Scrum team, which affects what we can deliver or complete.
(b) we provide deliverables to them (which affects them and our reputation).
First, prioritize the groups the Scrum team is working with. Put the most 'work' in on the team that is most important (obvious as soon as I say it).
Second, are there any personal relationships we can leverage, such as, Team Member John is a friend of George (who is in Dept 1)?
Often, John can visit George, and discuss agile-scrum a bit. (And maybe take the time to discuss Scrum over lunch with George's manager too.) This reassures George.
Then John should ask George "I know this Scrum stuff sounds a bit weird and is certainly different than what you are used to, but can you help us out?" And often George will do it, especially if we/John make things a bit easier for George. ("I'll scratch your back, if you scratch mine.") It's all part of the unofficial 'pizza & beer network' that many of you know well.
Sometimes this is enough.
Third, let's imagine that George's boss hears that George is "being easy" on the Scrum team and orders him to "be tough, demand that those guys fill out all the usual waterfall forms each time! And abide strictly by the rules!". And let's assume we know that this is a silly bureaucratic waste (mostly).
The next step is to have a high-level "Impediment Removal Team" (IRT) that hears about all the top impediments from all the Scrum teams. Assuming this impediment (George's boss) is important and we are sure we are right to complain, then the Scrum team sends this impediment to the IRT. A person from the IRT (a senior level person) goes to talk sense to George's boss. If done right, surprisingly George becomes more cooperative with our Scrum team in a few days.
Sometimes this is enough.
Sometimes the problem is not George's boss, but only that George has 15 things in the air, and we are not that important to him, so his performance for our team is not reliable. In that case, we can set up a special board (in the team room or virtual team room) and John or someone else in the Scrum team can 'manage' George, eg, visit him often, send him ticklers, go to his boss, help George fix his own impediments, etc, etc.
Sometimes George is so key to the Scrum team for a Sprint or two, that we have him come to the Daily Scrum every day to report on his progress. Sometimes we have somewhat formal 'weekly' meetings with George.
The main thing is: we add to 'Scrum' just enough other stuff to make things work with George and Dept 1. We try to ignore or minimize the stupid stuff as much as possible, and get as much value from Dept 1 with as little effort as possible. Sometimes we just accept some degree of 'stupid stuff' from Dept 1 for a while....but only for a while.
Again, each department or group will be different. Some of things we do for Dept 1 might be overkill for Dept 2. So, we adjust our response for each department and each "George". Based on our team's need and who they are. So, the way we work with Dept 3 will be different than how we worked with both Dept 1 and Dept 2.
Sometimes a 'serious' issue comes up. Be ready to explain Scrum, explain how it is less risky than other approaches, and why it does not need to comply (completely) with the usual BS bureaucratic stuff that we have always been doing. But learn to say this in a nice, non-confrontational way. That sounds (and is) supportive of the main business drivers in your firm ("we have to have faster time to market", "we must reduce costs", or others). But be reasonable. Bend 'em but don't break 'em. Remember that changing organizations takes time, and much of it is based on goodwill. So, increase your capital of goodwill and spend it judiciously.
Changing an organization takes time. Keep plugging, but have reasonable expectations. You don't have to win every battle in the first minute. Be adaptive.
One can go many places with this question, and there could be other questions within this questions.
For now, let me answer two questions.
1. In general the culture and the management systems (eg, metrics) is used to waterfall. With a Scrum team(s), what should we do about this?
The finding is that this will remain a small-ish and firm and increasingly annoying impediment until you fix it.
Fixing it entails, ultimately, changing the whole company culture in a pretty significant way. Which, for a large company, takes a long time. Sometimes, you can select out a major group within the larger company, and just change that culture.
Doing this is hard work and takes time. It must be balanced against fixing more immediate and pressing impediments now.
How to do it?
Gather a small group of change agents. Regularly. Identify the changes you want to put into effect...how you want to go about changing the culture, at least in some ways.
Fearless Change by Manns & Rising and A Sense of Urgency by Kotter are two places to get ideas about how to effect the change.
For metrics, I would initially get the Scrum teams exempted as pilot efforts. Then I would suggest that the basic Scrum metrics (velocity, Sprint burndown, Release burndown, etc, etc) be used in place of the old metrics. You will win some of these discussions and lose others. Typically, this means the team must do "extra" metrics, typically for no good reason except that "they are there." Make clear the extra cost to the team in doing the extra metrics. Over time, you will likely win more and more of these discussions as people become less afraid of the Scrum teams.
2. A Scrum team must work with other groups that are used to waterfall. What should we do about this?
The main advice is: use common sense and do just barely enough to make it work.
In general, different people will react differently to an agile-scrum team. So, your response will depend in part on how the other people react and perform.
In simple terms, there are two situations:
(a) they provide deliverables to the Scrum team, which affects what we can deliver or complete.
(b) we provide deliverables to them (which affects them and our reputation).
First, prioritize the groups the Scrum team is working with. Put the most 'work' in on the team that is most important (obvious as soon as I say it).
Second, are there any personal relationships we can leverage, such as, Team Member John is a friend of George (who is in Dept 1)?
Often, John can visit George, and discuss agile-scrum a bit. (And maybe take the time to discuss Scrum over lunch with George's manager too.) This reassures George.
Then John should ask George "I know this Scrum stuff sounds a bit weird and is certainly different than what you are used to, but can you help us out?" And often George will do it, especially if we/John make things a bit easier for George. ("I'll scratch your back, if you scratch mine.") It's all part of the unofficial 'pizza & beer network' that many of you know well.
Sometimes this is enough.
Third, let's imagine that George's boss hears that George is "being easy" on the Scrum team and orders him to "be tough, demand that those guys fill out all the usual waterfall forms each time! And abide strictly by the rules!". And let's assume we know that this is a silly bureaucratic waste (mostly).
The next step is to have a high-level "Impediment Removal Team" (IRT) that hears about all the top impediments from all the Scrum teams. Assuming this impediment (George's boss) is important and we are sure we are right to complain, then the Scrum team sends this impediment to the IRT. A person from the IRT (a senior level person) goes to talk sense to George's boss. If done right, surprisingly George becomes more cooperative with our Scrum team in a few days.
Sometimes this is enough.
Sometimes the problem is not George's boss, but only that George has 15 things in the air, and we are not that important to him, so his performance for our team is not reliable. In that case, we can set up a special board (in the team room or virtual team room) and John or someone else in the Scrum team can 'manage' George, eg, visit him often, send him ticklers, go to his boss, help George fix his own impediments, etc, etc.
Sometimes George is so key to the Scrum team for a Sprint or two, that we have him come to the Daily Scrum every day to report on his progress. Sometimes we have somewhat formal 'weekly' meetings with George.
The main thing is: we add to 'Scrum' just enough other stuff to make things work with George and Dept 1. We try to ignore or minimize the stupid stuff as much as possible, and get as much value from Dept 1 with as little effort as possible. Sometimes we just accept some degree of 'stupid stuff' from Dept 1 for a while....but only for a while.
Again, each department or group will be different. Some of things we do for Dept 1 might be overkill for Dept 2. So, we adjust our response for each department and each "George". Based on our team's need and who they are. So, the way we work with Dept 3 will be different than how we worked with both Dept 1 and Dept 2.
Sometimes a 'serious' issue comes up. Be ready to explain Scrum, explain how it is less risky than other approaches, and why it does not need to comply (completely) with the usual BS bureaucratic stuff that we have always been doing. But learn to say this in a nice, non-confrontational way. That sounds (and is) supportive of the main business drivers in your firm ("we have to have faster time to market", "we must reduce costs", or others). But be reasonable. Bend 'em but don't break 'em. Remember that changing organizations takes time, and much of it is based on goodwill. So, increase your capital of goodwill and spend it judiciously.
Changing an organization takes time. Keep plugging, but have reasonable expectations. You don't have to win every battle in the first minute. Be adaptive.
No comments:
Post a Comment