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 …
"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".
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 )
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.
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 :-)
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.
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.
{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.
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
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.
"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.
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!
:)
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.
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.
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.
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.
" 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.
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.
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.
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.
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.
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.
"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.
'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.
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.
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.
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.
"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.
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.
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.
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.
"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.
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.
"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).
In essence you're correct.
Agile is never about a process. It is about a mindset. A codification of principles to remind developers about the lessons learned over the industry lifetime.
Unfortunately vendors cannot sell a mindset so they offer a toolset instead and the two get conflated.
"the rest of us have to work in teams - typically with a wide range of skill, experience and frankly basic engineering talent."
This is where proper management comes into play, and a 'top down' method is superior: you define the requirements, put one member 'in charge' of the sub-tasking, and hand off "the task" to them in a way that stays out of other people's sandbox as much as possible. 'The Manager' would then be in charge of anything that crosses into other sandboxes. The manager would also assign the teams.
Competent management makes this possible. A lack of competent management may be the ROOT of why 'agile' was *FELT* to be "the right thing to do" (in a kind of 'straw' test case). Results, predictable.
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_...
I've seen agile methodologies work properly in multiple companies. Every time I've seen them fail, it's because they weren't being done right.
It may well be fair to state that this makes them fragile. I'd phrase it differently: They're very high discipline, and require intelligence and capability from the people using them. People that think about their development process, challenge and optimise it, and focus on delivering working software stray towards agile approaches whether that's the policy or not.
I don't think that means agile methodologies are broken at all. I think it means teams (and managers) need better self awareness, understanding, autonomy and a broader skillset than knowing language syntax.
Good software engineers use agile methods, crap software engineers fuck up whatever methodology they're using then blame management for imposing it on them.
Sorry but Linda Rising sounds like someone that is talking about something that she has no experience in - and being a COO it is quite a possibility.
Linda uses incomplete examples and metaphors to put forward a lacking State or concept. Pretty poor actually, but it all shows she needs a bigger view on Agile and a better understand of how to be a proper COO.
Actually, 10+ plus years of working and utilising Agile concepts is a good enough dataset showing that Agile does add more value than old-school waterfall methods. Agile is after all, just 'FUNCTIONAL' Coding, breaking functions and features into encapsulated pieces of work (that also includes what is needed to make post-live support) and wrapping a pull process around everything.
BUT to move into a DevOps approach you need to get rid of Scrum as it adds artificial barriers to continual improvement. Kanban works better than Scrum.
Anyone that fails within Agile has a poor framework and management around them, so it's not their fault.
If Rising is a COO then she is a very poor one. The 'As Is' and 'To Be' Operating Models have nothing to do with Science, nor do the 'Agile' coded improvements to Capabilities - it's adding new "business benefits" to the Business Capabilities - all of which links to Strategy..
Project Work (Coding) -> Deliverables (Software) -> Programme (of Projects) -> New or Improved Capability -> Business Benefit
I simply feel Linda Rising's view is just wrong and based on poor knowledge and understand
"I simply feel"
got my downvote. just being honest.
The problem with Agile appears to *BE* "feel". Instead of 'think'. Or study. Or analyze. Or 'manage'.
My number one example of this: The 'scrum' meeting in which everybody gets to have their 'say', including the PFY that wants to feel good about himself and his ideas. I've seen it before, and it was a disaster, when "junior guy" convinces "manager" that HIS idea is a good one, and then "manager" tells "senior people" to do it the way the PFY wants it done, amidst objection, but he's the boss. etc.
because, *feel* instead of think. A proper manager would NEVER allow THAT to happen. But it does.
And at the same time, science is not enough. "We know that evidence is not convincing for anyone, at any age," she said.
OK.....rather a sweeping statement there, do you have any, you know, EVIDENCE for what you're saying? Or is such a concept a kind of heresy in the faith-based world of Agile conferene land, as the true believers listen in rapt awe to the preachers of the new religion? What's next : "Agile works in mysterious ways"?
Rising encouraged those exploring new ways of working to involve others, to tell stories about their small experiments. "That will convince people more than any kind of evidence," she said.
I rather thought that stories about experiments were "a kind of evidence", seeing as they would have to consist of at least some statistics and analysis to be of any worthwhile substance and usefulness. Passing on experience of positive outcomes for the benefit of others is not exactly a wildly new and original idea in any field ever, and only adds more, erm, evidence to the theory that simple platitudes and snake oil are still available in profusion in agile world.
Pointing to the science pioneers like Isaac Newton, who is buried in Westminster Abbey, across the street from the conference venue, Rising observed that while we recognise science, we don't often practise it.
"For those who call themselves technical people, this is a strange way to make decisions," she said.
Oh dear. If she knew anything about Newton she'd have known that he was a deeply religious and superstitious man who dabbled in the occult, alchemy, prophecy, Biblical chronology and interpretation, Rosicrucianism....
"If your agile toolset is screwing things up, change it, repeatedly, until you settle on something that works"
That rather depends on having a consistent project-wide (company-wide?) definition of "works". One day maybe there'll even be industry-wide definitions of what works, but we're not there yet.
MethodX may appear to save development and test costs, which is what the management du jour appear to get paid for. Therefore, at least initially, it is "agreed" by ThePowersThatBe that MethodX works. MethodX may also sometimes have some predictable (to non-management) snags which, when they become obvious, are hidden until manglement have implemented the next stage of their personal career plans.
KinkedIn is full of career histories of muddle management (aka seagull management) who have come in, deployed some fashionable new approach in a blaze of internal publicity, and who have moved on when it becomes obvious that the smell near the roses isn't the perfume of success.
How do you proposed to do a randomized control study here? Lets say you decide on your metrics (quality, maintainability, delivery date, staff retention or some combination of a hundred other things). Will you get a couple of dozen teams to independently develop the large scale system? Will they have exactly the same level of skill, experience and context?
If you claimed you constructed that study I'm sure it would be torn apart in an article on The Register the day it was published.
Where's the evidence that a non-agile approach would work 'better'?
Also, remember that agile teams are self optimising, making changes to their own process based on quantitative data (eg #defects, time) as well as valuable qualitative data.
I did a little digging with IT friends after this talk, and I discovered that at least one company had done before/after research on the effectiveness of both Agile and static analysis, using their bug database spanning 20 years. Their conclusion: 70% increase in critical bug clearance rate after implementing scrum, and double the feature clearance rate. Static analysis improved the bug counts down by 60%, while slowing the speed minimally. Only, given that this was proprietary information, they haven't published.
Now if one company did this, surely they weren't alone. Management loves numbers, remember?
Of course there are no scientific studies for all these management fads like agile. There cannot be. It's not possible. The only way you could compensate for all the confounding factors when comparing, say, agile and (to invent a term for non-agile) clumsy is by a gigantic number of tests and statistical analysis. [Note, I exclude pair programming and rubber duck programming from this analysis because they might actually work.]
What confounding factors? Well, start from Fred Brooks' "Plan to throw one away, you will anyway." He's since recanted somewhat, but the fact remains that during the first implementation you end up learning a lot, to the extent that you spot all the things you did wrong and figure out better ways you could have done them if you'd realized those problems at the start. So you cannot have the same team try it first with agile and then with clumsy because they'll have learned a lot from the first go round.
So you need two teams, one to try agile and one to try clumsy. But you know damned well that teams are a mix of people and you cannot get an identical mix twice. Similar, maybe, but all it takes is one guy who thinks slightly differently to steer things down an entirely different path.
Now factor in that customer requirements change mid-project. Doesn't matter if it's agile or clumsy, the customer requirements change. They may change more frequently, and to a greater extent, with agile but that can be a mixed blessing.
You can't meaningfully compare different projects run different ways. Not for one-offs.
So one possible way of comparing is to have many, independent teams all implementing the same project, some using agile and some using clumsy. Except customer requirements change. What the customer learns from the agile teams may be reflected onto the clumsy teams. Which just leaves you with comparing the results of many, many, many different projects run in various ways and having a large enough sample to hope that you compensated for all the confounding factors (you can hope, but you'd be wrong).
It's just not feasible to scientifically compare these things. Do stand-up meetings help? Or is limiting a meeting to five minutes better than ten minutes? Should it be the scrum master who supplies the meeting with biscuits or the product owner? Should the biscuits be custard creams or jammy dodgers?
All of these management fads are dogmatic ideologies. Somebody, based on personal experience, noticed a possible correlation between doing something and something happening, which may have been pure coincidence. The classic post hoc, ergo propter hoc fallacy. Agile is as much a dogmatic ideology as Marxism, Free Market Economics, Freudian psychoanalysis, and any religion ever. Somebody made some shit up, possibly based on anecdotal evidence, possibly based on pulling stuff out of his arse, and enshrined it into a Holy book that may not be questioned. Ever.
Here's an enlightening video on the problem with dogmatic ideologies. 20 minutes, but it does explain some of the problems with them so is worth a look if you can spare the time.
This post has been deleted by its author
A lot of what we do in this business boils down to whatever is fashionable. That might be the language du jour or the methodology of the moment. And everyone, to some degree, creates straightjackets for themselves, while most have some tool or method that happens to be their own signature hammer*.
So yeah, the frequent/frugal experimentation, proposed here, does strike a chord. I think too many teams end up doing Agile in a way that doesn’t serve themselves or their client. Monkey see; monkey do.
* Excel lovers are the worst offenders, in my experience.
I'm certainly showing my age/experience here -- over my career in software development I've endured iso9000 certification, six sigma, total quality management, and a few others that escape me at the moment. Somebody is always writing a dissertation, gets their degree, writes a magazine article/book, and bingo, the management types see something they can implement to discuss in their annual review -> get raise for. Unfortunately, for us, this results in yet more silly process stuff and buzzwords to learn and slow down development.
Agile is just the latest fad iteration, which I'm seeing fail regularly today -- much to the chagrin of management. IMHO, Agile seems fine for small, relatively straight-forward projects without many dependencies. It fails for large, complicated projects with many dependencies / stakeholders. I've seen it over and over again. For such large projects, we're back to using the waterfall process -- which provide the schedule / resource information managers need, and we meet the schedule we've produced, so management has learned (again) to trust us.
I remember the day management first sprang Agile on us -- all of us experienced folks had the same look on our faces -- time for a blanket party for the Agile advocates -- using our copies of "The Mythical Man-Month" book by Frederick P. Brooks Jr. to beat them with. But, of course, experience has show us that sometimes trying to reason with management doesn't work and you have to go through the motions and let them see the folly of their ways themselves. First large project using Agile was a disaster. Testing folks didn't get what they needed when they needed it, Documentation folks couldn't get people's attention, components didn't work well together, quality greatly suffered, and we had no idea when we'd be "done". Senior folks performed triage, rescued the project. So -- now we do Agile for small projects, waterfall for larger ones.
This. Absolutely this.
For larger pieces of work I've found that Agile Just. Doesn't. Work. I mean, yes, you can build something that will functionally fit the requirements, but after a few iterations you find you've coded yourself into a corner and end up having to strip out huge chunks of existing, tested (often) production code in order to solve the problem.
Then you have the task of maintaining the inevitable rat's nest of objects that have resulted from the ad-hoc, piecemeal development (or, just end up ripping out the whole thing to start again).
I find that a combination of more traditional up-front/Waterfall design works well when used in conjunction with agile methodologies - spend the time up front to design the overall 'shape' of what you're building, design the framework and APIs off of which you'll hang the individual features and spend a chunk of time upfront building that and getting it working. Then switch to a more agile mode to build the individual features and components, always ensuring that they hang off of the framework that you'd spent the time up-front to build.
Tends to lead to more stable, better designed systems and ultimately, much more robust code in my experience.
Management fixates on surface details; we must use Jira, have standup, sprint planning, training classes etc. So But they do not grasp the underlying spirit and social messages. They buy the books, read the articles etc. but done read deeply enough. It's sort of like "everyone successful is wearing wide ties so I look successful and so will be successful". I somestimes refer to "cargo cult" management or programming.
Your post is a good example of using appropriate tools and being agile when developing software, use what works. If waterfall works, use it.
And then there is the matter of 2 week sprints. Everyone fixates on that. But to be agile you adjust sprints to the the complexity and organizational friction you encounter. Maybe 3 weeks or 4 weeks or whatever you need.
Remember, agile is an adjective not a noun.
The thing that's always grated about Agile technique is that it not only states the bleedin' obvious but tries to pretend that what its peddling is new and improved. Like all developers I need to work collaboratively to quickly produce working code that solves a problem or fulfills a need for a customer, its how we get paid. Regrettably, though, customers (at least the ones I work with) tend to also require maintainability which necessitates significant focus on tool chains, documentation and processes. The trick to successful work is finding a balance, knowing how to trade off actions even when they seem to conflict. Its a knack (and its why we get paid the big bucks). (You seriously don't think we get paid just to write code, do you?)
Taken literally, Agile development seems to be a bottom-up approach to design that follows the general rule of "Hose the code at the barn wall and see what sticks". I'm sure that's not what was intended by the Manifesto's author but that's how it seems to come out in practice.
We've talked about the usefulness/uselessness of Agile around the water cooler many a time and we generally agree that what matters is not the process itself, but that you HAVE a process. It doesn't really matter what it is, so long as you have it, you document it, and you follow it. (And you improve it whenever you find flaws.) Do that and your Agile process or Waterfall process or even Donkey-Unicorn Rainbow Fart Party process will be better than NO process. (Or any poorly defined process.) Switching to a completely different process only improves things if you do a better job of documenting and following than you did with the last process, and is not a function of the methodology itself.
It seems clear to me that Agile is too many things to too many people. Perhaps we can blame that on the bottom up nature of the thing. In recent weeks, I’ve talked to people who evangelist it, from their own experience, and others who prefix it with a silent fr.
Agile development could be shown by construction to be superior to some other methodology. There are more ways than one to demonstrate superiority.
But...
I sure wish we got to *do* agile development. Breaking work into sprints is great, but allocating 100% of resources on each sprint guarantees stuff will be late. And then yelling at staff for being late hardly values individuals over process. Doing frequent iterations is great, but refusing to plan altogether is an abrogation of responsibility that earns unsurprising results. I have yet to work in an agile shop that actually understood what the Manifesto was all about.
Agile has been taken away from developers and used by management as a stick to beat us with. Any blame for the poor results of magical thinking should properly flow to them.
Hello, I am a overconfident consultant from Fartworks. I am paid silly amounts of money to tell you to rewrite your code in <Scala> using Agile fluff fluff poo bum buggy break the production server release cycle, with Containerised vats of wee, then I'll bugger off after a few months and leave you to sort out the mess I made.
"... who'll bugger off after a few months and leave you to sort out the mess they made."
Good job that kind of thing doesn't happen in the safety critical systems world, who knows where that might lead.
In unrelated news from the airline engine market, Rolls Royce Trent 1000 engines, as used on some 25% of Dreamliners, seem to be still having reliability issues with some versions of the engine, leading to increased frequency of inspection (ie increased costs) and now to decreased ETOPS ratings (was 330 minutes, will likely be reduced to 140 minutes thereby disqualifying the affected Trent 1000 variants from much of its target market for the time being):
https://uk.reuters.com/article/uk-rolls-royce-hldg-engines/rolls-royce-and-airlines-grapple-with-further-dreamliner-engine-issues-idUKKBN1HK0L4 (13 April 2018).
https://www.telegraph.co.uk/business/2018/01/02/rolls-royce-kickstart-turnaround-executive-shake-up/
https://www.telegraph.co.uk/news/2018/05/05/ba-virgin-planes-warned-stay-within-hour-airport-amid-engine/
Coincidentally, that'd be the Rolls Royce that used to talk about (and promote) its "lean, agile" corporate culture.
Goal setting for example: my twin brother & I decide over a pint that we both need to lose weight. I (Leisure Larry) start eating better, exercise a lot more, drink fewer pints. My neighbor (Donny Disciplined) goes with an elaborate plan to lose X by date Y, and 2X by Y+7, etc. Who ends up losing more weight? Conventional wisdom says that Donny bests me in terms of both weight and time, but has anyone done the controlled experiment? What if his goal was too low, and I exceed it for not having set one at all?
The goal of agility after all is not to build software more cheaply, or produce software of higher quality as the article seems to imply. It is simply to adapt to a world in which requirements change more quickly than software can be developed using prior (e.g. waterfall) methodologies. Given perfect requirements you can build higher quality software more cheaply using waterfall than agile. I was surprised to hear none other than Allistair Cockburn admit as much a year or so back at a Groupon lunch & learn (Geekfest). Good luck getting perfect requirements.
I'm old enough to remember waterfall, and UUP (nee RUP) with it's 125 pre-coding artifacts, and a number of other pre-agile methodologies, but have been working with agile teams (various flavors) for a good dozen years or so, and for most projects I would refuse to go back. It's not perfect, it can be light on design & documentation, but you deliver something sooner rather than later, and the something ends up being more useful to more users, in my experience.
I don't need a controlled study to prove it to me.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
