How do you implement Scrum in an organization where not everyone is a believer?
Umm. This is a common question and a hard one. And yet also easy.
First, one misconception is that Scrum is a religion that only true believers practice. Scrum is actually empirical. Now, it should be said that Scrum (and lean-agile-scrum) has ideas that are on the surface counter-intuitive, perhaps we might even call them paradoxical. Example: "You have to go slow to go fast."
(I hope you will smile to see the picture of the waterfall model true believer.)
But mainly, we want everyone practicing Scrum to do so out of free will, and with an appreciation that it can and will produce a better result. And, if, after giving it a fair trial, it does not produce a better result, then you should examine the root causes. It just might be that the root cause is that Scrum is 'wrong for us'. Scrum is empirical. We live with reality; we face the truth.
Let me be honest. I do think there are some people in a few of the Myers-Briggs categories who should not be doing Scrum. Because it has too much relative 'chaos' for their personality type....but indeed, for that personality type, there is in reality too much chaos in new product development in general. They also should not be doing new product development.
Still, for most people, if 'scrum' seems to fail, I have never been convinced that it was really Scrum that failed. Typically, at least in my opinion based on what I knew, they did not do it well enough, fully enough or professionally enough. So, it was not truly Scrum that failed. But I might be wrong; I certainly have a limited data set; I have not seen anything close to every Scrum implementation.
Next: Most people who start Scrum are not really all that familiar with lean-agile-scrum ideas when they start Scrum. So, we are asking them to willingly suspend disbelief for some trial period. They are welcome to remain skeptical in a sense, but should make every effort to give it a fair trial. And they will do it 'ugly', as any beginner will. What is quite remarkable, in fact very very remarkable, is that even after only three 2-week Sprints, the Scrum that the beginning team plays is already better than what they were doing before (which they had practiced and used for some years, typically). This is really extraordinary!
Let me emphasize this again, another way. Many of the ideas of lean-agile-scrum are counter-intuitive and for many people will appear to be 'wrong' in many common situations. It is only with experience that the ideas will start to be regularly obvious and intuitive. This is not because the ideas are wrong, but simply because our minds are so used to (wrongly) another paradigm of looking at our work.
Now, sometimes, especially if they feel forced to do Scrum, the team cannot help but sabotage it. They can indeed, in my opinion, make it fail.
So, before the trial project, we should make reasonable efforts to get them to a place where they can give it a fair trial. And feel somewhat comfortable doing so. (Change is always somewhat uncomfortable, so expecting every team to start with 'excitement' is not realistic.)
Some suggestions in this area:
1. Give them training. Example: A Scrum course.
2. Give them a workshop. Example: To do release planning and sprint planning as a team.
3. Give them coaching. Example: Coaching for 3 consecutive days at the beginning of the first Sprint. And then 3 more days at the end of the first Sprint and the beginning of the 2nd Sprint.
4. Talk to them about lean-agile-scrum principles, so they start to understand the music behind the Scrum dance steps. Reinforce this as they experience 'issues' in the real-world implementation of Scrum. ("Talk" can include books and articles.)
5. Do not expect that they will fully understand it immediately. (Did you fully understand baseball when you first started playing it?) Expect them to forget even some of the basics that you told them or they were taught. All lessons, for all humans, must be repeated. The best we can say for people good at change is that we need fewer repetitions of the basic lessons. And do not expect all your people to be good at change. (That does not mean that they will be bad team members....They are good at other things, just not good at change.)
6. Do not let them feel Scrum is the idea of one person. It is not owned by you. It is not 'owned' by one trainer. It is not just Jeff Sutherland's or Ken Schwaber's idea. Many, many, many people have contributed to the idea set. Many, many, many different teams have used it with success. In almost every conceivable environment.
7. Find out what they might propose instead of Scrum. If it is waterfall, help them to understand that even the key people who originally advocated waterfall (the US DOD and Dr. Royce, for example) no longer do so. (In the case of Dr, Royce, his son no longer advocates waterfall.)
8. There are lots and lots of techniques and an endless list of specific things you can do to influence people. See, for example, Fearless Change by Manns and Rising. The list is indeed endless; you never run out of more things you can do. You might exhaust you own patience to continue trying to change someone who seems completely unwilling to change.
9. Remember this famous adage: "People do not resist change. They resist being changed." One meaning: Be sure your 'target' does not feel you have to change him. He should feel as though you are helpfully, fairmindedly sharing ideas that might actually help him in his own life (as he values things in his life).
10. Remember to go with the flow. In Hapkido (martial arts), if the opponent resists going one way, then we use their counter-energy to flip them the other way. There is always a way you can use their energy against them. Assuming you are aligned with the source of energy and truth. Laughter is one of those paradoxically powerful forces.
Remain positive, realistic and undaunted. You are indeed helping the world be better; yet you know it will never be perfect. Be patient with those whose eagerness to change is less than yours. As Yogi Berra said: If the world were perfect, it wouldn't be.
Umm. This is a common question and a hard one. And yet also easy.
First, one misconception is that Scrum is a religion that only true believers practice. Scrum is actually empirical. Now, it should be said that Scrum (and lean-agile-scrum) has ideas that are on the surface counter-intuitive, perhaps we might even call them paradoxical. Example: "You have to go slow to go fast."
(I hope you will smile to see the picture of the waterfall model true believer.)
But mainly, we want everyone practicing Scrum to do so out of free will, and with an appreciation that it can and will produce a better result. And, if, after giving it a fair trial, it does not produce a better result, then you should examine the root causes. It just might be that the root cause is that Scrum is 'wrong for us'. Scrum is empirical. We live with reality; we face the truth.
Let me be honest. I do think there are some people in a few of the Myers-Briggs categories who should not be doing Scrum. Because it has too much relative 'chaos' for their personality type....but indeed, for that personality type, there is in reality too much chaos in new product development in general. They also should not be doing new product development.
Still, for most people, if 'scrum' seems to fail, I have never been convinced that it was really Scrum that failed. Typically, at least in my opinion based on what I knew, they did not do it well enough, fully enough or professionally enough. So, it was not truly Scrum that failed. But I might be wrong; I certainly have a limited data set; I have not seen anything close to every Scrum implementation.
Next: Most people who start Scrum are not really all that familiar with lean-agile-scrum ideas when they start Scrum. So, we are asking them to willingly suspend disbelief for some trial period. They are welcome to remain skeptical in a sense, but should make every effort to give it a fair trial. And they will do it 'ugly', as any beginner will. What is quite remarkable, in fact very very remarkable, is that even after only three 2-week Sprints, the Scrum that the beginning team plays is already better than what they were doing before (which they had practiced and used for some years, typically). This is really extraordinary!
Let me emphasize this again, another way. Many of the ideas of lean-agile-scrum are counter-intuitive and for many people will appear to be 'wrong' in many common situations. It is only with experience that the ideas will start to be regularly obvious and intuitive. This is not because the ideas are wrong, but simply because our minds are so used to (wrongly) another paradigm of looking at our work.
Now, sometimes, especially if they feel forced to do Scrum, the team cannot help but sabotage it. They can indeed, in my opinion, make it fail.
So, before the trial project, we should make reasonable efforts to get them to a place where they can give it a fair trial. And feel somewhat comfortable doing so. (Change is always somewhat uncomfortable, so expecting every team to start with 'excitement' is not realistic.)
Some suggestions in this area:
1. Give them training. Example: A Scrum course.
2. Give them a workshop. Example: To do release planning and sprint planning as a team.
3. Give them coaching. Example: Coaching for 3 consecutive days at the beginning of the first Sprint. And then 3 more days at the end of the first Sprint and the beginning of the 2nd Sprint.
4. Talk to them about lean-agile-scrum principles, so they start to understand the music behind the Scrum dance steps. Reinforce this as they experience 'issues' in the real-world implementation of Scrum. ("Talk" can include books and articles.)
5. Do not expect that they will fully understand it immediately. (Did you fully understand baseball when you first started playing it?) Expect them to forget even some of the basics that you told them or they were taught. All lessons, for all humans, must be repeated. The best we can say for people good at change is that we need fewer repetitions of the basic lessons. And do not expect all your people to be good at change. (That does not mean that they will be bad team members....They are good at other things, just not good at change.)
6. Do not let them feel Scrum is the idea of one person. It is not owned by you. It is not 'owned' by one trainer. It is not just Jeff Sutherland's or Ken Schwaber's idea. Many, many, many people have contributed to the idea set. Many, many, many different teams have used it with success. In almost every conceivable environment.
7. Find out what they might propose instead of Scrum. If it is waterfall, help them to understand that even the key people who originally advocated waterfall (the US DOD and Dr. Royce, for example) no longer do so. (In the case of Dr, Royce, his son no longer advocates waterfall.)
8. There are lots and lots of techniques and an endless list of specific things you can do to influence people. See, for example, Fearless Change by Manns and Rising. The list is indeed endless; you never run out of more things you can do. You might exhaust you own patience to continue trying to change someone who seems completely unwilling to change.
9. Remember this famous adage: "People do not resist change. They resist being changed." One meaning: Be sure your 'target' does not feel you have to change him. He should feel as though you are helpfully, fairmindedly sharing ideas that might actually help him in his own life (as he values things in his life).
10. Remember to go with the flow. In Hapkido (martial arts), if the opponent resists going one way, then we use their counter-energy to flip them the other way. There is always a way you can use their energy against them. Assuming you are aligned with the source of energy and truth. Laughter is one of those paradoxically powerful forces.
Remain positive, realistic and undaunted. You are indeed helping the world be better; yet you know it will never be perfect. Be patient with those whose eagerness to change is less than yours. As Yogi Berra said: If the world were perfect, it wouldn't be.
2 comments:
From my experience Scrum completely sucks. It has slowed us down, we push less code and it has sucked the creativity out of a once creative team.
We work on tickets. Thats it. If you are considering implementing scrum consider the cost of reduced inovation.
Hi Anon,
I am very sorry to hear that your Team was not creative.
Why do you think Scrum is at fault?
I can well imagine that things people did help box the Team in. But I am doubtful it is fair to blame it on Scrum.
I do think that part of Agile (see the Agile Manifesto and Principles) is for Business and Technology to work together daily. I am doubtful that just working on tickets, that alone, will enable the highest possible business value for the customer.
Now, I am a big fan of Kanban when combined with the other feedback loops of Scrum. And sometimes Kanban is all you can do. But no good Lean shop would just do Kanban.
I like your values. Being a human being and being creative are very important.
It is the purpose of Scrum to bring those out more.
If you want to talk more about what happened in your case, please do so.
Thanks, Joe
Post a Comment