The Agile Excuse
The Agile Excuse
Now that Agile methodologies have been implemented in more organizations, misapplications of Agile are getting new excuses.
Join the DZone community and get the full member experience.Join For Free
Discover how TDM Is Essential To Achieving Quality At Speed For Agile, DevOps, And Continuous Delivery. Brought to you in partnership with CA Technologies.
"Our project is behind, but we're Agile." "Good, we're on track then."
I find it interesting how so many organizations appear to be content with a failed Agile transformation. For the sake of this post I’m considering failure to be the point where the very spirit of being Agile is lost in a static but chaotic world of stand-up status updates, Product Owners converting Business Requirements Documents into Product Backlogs, and Project Managers checking in on bi-weekly progress reporting demos; where the organization has no further appetite to improve or become more Agile, and where traditional product development is simply overlayed with iterations delivering no incremental value at all. I do not consider being on the road to agility, engaging in controlled, measured, and meaningful change with an optimistic vision of what could be, as a failure. That’s simply being part of the journey and is itself, a success.
When you dig deeper into a failed transformation, however, you, of course, realize that satisfaction is simply an organizational façade, hiding a great level of uncertainty and discomfort over the whole Agile movement. “We’re Agile! We do our own version of it, but everyone is on board!” Really? Your developers don’t seem to be happy with it. The usual complaints found in a ScrumBut environment, for example, are all too common: too many meetings, unclear requirements, inability to vertically slice an item of work, micromanagement, unsustainable pace, DevOps issues, individual annual reviews which contradict team goals, etc.
From middle management, we hear complaints such as the inability to ensure everyone has work to do, poor communication, unclear metrics, wasted funds on relatively ineffectual resources like Scrum Masters (do we really need to pay someone tens of thousands a year to facilitate a stand-up?) and so on. From senior management, we hear “our projects aren’t being completed any faster than before” and “we’re still spending just as much as before.”
So, if these complaints are a genuine cause for concern, which I would wager 99.9% of them are, why does management neither act to resolve them nor revert to traditional ways of working entirely? Agile change is hard and with improper support from the top, near impossible. Why, then, is there an insistence to still ‘be Agile’ from all layers of the organization? Why are these complaints no more than break room gossip? Maybe it’s a kind of sunk-cost fallacy: “We’ve come this far, it would be ridiculous to go back now!” Or is it because a poor understanding of Agile has offered a new set of excuses for overblown budgets, missed deadlines, scope creep, and poor-quality products?
Traditional project management came with heaps of methodologies, processes, and techniques to manage and control every single aspect of a project. A project manager had, in theory, total control. Any deviation from the original plan was flagged and escalated so that it could never be disguised (again, in theory). Such control didn’t lessen the number of instances, however, and that problem has been an input into modern, Agile techniques (think self-organization). Projects were still considered failures but there was something tangible to put the blame on. You could pinpoint exactly where something or someone went wrong. With blame comes the uncomfortable pressures on reputation, salary, job security, and so on. Who really enjoys those pressures? Cue Agile.
Now that "we're Agile", everyone has a bucket of new excuses to pull from. When there is no apparent end date for a project, it’s because “we’re Agile and there are no deadlines.” When a deadline is missed, it’s because “we’re Agile and requirements change.” When requirements change without clear communication, it’s because “we’re Agile and that’s the way Product Backlogs work.” What we have now is a traditional approach to product development without the control that traditional project management gives us. Now the pressures that are associated with traditional product development have been significantly reduced.
Are there really so many people purposely trying to con their superiors by using the Agile excuse? No, of course not. I believe this is a subconscious behavior, stemming from their own misunderstandings. The complaints about Agile surely prove that. In reality, this failed transformation state is not a comfortable situation to be in, but when things go wrong, the excuse is there. There is a way out and it brings comfort and security.
This comfort and security prevents us from wanting to go back. Why would we want to go back to the time where a missed deadline had our bonuses slashed or our jobs on the line? I also think this prevents us going forward. An Agile environment is famous for having a ‘no-blame culture’, but that doesn’t mean the roles of an Agile team and middle and senior management won’t have responsibilities that will be held accountable. Couple the reintroduction of career pressures with the often awkward and uncomfortable change Agile transformation brings and it’s not surprising organizations shy away from it.
This post is supposed to be little more than a theory for the limbo state a lot of organizations find themselves in when it comes to Agile transformation. However, we should be careful we don’t find ourselves using the Agile excuse. It’s worth asking if we’re doing ourselves, our team, and our organization the disservice of masking reality by saying, “but we’re Agile.” The more courage we show by asking that question and avoiding such an excuse, the more we can view a transformation objectively and transparently.
Opinions expressed by DZone contributors are their own.