By Jim Stewart, PMP, PgMP, PMI-ACP, CSM
As mentioned in my previous article, Agile involves moving to a new way of working on projects; 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, meaning 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 Project Manager who may now be a Scrum Master and is used to giving orders.
- The team who is used to being told what to do.
- 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 on-the-job training and informal sessions, preferably run by an Agile coach, that consist of executive briefings and team training.
Resistance to change
“it’s how we always did business” or something like that that was viral 1-2 years ago.
As touched upon in the first post, organizations (and people) tend to be resistant to change. If it isn’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.
It will take a deep behavioral research to analyze the reasons behind the reluctance to change, but some of the most common questions heard include: 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 gentleman 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 a 17-page document of rules and guidelines which, based on anecdotal evidence alone, not too many people are aware of, much less 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 in an Agile coach 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 do so haphazardly and hope for the best. As someone wiser than me once said, hope is not a strategy.
About the Author
Jim Stewart has over twenty years’ experience in managing projects in IT, financial services and pharmaceutical. A PMP since 2001 and Certified Scrum Master since 2013, he frequently helps organizations increase their project maturity by incorporating best practices.
- 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