back to article Agile development exposed as techie superstition

At DevOps-focused London conference Continuous Lifecycle* today, Linda Rising challenged the superstition of tech professionals, a group that ought to have some affinity for science. Rising, a consultant, author and COO of The Hillside Group, asked for a show of hands from anyone doing some flavour of agile development. Up …

Anonymous Coward

"How many looked at the randomized controlled studies that provided evidence that agile was better than your current process?" she asked.

How many indeed. Now ask "how many started doing DevOps, Agile, Cloud, etc. because either 1) a PHB told them it is better than whatever they were doing or 2) a consultant told them that it is better than whatever they were doing or 3) it is a new fad, therefore we should do it".

86
2
Silver badge

Indeed, few devs are allowed a blank slate on which to craete code, normally its a matter of starting a psot and slotting into the way of doing things.

A few lucky people may get a new post with sufficient "power" to be able to investigate & radically change things biut most people have to work within the proscribed in house methodologies.

Suggestions on changes often met with that would be nice but deadlines so it will have to wait (and wait, and wait, ad infinitum )

13
0

At the same time, asking for randomized, controlled trials of methods of managing large projects is kind of unreasonable. Why not go the full medical-grade route and ask for randomized, controlled, blind trials? Engineers aren't allowed to know with management method they're using...

20
7
Bronze badge

Well there is another approach often used in Sociology. Find 2 groups with as much overlap in factors as possible such as tool sets, problem domains, team sizes, maturity of the product etc. Make sure they are using different development methods. Gather data for both projects and compare. Repeat the process for several projects and throw in some longitudinal studies as well. Then over time you'll have a series of naturalistic studies from which inferences can be drawn.

22
0
Silver badge

{blockquote}Engineers aren't allowed to know with management method they're using...{blockquote}

I've worked in several places like that...

As a general rule, most of the places I've worked claim to be agile but they're actually waterfall with dev pushing back on things that make no sense or we don't don't want to do. Which probably means it looks a bit like agile from the outside.

15
0
Anonymous Coward

Agile, SCRUM, DevOps, Elixir, Docker, Kubernetes, Rails, Hadoop, NoSQL, Kafka, Blockchain, DeepLearning, WebASM, JQuery, ReactJS, Angular, ...

...hipsters these days.

All these cargo-cult behaviour, barely implementing a fad and quickly moving on the bandwagon to refactor everything to another new new unproven tech or methology.

Objectively, one is better of avoiding the fads and stay with proven things like: sysadmins, waterfall, XP, PHP, MySQL, Nginx, C, C++, Go, vanilla JS, HTML5, VBox/VMware

18
1
Anonymous Coward

Your ideas are intriguing to me and I wish to subscribe to your newsletter

Well there is another approach often used in Sociology. Find 2 groups with as much overlap in factors as possible...

Interesting -- is that a name for this approach so I can read more about it? Not being sarcastic, it seems a good approach to analyse some educational techniques (e.g. which factors have more influence on Problem Based Learning).

But in a software development workplace it has the advantage of leaving precious little time for development itself :-)

2
1
Anonymous Coward

Re: Your ideas are intriguing to me and I wish to subscribe to your newsletter

agreed, but think of the time saved re-doing it over and over, badly.

IMNSHO, to misquote Shakespeare about lawyers...First we hang the PHBs who read tech magazines and think they understand them, shoot remaining PHBs who think their job does not include running interference FOR the coal face crew. Ironically to some, highly reward those PHBs who understand this. They are literally priceless in their assistance to IT staff. Sack immediately any marketing or sales weasels who dare to show their faces inside a software coding space or use email to do so. Snail mail contact only. However we live in insane times where failure is rewarded handsomely and often.

6
0
Silver badge

Mostly...

Number 3.....

1
0
Bronze badge

Re: Your ideas are intriguing to me and I wish to subscribe to your newsletter

Here are some ways sociologists, use what fits https://www.cliffsnotes.com/study-guides/sociology/sociological-research-methods/sociological-research-designs-methods

I think I was talking about observational and case studies. But even so they try match up groups, e.g. while studying education level and it's impact they would try to control for age, ethnicity, income level of the subject's household while growing etc.

As far as burden you can run reports on defect escape rate, features delivered etc. which should be documented somewhere.

