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.
... later...
- 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.
... later...
- 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.