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:
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.
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:
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
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:
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.