Death to Agile! Or maybe not?

Death to Agile! Or maybe not?

Introduction
‘Snake oil or miracle cure?’ Is Agile all it’s cracked up to be?’, ‘Agile is dead!’ and ‘All the reasons Agile sucks!’ flood the internet and Linked-In; are companies really struggling with implementing Agile that much? What is really driving these articles and what are the merits of these claims? Is Agile really dead? Is Agile really nothing else than snake oil set in a contemporary setting? Have companies flushed their money down the drain and been taken for a ride on the Agile hype train? In the following article we attempt to make sense of the above by addressing some of the major complaints about ‘Agile’ and we introduce our perspective on the discussion.

Note: This is a #longread, written by two experienced Agile practitioners. You can read about them at the end of the article. A hands-on shorter follow-up article: “Unmask the Agile Quack with 5 questions” is in the making.

As we start our journey in the wildlands of anti-agile mutterings we hear an often-heard complaint from like-minded, somewhat frustrated developers: ‘Agile is the death of the craftsman and quality!’. By being pushed into implied deadlines (sprints) and a product owner that is pre-occupied with new features (as opposed to reducing technical debt), they argue they can’t possibly create the high-quality software they aspire to. Next, we look at the complaint that creativity is impaired because the room for experimentation is too narrow. Furthermore, we discuss architecture suffering heavily under ‘Agile’, as Scrum-theory proposes that design is emergent. Then we address the concern that the amount of meetings under Scrum make it difficult to come into a sense of ‘flow’. Lastly, we look into deadlines. We finish the article with a look at semantics, the risk of over-simplifying Scrum and we propose a way forward.


“Agile is the death of the craftsman and of quality!”
When it comes to quality, let’s not forget that the team is responsible for the quality of the system, which means the team has a say in how this is realized. A collectively defined Definition of Done (DoD) has been created for this purpose: the team agrees that to achieve the quality it requires, these conditions must be met.

If the definition is not respected by the business or by a(n) (inexperienced) Product Owner, the team should self-organize to tackle the issue. A metaphor I (James) like to use in these types of situations, is the ball-and-chain that gets continuously heavier and heavier from cutting corners until the progress of the team halts entirely. This imagery is powerful for creating the realization in the business and with the product owner that compound interest on technical debt hurts you badly in the long term.

“The sprint mantra kills all creativity!”
With regards to creativity being stifled by the ‘sprint’-nature of the approach. I (James) have frequently seen mature teams be given the space to try and create new things. In these teams ‘failing’ is seen as a valuable source of insights and is even ‘stimulated’ by the product owner. Often it is these experiments that lead to the best solutions: the popularity of hackathons is a case in point.

Similar to quality, educating the business is of paramount importance. Many companies, especially big corporations, still live in a world where IT and business are separate entities. This leads to huge penalties when it comes to efficiency, quality and innovation. the business must be educated that to stay competitive, the business must be aligned with IT towards a common goal and vision. A Scrum Master could, for example, organize a session with executives to teach them about trends in IT, the business and IT-landscape, and new methodologies and mindsets (think micro-enterprises, Lean Start-up, DevOps and so forth). Again, the problem is not directly related to Scrum, but more often to the maturity of the business.

“We create short term solutions as Agile has no place for architecture!”
Isn’t this ultimately a case of applying common sense based on the situation? This might seem like a very easy way to approach the argument, but seriously. If you are starting a Greenfield project and you collectively feel the need to have design sessions, or set a high-level architecture, go for it. Just give yourself the room to explore your product and figure out what the most sensible architecture is – then get it done. For me, one of the key take-outs of Management 3.0 by Jurgen Apello, is that organizations and software development are complex – there isn’t a one-size-fits all approach; there isn’t a mold that suits every organization. Organizations need to adapt based on their unique set of variables using the agile mindset as a safety line.

“I need flow dude, Agile kills my mojo”
So, what about the Scrum meeting extravaganza? It is well known that developers need sustained focus to be able to create excellent software. It’s also true that it is easy to get it wrong: 40 minute stand-ups every day, 2 hour refinements every week, and 3 hour retrospectives every fortnight will suck that energy right out of the team.

This problem isn’t a consequence of the Scrum-framework, but you do need a skilled facilitator, a sensible schedule and a good clock. Make sure you stick to the time boxes and plan your meetings to minimize interruptions. Simple. But simple does not mean easy.

“But what about those deadlines? We’re not all working for a charity!”       


Besides the point that there are probably plenty of very efficient and effective charities, this is an argument often heard from project- and line-managers. And you know what? They have a point. They have a point because some Scrum Masters keep telling them that “having a plan is not Agile”.

I (Erik) call BS on that.

It is definitely possible to make a release plan and even adhere to a deadline in Agile. However, to do that, you let go of detailed planning. You plan based on epics, and you give the Product Owner an important lever: scope.

Both Henrik Kniberg, SaFE (PI planning) and quite a few other frameworks and authors have described successful portfolio planning methods, and I have been able to apply these methods successfully over and over at companies from huge to small.

Two last topics remain to wrap up this article: the semantics of Agile and Scrum and the risk of over-simplifying the Scrum-framework.

“Burn Agile! Is it really Agile though? Burn her anyway!”

