Agile transformation (part 3) — convince others
As an agile advocate in the government, I get to meet many people to share insights, to be more agile. One of the most frequent requests that I received is to convince their colleagues, bosses, customers and other stakeholders to collaborate with them to adopt agile development.
Unfortunately, schedule does not allow me to accede to all requests. The next best thing is to share some effective techniques of persuasion that I find useful :)
I broadly categorise the audience into three categories. These categories are not mutually exclusive.
Perfectionist
Perfectionist is attached to the clarity (false sense of security) of waterfall. They like to think in binary — perfect plan vs. bad plan and they believe that most things can be perfectly planned in advance. They love to follow the plan and are often controlling in behaviour. They dislike minimal viable product (MVP) and disdain changes. They rather hide the MVP to prevent feedback from users — can’t handle the messy reality :)
What you can say or do
- Don’t let perfect be the enemy of good
- Working software in two weeks is better than almost perfect software, but not deliver.
- Changes are always expected. Blaming project failure because of changes is like blaming plane crash because of gravity. There are better ways to adapt to changes, just like <someone they know> who used agile to …
- Agile allows you to better control changes because of the transparency and frequent feedback. You get to prioritise the changes and decide which ones to do — there’s no need to do them all
- Share the story of FBI Sentinel project
Risk averse
These are the people who might not be perfectionist, rather very risk averse about new way of doing things. They want certainty and they fear words like experiment, try and see, fail fast.
What you can say or do
- In waterfall, you see the product at the end when it’s too late to do anything. Agile reduces risk because you get to see a working product increment every sprint.
- In waterfall, you have to sign off the entire requirement specs as if the requirements are complete and correct. In agile, you get to prioritise the product backlog and delay commitment until the last responsible moment.
- In agile, you get to conduct usability testing with real users, to make sure the product is user friendly before production release. There is no such opportunity in waterfall, yet you have to be responsible for many such uninformed decisions.
- In agile, quality is a first class citizen and baked into the process because you can’t be agile without automated testing. In waterfall, quality is often compromised because there’s not enough time to finish testing before release.
- You are not the first one. <Someone influential or they respect> successfully use agile to …
Laggard
They tend to be the last people to do anything and it is not because of risk aversion. They don’t care about the benefits of agile and neither the pitfalls of waterfall. They are usually apathetic about (most) things and prefer things to be business as usual — at least until they retire.
They are the hardest to influence because they are emotionally detached and disengaged from work.
What you can say or do
- Find out who can influence them — someone they respect or someone they can relate to or someone of higher authority in their organization.
- Send their influencers to the monthly agile sharing session and seek their help to influence the laggard.
- Wait it out. Chances are higher when agile transformation is driven from the top
If (s)he happens to be the top, try skunkworks to change your organization or change your organization. 😉
Hope you find this article valuable. Don’t forget to help others by recommending ❤ and sharing it.
Updates — Dec 2016
- If this article interests you, you might like to know more about our agile journey and challenges
- We are hiring. Find me if you want to know more! 😊
