4 Warning Signs that Agile Is Declining

By 19 commentsagile, Agile Developer Practices, scrum, Software craftsmanship

I’ve been thinking lately about how agile turned out to be the way we know it today. And the more I think about it, I get more depressed.

You see, agile was supposed to save us all. It was supposed to be the bridge between business and developers. And 10 years after its inception, we should be happy that more than half of the projects are done in agile manner (depending how you interpret the numbers). Agile has crossed the chasm, but not like we imagined it would.

  • Companies are “doing agile”. But they do it the way they implemented processes for the last 200 years: Top-down. First they train the top management. Then they move on to directors. Then to team leads. And at the end, they get to the developers. Remember that “working software” part? It looks like they didn’t read the small print (much like in the waterfall case).
  • The business and development divide has grown. Because scrum won, we now have project managers as scrum masters. They don’t know much about software, and that doesn’t help bridge the gap between the two worlds. Developers still look at those scrum master certifications funny (with some reason on their side), and the PMs still don’t understand that in order to get to “working software” you need to persist with actual software development practices. Because if you don’t write tests, or refactor, your team will slow down very quickly. And that will not produce as much “working software” as it said on the side of the box.
  • It’s been just 10 years and we’re already looking for the new hotness. We didn’t have enough time to learn or adjust. Agile has now become “boring” and we’re looking to uncover more better ways to develop software. Those things that looked “shiny” a few years ago, like TDD or continuous integration, have lost their shine, and aren’t attractive anymore. Don’t believe me? check out the big conferences – seen these topics lately? Much like good management is dull and repetitive, so are agile development practices. But while we appreciate the old ways, apparently we value the new stuff more (without any good reason).
  • We can’t even appear as a united front. We’re bickering inside ourselves. Agile vs kanban, craftsmen vs non-craftsmen – you’re doing it wrong, we hear from every side. And since agile has now become mainstream, it has a lot of money pouring in, and the side (read: consultants and trainers) that shout the loudest get a piece of the pie.

At this point, I feel Agile is declining into what TQM was. A brilliant success in the beginning, and now just a history fact. In a few years, months even, the business side will wake up and say: Agile is snake oil. It doesn’t deliver on its promise (and it doesn’t matter if it’s done wrong). The backlash will be grand.

There is still some light at the end of the tunnel: Regardless of our role in the process, as long as we’re delivering working software, we’re contributing to balance this future backlash. As long as we stick to the original agile ideas, we’re helping agile win a few more hearts.

I hope our collective work will be enough, that results will prevail. But I fear we’re seeing the beginning of the end.

Don’t agree? Cheer me up in the comments!

