Should Agile even be used anymore? The cases for and against Agile and the new Agility.

In my first article in this series, I discussed the Agile software development method in general and specifics about the daily meeting. In the second, I compared Agile to Waterfall and discussed pitfalls and misconceptions of each and where hybrid models could be used. Here I look at the cases for and against Agile.

Agile isn’t even that long out of the toolbox and already there are people calling for its demise. While some are looking to adopt and integrate Agile or some version of it into their processes, there are others who feel it is not working and should be discarded. Let’s take a look at those issues and what they are about. We need to keep in mind that the framework, the method and process need to be blended into company culture in order to be successfully adapted and adopted. Failure in implementation can result from misconceptions and dilution about how it should be implemented, and what that even means resulting in the questions – should Agile even be used anymore? and if not, then what?

In my previous two articles about Agile stand up meetings and Agile vs Waterfall, I have gone over in detail the mechanics and alternative implementations of various parts of Agile and the methodological differences between it and other methods so I am not going to go into detail about that again here. Here I want to discuss different points of view, strengths and weaknesses and how they can be addressed.

I will say at the outset that I am not completely sure where some of the authors of the criticism are coming from. For example, are they just entrenched in their various ways of doing things and don’t want to change, have they found real problems with implementing them and reject them on those grounds, or do they have a particular product or service they are selling which favors one over the other? But none of this should distract from what appear to be proven experts in their field who have an opinion and should be taken seriously as all discussion helps everyone learn and evolve to become better at what we do.

At yegor256.com, Yegor Bugayenko, a programmer, writes a very interesting piece about “Daily Stand-Up Meetings Are a Good Tool for a Bad Manager”. It’s not written from the point of view of whether or not daily meetings can work or how to do them but that as a management tool, it is only “bad” managers who use them as a key management tool and compares how he thinks “good” and “bad” managers should organize their work. He breaks this down into information and communications flow and what differentiates these two different styles of management. What this addresses at its root is the corporate culture at work and what processes and attitudes should be in place which remove the daily standup as a critical factor. This also addresses what I have talked about in the other articles about how the “Agile” process and daily standup are being adopted but its use and usefulness is being subverted from its original intention. Yegor’s article is really using the idea of a daily standup to discuss larger issues and pitfalls about what constitutes good and poor management techniques, and I actually agree with most of his points.

On his blog Michael O. Church rants (in his own words) “Why “Agile” and especially Scrum are “terrible”. His contention is that while Agile is better than Waterfall, “Agile as-practiced is deeply harmful” and that Scrum is just as bad if not worse. Church says that Agile/Scrum turns programmers into commoditized interchangeable components which among other reasons takes the creativity needed out of the work. The problem with Scrum he says is that two week iterations do not make people more productive. “There’s absolutely no evidence that any of this snake oil actually makes things get done quicker or better in the long run. It just makes people nervous.”

Church discusses the pitfalls of Business-driven engineering, and boils down Agile and Waterfall here to failed models of corporate culture in that “Waterfall replicates the social model of a dysfunctional organization with a defined hierarchy. Agile, quite often, replicates the social model of a dysfunctional organization without a well-defined hierarchy.” His conclusion is that these forms are perpetuated by business driven companies where the engineers are low man on the totem pole which cannot produce high quality products. Silicon Valley for example, on the other hand, he concludes has it right when they run engineer driven engineering businesses which can deliver high quality products. He concludes: “Ultimately, Agile (as practiced) and Waterfall both are forms of business-driven engineering, and that’s why neither is any good at producing quality software or happy employees.”

Additionally, Church says that the Agile model is too short term focused which causes long term problems for example with technical debt (also aligning with the business driven culture problem): “Under Agile, technical debt piles up and is not addressed because the business people calling the shots will not see a problem until it’s far too late or, at least, too expensive to fix it.” I would have to say that I have worked on Agile projects where this is true. It explains the kind of developer behavior I have seen (discussed (here mindset)) where they work to get a piece of work (a ticket) off their plate and into the next hopper regardless of if it’s done properly or not. As long as it’s off for now even if it will (or will not) come back later, they can meet their sprint (and estimate) goal and just go on to the next ticket.

Finally, Church’s point on what Scrum is or was good for before it became a more permanent way of creating software was as an emergency way of getting things done fast, when things were broken and needed to be fixed as quick as possible. The point being that when you are always working in an emergency mode, it leads to less creativity, lower productivity, and frequent burnout and attrition.

For now I will leave things there because I have found numerous other blogs posts and discussions going back and forth on these topics. There are very strong opinions on both sides. For example there are those who say Scrum and it’s daily meeting culture is really a form of micromanagement which I have described as toxic in a separate article. Instead of continuing to mention other people’s arguments for or against, let’s look at the current opinion from one of the founding members of the Manifesto: Dave Thomas.

