Unlike some recent trends, agile keeps going strong. It’s hard to tell how many organizations practice Agile – most of the research gives us different numbers.
However, it’s safe to say that the approach is as popular as ever these days. More and more companies want to adopt Agile but struggle making it “work”. There are many reasons for that: wrong interpretation of practices, conflicting business agendas, lazy management, etc.
In this article, I’ll focus on faulty mindsets – a number of preconceived notions about Agile that act as a ticking bomb for your organization’s workflow. These are responsible, in my opinion, for all the problems that eventually flood early adopters. I think it’s crucial to detect these mindsets and defuse them before your very first sprint.
“Magic Pill” Mindset
Here’s a story: an energetic manager eager to change the world (and the lives of a few innocent employees under his supervision) reads a PDF report on how good Agile can be. By implementing agile, respondents cited seeing improvements in the following areas:
- Delivery speed improved (62% companies)
- Ability to manage changing priorities increased (71%)
- Software quality increased (46%)
It doesn’t matter if the PDF was prepared by a company offering Agile consulting services, the guy is on the hook.
Add to that that he most definitely read about the wonders Agile can create on project management blogs, and you’ll get a typical “Magic Pill” scenario.
Even though it’s 2018, the project management community has just recently started reaching the peak of inflated assumptions towards Agile. It means that only now more problems related to adopting Agile methodologies are surfacing, and people are starting to think more critically about it.
However, there’s still an unhealthy hype around Agile practices, which leads to unhealthy expectations. Even though Agile can be a pill, it’s not magical and should be taken with precautions. As you’ll see in this article, blindly inserting new practices into your daily operations is a gamble.
Winging It
Often managers will dive into Agile… tomorrow. There’s no plan, just use this Scrum guide and do as it says. We’ll figure it out on the way. Then this happens: Agile doesn’t get traction, no one feels like they became more efficient, but now the old workflow is destroyed.
According to 6point6, a big data analytics company, 34% of Agile projects fail due to a lack of up-front planning. It sounds odd, but “winging it” is quite common among early adopters. Part of the problem is that the company switches to agile after having had some other methodology in place, usually “Waterfall”. And Waterfall is infamous for its extensive planning and documentation, so people decide to go to the opposite extreme and do little to no planning at all.
Not helping is that one of the core values in the Agile manifesto is, “Responding to change over following a plan”. When the founding fathers of Agile recommend to throw out the plan, there’s only so much you can do… Or is it really what they recommend? Of course, it’s not.
Agile supports extensive planning, even more so than Waterfall, with sprint planning, epics, planning poker, etc. The trick is to treat the plan as a flexible guideline, not something written in stone.
Show me the man who thinks he knows how Agile works and I’ll show you a liar
– Unemployed Scrum Master
However, I’m talking about a different kind of planning here. You need and should plan your Agile adoption. If you replace your entire existing workflow with the Agile framework next week, you risk completely collapsing the current production pipeline. I’m not saying it’s not fun to try sorting out this managerial chaos. I’m saying it’s only going to be fun for this one manager. The rest of the company will be suffering.
The transition should be slow and well laid out because Agile transforms the culture of work, not just the duration of meetings. Also, “winging it” leads to dropping or tainting Agile practices, creating a “pseudo-Agile” environment.
Bottom-Top Mindset
I’ve seen countless messages on forums that look like this: “I work in a **** [boring] company that doesn’t even want to hear about any kind of change. What can I do?”
Then there’s a whole slew of recommendations that start with “you are the torch” and end with “Agile is dead”.
The truth is, Agile works to its full potential only when it’s broadcasted to the whole company. Every product a company creates is affected by both junior developer’s decisions and CEO’s. If you are Agile at the bottom and Waterfall at the top, the clash is inevitable. Studies show that 63% of Agile implementations failed due to cultural clash between the existing business philosophy and Agile’s philosophy. Even Fortune 500 companies that deliberately try switching to Agile sometimes fail because they can’t transform the overall company culture to fully reap the benefits of the methodology.
What can you do? I remember stories when software developers acted as double agents, slowly recruiting their colleagues and managers into an underground Agile resistance. While it sounds romantic, it’s slow, painful and there are no guarantees that you’re not possessed by other subversive mindsets mentioned earlier.
When you try implementing agile from the bottom, you are prone to both the “Magic Pill” and “Winging it” mindsets at the same time.
Magic pill: let’s face it, you have no idea if this works for your company, you just blindly believe it will.
Winging it: you have no idea how managers will react, so you’re “winging” it by default
Conclusion? If you really want things to work, garner the support of your manager and their manager as well. If you are a manager, I’d strongly recommend finding Agile consultants or experienced practitioners at least at the beginning, or you risk building an abomination.
Everything Is Agile
As in every Oscar-worthy story, Agile’s biggest strength is its biggest weakness. People interpret Agile as a flexible system, one that can be adjusted to the needs of every company, big and small. However, sometimes early adopters take the word “Agile” too far.
Agile practices are agile, but it doesn’t mean they can be twisted as much as needed. Take Scrum, one of the most popular Agile methodologies. It has a set of core practices, one of which is a retrospective at the end of every sprint. Retrospectives are essential for a never-ending growth of a team’s potential. The better the team adjusts to Agile practices, the more efficient it is, and there’s an endless loop of improvement.
However, some product managers think that retrospectives are a waste of time. “If anything, we can always gather by the water cooler and discuss what could be improved.” Well, if all the water cooler talks had the strength to change things we’d probably have a different president every month. Retrospectives do not even take that long, no more than an hour every sprint. Drop it, and your team stops growing and adapting. You’re not Agile anymore.
Another situation: sometimes, especially in small companies, people may assign several roles to one person. In Scrum, Product Owner (PO) and Scrum Master (SM) are two different people. Why? Because one is an advocate for users, and the other one is an advocate for developers. These two forces, users and developers, constantly collide with each other, and the goal of the PO and SM is to maintain a delicate balance between them. Giving both roles to one person is the shortest way to make both sides unhappy.
Even though Agile aims to be as flexible as possible, don’t stretch it. Core practices were created not randomly, they’ve been tested in a working environment and each one of them has a certain purpose.
New Name, Old Ways
This one usually comes from managers who want results, but don’t want much change.
Next meeting:
“You’re a scrum member now. And you too, Jack. And so are you, Lisa. We’re a team! I [your manager] am a Product Owner. We meet here every day at 10 a.m. and talk for 10 minutes. Now, this is very important. We talk while standing, ok? Great! You all are agile now. Now go and do your job.”
Nothing changed, and everything changed. Talk about transformational leadership.
This mindset is a testimonial to why compromises are not always good. Someone offers Agile as a new work culture and management does not want to upset employees, or maybe they are even up a small amount of change, so they say yes. In reality, though, management does not want to change. And why should it? Everything seems fine for now. Another reason can be a lack of knowledge and experience. The latter reason is much easier to fix than the former.
This is probably a cliché phrase by now, but Agile is not about practices, it’s about the culture of work. Superficial adoptions and bootless compromises are not facilitating real change, but only a lovely spectacle.
All the detrimental mindsets mentioned in this article may come from a good place. The “Magic Pill” mindset is an homage to undying optimism in a bleak corporate environment. The “Winging It” mindset is a call for an adventure, and the “Bottom-Top” mindset can come from a strong belief that even one man or a woman can change the course of a company history. Romantics.
But Agile has matured. Now it’s obvious that to make it work you have to work hard and be determined to change. It should not be carried out by romantics anymore, but diligent professionals and astute managers that know what they are doing. So read versatile case studies, hire experienced Agile professionals, make sure your company is ready to make some real changes, and there will be one less “Agile Is Dying” blog post in the world.