19 comments on “4 Warning Signs that Agile Is Declining”

  1. Robert Reply

    I take solace in the fact that while TDD is no longer a conference draw, my classes in TDD are enjoying ever larger attendance. More and more people are _adopting_ TDD, and getting serious about good software practice. And _that_ is the thing that will advance the software industry, no matter what happens to the “Agile movement”.

  2. Gil Zilberfeld Reply

    Bob,

    Thanks for the comment!

    I really hope that TDD will continue to draw the crowds. The adoption of testing is indeed what drives getting great software out.

    I’m not sure we can really disconnect the fate of the “agile movement” from the adoption of practices. The organizations that invite you, pay you because they’ve bought into agile in some way.

    Don’t you think that when the tide turns it would be hard for people to convince their organizations that TDD training is worth it? It’s hard enough without the baggage of “agile is just another scheme to get us to pay for certifications”.

    Like I said, I hope for the best, and I applaud the people that promote and produce great quality software. I really believe this is the absolute proof that the method works.

    But developers have been trumped by the business before. And it’s going to happen again.

    Thanks for trying to cheer me up, though!

  3. PM Hut Reply

    Hi Gil,

    Another excellent read…

    About #3, people now looking for new hotness. I fully agree with this point, now people are talking about Kanban, which may or may not be Agile.

    The problem also is that there are so many Agile variations nowadays it’s not even funny (as your last point hints). Waterfall, on the other hand, is consistent and there’s only one Waterfall.

  4. Gil Zilberfeld Reply

    Thank you for the comment PM Hut!

    Agile and kanban can either do the work, or can be misused. As long as we get quality working software out the window, the definition is not important.

    There are as many agile variations indeed. But it’s also true for waterfall: every modification done on waterfall (usually for improvement) is a variation. And again, it doesn’t matter what you call it as long is brings value to the customer.

  7. Lior Friedman: Reply

    Agile is not a process. Agile is a mind set.
    One delicate change I do see in some places which truly adopt agile is that difference. In the context of you post, the biggest change is that all Agile variants come with built in mechanisms to improve.
    and while Scrum has definitely has forgot something, more and more organizations realize that and take corrective actions.
    That’s why Bob sees what he sees and that’s why I myself am more busy today then ever.

  8. Gil Zilberfeld Reply

    @Lior,

    When “doing agile” comes with the understanding that you need proper software practices, that’s the sweet spot. And I hope we all enjoy the fruits of that understanding.

    But you are wrong about one thing. Agile is no longer a process, or a mindset. It is a brand. And as such it comes with many interpretations that weren’t there at the beginning. With its success it becomes eve more vague. But when it blows up, it will be “agile” that failed, along with the messengers.

  9. Edward Yavno Reply

    Gil,
    sounds like you took your most negative experiences observing how agile is adapted and made them into 4 signs that sound more like exceptions, rather than the rule with facts of even anecdotal evidence to support them.

    You’re right that agile has gone mainstream and there are some negatives to overcome as a result of that, but my experience is quite different, so let me address each of your 4 points.

    * “Top down agile”.
    I’ve never seen agile being adapted from the top – majority of the cases are exactly the opposite – developers bringing it in and start doing “stealth agile” before it trickles up to the top. When I’ve seen top management involved – it’s not to be trained, but to provide support for adapting it – and this is when it works the best.

    * “Project Managers as Scrum Masters”.
    I agree – a non technical person as a Scrum Master on a dev team is a risk. However, again – I almost never see this – usually it’s one of the team members with enough seniority to enforce the process. This is how I guide the teams I train, and this is how I usually see others adapting it. At most, Project Managers run Scrum of Scrums or become part of the Product Owners team (when the project is big enough). Several cases where I have seen it, the PMs have strong technical background (former devs), so it works out well.

    * “We’re looking at the new hotness”.
    Nothing wrong with looking at the new stuff, especially with so much new and exciting changes going on in software development now. The absence of talks on TDD and Continuous Integration is exactly because they are mostly mainstream now. As an similar example, in Java, you don’t find many talks on how to use the concurrent package released with Java 5 in 2006 even though everybody uses it, but you will find plenty of posts and some talks on fork-join that was just released with Java 7. That’s just natural progression. Another example is that the hugely popular Ruby on Rails has testing basically baked into the platform. You don’t think it’s a result of widely accepted TDD principals?

    * “We’re not a united front”
    So what?! I’ve never perceived it as bickering, it’s a healthy variety. If you look at most writings and talks on say Scrum vs Kanban – it’s very non-judgmental and the attitude is usually “use whatever applies to you the most”. Moreover, best practices usually converge under the right leadership and the result is pretty synergistic. For me, I use Kanban for personal projects, introduce Scrum with Lean influence to new client teams and we often use Scrumban approach within our consulting firm internally. I love this variety.

    With all this said, the biggest danger and the warning sign I see is teams falling into “Water-scrum-fall”. These are usually teams going through the motions of agile and calling it agile, but not producing enough functionality after each iteration, and what’s worse they are complacent with it. This type of approach is usually worse than the straight waterfall because of the added overhead with no apparent benefits and that’s the biggest danger I see that can lead to “Agile is snake oil” situation.

  10. Gil Zilberfeld Reply

    @Edward,

    Thank you for the comment. An “half full glass” kind of guy, aren’t you?

    No, these are not exceptions. Like Robert’s response, I’m really excited that consultants and trainers are invited into organizations, because that means that organizations have accepted and are willing to try the new way.

    And it can work miracles. And it can fail abysmally. Probably will. The “WaterScrumFall” stories already come in different flavors.

    To be successful, we need discipline. Most people are not, or not willing to do what is needed, over time. It’s not complacency – It’s just reverting to default. Or rather, working according to incentives. Sure, I’ll double my team velocity, we just won’t write tests.

    So nice try, but I’m not cheered up yet.

  11. Edward Yavno Reply

    I’m actually being quite pragmatic here. Cheering you up wasn’t my goal :), but rather arguing that the 4 specific points you listed as the main indicators of declining agile are not that indicative from my experience.

    Like I said on the Twitters – Agile is here to stay and it’s a toolbox in our disposal for building software.
    Just like with most other tools, learn to use it right and get a benefit out of it, use it wrong and shoot yourself in a foot. Or don’t use it at all if you’re happy with existing alternatives. Thought waterfall has already become much less of an accepted alternative for many projects due to competitive forces and rapid requirements changes.

    The more powerful the tool, the more benefit you can get, but also the bigger chance you’ll shoot yourself in a foot.

    – Ed Y.

  12. Gil Zilberfeld Reply

    Not trying to cheer me up? But that was the call to action…

    Agile is here to stay as long as people want it. If and when there’s overwhelming bad rep against it, agile will go into hiding.

    You want to save it? Do the only thing that matters: produce working software.

    And try to cheer people up, I don’t ask much.

  15. Vijith Reply

    Agree to the points mentioned. I am a developer and I see more stand ups than ‘working software. Trying to cover up iterative waterfall in an agile environment is more problematic than doing iterative waterfall straight away.

  17. Jeff Dickey Reply

    Gil, there’s two problems that I see affecting Agile, and they’re the same problems that have been affecting software development since I got into it professionally in the late ’70s.

    1) Underresourcing. Agile has been sold to the C-level suite as “doing more with less” and so, too often, teams that were already critically under-resourced have been cut even more. Pairing? “Can’t one guy write software by himself?” Training? “We bought an online course for you guys; what more do you need? Do it on your own time.” Domain experts and software teams working together? “Everything you need, you can ask the project manager, and what he can’t answer right away, he’ll get back to you with.” Marketroids running the show, and giving themselves bonuses appropriately. Nothing at all unfamiliar to Dilbert or Fred Brooks (of The Mythical Man-Month fame). We got “shiny new toys”, but they’ve been subverted into the continuing corporate internal/extermal marketing machine;

    2) In the same vein, companies have doubled down on offshoring and outsourcing. I’ve been asked to take over projects that have gone off the tracks and over the cliff at hypersonic speed, and when I look at the guys who were doing things before, they’re virtually invariably lowest-cost, highest-BS marketing providers who can’t even be bothered to create their own Web site with valid markup or decent English.

    Let me be clear: Every single failing or failed project I have seen in the last 35 years, regardless of development process, has had self-inflicted mortal wounds from execrable language skills and the resulting breakdown of communication. People nod their heads up and down when they don’t understand the question, and hope like hell they can figure it out before the client figures out just how pathologically, systematically clueless they are. Meanwhile, people who actually do know how to write code without putting every single module as a question on StackOverflow are “priced out of the market”, because they’ve actually invested the time and money to stay current, and (rightly) expect a return on that investment.

    Back in the seventies, Sturgeon’s Law was the defining principle in commercial software development: ninety percent of everything was crap. Nowadays, it’s the rare commercial project that does that well.

  18. Jeff Dickey Reply

    Gil, there’s two problems that I see affecting Agile, and they’re the same problems that have been affecting software development since I got into it professionally in the late ’70s.

    1) Underresourcing. Agile has been sold to the C-level suite as “doing more with less” and so, too often, teams that were already critically under-resourced have been cut even more. Pairing? “Can’t one guy write software by himself?” Training? “We bought an online course for you guys; what more do you need? Do it on your own time.” Domain experts and software teams working together? “Everything you need, you can ask the project manager, and what he can’t answer right away, he’ll get back to you with.” Marketroids running the show, and giving themselves bonuses appropriately. Nothing at all unfamiliar to Dilbert or Fred Brooks (of The Mythical Man-Month fame). We got “shiny new toys”, but they’ve been subverted into the continuing corporate internal/extermal marketing machine;

    2) In the same vein, companies have doubled down on offshoring and outsourcing. I’ve been asked to take over projects that have gone off the tracks and over the cliff at hypersonic speed, and when I look at the guys who were doing things before, they’re virtually invariably lowest-cost, highest-BS marketing providers who can’t even be bothered to create their own Web site with valid markup or decent English.

    Let me be clear: Every single failing or failed project I have seen in the last 35 years, regardless of development process, has had self-inflicted mortal wounds from execrable language skills and the resulting breakdown of communication. People nod their heads up and down when they don’t understand the question, and hope like hell they can figure it out before the client figures out just how pathologically, systematically clueless they are. Meanwhile, people who actually do know how to write code without putting every single module as a question on StackOverflow are “priced out of the market”, because they’ve actually invested the time and money to stay current, and (rightly) expect a return on that investment.

    Back in the seventies, Sturgeon’s Law was the defining principle in commercial software development: ninety percent of everything was crap. Nowadays, it’s the rare commercial project that does that well.

  19. Gil Zilberfeld Reply

    Thanks for the comment Jeff!

    Boy, I’m with you. The selling of agile as a “lean” process, while misunderstanding what “lean” really is, is a major cause of big expectations, and then a huge let down.

    Regarding dysfunctional communication, in all its forms, I agree. While agile might not be THE solution, I see the real solution as holistic, and therefore it takes quite an effort to turn whole organizations around. The fact is that we still don’t have enough experience in turning whole organizations around, doesn’t stop people from selling agile as the solution, whatever the scale is.

    I’ve written an updated post about this

Leave A Reply

Your email address will not be published. Required fields are marked *

%d bloggers like this: