by John “Eljay” Love-Jensen
A friend of mine is at a company that is in the process of adopting "doing agile". This kind of fad agile is the antithesis of agile software development, and unfortunately it is the kind of cargo-cult non-agile that sometimes takes root.
There is genuine bona fide agile software development. And there is fad agile. They are not the same thing. Fad agile is sometimes adopted by big companies that you would expect to know better.
There is a lot of literature on how to adopt agile software development successfully. And lots of resources on how to adopt Scrum management process, successfully. Sometimes, companies do both, because agile software development and Scrum management process can be complimentary.
This is not an article on how to be successful with agile software development. This is not an article on how to be successful with Scrum management process. This is an article that explores the business disaster of fad agile.
Also, this is not the situation of trying to adopt honest to goodness agile software development, and being thwarted by "corporate antibodies", or "organ rejection", or "backsliding to the comfort zone of the old ways".
No. This is the worst case scenario business disaster: someone in the upper echelons of the business decides to mandate "we will be agile" who has no clue what agile software development is, nor how to execute rolling out the new shiny fad agile.
For the rest of this article, I will be calling fad agile "Agile" (capitalized, one word) or "Doing Agile", and real agile software development "agile software development" (lowercase, the entire phrase), and Scrum management process "Scrum".
Yes, there are other agile-friendly management processes besides Scrum, but Scrum is the most popular. And Scrum coupled with agile software development works pretty well. Even agile-less Scrum can work okay as a management process, since Scrum is independent of the agile part of agile software development.
Doing Agile will go through the traditional six phases:
Good news! Don't give up hope! You, as one of the interchangeable cogs
individual contributors, merely need to weather the storm for the twelve months
or so that it will take for the fad to run its course. This too shall pass.
Unless you are the goat, in which case you are screwed.
You are at a big company, and have processes in place to formulate a software project, then have business analysts assess the requirements, then have the project approved, then a team is assembled to create the application from the requirements, then pass the application to quality assurance for testing, then when approved pass the application to operations for deployment. All under the guidance of the Project Management Office.
A fairly typical real life waterfall model. Not the strawman waterfall model panned by the Scrum evanglists. But the actual in practice business practice waterfall model used by most companies.
Then one day, one of the big company big shot executives picks up an executive trade magazine that touts that agile companies have a huge competitive advantage over non-agile companies. The big shot executive gets all excited. The big shot can make a mark on the company and claim all the glory. Notice, recognition, prestige, and a nice big bonus.
There's only one catch: the big shot executive does not understand what agile software development is about. All big shot executive knows is "agile good, non-agile bad."
So big shot executive consults with expensive Agile‘Я’Us Expert Consulting, who promise to transform the company from a lumbering behemoth to a well-oiled lightning-fast Agile machine.
The consulting company is, likely, very well aware of what agile software development is, and what Agile is, and that they are not the same. For a company to transform itself into one that is agile software development is hard. For a company to transform itself to one that is Doing Agile is easy. And they consultants get paid the same amount of money if they do the hard way or the easy way. So they chose the easy way, because they get in, make their money, and get out before the crapola hits the fan. Mission accomplished.
They also get a big commission for selling the expensive suite of Agile tools.
The experts tell the executives the plan:
The employees are used to the established processes. Now the middle management has been handed that mandate that everyone has to Do Agile. So middle management tells all the employees that they must now Do Agile... or else.
There are a slew of new Agile tools that everyone is required to use. There is a scrambled panic to Do Agile. Employees will be asking each other "What the heck is Agile? How do we Do Agile?"
To ensure that the catastrophe will be epic, a handful of management folks that will not be using the tools will be sent to training for the tools. None of the employees who have to use the tools on a day-to-day basis will be sent to training. Those employees will have to glean how to use the tools by word-of-mouth tribal lore and by asking the few managers who had ostensibly been trained in the tools that they won't be using.
Also, the employees will have no training on how to Do Agile, because to "Do Agile" means simply to stop doing all the processes that have worked adequately for years, but instead use the new and unfamiliar tools to do their jobs, but without the former clearly defined stages of project lifecycle.
At this point the Project Management Office is in a blind panic. All the projects are going pear-shaped, nothing is coming together, the employees are disheartened, demoralized, and disgruntled.
But what about the big shot executive? How can big shot be told that Emperor Agile has no clothes, and the whole endeavor has turned out to be a big fiasco?
Not yet. Needs more adoption time, and everything will work out in the end. This is the expected learning curve, and not the time to be Mr. Doom & Gloom.
So the executives are told that everything is on track and proceeding as expected. Happy happy, joy joy!
But its not. Everything is going to hell in a handbasket.
The fad is over.
Project Management Office paints as diplomatic picture to the executives as they can manage. However, it was a big steaming pile of poo, and all the employees know it.
Big shot executive who is willing to shake the tree, move the needle, and make something happen collects his big bonus for the Do Agile Initiative. Since all the executives know it was a rocky road, but things are running smoothly now.
Even though all the processes have reverted back to pretty much the old waterfall way that worked, the legacy of Agile will be that the terminology is still used and some of the new expensive Agile tools will continue being used where they make sense.
Because the vestigal Agile terminology is being used, middle management can say to the executives with a straight face "We're Agile!"
And they lived happily in denial ever after. The end.
Practice these responses:
Manager asks, "Are you Doing Agile?"
You respond in a clear, confident voice "Yes, I am Doing Agile!"
Manager asks, "How's Agile going?"
You respond with an upbeat smile "Agile is the best, I am so glad we are Doing
Agile!"
Manager asks, "What is Agile?"
You respond a bit sheepishly "Well, I'm a little fuzzy on Agile. Could you go
over the basics of Doing Agile real quick?"
The manager will say "I will get back to you on that", because the manager is
also a little fuzzy on the basics of Doing Agile as well. And the Agile the
company is doing does not jibe with the agile software development described in
the books.
In order to Do Agile, what you will end up doing is your old processes that were adequate, with the addition of having to do extra work with the new mandatory Agile tools even though they are suboptimal for the old processes. Which is okay, they are also suboptimal for Agile. And likely suboptimal for bona fide agile software development too.
The sooner you can get back to your old role and adequate processes yet describe them to your manager as Doing Agile, the better. Because you will be getting the actual work done instead of spinning your wheels whilst Doing Agile.
Good luck!
Agile Failure Patterns in Organizations which dives into more point-by-points details than this diatribe.
How to Implement Scrum in 10 Easy Steps, for how to adopt Scrum. It's easy! Really, just read it... it's that simple. Yet sadly it appears so terribly hard for companies to actually do it.
Agile Engineering Practices Necessary for Scrum, this is the agile practices part of actually being agile.
Succeeding with Agile: Software Development Using Scrum, an excellent book by Mike Cohn
Obligatory Dilbert on Agile.