3
0
Silver badge

There were studies ...

You will find a list of some at the end of this fine advice for programmers. As the most modern reference is for '92 I can understand why only grey beards are aware of them.

28
0

Re: There were studies ...

Some of my coworkers and I noticed the same affect around the same time. We would have a problem with our code and ask another programmer to look at it. While explaining the code to the other programmer, we would, inevitably, see the issue ourselves.

We would joke around and say that all we really needed was a golden retriever that would just sit there so we could explain it to him. After a while, we would literally ask someone to come to our desk to 'play golden retriever'.

I have also seen this practice call 'rubber ducking', the idea being you sit a rubber duck on your desk and explain the code to them.

Whatever the name, it is a highly effective practice.

44
0
Silver badge

Re: There were studies ...

"While explaining the code to the other programmer, we would, inevitably, see the issue ourselves."

Yes. I've been doing this for a couple of decades now. I used to keep a stuffed animal on my desk to explain the problem to, but eventually I stopped needing the prop. Now I write an "email" that explains the problem instead. I get the same effect and my coworkers have one less reason to question my sanity.

21
0
Silver badge

Re: There were studies ...

I used it in University. Friend of mine named Mark Bjorke. He would just smile and nod while I went over the code until I found the problem. And I was always sure to thank him.

This was back in 1974, in Fortran IV on an IBM 360/50 running OS and HASP (Houston Automatic Spooling Processor). And my beard is silver, dammit, not grey!

:)

23
1
Silver badge

Re: There were studies ...

AKA Rubber duck debugging.

It works in reverse, too: you can debug other people's code by getting them to explain it to you until they spot the bug.

11
0
Silver badge

Re: There were studies ... and a result is Donald J Trump .... an Energetic Distraction?

Is the current President a valuable precedent to set for Emergence of Future Savvy Existence, with this Clone Role Cannily Filled for Fulfilling .........

The contribution of the Cardboard Cutout Dog to Software generation and maintenance is well known to practitioners of the software arts - but perhaps many have forgotten how it came about. This paper presents a retrospective of the evolution of this invaluable technique and delves a little into the future development of the technology.
...... which proves itself to be an Addictive COSMIC Pleasure .... with the Generation, Guarding and Distribution of Immaculate Treasure to XSSXXXX Levels/Depths/Heights for Bounty Hunters and Privateering Pirates alike?!

That has Greater IntelAIgent Games Players Travelling in Parallel Planes to a Similar Familiar Ultimate Destination ...... Back to the Very Beginning to Start IT All Over Again with Everything Known to Man and Womankind Freely Available for Using ...... thus to Search to Find Anything New which is Core Raw Source Applied Imagination and a Future Perfecting Driver for NEUKlearer HyperRadioProACTive IT and Quantum ProgramMING.

Fire up the very best of that and you're gonna need a whole new Class of Cruise for Easy Street with Sweet Castles to Savour and Favour.

1
8

Re: There were studies ...

A former manager called it the "wooden Indian" method - after the mannequins of Native Americans used in the US to advertise cigarettes.

2
0

Re: There were studies ...

We called it "Hey Elton". Elton worked in shipping. If no one else was around, he usually was.

2
0

Re: There were studies ... and a result is Donald J Trump .... an Energetic Distraction?

Stop smoking that stuff - it's rotting your brain...

0
0
Pint

Re: There were studies ...

Used to call it the "cardboard programmer" technique.

It inevitably had two outcomes: A fixed problem and a confused colleague.

So a "win win" then

0
0
Anonymous Coward

Been there done that

I worked at an agency where pretty much every week we were told to follow some new way of development.

I kept asking the same questions, why is it better than the current way, what is it going to do to improve things... Never did get an answer.

One week we were told to delete the branches after we submitted them for testing and were merged, so the manager could see which branches were ahead of the main branch (if we deleted them it was obvious for him to see apparently), if any changes came back we'd need to make new branches to continue working.

7
0
Anonymous Coward

Agile is b*llocks. Any non-idiot knows this.

I think we can all agree that DevOps and Agile is the latest buzzword-driven nonsense pushed by half-witted consultants in cheap suits, who know nothing yet opine much.

