Question from Denise: My organization has decided to go from
Waterfall to Agile SCRUM. I have experience with SCRUM, but very little
experience implementing it. I was wondering if anybody has this
experience? If so, what were some of the challenges you faced? Lessons
learned? Best practices?
Answer: This is a big question. And no one can answer if fully for you. Whole books have been written on this subject and no two 'experts' fully agree. (I guess I am one of those experts.)
Some basics.
1. It usually starts with one person, driving the idea. I strongly recommend that, whoever is the initial 'agile evangelist', that he or she gather others in support. John Kotter says establishing a Sense of Urgency, in the right people, for the change is essential.
2. Start a pilot. Get one team going. Use it to help you (maybe you personally, or the generic 'you')....to help you identify how it will work at your place. Each place is unique. Each place will have different priority issues. Reality teaches us best what the biggest issues are. Crystal balls do not work as well.
3. Get some good training. (I am a CST Scrum Trainer. Smile. Yet actually all the people who do it well suggest this.) Train 'everyone'. What does that mean? Well, if you have 50 people, I might train 15-20 when I got the first team started. Train some people around that first Team. Some of those 'around' people should include managers.
4. Help the managers adjust. It is new and different for them. And often, some think they understand, but really they all need some help.
5. Get some coaching. Teams get started better with a coach. It seems expensive -- it really is cheap.
6. Identify and drive impediment removal. This is key. Lots to say in this area.
7. Get the Business side engaged. Or, start working on getting them engaged better. Often Scrum starts as an IT or technology initiative, but really it is better for all if it is a business initiative.
8. Make the PO better. Usually, the weakest person is the PO. Not because George was not good at his last job. But because the PO role is a different role than George has ever tried to do. He will naturally misunderstand it, and not dedicate enough to it. Unless....well, usually, unless the SM and the Agile Coach work on him, and make him (or her) better.
9. Get ready to live and learn.
10. Dan Mezick has a new book, called Open Agile Adoption Handbook. The idea is to get 'everyone' to want to volunteer to help implement agile (Scrum). Here is Little's Second Law: "People are remarkably good at doing what they want to do." The book may seem weird to you at first, or it might not work at your place. If you look at it, I will be happy to explain more.
Get your first team going. And use that to drive more change.
***
Now, tell us your situation more, in more detail. What is your role? How big is the group? What does your 'dev' group do? What is your industry? Who in your organization 'has decided'? How much scaling is there? (By scaling, I only mean '3 to 7 teams working together on the same product'.) Tell us any other big issues in your situation. (Each situation is different.)
That may help us give you more advice.
This is key: It will be hard. It will be fun. You will learn a lot. You can succeed. And it will be worth it.
And there is no silver bullet. Some of the best agile people ever can run into situations that 'will not work'. Even then, you will learn a lot.
But after a while, if it seems impossible, it might be impossible. And you might do better to climb another mountain.(Still, don't give up climbing mountains. It's fun!)
Hope that helps some....
***
There might be some Top 10 things I forgot. But more likely, there are other things to discuss, but they do not deserve the same attention and priority. Example: Which Scrum tool to use. Important, yes. But not in the top 10, not worry the same energy and time, in my opinion.
Answer: This is a big question. And no one can answer if fully for you. Whole books have been written on this subject and no two 'experts' fully agree. (I guess I am one of those experts.)
Some basics.
1. It usually starts with one person, driving the idea. I strongly recommend that, whoever is the initial 'agile evangelist', that he or she gather others in support. John Kotter says establishing a Sense of Urgency, in the right people, for the change is essential.
2. Start a pilot. Get one team going. Use it to help you (maybe you personally, or the generic 'you')....to help you identify how it will work at your place. Each place is unique. Each place will have different priority issues. Reality teaches us best what the biggest issues are. Crystal balls do not work as well.
3. Get some good training. (I am a CST Scrum Trainer. Smile. Yet actually all the people who do it well suggest this.) Train 'everyone'. What does that mean? Well, if you have 50 people, I might train 15-20 when I got the first team started. Train some people around that first Team. Some of those 'around' people should include managers.
4. Help the managers adjust. It is new and different for them. And often, some think they understand, but really they all need some help.
5. Get some coaching. Teams get started better with a coach. It seems expensive -- it really is cheap.
6. Identify and drive impediment removal. This is key. Lots to say in this area.
7. Get the Business side engaged. Or, start working on getting them engaged better. Often Scrum starts as an IT or technology initiative, but really it is better for all if it is a business initiative.
8. Make the PO better. Usually, the weakest person is the PO. Not because George was not good at his last job. But because the PO role is a different role than George has ever tried to do. He will naturally misunderstand it, and not dedicate enough to it. Unless....well, usually, unless the SM and the Agile Coach work on him, and make him (or her) better.
9. Get ready to live and learn.
10. Dan Mezick has a new book, called Open Agile Adoption Handbook. The idea is to get 'everyone' to want to volunteer to help implement agile (Scrum). Here is Little's Second Law: "People are remarkably good at doing what they want to do." The book may seem weird to you at first, or it might not work at your place. If you look at it, I will be happy to explain more.
Get your first team going. And use that to drive more change.
***
Now, tell us your situation more, in more detail. What is your role? How big is the group? What does your 'dev' group do? What is your industry? Who in your organization 'has decided'? How much scaling is there? (By scaling, I only mean '3 to 7 teams working together on the same product'.) Tell us any other big issues in your situation. (Each situation is different.)
That may help us give you more advice.
This is key: It will be hard. It will be fun. You will learn a lot. You can succeed. And it will be worth it.
And there is no silver bullet. Some of the best agile people ever can run into situations that 'will not work'. Even then, you will learn a lot.
But after a while, if it seems impossible, it might be impossible. And you might do better to climb another mountain.(Still, don't give up climbing mountains. It's fun!)
Hope that helps some....
***
There might be some Top 10 things I forgot. But more likely, there are other things to discuss, but they do not deserve the same attention and priority. Example: Which Scrum tool to use. Important, yes. But not in the top 10, not worry the same energy and time, in my opinion.
No comments:
Post a Comment