VILLAGER #1: We have found a witch, might we burn her?
CROWD: Burn her! Burn!
BEDEVERE: How do you know she is a witch?
VILLAGER #2: She looks like one.
BEDEVERE: Bring her forward.
WITCH: I’m not a witch. I’m not a witch.
BEDEVERE: But you are dressed as one.
WITCH: They dressed me up like this.
CROWD: No, we didn’t — no.
WITCH: And this isn’t my nose, it’s a false one.
BEDEVERE: Well?
VILLAGER #1: Well, we did do the nose.
BEDEVERE: The nose?
VILLAGER #1: And the hat — but she is a witch!
CROWD: Burn her! Witch! Witch! Burn her!
BEDEVERE: Did you dress her up like this?
CROWD: No, no… no… yes. Yes, yes, a bit, a bit.
VILLAGER #1: She has got a wart.
BEDEVERE: What makes you think she is a witch?
VILLAGER #3: Well, she turned me into a newt.
BEDEVERE: A newt?
VILLAGER #3: I got better.
VILLAGER #2: Burn her anyway!
CROWD: Burn! Burn her!

Source: Monty Python and the Holy Grail

We need to get our semantics right (yes, really) before we burn our ‘Agile witch’. Although the titles of the articles clearly aim their pointy sticks at Agile, in reality, the content and arguments of the articles have hardly anything to do with Agile: it’s Scrum that’s causing the fuss. The distinction is important: Agile as a concept, the Agile manifesto and the Agile-principles describe a mindset: a way of viewing and approaching software development. Fundamentally, Agile as a term can be defined as: the ability to create and respond to change in order to succeed in an uncertain and turbulent environment. As Dave Thomas excellently puts: ‘the whole point of [Agile] values is that they are a compass, not a map’. Technical practices, frameworks and processes are therefore different to the concept of Agile, yet these are the essence of the articles supposedly challenging Agile.

Scrum on the other hand is a framework (not a process, mind you – just so we steer away from angry evangelists), that has a parent-child relationship with the concept of Agile. One that focusses on teamwork, accountability and iterative progress towards achieving a (business) goal; based on the three pillars of transparency, inspection and adaptation. Here artifacts, roles and ceremonies are defined, however loosely. This Scrum-framework is the predominant topic of most of the anti-‘Agile’ articles. Let’s stop sticking fake warts and noses on Agile – she is not casting any spells here.

Beware of over-simplifying
Scrum has been excellently marketed as the winning formula for software development. All you need is a coach, and/or send some people to a Scrum training, follow the Scrum-guide and you’re golden. Salesmen, avoiding the implications and stressing the supposed benefits of Scrum, got all the executives hooked. Which organization didn’t want to double productivity, minimize the time to market, create energized, responsible and committed teams, and bridge the gap between business and IT? ‘Make us Agile’ [Dave Thomas] became the standard response as consultants came pouring in from everywhere. Greater yet, if it didn’t work out, you just didn’t do it right; sound familiar?

The reality is that working in an Agile way in general is difficult, let alone successfully applying the Scrum-framework. It is worth looking at an analogy. Traditional software development is often compared with civil engineering. In civil engineering we create a blue print for a house, lay the fundaments, build the walls and so forth and can essentially copy-paste the approach to build an identical house next to it. Scrum challenged this assumption by arguing that software development is complex and unpredictable: you can apply exactly the same software development procedure in organization B, as in organization A, but the results might be completely different as a function of people, infrastructure, technology, suppliers, and so on. Yet, ironically, we do expect that if we apply the Scrum-guide it should work everywhere?

Everyone that has gone through a two- or three day Scrum-training and answered some multiple choice questions to get their certificate, calling themselves ‘Agile coaches’ doesn’t help either. The quality of Agile coaching and Scrum Masters has gotten watered down this way. It isn’t rare to see ‘Agile coaches’ or ‘Scrum masters’ relentlessly stressing each sentence of the scrum guide to teams, or project managers preaching Scrum, but still describe themselves as ‘managing a team’.

Lastly, executives stating they want to change their organization ‘towards Agile’ in a committed attempt to ‘cut costs’ or ‘reduce the size of the workforce’ sends the wrong message to those living the change.  

Parting words
Although the objections with regards to Scrum are understandable, they aren’t symptoms of applying Scrum – they are symptoms of teams and organizations that aren’t mature yet in their Agile-journey. In many cases, companies have bought into Scrum without fully understanding or realizing the implications.

To those frustrated developers we’d like to say one thing: ‘hang in there!’; over time organizations will get it. In the meantime: go back to the bare essentials – apply Agile principles and the manifesto to your situation and take baby steps. You don’t need to follow the Scrum-guide word-for-word to be Agile. In our upcoming article “Unmask the Agile Quack with 5 questions” we offer some assistance when interviewing candidates to make sure you select useful pragmatists instead of unruly evangelists.

About the authors

James De Mulder spends his days helping organizations in their transitions towards high performing Scrum- and DevOps teams. Additionally, he is constantly expanding his knowledge on the topics of Agile, Lean and Lean-startup by reading books, articles and attending summits and meet-ups.


Erik van Eekelen
has been leading and coaching Agile teams, departments and organizations for more than 10 years. These days he still applies the Agile mindset while he coaches on innovation execution at startups and corporates.