As 'using the cloud' is nothing more than putting your balls in someone else's vice and hoping they know which way to twist the handle, Agile is relying on meaningless ritual and mantras rather than on your own intelligence. If you need a crutch like Agile, or you think that going to a conference like this is actually making you a better person, then you're simply not very good and should be in another industry. I expect McDonalds always has vacancies as people fall into the meat grinders.

I shouldn't have to stress this, but DevOps and Agile is nothing to do with using the best tool for the job in hand; any sane individual in any walk of life does this without needing any more of a label than 'common sense'.

Still - you Agilers enjoy your bickering, your funny sports metaphors, your daft terms and sermons - you're generally harmless as long as you're not typing, and you'll all be outsourced soon enough anyway - and us real developers will get on with writing the solid code people use every single day. And getting paid very handsomely for doing so.

Bye.

54
10
Silver badge

Re: Agile is b*llocks. Any non-idiot knows this.

" you think that going to a conference like this is actually making you a better person, then you're simply not very good and should be in another industry. "

To be fair, discovering the pointlessness of this is a rite of passage. If you don't grok what's wrong after the second conference that convincingly contradicts everything that was so convincing in the first then you really should be in another industry; probably management consultancy.

23
1
Anonymous Coward

Re: Agile is b*llocks. Any non-idiot knows this.

I call it "Fr"agile. Because it broke down so very often.

In my last but one role, one person was able to achieve the same output as five people following an Agile process. The one person just got on with the job instead of argung about Test coverage, Build processes and all that other crap.

Guess which had the lowest bug rate as measured after one year?

hint, not the Agile one. Either the methodology is wrong or the people who were using it were crap.

21
4
Anonymous Coward

Re: Agile is b*llocks. Any non-idiot knows this.

They'd struggle to get a place at McDonalds now what with all the self service screens replacing staff.

4
1
Bronze badge

Re: Agile is b*llocks. Any non-idiot knows this.

This is the perspective of one of the original authors of the agile (small "a") Manifesto. An interesting talk titled "Agile Is Dead" https://www.youtube.com/watch?v=a-BOSpxYJ9M

3
0
Silver badge
Devil

Re: Agile is b*llocks. Any non-idiot knows this.

I call it "Fr"agile. Because it broke down so very often.

There should be a requirement to use "the hacker term" whenever possible. It usually lacks the ironic, oxymoronic, and/or "market speak" overtone, replacing it with a more accurate (and humorous) term.

'Agile' - like someone who's told to "dance" in an old western (while bad guy shoots at his feet)

To upper level management and marketeers [that want to drive development], it must sound like a MIRACLE!

To the rest of us, it sounds like "endless boring meetings" "last minute overtime crunches" "spinning compass direction guessing" and "getting yelled at a lot for being unable to meet expectations".

etc.

11
1
Anonymous Coward

RE: Either the methodology is wrong or the people who were using it were crap.

Probably both, but the methodology was being *applied* wrong or misunderstood.

I run two agile teams of junior, mid, and senior devs. Our main products have bug rates *in the single digits per year*, and this is for complex projects (sites, enterprise integrations etc) with public interactions. At the same time we are known within our organisation as teams that get things done fast as we rely on delivering value rather than to specs. We also iterate extremely rapidly.

This is not to boast, or even to say agile is better (I would have the same single digit bug rate as a solo dev and we are not tied to agile if it were not working; the decision is a dev team one), but rather to point out that - when done right - agile does not have to be a worse way of working.

4
1
Anonymous Coward

RE: "endless boring meetings" and "last minute overtime crunches"

Agile team(s) lead here.

We have only two meetings per week as part of our agile process; a backlog grooming session (awful term) and a retrospective (which is devs only). That's it. I don't count daily stand-ups as they take minutes and are not meetings, simply a quick statement about each ongoing bit of work.

If you need more than this then that is because *you* need more than this, not because agile requires it. And there's a good chance, therefore, that whatever "system" you did you'd have the same problems.

6
0
Silver badge

@AC

"Agile is relying on meaningless ritual and mantras rather than on your own intelligence."

No it's not.

See, that's is the exact same problem you see happening with other development / design schemes such as UML / SysML. It's not the practice or the modeling language which relies on meaningless crap: that's what those beancounters / consultants want to make you believe.

