ADAPTing to SCRUM
Lori’s story encapsulates the five common activities necessary for a successful
and lasting Scrum adoption:
● Awareness that the current process is not delivering acceptable results
● Desire to adopt Scrum as a way to address current problems
● Ability to succeed with Scrum
● Promotion of Scrum through sharing experiences so that we remember
and others can see our successes
● Transfer of the implications of using Scrum throughout the company
Use metrics to see the current state of the company and 3 to 6 months after introducing SCRUM see the metrics than and if it has improved.
Run a pilot project with just part of the company to see the benefits SCRUM could give to your company.
Focus on the most important things that need to be changed from the current process like: long time of development (low productivity), bad quality of code, morale of the developers is low, lots of overtime working... and present how SCRUM can make those better.
Create a sense of urgency, put some deadline or a pressure until when things that are not functioning need to be changed and people might be more open to the better alternative then.
Build momentum by focusing more on the people who are open and willing to give SCRUM instead of wasting time and energy on those that are not open to it.
Just get people to give it a go for at least 3 months and then you can have them discuss it after they have given it a try and can understand it better in reality.
Let people grieve. Every change brings a grieve for the old "safe" way of running things. Even though company is transitioning to a new way of working, give people a chance to communicate what they are missing about the old system without saying how it was not so important. Just let them communicate it out. Do not make fun of the old system, because people identify with it still.
Ability
Starting a new process requires people also to learn something new.
Working in a agile way will make people need to learn some new technical skills or just do the same things in a different way, with less specification, without seeing the entire picture etc.
SCRUM requires that the people start really working as a team.
Provide training and coaching. When trying to introduce SCRUM to a new system you could start with organizing a 2 day presentation about SCRUM, followed by a hands on workshop and later being there for any open questions that will arise when adopting SCRUM.
If the company is large enough have people organize a whole day internal SCRUM conference.
Start doing SCRUM on only one feature for example.
After you have had success with one feature or with one team in the organization, promote those success stories as a motivation for Scrum.
or fears, people who use standard waterfall approach have are:
● Scrum teams don’t plan, so we’re unable to make commitments to
customers.
● Scrum requires everyone to be a generalist.
● Our team is spread around the world. Self-organization clashes with
some cultures, so we can’t be agile.
● Our team is spread around the world, and Scrum requires face-to-face
communication.
● Scrum ignores architecture, which would be disastrous for the type of
system we build.
● Scrum is OK for simple websites, but our system is too complicated.
Common thought of the people not willing to change is: “Better the devil you
know than the devil you don’t”
Lori’s story encapsulates the five common activities necessary for a successful
and lasting Scrum adoption:
● Awareness that the current process is not delivering acceptable results
● Desire to adopt Scrum as a way to address current problems
● Ability to succeed with Scrum
● Promotion of Scrum through sharing experiences so that we remember
and others can see our successes
● Transfer of the implications of using Scrum throughout the company
Use metrics to see the current state of the company and 3 to 6 months after introducing SCRUM see the metrics than and if it has improved.
Run a pilot project with just part of the company to see the benefits SCRUM could give to your company.
Focus on the most important things that need to be changed from the current process like: long time of development (low productivity), bad quality of code, morale of the developers is low, lots of overtime working... and present how SCRUM can make those better.
Create a sense of urgency, put some deadline or a pressure until when things that are not functioning need to be changed and people might be more open to the better alternative then.
Build momentum by focusing more on the people who are open and willing to give SCRUM instead of wasting time and energy on those that are not open to it.
Just get people to give it a go for at least 3 months and then you can have them discuss it after they have given it a try and can understand it better in reality.
Let people grieve. Every change brings a grieve for the old "safe" way of running things. Even though company is transitioning to a new way of working, give people a chance to communicate what they are missing about the old system without saying how it was not so important. Just let them communicate it out. Do not make fun of the old system, because people identify with it still.
Ability
Starting a new process requires people also to learn something new.
Working in a agile way will make people need to learn some new technical skills or just do the same things in a different way, with less specification, without seeing the entire picture etc.
SCRUM requires that the people start really working as a team.
Provide training and coaching. When trying to introduce SCRUM to a new system you could start with organizing a 2 day presentation about SCRUM, followed by a hands on workshop and later being there for any open questions that will arise when adopting SCRUM.
If the company is large enough have people organize a whole day internal SCRUM conference.
Start doing SCRUM on only one feature for example.
After you have had success with one feature or with one team in the organization, promote those success stories as a motivation for Scrum.
Agile Phobias
or fears, people who use standard waterfall approach have are:
● Scrum teams don’t plan, so we’re unable to make commitments to
customers.
● Scrum requires everyone to be a generalist.
● Our team is spread around the world. Self-organization clashes with
some cultures, so we can’t be agile.
● Our team is spread around the world, and Scrum requires face-to-face
communication.
● Scrum ignores architecture, which would be disastrous for the type of
system we build.
● Scrum is OK for simple websites, but our system is too complicated.
Common thought of the people not willing to change is: “Better the devil you
know than the devil you don’t”
