Is Agile Becoming Less and Less Relevant? (forbes.com) 235
OneHundredAndTen shares "an interesting Forbes article that posits that Agile software development is losing relevance, it is not the silver bullet that some claimed, and it has become a sort of religion -- 'If Agile doesn't work for you, you are not doing it right.'"
Writer/data scientist Kurt Cagle even describes passing around "the holy hockey stick" while begging the scrum master for forgiveness, arguing that "like most religions it really didn't make that much sense to the outsider -- or even to the participants, when it got right down to it." Agile does not always scale well. Integration dependencies are often not tracked (or are subsumed into hierarchical stories), yet it tends to be one of the most variable aspects of any software development... [T]here are whole classes of projects where traditional Agile is counterproductive. Enterprise data projects, in particular, do not fit the criteria for being good Agile candidates... the kind of work that is being done is shifting from an engineering problem (dedicated short term projects intended to connect systems) to a curational one (mapping models via minimal technical tools).
This transition also points to what the future of Agile will end up being. In many respects we're leaving the application era of development -- applications are thinner, mostly web-based, where connectivity to both data sets and composite enterprise data will be more important than complex client-based functionality. This is also true of mobile applications -- increasingly, smart phone and tablet apps are just thin shells around mobile HTML+CSS, a sea-change from the "there's an app for that" era.
The client as relatively thin endpoint means that the environment for which Agile first emerged and for which it is most well suited -- stand-alone open source applications -- is disappearing. Today, the typical application is more likely a data stream of some sort, in which the value is not in the programming but in the data itself, with the programming consequently far simpler (and with a far broader array of existing tools) than was the case twenty or even ten years ago... While aspects of Agile will remain, the post-Agile world has different priorities and requirements, and we should expect whatever paradigm finally succeeds it to deal with the information stream as the fundamental unit of information.
Writer/data scientist Kurt Cagle even describes passing around "the holy hockey stick" while begging the scrum master for forgiveness, arguing that "like most religions it really didn't make that much sense to the outsider -- or even to the participants, when it got right down to it." Agile does not always scale well. Integration dependencies are often not tracked (or are subsumed into hierarchical stories), yet it tends to be one of the most variable aspects of any software development... [T]here are whole classes of projects where traditional Agile is counterproductive. Enterprise data projects, in particular, do not fit the criteria for being good Agile candidates... the kind of work that is being done is shifting from an engineering problem (dedicated short term projects intended to connect systems) to a curational one (mapping models via minimal technical tools).
This transition also points to what the future of Agile will end up being. In many respects we're leaving the application era of development -- applications are thinner, mostly web-based, where connectivity to both data sets and composite enterprise data will be more important than complex client-based functionality. This is also true of mobile applications -- increasingly, smart phone and tablet apps are just thin shells around mobile HTML+CSS, a sea-change from the "there's an app for that" era.
The client as relatively thin endpoint means that the environment for which Agile first emerged and for which it is most well suited -- stand-alone open source applications -- is disappearing. Today, the typical application is more likely a data stream of some sort, in which the value is not in the programming but in the data itself, with the programming consequently far simpler (and with a far broader array of existing tools) than was the case twenty or even ten years ago... While aspects of Agile will remain, the post-Agile world has different priorities and requirements, and we should expect whatever paradigm finally succeeds it to deal with the information stream as the fundamental unit of information.
Yes, but not for reasons you'd expect. (Score:3, Interesting)
Disclaimer: Agile guy /Scrum person here.
Agile software development grew out of the requirement to do Web software development for people who don't know what they want but know what it may cost and when it needs to be finished.
These people are becoming less of a problem, because more and more a single developer can click together a piece of software while he is discussing the requirements. Agile software development is disappearing because software development for the Web in general is more or less disappearing. I've recently moved to using preconfectioned software modules just about entirely and only programming very little glue code on top of systems cobbled together this way. The effect being that I'm the sole developer in a 25 people company and need roughly 6 weeks to build a product start to finish. And that's with a poorly governed project in which I have to take on tech and web PM roles because no one knows what's going on or how Web is done.
The tools and services we need to build complex applications are finished and manifold. It's more and more about clicking the right buttons and subscribing to the right services which makes the whole thing agile all by itself without needing a big fuss about it.
Cargo cult (Score:5, Insightful)
The problem is that the definitions of "agile" allow for cargo cult implementations: going through some or all of the motions of agile without understanding the underlying assumptions or providing the necessary background. The result is nothing: you spend a lot of time doing the agile rain dance, but do not get the productivity rain. You have high priests, not scrum masters. You spend a ton of money on consultants who study your organization and then come back with a solution: spend more money on their trainings.
There is a lot of agile scam going on, and the end goal is not improving productivity or helping developers. It is to milk companies of money. There's a whole industry of these now.
Re: (Score:3)
Absolutely.
I have done all kinds of "agile", the worst was DSDM which is a cargo-cult of terms and management oversight that would put waterfall to shame for heaviness.
But I also know agile can be done right, you need 3 things:
1. decent guys who know what they're doing.
2. a place to send them away to by themselves.
3. someone they can say "this is what we've done" every so often.
I suppose you might also need 4. shut up and let them get on with it.
That works, the trick is to let them do their thing with the s
Re: (Score:2)
I see. If it's not working, you're not doing it right.
Re: (Score:2)
That is actually true for most things in live.
If it is not working, you are not doing it right.
I really wonder what is so complicated in grasping that.
Re: (Score:2)
At least two logical fallacies in that reply:
If it is not working, you are not doing it right.
False choice dilemma. There are far more explanations than that. I'm going to assume you're not actually lacking awareness of this so is comes out as some tainted advocacy for agile.
I really wonder what is so complicated in grasping that.
While this doesn't appear to be a critical platform in your response, lack of imagination is also a logical fallacy.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
So you're saying that Agile is "that which, when done right, leads to better software". That makes it absolutely useless as a process. It doesn't mean anything. Especially as you can never realistically compare old and new processes used by the same team to implement the same software.
Re:Cargo cult (Score:5, Interesting)
Scrum is a discipline. There are particular steps that you need to do to say you're doing scrum. Extreme programming is a discipline. There are particular steps you need to do to say you're doing XP. "Agile" is not a discipline. It's a generic term that loosely describes a large family of disciplines. If all you're doing is "agile" with no further qualification, there you're probably not following any discipline, and you can't expect it to work for you.
With any discipline, you need to learn the rules, and you need to practice them faithfully. If you say you're trying Atkins but it doesn't work, and I can point to a large stack of pizza boxes, then I may reasonably say that you haven't proven anything about Atkins because you haven't really tried it.
When you say that agile doesn't work as a process, then what you're really saying is that management writing some nice sounding words in a process description document doesn't work. Which is true. If you don't manage to convince the practitioners to follow a discipline, then it doesn't matter how "agile" your nominal process is.
Re: (Score:2)
"Agile" is not a process. It is a meta process.
It does not tell you when and how to close an issue in an issue tracker.
It does not tell you when, how often and with which comment (ticket number? In issuers tracker) do a commit.
Agile is mostly a set of meta rules telling you: what not to do.
Can't be so hard to grasp.
And no: agile never was supposed to lead to better software. It is supposed to help you judge/track how much time/money you need to make he good/bad/worse software.
Re:Cargo cult (Score:5, Informative)
Agile sets forward a bunch of common areas that if done incorrectly, will almost always lead to failure. Agile doesn't tell you how to do anything, it just says what you should probably be focused on and how to determine when you're doing the wrong thing. For example: don't do all of the work up-front, deliver in the smallest practical features to get valuable feed back.
There are many areas Agile attempts to address
1) Developers don't know everything
2) Specs are never complete
3) Business requirements change. Welcome to the real world.
4) Customers don't know what they want, but they know what they don't want
5) Priorities change
6) Mistakes happen
7) Timelines are important
Agile is a collection of guidelines, areas of concern, and a simple way to tell if you're going the wrong way, aka feed back. Saying Agile is useless is like saying factoring your code is useless because no one tells you how to factor your code, so just make a monolithic method. I will agree that 99% of what people call Agile is pure crap. The signal to noise ratio is horrible.
Re: (Score:3)
I suspect parent and grandparent are using different definitions of 'Agile'. Which concisely sums up what it is about Agile that doesn't work. Agile the process works in the right situations. Agile the slogan is something else.
Re:Cargo cult (Score:5, Interesting)
Exactly. Agile buffs seem to define failed attempts at applying Agile as "not really Agile". Of course, if you read the manifesto and listen to what its authors have said in the intervening years, you come away with a very different idea of what Agile was supposed to be.
To sum it up: if your team can iterate efficiently, it's Agile. That's it. All the buzzwords like scrum and kanban are just labels for a set of procedures to formalize something never meant to be formalized.
Re: (Score:2)
When Agile was introduced into the organization I work it was combined with "become more T-shaped" with the intent that everyone should be able to do everything, but the result was that nobody really understands what they are doing and use it as an excuse for "Somebody Else's Problem". I'm sort of the few remaining "specialists" with deep knowledge regarding my areas of functionality left, which has resulted in the case that I have had to present the intended logic of the functionality 5 times in 2 years no
Re: (Score:2)
Yes, this is why I have a problem with people complaining about the phrase:
"If Agile doesn't work for you, you are not doing it right."
This has been the history of programming since I was first involved professionally at it in the 80s. If $X is not working for you, then you're not using enough $X. Always there's yet another magic bullet to solve everything. Sometimes something trivial, like not using goto, and then it becomes a fundamentalist religion rather than just a basic guideline. Sometimes it's a tool to fix all ills, like UML, or a fad like design patterns. This cycle, the magic bullet is Agile...
Re:Yes, but not for reasons you'd expect. (Score:5, Interesting)
Thank you! That was one of the most to-the-point summaries of agile I've seen. To me, it always seemed like it was a web and mobile focused methodology.
The kind of problems described in the summary have always existed even if web and mobile phone developers are only discovering them now. Agile always was a poor fit for anything that requires thought and planning. I've spent months working on changes that resulted in maybe 100 lines of code. First, I have to figure out what to do, then do a preliminary analysis of how it might change things and discuss it with colleagues, then implement and test it (which is takes no time at all) and then to finally try it on real data and prove it does exactly what it was supposed to with no unintended side effects. And, yes, you always find unexpected side effects. Some are due to bugs or limitations in the rest of the code that did not make a difference before, some are due to corner cases or improper inputs which worked "by accident" and some changes just look really weird but after careful analysis (by hand) turn out to actually be correct.
The point is, when the testing and verification of a feature takes a month, you really don't want to find fundamental flaws in your thinking or your code since that would require rechecking and retesting everything again. I don't see how any of this could be packaged into 2 week sprints or how daily meetings would help (Yes, I'm doing the same thing as yesterday. Yes, it is still hard. No, I don't know how long it will take since it depends on the number of issues I find that needs analysis).
It seems to me "agile" only works if all the features are "light": quick to implement, no side effects, easy to test and verify etc. Like "add a green button here" and not "replace the central calculation engine which is used by everyone and everything and make sure no one is adversely affected".
Alternative headline: Is the fad fading?
Re: (Score:2)
Do you work at Oracle?
If it's not a new algorithm needing to spend that long to make changes means the codebase must be a horror.
Re:Yes, but not for reasons you'd expect. (Score:4, Interesting)
Did you read the original article? There are many classes of problems that result in the kind of work that was described by the GP - data analysis and curation being the example quoted in the linked article. There analytical work is huge and needed upfront, and the changes, if any, that is needed to the system, can be small. Maintenance work in data processing in data transformation constantly gives challenges like this. I once dealt with an entire system that got mothballed because of a critical defect that required 3 months of analysis to understand the problem. The fix took three lines of code. How do you break this up into an an agile story and work it into a sprint timeline?
There are other problems where the ability to iteratively produce a converging set of features takes a back seat to completing the whole work within a deadline (for example - imposed by legislation). It doesn't matter what your minimum viable product is, or how quickly you can get there. What matters is that you know how many people you need to deliver a complete solution (you don't get points for something that only partially implements the legislation), and that you have a roadmap for how to deliver the solution with that many people. Agile doesn't fit here.
And then there is of course the "fixed price" consulting project - where the consulting company makes a fixed price bid for a piece of work, and then does agile delivery. The product backlog is a useful notion here for picking up work. Iterative delivery helps assess that you are on track. But if your product backlog isn't zero when you run out of money, it doesn't matter a bit what you've accomplished to date: you will get sued for breach of contract. I question the sanity of people who pick agile in such situations.
Re: (Score:2)
Wellllll,
and how hard is it actually in your situation to realize that you are a "special case" and that this has absolutely nothing to do with "agile works" or "agile does not work" ???
Sorry, usually I add. a well sounding moniker here ... you can chose, starts with an Ixxx or with an Mxxxx.
Re: (Score:2)
Agile software development grew out of the requirement to do Web software development for people who don't know what they want but know what it may cost and when it needs to be finished.
The c2 payroll project, the project that launched the whole agile thing, was not a web project.
It doesn't matter what kind of business you're in, no-one knows what they want in advance.
Re: (Score:3)
They do know, its just that they have a hard tiome expressing it ans communicating their requirements to others. That's why we have the back-and-forth aspect in agile. But that doesn't have to be done in a "here's what we've done, tell us if we got it right" fashion, when it can also be achieved by questioning the spec up front, or tweaking it as you go on an ah-hoc basis.
Re: (Score:2)
They do know, its just that they have a hard tiome expressing it ans communicating their requirements to others.
There's been plenty of times where people have willingly admitted they got what they thought they wanted, but it only looked good on paper and didn't work well in practice. No matter how thoroughly you quiz them that'll happen, that's what change orders are for. It's actually quite straight forward as long as they admit this is a genuinely new requirement and not a bug you should fix for free.
Re: Yes, but not for reasons you'd expect. (Score:4, Insightful)
Re: (Score:2)
Agile software development grew out of the requirement to do Web software development for people who don't know what they want but know what it may cost and when it needs to be finished.
"That's what I asked for . . . but not what I need!"
In my company, we have advanced to Flexible Recursive Agile, aka Fragile.
The software breaks on delivery . . . but the blame is put on UPS.
It said "Warning Fragile" right there on the box!
Re:Yes, but not for reasons you'd expect. (Score:4, Interesting)
agile as a philosophy (Score:2)
Then again agile can be defined as a philosophy with a number of possible approaches. If something doesn’t work evolve it. There is no need to set it in stone.
In many ways the simplest way of looking at it is “agile is not waterfall”, so as long as you can provide a working approach for you team that allows for iterative development and deployment, then there is no need to follow any specific dogma.
Certainly there are a certain common set of tools out there, such as scrum, kanban and spri
Re:Yes, but not for reasons you'd expect. (Score:4, Interesting)
I agree that Agile seems ok for Web development, even application development. But some of the core principles just don't work for embedded systems, hardware/software integration, maybe integration in general, protocol development, and so forth.
Part of the problem is the decomposing problems into 2 (or 3) week chunks, avoiding a high level design, focusing on low level module testing while glossing over the more important integration and system testing. There are tasks that are just huge, do you really have a sprint for reading chapter one and two of the SoC developer's guide, another sprint for chapter three, and so forth. which all must happen before you tell the team of the product is viable or if you need to look at other vendors? And unit test can't even begin until you've created enough of the base platform that you can run the tests on the real hardware (except for simplistic tests. There are unexpected road bumps every day, the two week task will become a 12 week hurdle, you have to plan changes like that. And on a real device you can't give a demo at the end of a sprint when it takes a couple sprints just to build enough framework for a demo. Testing a feature may take 4 or 5 sprints, that's the first thing we had to change in the Orthodox Agile Religion, we couldn't have development and testing be simultaneous.
Finally, you don't have interchangeable developers. Sure, in a web world where you have 7 people who all do the same job it's easy. But if you have only one expert on the radio, and only one expert on protocols, and only one expert on crypto, and three junior people all unfamiliar with RTOS concepts, then the developers aren't fungible.
Also there's maintenance. In my entire career, probably 95% of my time has been about maintenance; adding features to old releases, fixing bugs, etc. Maybe Web people don't see this with their continuous delivery of barely usable web pages. Maybe 80% of the time is bug fixing, and you CANNOT predict when a bug will be understood much less fixed, despite being shouted at daily in the scrums. Some people are good at fixing bugs, some people are not.
Re: (Score:2)
Agile software development grew out of the requirement to do Web software development for people who don't know what they want but know what it may cost and when it needs to be finished.
No it did not, and adding "Web software" n the middle makes it even more wrong. What the funk has web or no web, cloud or no cloud to do with the way you make software?
Agile comes from a few conclusions:
a) programmers like to program, so let them
b) restraining programmers by over complicated rules makes them: less programmin
Edge computing and privacy (Score:2, Informative)
The rise of edge computing - partially driven by a public that is slowly grasping that profiling is not just being used for advertising anymore - makes me wonder if the whole "everything will be connected networks" notion will be as prevalent as the author believes.
That being said, I'm not a big fan of agile either. Especially when it comes to implementing privacy by design, there is a strong need to have a good "waterfall-like" design plan. Tacking on privacy protection in an agile sprint is often difficu
Re: (Score:2, Funny)
Especially when it comes to implementing privacy by design, there is a strong need to have a good "waterfall-like" design plan.
Utter nonsense.
Good privacy tools are virtually plug-and-play these days, and as long as you play by the proper rules (using POST rather than GET, for example) most of the work is done for you.
BUT a security audit is still needed to make sure all relevant code adheres to the plugin's guidelines. An audit afterward is not the same as waterfall before.
Re:Edge computing and privacy (Score:4, Interesting)
Is my sarcasm detector broken or did this person just say information privacy can be achieved by including a plugin?
I mean, this may actually explain the massive proliferation of data breaches in the past several years if "agile" is responsible for these kind of design patterns.
Re: (Score:2)
Did you POST that, or GET that? Apparently POSTing it is safer.
Re: (Score:2)
Luckily, nobody cares about privacy anymore.
Agile never was a good idea in serious dev (Score:5, Interesting)
Sure, for some mickey mouse startups that chuck stuff over the fence every 5 minutes in a desperate attempt to get noticed then it might work. But when you're working on a huge project you want grown up milestones on the order of weeks or months with the occasional meeting to discuss issues that can't be done by swivelling on your chair and talking to a team member nearby. Standing up every morning and saying the same damn thing every day so some piss poor excuse of an adolesecent manager can fool himself and his superiors that he has his finger on the pulse is a fast way to piss everyone in the team off. In fact in the last place I worked that did this people started deliberately turning up late for work so they could avoid the morning farce to face.
Re: (Score:3, Informative)
Morning stand up meetings are a facet of specific methodologies, not a necessity of an agile approach.
What you're telling me is that you and your team failed to understand the ethos of agile development and particularly failed to apply it.
You're slating an entire approach because you're incapable of following it. That's ok, not everybody's a good software engineer. Maybe you can get a job in testing or support.
Re:Agile never was a good idea in serious dev (Score:5, Interesting)
The ethos of Agile is "do what works". It's not particularly prescriptive, so it's mostly-useless. Almost by definition, anything that is "working" can be called Agile, and anything that isn't, can't. Yippee?
Re: (Score:2)
You've greatly oversimplified there, yet.. even with that simplistic description it's obvious that the person to whom I was replying had gone wrong.
Re:Agile never was a good idea in serious dev (Score:4, Interesting)
So where did he say that morning was a necessity of an agile approach? The way I read it he was making two points:
- The way companies implement agile is often BS (like daily standups where you report progress to a manager)
- The constant small iterations and checking in of agile (sorry, but highly regular checking in with the customer and high levels of cooperation are parts of agile) does not work well with large products that have roadmaps, large increments and long term plannings.
People that defend Agile tend to go all 'No true scotsman', but in reality it's simply true that agile does not fit every project.
Re:Agile never was a good idea in serious dev (Score:5, Insightful)
Small iterations and checking in are different to regular engagement and cooperation with the customer.
Both are useful, even if you're otherwise following a waterfall methodology.
Indeed, back when I was using waterfall approaches there'd still be constant validation and feedback loops because - get this - they're fucking important.
The people doing long term planning don't know what's possible, what's not possible, they often don't know what they want or what they want isn't what they need. Waiting until the end of the whole process then showing them something that isn't useful to them would be fucking stupid.
Re: (Score:2)
No. I'm someone that's successfully delivered working software using agile methods, that's successfully delivered major programmes using agile methods, that continually identifies and helps others introduce agility into their working practices.
I'm someone with no patience for idiots going, "This thing we're not doing properly isn't working. The thing must be wrong, not the way we're misusing it."
Too fucking right I'm calling out that lack of self awareness, because it doesn't matter which fucking methodolog
Re: (Score:2)
Hell no. I'll go and work with competent people capable of understanding their own issues.
Re: (Score:2)
Not quite. I'm saying that business environments are complex and in a constant state of change, and that technology advancing rapidly exacerbates both while at the same time adding tremendous risk and opportunity, and as a result strong rapid feedback mechanisms are bloody sensible.
No incompetence involved or required.
Re: Agile never was a good idea in serious dev (Score:2)
Re: (Score:2)
I on the other hand don't follow a broken process - such as, e.g. non-productive daily morning meetings that add no value.
I'm glad that we agree that following a broken process is fucking stupid. Just like the person blaming this on agile approaches.
Re: (Score:2)
Re: (Score:2)
No.
"Here are things that work. Try them. If they work for you, keep them. Don't do this without that, as that mitigates a key risk this introduces."
Is that so hard a message? Nobody pretends agile methods are a universal panacea, it's only the people that lack the ability to implement them that pretend they're universally wrong.
Re: (Score:3)
Re: (Score:2)
No, it's not, because Agile isn't a process.
Is that really what you think? You should go and do some learning before commenting further.
Re: (Score:2)
"You're slating an entire approach because you're incapable of following it. That's ok, not everybody's a good software engineer. Maybe you can get a job in testing or support."
Oh dear, another one for Dunning-Kruger.
Re: (Score:2)
Re: (Score:3)
when you're working on a huge project
Stop right there. As soon as you are "working on a huge project," you're already not doing agile.
The reason many attempts at "agile" fail, is that people don't understand how to break up a "huge project" into small pieces. This is part art and part science. It can be done, it just often isn't. If you don't do this, of course agile isn't going to work!
Re: Agile never was a good idea in serious dev (Score:2)
Re: (Score:2)
OK enlighten me!
Re: (Score:3)
A project might be "create a new IoT device so we can jump on the bandwagon". Ok, bad example, those are huge projects that people incorrectly assume are small. A huge project, such as one I'm starting on, is "port our existing system to a brand new platform, replacing the monolithic design with everyone using global variables and have it run on an existing Linux platform, with parts being placed in kernel, user space, and DSP/helper processors; physical radio will be replaced with a software defined radi
Re: (Score:2)
You're conflating "agile" with "scrum". That's fine, most of the industry does. What's worse, what people call "scrum" 80% of the time isn't at all. Not just "No True Scrum", as in some detail is wrong, but the basic fundamental idea isn't there at all.
If your daily stand-up is in effect a progress report to your manager, you're not doing scrum at all - you've entirely missed the point. This is of course normal, and why people hate scrum.
If your sprint retrospective is led by your manager and mostly inv
Agile is an Adjective (Score:2)
Agility is a property of a process. In software engineering and development it refers to the ability to be able to tackle requirement/feature changes which occur frequently. If you built something which has a different setup, you do not need agile.
In addition scrum is only one way to organize an agile process. There are others.
The truth is agile processes are becoming more normal and less hyped right now. While still a lot of people use it as bad excuse to chaos hacking.
You don't say (Score:2)
Wait, so breaking up your existing development process into sprints, holding daily standups, and randomly calling someone a scrummaster doesn't magically fix things like a silver bullet? For the most part, what companies were doing had nothing to do with agile (other than vaguely looking like it and using terms borrowing from agile), so it would be great if they stopped calling it agile.
Incremental vs iterative delivery (Score:4, Interesting)
Incremental delivery:
We'll remodel and expand your house from v1 to v2 to v3 to v4 while you're living in it. We'll try to keep everything working through every change, even while we're redoing the whole plumbing.
Iterative delivery:
You live in house v1 while we build house v2. We test it, you test it and then you move as we demolish v1 and start building v3. This is a repeating cycle.
What method makes sense? Both. You obviously don't build a skyscraper one floor at a time, turning a one-story building into a two story building into a three story building and so on. Equally obvious you don't have to build a new house to get a new light fixture. But Agile likes to pretend that all change is incremental and the end goal is unknown even though for every project somebody's made a cost/benefit estimate and decided the money is better spent here than somewhere else. No sane project is actually driven by the "let's keep throwing money at it and see what we get" model, even if it's your single flagship product somebody's got a long term plan, even though we're only supposed to look at what we can get done in the next sprint.
Part of that is that business value is often realized when everything is done. If you're building out a rail line you need tracks with bridges and tunnels, signals, stations and trains. Nobody cares that you've laid down 95% of the track unless the train can actually run. The same is often true in software, we can't replace the old system until the new system does all of these things, not just a few of them. If you wanted a rail system that's ready to run every two weeks they'd say you were insane, in software nobody bats an eye. That's not to say I can't break it down in a traditional Work Breakdown Structure (WBS) from waterfall development, just that the value can't be realized until it's all there. Like a legacy system you can't shut down until all the users are migrated off it.
My impression of Agile - even though it seems everyone and their dog has their own understanding of it - is that it's okay for time boxing all the small stuff, our users want a thousand little things and they get ten in the next sprint. But if we have a project that'll go live in a year it's attention starved, it doesn't have any deliverable due now and we're not able to find any meaningful task to do now so it kinda just drifts in the product backlog until somebody realizes that gross estimate of hours = number of developers * time to deadline, forget Agile just scramble to make progress so maybe we'll reach the finish line in time. Same with any other long term effort, we're optimizing for where we'll be at the end of next sprint not where we'll end up.
Re:Incremental vs iterative delivery (Score:5, Insightful)
Nobody cares that you've laid down 95% of the track unless the train can actually run.
And that's why the first question in agile planning is: What's the simplest thing that can possibly provide business value?
Perhaps you could lay down just 50% of the track and hurry up building the midpoint train station. Then you could run trains on the shorter stretch while you're still laying down the rest of the track.
Or maybe we can use the track already built to transport materials to the builders.
Or maybe a segment of the already laid track can be used for testing trains.
If you actively look for these opportunities, you find them. If you don't, you end up accidentally putting road-blocks in place; keeping with the example, perhaps the signal systems are scheduled to be built last, which you can't change because the dates are set in stone in the contract you made with the lowest bidder.
Part of that is that business value is often realized when everything is done.
Even if it's true, you must never concede that up front, or else you're going to do a poor job. The sooner you get something up and running that is useful in itself, the sooner you get feedback. Lack of feedback ruins products.
Re: (Score:3)
Nobody cares that you've laid down 95% of the track unless the train can actually run.
And that's why the first question in agile planning is: What's the simplest thing that can possibly provide business value? Perhaps you could lay down just 50% of the track and hurry up building the midpoint train station.
I think it's here we disagree whether Agile is an advantage or a distraction. Because the business case is connecting the big cities on both ends, a train route from one city to the midway station might be like 20% of the business value for 50% of the cost. Or maybe more than that, even though you lay down half the track you might have to buy the entire train set and any custom design work already. All the delivery times and scheduling dependencies have to fit a tighter time window. You end up chasing a ver
Re: Incremental vs iterative delivery (Score:4, Informative)
But it's not really about extracting value early. It's really about course-correcting early. If you start building track in two location, it's nice to know early if those tracks aren't going to line up. That's agile.
Re: (Score:3)
But it's not really about extracting value early. It's really about course-correcting early. If you start building track in two location, it's nice to know early if those tracks aren't going to line up. That's agile.
Yes it is, that's why they're nagging about the software always being in a shippable state. The waterfall model also has mock-ups, prototypes, proofs of concept and other forms of customer interaction/verification, but it's the constant shipping of new features over large, rare releases - particularly the initial release - that is unique for agile. Ideally they want it straight out of the CI system with 100% test coverage and straight into production. As for course correcting early, like make a detailed pla
Re: (Score:2)
Buzzword Adoption (Score:2)
I guess it is (Score:5, Funny)
My company decided to go all agile with its development a few months ago, and us adapting something is usually a telltale sign that a trend is over.
Re: I guess it is (Score:2)
It isn't Agile (Score:4, Interesting)
Unfortunately, most methods / methodologies receive their fame through fads. Mostly by chieftains trying it out as a means to make their job all about saying "there there", without actually putting in the effort to get stuff going.
You almost see crappy managers thinking "Surely there must be a way for me to get all the attention, honors and gratifications by commoners willing to organize themselves and do the hard work. Let's see if Agile is a thing. If not, then we'll fire people and jump onto the next bandwagon."
Most Agile methodologies are highly commendable. However, they don't replace the need for people actually doing sensible work. No software writes itself. No problem solves itself.
There's a tipping point with organization size where it starts to be very hard to find a management tier that is actually interested in bringing the business forward.
On the plus side, when Agile looses management attention, you can actually adopt the methodologies for what they were meant to be and do a good job.
Signal to noise (Score:2)
The problem with Agile is that because it was successful in a few edge cases it became a fad and people who didn't understand Agile starting doing inefficient things that they mistakenly called Agile.
The last time I worked with something called 'Agile' it was basically waterfall (*all* client feedback was ignored by the developer team) with scrums tacked on, in a project with dozens of people and where scrum simply didn't scale and simply took up an hour or more of everyone's time every day but individual d
Who writes this stuff? (Score:5, Insightful)
"where connectivity to both data sets and composite enterprise data"
"to a curational one (mapping models via minimal technical tools)."
" Today, the typical application is more likely a data stream of some sort"
This guy is a "data scientist", AKA a database analyst (what we used to call them). People are way too self-centered. And his writing style is garbage. Mapping models via minimal technical tools? WTF does that even mean?
Re: (Score:2)
This guy is a "data scientist"
No, he's a self-proclaimed guru. He throws out what he thinks is fancy jargon because it will almost always get nods from management who have no idea what he just said. Meanwhile the developers keep their resumes up to date.
Agile (Score:2)
Nothing new... (Score:5, Insightful)
This sentiment has been around since 'Agile' became a huge branded cult to push certain software tools and consultancy. Give Atlassian and/or consultants branded 'Agile' enough money and they'll fix your company. It is self-help snakeoil for companies.
Agile started out as a group of folks stating four sentences that should be obvious. Since they had the word 'Agile' in their title and it resonated with a lot of software developers, consultancy picked it up and ran with it.
Agile consultants immediate threw out the prioritization of individuals and interactions over processes and tools, because they couldn't profit from that but they can profit from telling you specific processes to run and tools to use. So in modern Agile consultancy, the exact opposite of the very first sentence is advocated: processes and tools are the sacred thing.
The next two sentences are pretty much ignored or mentioned in passing. The whole reason document workarounds instead of fixing code is so prevalent is that it is seen as a cheaper alternative, and again it's hard to get your snake oil money if you go too directly against the business priorities.
Customer collaboration is great, but again businesses love a concrete end game and so they won't get comfortable with a loosely defined partnership between businesses so Agile consultants won't push that.
So finally we come to the one part of the manifesto they root everything in. The horrendously obvious fact that responding to change is good. That's where no one can possibly disagree and where the maximum milking companies for money potential exists.
The reason Agile accumulates so much association with failure (apart from deniers who decry failures as 'not true practitioners of Agile) is that it is *the* current fad and as such going big on Agile is usually the mark of a company that is already failing due to bad management, bad developers, or just targeting a market that isn't going to pan out. Such a company hopes a project management consultant can pull them out and thus they become 'Agile'. Regurgitating self-help is never a healthy sign for a business, even if the statements are correct. Any branded fad will fall to the same fate.
The simple reality is that bad project management methodology can tank a good effort. However good project management cannot salvage a bad effort. However that's what companies want, because other options are either not what they want to hear (the leaders are at fault), impossible to overcome (bad fundamental idea) or more expensive to overcome (you need to employ better people and actually care about retention).
Re:Nothing new... (Score:4, Insightful)
Yes (Score:2)
Well, for me it was never relevant.
I called it Fragile right from the beginning and still have that view today.
Fads come and fads go.
RIP Agile.
Enterprise Data Systems??? (Score:2)
There's nothing special about "Enterprise Data Systems," when it comes to suitability for agile. What this author is admitting, is that he doesn't know how to break up a large project into small pieces. This is not a failure of agile, it's a lack of ability by the analysts.
Re: (Score:2)
Not true.
the reality is that in enterprise many other systems and groups not under the agile manager's control will be in play, those will NOT be subject to agile methodology and dictates.
Clients are still very relevant. (Score:2)
The statement that client code is becoming less relevant is false. There is a lot of client code, just because it may run in a browser, does not mean its not there. There are reasons, you can unload some processing from the server end, things related to the UI may not need to be done server end. Many clients running in web browser can be as complex as native clients. With Progressive Web Apps, the possibility of saving transfer and server processing time of having to download the client code with every logi
PRETEND agile is becoming less relevant (Score:2)
Agile is the big buzzword, everybody is doing it. Few do it.
Years ago, my company decided to do scrum. They decided to have daily standups. Of course, they all do this, right!
Next, they decided to divide an upcoming project into sprints:
1. Design sprint
2. Coding sprint
3. QA sprint
4. Deployment sprint
This is the kind of stuff I run into all the time. This is not agile, it's just waterfall dressed up in agile ceremonies. Of course this kind of thing is becoming less relevant.
Re: (Score:2)
Don't forget "bug fix sprint" which is usually postponed until end of project.
Re: (Score:2)
Yeah that one always gets forgotten, and postponed, and there is lots of anguish and finger-pointing to go with it.
Re: (Score:2)
and "never actually document"
yup, it's mad dash to trainwreck that is thrown over the wall at others to support while the "scrum hero" manager goes to his next gig.
Re: (Score:2)
You mean scrumbag [reddit.com] I presume.
Execs think agile is about saving time and money (Score:5, Interesting)
Executives think, "If we switch to agile, we can have new features in half the time." When reality sets in, they are disappointed.
The reality is, agile development isn't speed up coding, what it really does is help eliminate work that shouldn't be done in the first place.
When a big project is designed in its entirety up front, that design will include many bells and whistles that don't need to be there. One advantage of agile is that incremental delivery will make it clear, earlier in the project, that these superfluous features aren't really necessary to build--ever.
If you go in to an agile transformation without understanding its real goals, advantages, and pitfalls, of course the transformation will fail. I will gladly compete in the market against you, my agile approach will beat your waterfall (or false agile) approach every time.
Re:Execs think agile is about saving time and mone (Score:4, Interesting)
Re: (Score:2)
Yes! I'd give you mod points if I could.
Re: (Score:3)
what it really does is help eliminate work that shouldn't be done in the first place.
Or it allows the feature to be redesigned after stakeholders can see that it doesn't quite work as intended or as hoped. Agile is about iteration, and that can include refactoring, not just prevention.
Re: (Score:2)
Exactly. One of the big advantages of Agile is it give you more tools for having genuinely useful conversations about uncertainty in the requirements, up and down the chain of command.
If your requirements are trustworthy enough to carve into stone on day 1, yes, it is quite possible that Agile is not a big win, and you might even find advantages in a more Waterfall approach.
For anybody that wants to know how to do real agil (Score:2)
Re: (Score:2)
Re: (Score:2)
}} So for anybody that actually wants to do real agile the first step is don't read the agile dogma. {{ --- that's one of the many problems with agile. In the eyes of those doing agile, no one else seems to do it correctly.
The worst part is those that think that way often seem to think everybody else is a heretic to the religion of agile. (I wish I was making that up.)
Re: (Score:2)
Since it seems contradictory not to read the dogma by the people that invented it, how about the successful (making money) places that never did agile just forget the whole thing and keep doing what they're doing?
Re: (Score:2)
"it is not the silver bullet that some claimed" (Score:2)
Efficient iteration (Score:3)
Agile is about building a team that can iterate efficiently. The reason for doing so is that large projects are practically impossible to design in detail up-front, and it thus makes more sense to structure your team and the way it works to focus on small pieces. It doesn't matter if a particular piece is thrown away later, or if it's permanent. If the team can iterate quickly and efficiently, the software can be improved.
It's like refactoring at the feature level, instead of on the code level. When refactoring, code is often thrown away. You have to be able to do that with features. The team has to be able to pull out features without destabilizing the code base, and they have to have no emotional attachment to a particular implementation.
That's Agile.
All the rest, like SCRUM, KANBAN and sprints are just ways to formalize what was never meant to be formalized.
I'm not a zealot... (Score:3)
'If Agile doesn't work for you, you are not doing it right.'
is absolutely true IMHO.
I have walked into so many places that you can tell have adopted 'agile' just because it was at one point a buzzword, and their implementation comes down to just having a daily 'scrum' call w/ developers to say what their doing, but is certainly no where near the real scrum meaning.
At the end of the day, Agile is really not different than other project management techniques. It is a defined process to establish a plan to deliver software on time. The details on how that is done, sure there are lots of differences vs waterfall, for example.
But it absolutely still requires the same things such as analysis and design time, risk identification and mitigation, scope management, defending of the project plan, etc. For Agile, you also need scrum masters who know how to run a scrum meeting, sprints with reachable goals and measurable outcomes, testing resources available throughout the project and commitment from the project sponsors to be involved throughout the project for deliverable reviews
I have only seen a small handful of companies that knew Agile and did Agile correctly. Most of the others took their old waterfall model, sprinkled in daily status calls with developers and token sprint deadlines and then claimed they were Agile.
It has ALWAYS been about the data, stupid! (Score:2)
> in which the value is not in the programming but in the data itself
Programs exist SOLEY to transform data. Show me a useful program without input or output?? Programs that don't deal with data are toy examples.
Sounds like authors haven't read the Mythical Man Month [amazon.com]
Which in the modern vernacular would read:
Re:If agile doesnt work for you, switch (Score:4, Insightful)
Each company can, and SHOULD, implement 'agile' in a way that suits their culture, their pace of development.
This is the crux of the problem: 'Agile' doesn't really mean much specific. Advocates claim victory over any example even when the examples have no commonality.
This fuels snake-oil consultancy and software. 'Agile' is used as a brand to suck money out of troubled businesses. The ability to point to any success story in the world and assert 'Agile' as the cause (even if the developers didn't claim they were doing Agile) combined with any bad examples as 'well they just didn't embrace Agile the right way'. It's a rather profitable no true Scotsman fallacy.
Re:We tried agile, and it was a disaster. (Score:4, Interesting)
The major problem I have experienced with "Agile" is that any problem fixes now have to end up being delayed because they have to go into the "backlog" and then put into a planning meeting to schedule when they shall be fixed.
To me a backlog shall only be used for stuff that you failed to do in the initial plan for new development and any problem reports shall be fixed straight away without being flooded into a "backlog" unless there's a specific reason like reports on stuff not yet implemented and misunderstanding of functionality.
With the "Agile" mindset we now have had problems in the queue for 6+ months that aren't fixed.
Agile does not stop micromanagers (Score:2)
No, that is not an Agile problem. That is a problem with project managers and line managers who micromanage day to day tasks of the people who already should know what they are doing just fine.
It is quite conceivable that how Agile is being used where you work made this problem worse. But Waterfall, for example, does not automatically make this an iota better. How many times have you seen a group organize around achieving major "milestones" and the result is pushing off bug fixes to after "feature comple