The State of Agile Software in 2018 (martinfowler.com)

On the surface, the world of agile software development is bright, since it is now mainstream. But the reality is troubling, because much of what is done is faux-agile, disregarding agile's values and principles, writes programmer Martin Fowler. The three main challenges we should focus on are: fighting the Agile Industrial Complex and its habit of imposing process upon teams, raising the importance of technical excellence, and organizing our teams around products (rather than projects), he added. An anonymous reader shares his post: Now agile is everywhere, it's popular, but there's been an important shift. It was summed up quite nicely by a colleague of mine who said, "In the old days when we talked about doing agile, there was always this pushback right from the beginning from a client, and that would bring out some important conversations that we would have. Now, they say, 'Oh, yeah, we're doing agile already,' but you go in there and you suddenly find there's some very big differences to what we expect to be doing. As ThoughtWorks, we like to think we're very deeply steeped in agile notions, and yet we're going to a company that says, "Yeah, we're doing agile, it's no problem," and we find a very different world to what we expect.

Our challenge at the moment isn't making agile a thing that people want to do, it's dealing with what I call faux-agile: agile that's just the name, but none of the practices and values in place. Ron Jeffries often refers to it as "Dark Agile," or specifically "Dark Scrum." This is actually even worse than just pretending to do agile, it's actively using the name "agile" against the basic principles of what we were trying to do, when we talked about doing this kind of work in the late 90s and at Snowbird. So that's our current battle. It's not about getting agile respectable enough to have a crowd like this come to a conference like this, it's realizing that a lot of what people are doing and calling agile, just isn't. We have to recognize that and fight against it because some people have said, "Oh, we're going to 'post-agile,' we've got to come up with some new word," - but that doesn't help the fundamental problem. It's the values and principles that count and we have to address and keep pushing those forwards and we might as well use the same label, but we've got to let people know what it really stands for.

Comments

A new pile.

[Anonymous Coward]

Seems like with each new manager and team lead they change things. From codewords to project phases to agile. The not invented here mentality is the problem

Re:A new pile.

[Darinbob]

When I see things like "because much of what is done is faux-agile, disregarding agile's values and principles", it sounds like the church arguing against reformers and splitters. Agile started life sounding like a religion, and over time that has only intensified. Sure some people do it badly, but Agile is not a magic bullet that solves everyone's problems all the time as long as it's done perfectly.

The problem is the adherents insist that there are only two models - agile or waterfall, nothing else. And then they try to put the two in conflict with each other. But waterfall is mandatory in so many environments. If you must tell your customers what features will ship on a certain date in the future, then you have to have project planning in advance of building or implementing, and that's where waterfall works. Agile is good for web sites where you're just tweaking small things and doing "continuous delivery". But it becomes clumsy with complex systems, and where you need specialists and not generalists.

Sure, I have seen some advocate that you just put the design phase into agile, but you're still stuck with the silly scrum model where you have to have results every two weeks even if a design task takes two months or more.

If a company is failing because of waterfall, they are almost certain to be failing with Agile as well.

Re: A new pile.

[HornWumpus]

Agile is a manifesto full of truisms. Nothing to argue with, but PHBs are not the target audience and DON'T GET IT. Only take the parts they like, such as (para via PHB brain) 'specs are useless'.

Scrum is just a bad idea and is often called 'Agile'.

Re:A new pile.

[zmooc]

I think the main problem is something else: proper agile requires buy-in from just about any organisational layer above the agile team. Usually the time, attention-spam and understanding to achieve this is almost impossible to achieve. Agile requires trust while company hierarchies are usually organized around distrust; agile requires doing things together while traditional company hierarchies demand clear separation of responsibilities. Agile requires thinking about what to do next while companies revolve around yearly planning. Agile requires accepting uncertainty inherent to software development while companies revolve around containing such uncertainties, usually in a superficial way. Those kind of things make achieving true agile in a commercial organization next to impossible.

Re: A new pile.

[ichimunki]

Absolutely brilliant response to the Agile Manifesto. As someone who used to be an Agile fanatic, I've never once seen it work the way it's supposed to. The fact that it's so prone to abuse is just further evidence to me that it's a flawed ideal. I especially dislike the "welcome changes in requirements" part... WTF. No. It's one thing to *clarify* requirements as you go along, it's another thing to scrap them completely. And even the most rigid waterfall system always had a robust system for change control, updating requirements, and responding to new information/understanding. The best thing I can say about Agile or DevOps is that it's got management types actually taking things like automated deploys and source control seriously. But as you say, that's "tools and processes" over individuals.

No True Scotsman

[Anonymous Coward]

Just the latest management fad in a long line of management fads, watch as we wave away criticism of our touted silver bullet.

Re:No True Scotsman

[laird]

In reality, lean production techniques are why the Japanese car companies outperformed US car companies for several decades, until the US car companies copied their management techniques and (somewhat) caught up. Very real stuff, worth $billions.

If MBA's don't understand lean manufacturing and copy the form without the substance, the problem is the MBA's, not lean manufacturing.

YMMV

[ZiakII]

YMMV I still find it better then the old system and waterfall. My biggest problem you would get stuck in a 2-3 year death march when you know the project is going terrible due to the sunken cost fallacy. Now at least with agile the most you waste is 2 months.

Re:Handy cross-reference for job seekers

[halivar]

My old scrum team of 10 years had a policy of only considering half the available work hours when placing hours on tasks. More often than not, it was spot on. After 6 months our velocity projections were spot on, every sprint. After that I worked on a "scrum" team that packed everyone's sprint board with 40 hours/week of work.... but sprint "planning" ate one of those days.

Underestimating work availability and overestimating needed work was pejoratively called "sandbagging" on that team, and yet the former delivered project on the estimated date, and the latter never did, even once.

Who is agile IRL? And how did they get that way?

[sbjornda]

Athletes are agile. Ballet dancers are agile. Acrobats are agile. Martial Arts experts are agile.

How did they get that way? Discipline and practice; practice and discipline, more practice, more discipline.

Too often, Agile as applied to software development seems to mean the opposite of discipline, and I'm not sure where practice fits in.

--
.nosig