Take for example "You need to stand during the daily meeting". That is bollocks, because the standing part is only a means. The goal is to keep the whole meeting as short as possible. You don't have to stand up for that, you can just as easy sit down and agree that each person gets no more than 2 - 3 minutes to summarize their issue(s).

But if you're in a crowd where no one questions anything and blindly allow themselves to get led around by example alone then you get into this mess. But in this case you really should blame the messenger.

9
0
Bronze badge

Re: Agile is b*llocks. Any non-idiot knows this.

'using the cloud' is nothing more than putting your balls in someone else's vice and hoping they know which way to twist the handle,

Utter brilliant; I'll definitely be ripping off your comment and will randomly throwing it into polite conversation.

10
0
Coat

Re: Agile is b*llocks. Any non-idiot knows this.

Utter brilliant; I'll definitely be ripping off your comment and will randomly throwing it into polite conversation.

Great idea!

Nice sermon, Reverend, but 'using the cloud' is nothing more than putting your balls in someone else's vice and hoping they know which way to twist the handle.

Sorry.

9
0
Silver badge

Re: Agile is b*llocks. Any non-idiot knows this.

I generally agree with what you've said.

But I do think Agile has a place - a very specific place - but it is being used as the corporate development methodology instead of using it only in its appropriate niche.

TLDR version: Agile is a tool fit for certain types of projects, it is not a be-all end-all methodology, or even the 'default' methodology when a new project spins up. A project itself should be able to work out in its initial management-level phases what methodology (or methodologies if it's big enough to spawn sub-projects) it's going to need.

Full rant

As was explained to me - and patently common-sense obvious - during the in-house training sessions that some high-priced consultants were brought in to perform, Agile was one of several methodologies in the toolbox, and you need to pick the right tool (methodology) depending on the circumstances of the project.

This consultant drew up an XY graph (positive quadrant only), with the vertical (Y) axis labelled COMPLEX at the top and SIMPLE at the bottom. The X axis was labelled on the left - where it intersected the Y axis - with WELL DEFINED and at the right with UNCERTAIN.

These referred to whether the task itself was a complex task (e.g. building a nuclear power station) vs a simple task - walking the dog. And the X axis referred to whether you had a precise specification of what needed to be delivered, e.g. working from an engineering blue print, or whether you only had a general idea of what the end-goal the customer wanted - I want a high tech fighter plane that has gee-wow features - which is likely subject to change in the details - I now want this feature added, no take that one away, hey a senator says he'll block funding unless we make this widget in a factory in his state.

So something like the F-35 would be at the top (COMPLEX) right (UNCERTAIN) quadrant, a giant cruise ship at the top (COMPLEX) left (WELL DEFINED) quadrant, making a model-kit airplane at the bottom (SIMPLE) left (WELL DEFINED), with decorating the office of the new PM being in the bottom (SIMPLE) right (UNCERTAIN) quadrant.

If you project falls into the top-left, then waterfall (or similar) is most likely the appropriate tool.

If it falls into the bottom left, who cares? It's simple and well defined, detailed specifications, just get it done.

If it falls into the bottom right, that's Agile, as you'll have to adjust what you are doing as the customer changes their minds, adds/removes features, and so on.

If you are in the top right, you are already doomed so might as well just give up before getting started. (In an ideal world, it'd be up to the Programme Managers to sort it out, and split it into sub-components that could then be hoiked off to one of the other three quadrants, split it up into sub-programs that that will then fall into waterfall, agile, who-the-fuck-cares quadrants).

So Agile is a tool that works in specific categories of projects - government projects tend to fall in this category, as they are always changing. There could be a change of government itself during the life-cycle of the project therefore specifications/priorities change, or old-fashioned political infighting - SLS vested interests for example.

Edit: added the TLDR.

10
0
Silver badge

Uncertian, Complex...

Think Apollo Moon project.

Sometimes it can be done. It takes time.

2
0
Silver badge

Re: Agile is b*llocks. Any non-idiot knows this.

I suspect your man was a mapper: for those that haven't seen this, it's worth a read. In my thirty years of coding it's the only idea that's stood up to scrutiny.

1
0
Anonymous Coward

Re: Agile is b*llocks. Any non-idiot knows this.

> hint, not the Agile one. Either the methodology is wrong or the people who were using it were crap.

Two things can be true at the same time. Plus, maybe agile attracts the crap people.

3
0
Bronze badge

Re: Agile is b*llocks. Any non-idiot knows this.

and always write it with a small "a" and not as a proper noun.

1
0
Silver badge

Re: Agile is b*llocks. Any non-idiot knows this.

As 'using the cloud' is nothing more than putting your balls in someone else's vice and hoping they know which way to twist the handle, Agile is relying on meaningless ritual and mantras rather than on your own intelligence.

Entertaining.

Using the cloud is just using other peoples computers, hopefully everyone sees this and understands the risks. So how the hell has it gotten so popular? Well, from a developers perspective, the on prem servers are other peoples computers - they belong to networks/ops/whatever your business calls them this week. Getting access to them is all too frequently painful, involves lots of paperwork, and takes a disproportionate amount of time. Getting more servers in the cloud is trivial. Which, I'm guessing is why so many devs find the concept so appealing. Note ye rash downvoters, that I'm not suggesting its a flawless plan from the companies perspective and certainly not over time. These are, after all, other peoples computers which now hold all of your data.

Agile is just a means of managing code production. The best bit about it, is that management types expect push back, or scrolling deadlines as the spec changes. What they no longer expect is a deadline to be fixed, with a fixed resource budget, and a spec to be fluid. All that does is kill the developers social life. Waterfall doesn't work - we've known that for more than 20 years. I'm not suggesting Agile is brilliant either, but its less disruptive to my social life than waterfall was. Just ignore the ceremonies, sermons etc and crack on. Its easier to get the PHBs to focus on one small thing at a time, rather than understand the whole of their business process and be able to coherently model that in a way that can then be implemented.

1
0
Bronze badge

Let's get rid of these myth too

They have no scientific foundation.

they are:

10x programmer

Exponential Defect Cost Curve

The Software Crisis

https://blog.fogcreek.com/10x-programmer-and-other-myths-in-software-engineering-interview-with-laurent-bossavit/

3
1
Silver badge
Devil

Re: Let's get rid of these myth too

"10x programmer"

no, that would be me. The secret to being a 10x developer is to get as much done in as short of a period of time as you can, so that you'll be left alone to work independently on "the hard stuff".

So if you come in and there's a backlog of things that need to get done, you hit them in order of 'easy to hard', with some "high priority" items stuck near the top so that people are happy with you. not only do you look as if you're DOING SOMETHING, you earn the freedom to approach things your own way, because it WORKS.

Then, when you've reached that difficult thing, you can spend time on that as you need to, because everything else got done. You can explain how hard it is, and maybe break it up into smaller goals that you can get as many as possible "done" within a short period of time, so it looks like you're busy and good at what you do.

Interestingly, when you reach a major roadblock, that requirement might end up being removed, when other people see how much effort is required. They get used to getting things done, too. Everybody wins.

7
0

Re: Let's get rid of these myth too

Equally, the software defect curve is true too if you have a large complex system with many integrated parts, e.g. a complex workflow with many microservices, or a serverless implementation with many external functions. Get one of the microservices or functions 'wrong' (insecurity feature, for example) and you are faced with a dilemma - don't thoroughly test and risk downtime, test and implement expensively.

The costs of test and implementation are not related to how automated you are in testing, deployment, scripting etc, but in how tolerant of failure you are. Are you prepared to risk an outage? Do you have paying customers with penalty clause contracts? No? Hack it up, the customers will find it. OTOH, if it'll cost you money for something to fail in production, you're pretty much humped if you think anything is going to make it cheaper - the only thing that'll make it cheaper is minimising chaos in the development and deployment process and agile really doesn't do that.

0
0
Bronze badge

Re: Let's get rid of these myth too

Have you measured your output? How? Never underestimate the https://en.wikipedia.org/wiki/Dunning–Kruger_effect

1
0
Bronze badge

Re: Let's get rid of these myth too

Have you done studies on it? Would you publish your results online?

0
0
Silver badge

randomized trials

I suspect that any attempt at rigorous trials would be subject to the "Hawthorne Effect".

I suspect also that many of us are aware of obstructions to our work, and are susceptible to ways of working that seem to reduce these obstructions. Whether these ways of working amount to "methods" is another question.

2
0
Silver badge

Thank the heavens

Thanks Linda for finally calling this out, although I'd not go so far as to say that all "agile" is bollocks. It's just that organisations implement it differently and not necessarily with all of the controls required to ensure it is achieving it's goals.

We have the same issue at our place where our CTO is like a kid in a sweet shop when it comes to implementing new methods. Two years after I pulled his business case and implementation approach apart they are still trying to implement it successfully. I guess our organisation must have more money than sense though as they are still chucking cash at it.

6
0
Silver badge

Re: Thank the heavens

"It's just that organisations implement it differently and not necessarily with all of the controls required to ensure it is achieving it's goals."

This hits on my chief criticism of Agile methodologies. I've rarely seen them actually work properly, and every time they fail, the response is "you guys weren't doing it right".

That may or may not actually be true, but let's assume it is for the sake of argument. If that's the case, then it means that Agile is so complicated and fragile that it is extraordinarily difficult to "do it right," since so few people seem to be able to pull that off.

Any methodology that can't be adequately implemented by the average practitioner in the field is a broken methodology, no matter how great it may be if done perfectly.

15
1

Re: Thank the heavens

Ironically, the problem is exactly the opposite - in that the 'Agile development process' doesn't really define anything concrete. The core premise was always fairly ethereal - to value conversations, iteration and discovery over hard strict formal processes.

The problem is most managers (and to be fair most devs) find a lack of formal process uncomfortable, and need a strict framework to work around - and after all you can't produce pivot tables & performance reports out of the 'Agile ether'.

So the 'Agile method' becomes enshrined in strict formal processes so the management can measure it & report it and the less capable team members; 'supported'. So it's not that most people 'do Agile wrong', it's that most people just don't do Agile at all - they just call it "Agile", and wrap it up in their familiar, comfortable (reportable) processes.

Of course the other extreme is the PM/PO that thinks 'Agile' means you just throw a wishlist over the fence and expect everything to happen by magic - on time & on budget.

Calling Agile boll@x is a luxury only those that code alone have, the rest of us have to work in teams - typically with a wide range of skill, experience and frankly basic engineering talent.

Personally the core premise I'd add to 'Agile', would be to abide by the "Mythical Man Month":

Hire fewer people, create smaller teams, pay them better. Expect great people to produce higher quality results faster, get out of their way, and allow them to get on with it.

24
1
Silver badge

Re: Thank the heavens

"The core premise was always fairly ethereal - to value conversations, iteration and discovery over hard strict formal processes."

In which case, Agile brings nothing to the table at all, since that core premise has always been at the heart of best development practices (or at least, it has in the 30 years that I've been in the field).

7
1
vir
Silver badge

Re: Thank the heavens

"You guys weren't doing it right." = "Hire my company to consult for 6 months at $50,000 a week."

8
1
Silver badge
Unhappy

Re: Thank the heavens

On the surface, 'Agile' sounds more like 'affiliation' management style, rather than a proper top-down 'delegator' style. Even a dictatorial 'authoritarian' style would be better [since directions and specifications are more likely to be clear, and not moving all of the time].

As opposed to what FRagile appears to be, an affiliation-based collective with a "let's just have a meeting and that will solve it" approach, because PFY *must* have ideas that are as good as grey-beard-ent engineers, because, FRagile. And meetings fix EVERYTHING!

/me once wrote a proof of concept in ~8 weeks [total effort], a linux kernel module, that was used as the demo for a new software product that was being worked on by 3 people (manager, senior eng, junior eng) for a *YEAR* and they STILL didn't finish, so they asked me to come back into that project [when junior guy was getting laid off] and basically 'get it working'. I saw the manager's door closed a LOT during that year, while the 3 of them wasted endless time in 'meetings' and I worked on a bunch of 'other things'. And I heard senior engineer trying NOT to complain, but throwing his hands in the air [effectively] at what "was decided" by the other two. A LOT. He did what he was told. Can't expect much else, really.

And, the talk when they started? How great 'agile' was and how they wanted to implement it in this project!

I've been told that what THEY ACTUALLY DID was not "agile" but who knows, maybe it really _was_...

1
1

Page:

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Forums

Biting the hand that feeds IT © 1998–2018