How do you convince an organization to use Scrum or another agile practice and really adopt it?
I asked this question to three Project Managers experienced with agile practices and traditional approaches.
Jesse Fewell, JesseFewell.com
“PMI CEO Greg Balestrero has been talking a lot lately about moving the Project Management field away from performance-to-plan and toward value-delivery. Often the key barriers are stereotypes about Agile (“renegades who do what they want”) and Lean (“doing the same amount of work with fewer resources”).
In the end, every organization wants to “deliver value early and deliver value often”, and that is what Agile is all about. As a result, you find many organizations quickly sign on to experiment with Agile.
The difficulty comes when Agile starts to create transparency and accountability. Most organizations are not used to that, and will go through many “growing pains” that will either slow down or completely stop an Agile adoption effort. For example, the modern Project Manager is called upon to fill many roles at once, which masks a lot of confused responsibilities in the organization.
When the Project Manager starts pushing more decisions onto the sponsor, and more accountability onto the project team, things can get awkward and frustrating. But you have to go through that discomfort in order to grow. “No pain, no gain”.
Convincing organizations to “Go Agile” is not so hard. The greatest difficulty is convincing organizations to “stay Agile.”
Craig Brown, BetterProjects.net
“Project managers can’t convince an organization or senior management to adopt Scrum.
The owners of the project have to want to change. Project managers can simply provide Scrum as an option. Someone needs to have an urgent and important problem that they both see intellectually and feel emotionally.
IT managers and project managers are much more likely to feel the pain and seek help via agile methods than operations project managers or non-IT executives. The IT folk are at the end of the delivery chain and so when things go wrong at any stage of a project it is usually discovered at the IT delivery end.
If you are dealing with IT manager only, you’ll find kindred spirits who want to throw off the shackles of dysfunctional process.
If on the other hand you are dealing with people who don’t usually work on projects, or people who only deal with the front end of projects (initiation, requirement specification, and maybe design) then you’ll have a harder time convincing them of the need for change. They aren’t feeling the pain.
Recently I read a paper by a project manager who implemented scrum at a Queensland government department. It is here (PDF); (discovered here).
You’d think senior execs would want a change, but their business isn’t IT and they have process experts and auditors who are used to working a particular way. Convincing them to change is possible, but you have to be the right person with the right levels of trust and so on.”
Bob Tarne, Zen-Pm.blogspot.com
“I think each organization is different and therefore there could be different reasons for why organizations should adopt Scrum/agile. In the situations I’ve been in the biggest benefit for adopting agile is to increase the speed of delivery. I’ve worked with organizations that get to caught up in analysis/design.
They try to get answers that aren’t available yet and build the system around that, finding that they need to go back and make changes, which slows things down. Since change is inevitable, you need to spend less time trying to lock down the design up front and build your process to quickly identify and accept the changes.”
Image by Army.mil.
Esther Derby gave me this tip on twitter:
“@projectshrink also see The Business Case for Agility from SIQ CEO John Rudd http://tinyurl.com/nlk72p”
- interesting stuff.
Bas, great question and I loved the answers you got back. Let me throw a reason larger organizations and in particularly the Government resists this kind of movement; frequently using the renegade argument.
Large organizations worry about compliance; they have enterprise architecture, legal, auditing, security, etc. stakeholders they have to make happy and in some cases these stakeholders actually displace the customers of the systems being built in their importance. It has taken forever for organizations to figure out how to comply: how to do EVM, how to show they have an enterprise architecture, how to develop the documents that get the system accredited, etc.. To figure out how to do this stuff for yet another approach is unfathomably hard, since they can’t keep up with the changes these stakeholders have now, how will they do it supporting a different approach.
In reality, Agile would actually make this much easier to both accomplish and to measure the impact of these additional stakeholder effects, but the bureaucracy of the large often doesn’t want to change from known to unknown.
@Jesse Greater accountability has been a snag for our customers, especially when we show project chunks in red/yellow/green status colors. I have a feeling that the lack of transparency and accountability that 300 line Gantt charts and task lists provide are a big reason why they still survive.
I think Jesse’s comment directly applied to me. I have seen the situations described by the other two, but haven’t seen it with our customers yet.
Bas,
I think one primary reason why a lot of organizations (especially the big ones) are so tied up with doing software and IT projects in the traditional way instead of better agile methods is because the former tends to give them a sense of having an “actual” tight schedule which should be met. Most leaders, PMs, senior level management have not been fully exposed on the principles of what and how makes agile tick that they do not want to simply jump on the bandwagon – taking into consideration as well that they felt secure and had found success (to some degree) using traditional methodologies.
I think we might see a further shift to agile methodologies when people who would be later assuming more senior roles are the ones who have used them in their projects. These people know the values offered by going agile to an organization and have the actual drive to implement them. But as of the moment, with most top levels in organization still proud of how they do things, then it applies they are most likely not to employ and embrace change.
For what it’s worth I think Jesse’s espnse is the most important answer you got Bas.
How do you addres a ssytem that is ging to make you work harder and remove the ability to blame someone else?
I think: Buy the model and your whole operation will improve osmotically
I JUST COMPLETED A PROGRAM IN PROJECT MANAGEMENT.
WHAT DO I NEED FURTHER.
THANX.
@Paul, Diwant, Angelo: yes, yes! thanks for the addition.
@Craig: it almost is like “plan to throw one away”… a project that is. First do a project agile style to create transparency, flush the pipes so you know where your trouble spots will be?
Hi Maame,
It depends on what you want to achieve and where you are located.
You can drop me a mail if you want. bas- at- projectshrink . com
Cheers
Bas
Dear B.
Thank you for a your message.