Oldies can still function
Can I just say that I am in my 50s and I'm doing Agile Scala development on Spark.
Since the publication of the Agile Manifesto, there’s been a steady acceptance that Agile is the way to go when it comes to software development. The old waterfall method was seen as something rather quaint and old-fashioned, the equivalent of hanging onto your vinyl LPs when the rest of the world was downloading onto their …
I have seen a COBOL guy in his 50s and he was a non-talking curmudgeon, practically impossible to work with, a danger to the company.
Maybe the "guys in their 50s doing COBOL" who quit when hearing "agile" were like that, in which case they deserve the job market they will encounter. Otherwise there should be ways to accommodate that particular development section which more likely wants some steadiness instead crazy youngsters re-discovering
sexthe ropes making them confused and angry. Put a communicating "project manager" in front of their door to perform proper I/O.
project managers can become a rare breed and can become scrum-masters
The scrum master is just the scrum master. The propels the scrum cycle. The project manager is the guy on the phone, in contact with the guy with the money and doing the Gantt chart. Both job descriptions are not comparable at all. Once project managers think they are scrum masters or the converse, problems beckon.
JP Morgan Australia senior managers have installed cambam boards for themselves.
I think this is written "Kanban". It is a nice communication device, especially to give some visual input to PHB dropping by to "ask for a little project on the side", but it's orthogonal to agilism...
He, he. I worked for a global telecoms company (now mercifully defunct) back in the 90's. The entire call routing software infrastructure was maintained by one guy. He was far from curmudgeonly (he was a very affable middle-aged Dutch hippie), but he had the management by the balls, and by god did he know it. He was on an extremely lucrative contract and had basically lived in 5 star hotels around the world for the past decade - strange life, but it seemed to suit him.
At the time I was keen on getting in on some of that myself. Of course he wasn't having any of it, but I eventually managed (with no backup from management, who were complete pussies) to get my hands on the source - a huge C/Unix real-time system, completely undocumented and void of a single comment. Turns out that the guy's weak point was that he was such an elegant programmer - the code was beautifully structured - that I was starting to get on top of it. Then the company imploded, I was out of a job and your man (I'm guessing) retired in style.
"Maybe the "guys in their 50s doing COBOL" who quit when hearing "agile" were like that, in which case they deserve the job market they will encounter"
@DAM - actually - the COBOL guys have been making BANK for a while (since before Y2K), so at this point unless they did something foolish with their money, they can just retire and be done with it. If they quit when they heard Agile, I suspect they could have left at any time and were just there for "fun". Let that be a lesson for anyone with legacy systems where the only folks that can *properly* develop on it are in their 50's. Its time to do a crash program migration (or get fresh blood that likes COBOL ha), since many folks in their 50's can just up and walk at any time if they so choose, and those two did so choose. I've seen well positioned guys in their 40's do that as well.
Zealots are almost always wrong. They get so narrow minded that they fail to consider alternate viewpoints and dismiss any criticisms,
Sure Agile can be great,just don't force it's use where it doesn't belong. And that's not just because of culture. The nature of certain projects just may not work well with Agile, or at least not pure Agile as the true Agile nuts would have you believe is the only path to software enlightenment.
The Church of Agile is so welcoming and all encompassing that anyone, in any role, can join and become a believer and even an expert without any real credentials. Talk the talk with supreme confidence and enthusiasm and it doesn't matter whether you are right or wrong. Agile in marketing - who needs a marketing plan, just use Agile. Agile in upper management - change your company culture and reap the benefits ( with no ROI proof mind you). Everything can be Agilized. It's your destiny, if you will only beeeelieeeeeve.
I walked out of that sermon and haven't been back to that realm for a while. Certified Scrum Master from 2006.
Love the cambam. Seems like El Reg is hiring people with fewer clues as time goes on. Unless, of course, they are actually brilliant and the writers/editors are inserting typos in key places so us commenters will call them on it ( TB, MB, PB, millions, billions, etc that the writers and editors can't seem to get a handle on) and that way, they can tell the advertisers that they have an active comments environment with an average of X number of posts per article, so they are assured to make people talk about their products if they write an article about them and throw some advertising dollars their way. Genius. Must be Agile.
Agile seems like Communism - it would be the perfect system if only we had perfect people.
In reality, Agile seems to all too frequently result in developers getting jerked around by people who don't know what they want, resulting in code that's over budget, underspec, and buggy. I always know when I've had enough of a project - I start wishing we'd had a tightly nailed down waterfall spec.
When no-body bothers to fully peer review the software, or the lone developer pulls the code from a repository because everyone's messing him about, or hell.. even just gets downright abusive, then I can't help but feel compelled to disagree.
There's also how many projects using GNU licences that don't reciprocate or make said code closed source, or just get plain lazy and leave default configurations/plugins that are open to abuse.
I'm not saying closed source is inherently better, or that smaller teams work better but the reality is much more complex.
When no-body bothers to fully peer review the software, or the lone developer pulls the code from a repository because everyone's messing him about, or hell.. even just gets downright abusive, then I can't help but feel compelled to disagree.
The biggest "except" is that none of your three listed projects (OpenSSL, lpad and Linux) are remotely developed using the Agile methodology.
Agile is pretty great in certain environments - if I was in a start-up combining design and development on a growing product that needed to have it usable by users as soon as possible and needed it to stay usable by users as the product grew and added new features, I would probably be looking at a full Agile methodology.
That isn't where most businesses are, though. It might look cool because it is what start-ups do, but those requirements are quite different from what most development work seems to be about, which is getting a project to a specific "finished" state within a timespan and a budget that makes it viable for the organisation who are sponsoring it. If you are doing Agile by the book, then you cannot offer any guide for when "finished" is likely to happen and consequently how much it is likely to cost.
Also it seems as though businesses often want to see results fast, which means the first thing they skimp on is the requirements gathering. That is super-important regardless of development methodology, but most of the time they seem determined to get code working from day one rather than figuring out what code would actually be helpful.
In fact, the more I think about it the more I think that if you can set up your starting variables correctly - a solid and well researched requirement, some prototypes and wireframes that people like, an agreement about what goes in and what doesn't from the start - then you have a fair chance of success regardless of methodology. Often you're going to end up with some kind of bastardised sprinterfall or kanbince type approach anyways.
Perhaps I should sell this as "foundationalism" or somesuch and set up as a consultant...
Yes the answer is always hybrid. But of course it depends on the scope and scale of the project. By all means use an Agile sprint method or scrum organisation structure to deliver key and core work packages, but on large multi stage development projects and programmes, these need to sit under a waterfall stage driven structure because it gives the Sponsors, Programme board, PEs and other steering group rerpresentatives the comfort that the programme has a clearly defined structure and approach, and because looking at a large project in high level stages, and being able to track key milestones against those stages is how it works for those seniors whose necks are on the blocks to influence and deliver.
Let the PM manage the project, and let the scrum-master or whichever unfortunate has been nominated to make it work, manage the work package driven sprints. All of which sits beneath the key stage plan.
The guy in the article claiming some mutual exclusivity of methods obviously isn't delivering change projects to the size and scale that a lot of PMs do (or maybe he just has a lumberjack shirt and a beard and makes it all up as he goes along?)
If you have staff that treat your corporate systems as their own, and refuse to adapt to new methods - then they need to be released. You will feel some pain but in the long term that issue should have been identified, and be actively managed with a contingency plan.
It's not rocket science. It's really really isn't.
Rocket Science Easy F = ma
Rocket Engineering now that's difficult. makig something that doesn't explode, melt go sideways etc.. and still lofts several tons to a pre-determined point in space
Same with software, easy to comprehend the approach bloody hard to do it well.
Yes, in basic physics books, where everything is a point in an uni-dimensional world and forces are nice arrows, without atmosphere, etc. Bring it into the real world and it becomes a little more complex.
The there's the internal physics - hypercooled propellants and their effects on materials they touch, how them and exhaust gas behave along the engine, how to make a rocket lighter but still structurally sound using new materials, and so on.
Even firing from a cannon was complex enough one of the first computer was designed to compute more accurate firing tables....
Sorry, we can't throw in some nude women/sex scene every time our software doesn't work. It would simplify development a lot, mostly no customers complains, I guess. Imagine an exception handler designed such a way... guess helldesk would receive calls like "I don't see any errors, how could I obtain one, please??!!"
The bottom line is Game of Thrones is exactly designed to give "users" what they ask for. Sex and violence. Software, unluckily, can't.
- A girl is not ready to become agile, but she's ready to try another development methodology...
- A girl must wait.
- A girl does not use waterfall any more. A girl uses no development methodology.
- A girl is finally ready to become agile. A girl must drink the kool aid. If a girl really believes, there is nothing to fear.
- A project was a failure.
- A girl had doubts. A girl was not agile.
Disagree completely - I have worked in three places that did Agile well and it worked very well indeed. As far as I can tell the main thrust of the article is creect in that you really need everyone (especially the business sponsors) to buy into it too. If they don't understand the process then you might as well not bother..
Totally disagree with your disagreement.
Never worked in an Agile project that actually worked.
Currently working on project, seen two attempts to deliver, now on the third and still no delivery. Agile is an excuse for having no idea how to do something and just starting and attempting to learn on the job.
In the real world when you have a multi million dollar project with a fixed functionality, fixed time frame and fixed budget agile doesn't work.
The agile approach is to start with an undefined idea, no requirements, stuff around for ages, waste a lot of money then deliver some flaky stuff that does something. This might be ok for a startup where the stuff delivered becomes hipster and takes off for a couple of months. But if you are a real world bricks and mortar place with real stuff to do with people and suppliers to pay then build your software using the same techniques as you would build a building, dam etc. Start with a set of solid requirements functional and NON-functional, plan it cost it then start building. At least you will have a chance of getting it built on time and on schedule.
Problem is that Agile doesn't work
Agile *can* work.
The problem is that far too many "agile" developments are simply bullshit dressed up as Agile.
If anyone ever tell you that you don't need requirement capture - that's not Agile.
If anyone tells you that you don't need a spec - again, not Agile.
Documentation? Agile requires it.
In fact, there is really only one difference between Waterfall and Agile - and that is that Agile expects the spec to change during the lifetime of the project. That's it - all this bullshit about not testing or documenting are nothing whatsoever to do with Agile. But someone will still pretend it is...
 This is not true; the original Benington paper describing the Waterfall process had feedback loops in it - meaning *real* Waterfall and *real* Agile are essentially identical. But the Waterfall process is frequently misrepresented as well...
Vic you are spot on. Both methods, if done clearly, deliver. I've seen waterfalls work well (early days), but I have also seen the team plough ahead regardless of the billowing fires of fail around them, because That's What You Do. I have also seen an Agile project fail because the team was so sure it could handle changes to the specs that they lost sight of the Great Big Deliverable.
And I have seen every kind of project fail because project management was so dire, so disorganised, so pathetic, that finally it killed either the will to live or (in one instance) actually killed the project, mostly by spending all the money on business analysts who sliced and diced the requirements into shards.
I'm used to this sort of article explaining to me that DevOps is in fact a panacea. That is, it has more or less random anecdotes (COBOL guys quitting), sweeping unsupported assertions, and a tin ear for language.
"There is a way that Prince can work with Agile, said the evangelist: either the Prince methodology can change or project managers can become a rare breed and can become scrum-masters,” says Harris.
How does one become a rare breed? Refuse to reproduce? But I do like
"drift back to Waterfall"--a staple of many cartoons, no?
"waterfall clinging on tenaciously". S'ok, the spring thaw will take care of that.
"show by example". (Well, OK, that is said to have been uttered by a "business guy".)
agile antibodies in the permafrost.
We are doomed to have this stupid argument forever: Waterfall vs Agile, as if no other methods exsit. Waterfall is always put up as a strawman. There are, and have been, other methods besides Waterfall. Some are very good robust methods. As for Agile, you cannot do better than read St Bertrand's wonderul assessment.
"Translation: middle management, which is like permafrost – something that’s hard to penetrate."
A better analogy for middle management is one I heard many years ago. Just before he left - the CEO was addressing the coalface workers who were enthusiastically in tune with his ideas for the way the company should progress.
"Middle management is a blancmange - whatever you do it just wobbles then stays the same".
That's likely where all that twentysomething enthusiasm is going to come to a complete halt.
It's 2016 and somewhere out there a bunch of people are writing Accounts Receivable packages.
And at least one of them is failing.
I find the best method of delivery is just get on with it. Do a proper job, be organised, put the hours in, hold people to account and get it delivered. Every PM needs a keyboard with a JFDI button and be prepared to press that button rather than dice with the death of endless detail and waste time playing methodology bingo.
Why is agile hard to report on? Don't you just go to your ALM tool of choice and download the charts? It'll tell you how many story points have been done and how many are still to do; extrapolate how far down the backlog you'll get by the end of the project;show you who's working on what tasks and whether they have time to complete them before the end of the sprint; there's all sorts of reporting. My experience is that you have far better visibility of progress on agile projects than waterfall ones.
Certainly you can improve waterfall by using some of the tools and methods developed for agile, to give yourself some of that visibility in a waterfall project. But unless the developers are actually delivering something on a regular basis, then you're still pretty much taking their word for it that everything is fine and on target.
(ignoring possible sarcasm, and adding my own :-) ).
Let me see - because middle management found story points too confusing, so they insisted on story point is defined as a 1 hour estimate. But then not enough points were getting done, so they officially declared the sprint velocity to be 50% - you accomplish 4 story points per day. Then they decided that the "other 4 hours" (a phrase I have grown to really hate) encompasses all non-sprint work, so that has to include everything other than visible progress.
When the main branch has code checked in that won't compile, fetching the latest source and getting it to compile and be usable on your machine is part of the other 4 hours (and yes, branches are too hard to manage, so all work occurs on the main branch - branches are reserved for prototypes). Grooming future work is part of the other 4 hours. Your machine needs to be re-imaged because of buggy IT sw (from a large remote company that does all support) means your encrypted disk won't boot (and no-one on this continent is allowed to decrypt and recover data) - you guessed it - just part of your other 4 hours.
But - upper management says we have to be agile, so we are agile (sprint length = 1 month). Perhaps a third of the developers have done agile at other companies, and sort of try - let's see, I would have given this a 5, which tended to be around a week, which has 20 official hours, so I give it a 20.
But yes, agile isn't that hard to report on - I get the emails every day with the pretty charts from the official tools to prove that.
The reality of the Agile deployments I have had the pain of having to deal with is that it is nothing more than an excuse for developers to go back to the bad old days of no planning, no designing, and no testing. Just throw some crap code into production and then fix it as you go along. I agree with the comments above that the best method is to have good developers do a conscientious job in test and dev and then when the code is stable move it into production. Not sexy but nothing breaks as a result.
Agile tends to foster good communication WITHIN a team and makes it easier for everyone to engage with the project;
Pure double speak bullsh*t, this is just another way that agile is used to blame the development team.
What! it failed!!!!! You devs must have failed to communicate!!!! BAD DEVS
The worst part are the developers who feel the need to become scrum masters.
Not the best technically, lacking people skills, but not quite bright or personable enough to be a fully blown non-technical manager or project manager. The result always seems to be micro-management, no trust, no creativity while the scrum master undermines all the developers to the upper management, while not realising that the upper management give them no real authority or input.
I read the whole thing, and now I feel dumber.
COBOL programmers are not as agile as they should be?
At my work, now we have multi-hour 'sprint' meetings where I get to doze off to the sound of QA people planning their work in detail, rather than being at my desk coding. Seems legit.
"Break fast, fix quickly" is not something the business sponsors involved with systems running cobol want to hear.
Agile might be fine for new things which don't have to work, but when your software supports a product which has moved from the innovation to exploitation phase of business usage, its time to protect the investment.
Too much innovation, not enough exploitation -> never turn a profit from your work
Too much exploitation, not enough innovation -> be overtaken by innovators
The trick is to keep the balance.
/credit -> TED
> Difficulties with Prince aside, there’s little doubt that agile is going to be the way forward.
Speaking as one of those 50+ dinosaurs (though I've not touched COBOL for twenty years), I can tell you that agile will be identified as "the way forward" for couple of years, and then be replaced by some other half-arsed methodology invented by MBA-toting idiots and imposed by people who don't really understand it on the poor sods who actually have to do the work.
The fact is that there's no magic universal approach that works in all situations, you have to blend different approaches to suit your own particular case. Sometimes that might be pure waterfall, somtimes agile, most of the time somewhere in the middle.
The few programmers I know are older masters (almost everyone in the world has used their work) and they are unanimous that the best working conditions is to be left the fuck alone while writing code and the best practice for quality control is to divide the software into sections and let each programmer work on their section alone, but with very strict guidelines for continuity and compatibility with the other sections and promptly fire the asshole that won't play by the rules. And test, test, test.
Everything else is just buzzword bollocks and needless wheel spinning.
I don't generally disagree, but I have seen coding masters deciding that what the business wanted was something other than what they business asked for. In this case, the business actually asked for something sensible and focused, but it was too 'simple' and the master coder decided to make it a challenge by doing something else. It worked fine, but it wasn't what was needed. That slab of code got dumped and replaced, and he sat in his cubicle and fumed and played games.
The problem with agile is simple: there's a school of thought (or lack thereof) that says agile means running a project without defining anything at all, because even the most basic requirements analysis is "too waterfall", and then obfuscate reports to sr. Management around the cluster**** that happens in UAT, keeping the project limping along until they can't hide failure any longer, by which time the original project champion has moved to another project / department / company / career, and the project gets cancelled under a cloud, usually tainting the poor sod who just got lumbered with it. Those who didn't understand agile, blame agile, those who do understand agile, blame the original project champion, who was "the agile guy", management hear a post mortem where everyone is covering their butts, and blaming "the other guy's" implementation of agile methodology is easier than blaming someone sat around the table, management, desparate to cast off the albatross aroubd their department's neck, take away the impression that agile projects are a disaster waiting to happen
(even though the project in question bore little or no resemblance to an agile project), and "action a best practice" to avoid agile at all costs in future: spreading the misconception as they wander from company to company.
Wait, agile fails to take hold because "the agile antibodies aren't strong"? The things that, in a living organism, would protect it against future infections of agile? (Compare "flu antibodies", "Hepatitis-B antibodies".)
People shouldn't use metaphors they don't understand, because then this happens.
But execution has been more like a death penalty. My current corporation made that decision that program managers are just scrum masters with spreadsheets. So most of my day is spent being "coached" by a SM that's failing to hide their contempt for anything related to Agile, while bitching about the tool that won't let them report out the exact number of minutes spent on a story. I'm a bus sys analyst, which people cheerfully remind me has no actual role in Agile. A proxy PO at best, most often I'm just the person who needs to gleefully fall on my sword when something doesn't go perfectly.
So yeah, I'd love to be an actual product owner, though again, my company has decided that POs are less about delivery of business value and more about kissing client ass and writing a two sentence description of a thousand hour project, then mysteriously disappearing whenever I come hunting for them. And now that the expensive Agile Coaches we hired have left the building, PMs are reverting to their old ways of micromanaging, under the guise of mentoring, while the architects are cavorting with sales to give vague, bordering on abusive, estimates for Client X's most recent high cost, low margin brain waves.
Anon, even though I'm ready to invite a few people to watch a bridge-burning... from the bridge.
Puny programmers need overhead. Puny programmers need communication and customer reassurance.
Hulk programmer listens to customer, forms vision in head, gives token acceptance document, then does the plumbing, wiring, and constructs castle. Client likes, and Hulk programmer does changes and fixes easily because all his code.
Frankly, software development has become too easy. Sounds like a lot of time wasting going on here.
Whereas "Code Monkey like Fritos. Code Monkey like Tab & Mountain Dew. Code Monkey very simple man, big warm fuzzy secret heart. Code Monkey like you." –Jonathan Coulton
...And Real Programmers, of course, "wrote in machine code. Not FORTRAN. Not RATFOR. Not, even, assembly language. Machine Code. Raw, unadorned, inscrutable hexadecimal numbers. Directly."
I quite like doing things the Agile way. We switched all our dev to that, works great.
What I DO NOT like is the incoherent and utterly useless documentation that Agile vomits out. "How does X work?" "Oh, was that in sprint 4? Check the JIRA." Utterly, fucking useless when you don't always have access to said JIRA.
If Agile had better processes for creating documentation, testing it, and maintaining it; then it'd be pretty much perfect. Instead one is forced to waterfall the docs in a blind panic post release and that is just complete bullshit.
I am a developer, so I don't say this lightly, documentation is an order of magnitude more important than code when it comes to deployment and sustainability.
80% of all the support calls I handle (don't ask) result in 2 or more tickets being logged against documentation because they are asking how to do something or the users are confused why the system is blocking them (i.e. defending itself). That is a MASSIVE drag on resources and all because Agile is code-focused rather than quality-focused.
Write the tests first, write the docs second (should be easy *IF* you have a design), then write the code. The code should be last outside of research/dicking-around-time. But no, not in Agile.
"He cites as one example a project that was implemented using an agile approach but after a few months, it was clear it was falling behind and eventually the team started using an old methodology."
so this thing happened somewhere and after a while it wasn't working the way they hoped so they decided not to do that thing anymore and reverted to do the other thing they were more used to.
was there a minimum word count the author was trying to reach?
The problem with Agile, from an antiquated management perspective, is that you can't claim you've completed any of the traditional work items until the end.
MGR: "When will code be done?"
DEV: "At the end of the project".
MG: "When will test be done?"
DEV: "The same time as the code."
MGR: "So we're doing NOTHING for the whole time? How do I justify my existence to MY boss?"
We're having a hard time explaining that, while we haven't completed any specific group of artifacts, we are in fact making progress on ALL OF THEM. We need to track FEATURES, not ARTIFACTS.
I used to work at a pure Earned Value factory. How did you know you were done? You had burned all the hours in the bucket. No time left, we must be done. I mean, those people must have had a sixth sense, to know Task A would take exactly 6 hours, while Task B would take exactly 12 hours.
The best analogy I saw on how software development should be done was in "Code Complete" .
It used a building metaphor. Design, test and build.
If skyscrapers were built using methods the way software is quite often developed there'd be a whole lot more stories of collapsing buildings in the news than we currently see.
Biting the hand that feeds IT © 1998–2019