Dave Thomas explains why Agile is Dead

One of the originators of the original Manifesto for Agile Development is programmer Dave Thomas. He wrote a blog post in 2014 called Agile is Dead (Long Live Agility) .

Subsequently he was invited to speak at numerous conferences about his disillusionment with the Agile movement. One of these conferences was the GOTO 2015 conference in Amsterdam. Below I have embedded the video for your convenience.

In this video presentation from 2015, he explains why “Agile is Dead”.
Let me summarize the main points:

He says, at the conference in Snowbird where they put together the principles, they were pretty happy with it. They published it and that was it and moved on but as he says “that was probably a mistake because what has happened since is that the values have been totally lost behind the implementation.” The root of all the (evil) problems as he sees it is that people have confused and mixed up the terminology. It’s Manifesto for Agile SD but people call it The Agile Manifesto effectively turning the word agile from an adjective into a noun. Why is this hair splitting on semantics important? Let’s not forget that programmers are very logical and detail oriented, and everything has a specific meaning.

What’s at issue is that nouns sell – Training, Consultancy, Books, Conferences

“The industry that sprang up around the manifesto wanted to sell you things….and therefore they needed to convert agile from an adjective into a noun and they succeeded very quickly. ” “This industry that sprang up…it’s nowhere close to the spirit of the original manifesto and the value… ” of that.  “But it gets worse because how do they sell you Agile? The same way they sell you medicine…they use fear. ”  New words, roles, metrics, structure (hierarchical to flat), and then finally are they doing it right. And finally, cool sells – bright and shiny, feeling of power, why aren’t you doing Agile?

In addition and as a result, the “right” way to “do Agile” has been turned into something of a fundamentalist religion. In the Agile community people can be put down for not doing it “our” way. That the way to do it has become like a religion and if you’re not doing in their way it’s the wrong way. So now Agile is an industry. So it incites fear and then asks for money to assuage fear.  The industry discovered that the big money was in big companies so they scaled it to fit with teams larger than 6 to 12 people. Scrum within scrum. Scaled Agile Framework 3.0 SAFe for example.

What is Dave’s solution to all this?
“I believe it is time to reclaim agility. Because I still profoundly believe in the values of agility. “

In the video he presented a one slide take away version of how to utilize agility:

Three steps plus a loop

Agility – What to do

Find out where you are

Take a small step towards your goal

Adjust your understanding based on what you learned

Repeat

Agility – How to do it

When faced with two or more alternatives that deliver roughly the same value, take the path that makes future change easier.

Dave’s rule of design, for any and every design methodology  – a good design is easier to change than a bad design.

So what does that mean for creating a framework and a process with agility?

It means – No rules are Universal (except this one). All rules need context.

Thus experts and consultants can’t tell you what to do or what is the best way to do something or that you’re doing it wrong.

How do you know what to do?

You don’t!

Go back to the one slide Agility steps – what to do and how to do it.

It takes Courage (at all levels of the organization down to team and indiv).

You already have the values – use them to create practices.

Get feedback, refine, repeat.

Thus

Agile is not what you do.

Agility is how you do it.

 

Dave was asked his opinion of Scrum.

“The ideas behind Scrum are powerful. Where I part ways with Scrum is the concept of two or even one day Scrum Master courses. It devalues the entire industry.” What he doesn’t like about the courses which tell you how to do it, don’t tell you if you’re doing it right, how to modify or organize it to fit your organization and culture. So Scrum, the concept is good, it’s the implementations which fall short.

The Final takeaway.

Whether or not a particular endeavor succeeds or fails using these methods or something else most depends on whether or not the tools and processes are a fit for the purpose and the people who are running it know the best ways to use those tools and to manage the people in the project. Some people say that Agile was originally only meant to be used on small teams of at best 6 to 12 people. Some would  argue that Agile and Scrum really don’t go together. The Manifesto for Agile Development says “Individuals and interactions over processes and tools”. But that “Scrum is all about process frequently at the expense of people.” Therefore it needs to be pointed out that Agile is a set of values and principles, Scrum is a framework. There may be better frameworks with which to use to implement Agile practices and principles or create your own.

Really, after all this, the takeaway is that Agile and Scrum, more often than not, don’t go together, don’t work well together. Don’t implement Scrum and call it Agile. It’s not. You can implement Agile without using Scrum. You’re probably better off. What’s really dead is Scrum or you could also say Scrum killed Agile. Either way, Scrum is Dead, Long Live Agile (or now Agility)!

Where would scrum be useful in an Agile project? In the end doing bug fixing and triage in the end. That’s an emergency and that’s where a short period of vigilance and effort can have the biggest payoff.

What do you think? Is Agile dead? Does it work for you and your team/company? What about Scrum or some other framework? Should we now take up Agility? Comment down below with your thoughts. Like, Share and Subscribe!