The Agile Transformation (Part 2) – Challenges
As mentioned in the previous article, Agile involves moving to a new way of working on projects, a new paradigm if you will. Therefore it brings its own set of issues that must be dealt with. Here are a few of the more common ones:
- Organizational Culture
Organizations are typically top-down in nature, in that there is a clear chain of command, a clear hierarchy. This manifests itself in projects to the extent that the project manager is in charge of running the project and team members report to him or her, even if only for that project.
Agile turns this paradigm on its head. For starters, there is no project manager as such. It is commonly believed that the Scrum Master is just a renamed PM. But that is not true as the Scrum Master’s job is to facilitate, to remove impediments. It is not his or her job to tell the team what to do and when to do it.
So who does that? Well, this is the second issue that traditional organizations have to deal with in the Agile Transformation – teams are self-organizing and responsible for their own work.
So you can see that this creates problems for (at least) three entities – the PM, who may now be a Scrum Master and is used to giving orders; the team, who are used to being told what to do and the product owner who may not be entirely comfortable with this brave new project world.
One possible solution to this is education. By education, I don’t necessarily mean that everyone on all teams must go to class. But at the very least, there should be informal sessions, preferably run by an Agile coach, that consist of executive briefings and team training.
- Resistance to change
As touched upon in the first post, organizations (and people) tend to be resistant to change. If it ain’t broke, they will tell you, don’t fix it. The problem is that “it” is often broken and they still don’t want to fix it.
Numerous studies along with anecdotal evidence over the years have demonstrated that people resist change for any number of reasons – comfort with the status quo, fear of what will happen to their job, concern about whether the change is really necessary or will do any good.
Why is that? That subject is too big for this blog post but there are a myriad of reasons why change is frightening to people:
- What does this mean for me and/or my job?
- Every time we have a change, it just means more paperwork
- There’s always a new flavor-of-the-month we have to learn. Agile will fall by the wayside too
So the reaction to change isn’t just because people don’t like it, there’s also an emotional component. According to one study, “directed change is driven from the top of the organization, relies on authority and compliance, and focuses on coping with people’s emotional reactions to change.”1
- Misunderstanding or subverting the process
I went to an Agile networking session a short while back. It was clear to me that a lot of people in the room were new to Agile and were trying to get their arms around it.
As part of an exercise we were asked to do, I discussed the challenges of implementing Agile with a gentlemen from a manufacturing company. When he told me they were having trouble establishing the backlog of requirements, I asked him who the product owner was. He shrugged and said, “I guess I am.”
And that to me signifies much of the problem with Agile implementations that are currently ongoing. Someone either decides to use Agile or is directed to use it. But they learn a few key terms, maybe time-bound their work in sprints, never get any real training and then dive right in.
Agile is meant to be nimble, not chaotic. The fact that it’s not as process-driven as waterfall does not mean anarchy should be the order of the day. It has certain rules, guidelines, and precepts. Scrum has 17-page document of rules and guidelines which, based on anecdotal evidence alone, not too many people have read.2
By subverting the process, we mean that organizations try to bring command-and-control techniques to a process that does not work well with them. Asking Jen to become a Scrum Master because she “really knows how to crack the whip” is not what is called for. What Agile needs is a good facilitator who listens to people, knows how to remove impediments and can coach teams.
So if you’re planning an Agile implementation, here are some ideas:
- Realize that it’s all about change and bring in change agents to guide you through the process
- Get an executive briefing and bring an Agile coach in to train the team
- Run a pilot project of 4- 6 months. Don’t make it a “bet-the farm” project but be sure it has at least some importance to the company
- Put a mixture of enthusiasts and even naysayers on the team. You are going to want to roll this out to the larger organization or enterprise and you need a laboratory of sorts to simulate what it’s like
The Agile Transformation is not something to be taken lightly. Like all new methods or processes, you can introduce it methodically and respect its guidelines or haphazardly. It’s clear that those companies that respect the process and use Agile for the right type of projects are starting to see benefits.
- Rethinking Organizational Change: Reframing the Challenge of Change Management. Kenneth Kerber, Anthony F. Buono. Organizational Development Journal. Fall 2005.
- The Scrum Guide. Ken Schwaber and Jeff Sutherland. Scrum.org. https://www.scrum.org/resources/scrum-guide
For further reading, I recommend this article, Scrum Master vs. Agile Coach: Why Successful Transformations Need Both. You can read it here.
I think people get tied up in Guidelines and mistake them for Rules. By definition, they are meant to “guide” you. I like to call them guardrails. Every organization has its quirks and culture that require adaptation. That doesn’t mean you can’t be good at Agile, at ITIL, or whatever standard process your company is following.
Sure. The problem I think is that some companies follow no guidelines. I had an email conversation with a student of mine. They were using almost none of the precepts of Agile. And yet management insisted on calling it that so they could say they were Agile. It’s almost like it’s become “hip” to be Agile but not everybody wants to do the actual hard work.