Slashdot Mirror
Should Developers Abandon Agile? (ronjeffries.com)
An anonymous reader quotes InfoQ:
Ron Jeffries, author, speaker, one of the creators of Extreme Programming (XP), and a signatory of the Agile Manifesto back in 2001, shared a post on his blog in which he advocates that developers should abandon "Agile". The post further elaborated that developers should stay away from the "Faux Agile" or "Dark Agile" forms, and instead get closer to the values and principles of the Manifesto. The terms "Faux Agile" and "Dark Agile" are used by the author to give emphasis to the variety of the so-called "Agile" approaches that have contributed, according to him, to make the life of the developers worse rather than better, which is the antithesis of one of the initial ideas of the Agile Manifesto...
Jeffries writes that "When 'Agile' ideas are applied poorly, they often lead to more interference with developers, less time to do the work, higher pressure, and demands to 'go faster'. This is bad for the developers, and, ultimately, bad for the enterprise as well, because doing 'Agile' poorly will result, more often than not, in far more defects and much slower progress than could be attained. Often, good developers leave such organizations, resulting in a less effective enterprise than prior to installing 'Agile'...
"it breaks my heart to see the ideas we wrote about in the Agile Manifesto used to make developers' lives worse, instead of better. It also saddens me that the enterprise isn't getting what it could out of the deal, but my main concern is for the people doing the work..." He argues developers should instead just focus on Agile's good general software development practices -- like regularly producing fully-tested software and consciously avoiding "crufty" complex designs.
But what do Slashdot's readers think? Should developers abandon Agile?
Jeffries writes that "When 'Agile' ideas are applied poorly, they often lead to more interference with developers, less time to do the work, higher pressure, and demands to 'go faster'. This is bad for the developers, and, ultimately, bad for the enterprise as well, because doing 'Agile' poorly will result, more often than not, in far more defects and much slower progress than could be attained. Often, good developers leave such organizations, resulting in a less effective enterprise than prior to installing 'Agile'...
"it breaks my heart to see the ideas we wrote about in the Agile Manifesto used to make developers' lives worse, instead of better. It also saddens me that the enterprise isn't getting what it could out of the deal, but my main concern is for the people doing the work..." He argues developers should instead just focus on Agile's good general software development practices -- like regularly producing fully-tested software and consciously avoiding "crufty" complex designs.
But what do Slashdot's readers think? Should developers abandon Agile?
Agile, the idea, is total bullshit. Its execu-speak at its worst. Just fucking grade-a unproductive hot air
This makes it really difficult for an organization to determine if they're truly doing "Agile" or some bastard form. It also calls into question methods and even formal standards built on 'Agile'.
But when I've pressed Agile Evangelists on this, usually when we've had problems and I've asked, "So are we doing Agile", all I've gotten in return is, "If it's not working, you're not doing it right."
No. What make agile work is accountability. The agile shops I've seen have what's basically a case system that tracks User Stories which describe small amounts of work. That's used to manage the teams and make sure they're move forward to some definite goal. That's the reason agile works. You can keep tabs on what your devs are doing and if they go off the rails fix it in 1 sprint.
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
It's time to idiot-proof your methodologies. If even the lightweight methodologies are so easy to do wrong, what change is there for the efficient application of the heavier ones? After all, the water-fall was the anti-thesis of a working approach which people adopted as the method. This has to prove that people have difficulties even in the skills like reading.
The failure of Agile was always there from the start. The original consulting firm pushing it was a failed software development firm that found a hustle to keep going. Good programmers (in the broad sense, including many related job descriptions) are necessary but not sufficient to deliver working software. Having reasonable goals is also a requirement. If you have both, you often succeed. If you don't have both, you fail. That's it, everything else is for the benefit of middle mismanagement.
It's rarely done by the book - almost ever org I've worked for tries to tweak it to "make it work better for us". It usually means longer or shorter sprints (screwing up cadence, where you run behind or only do "big" sprints) or daily meetings that last for an hour.
Either do Agile like it was designed or do something else (Agile is absolutely not the only way to run a dev shop), but don't hybridize it and try to convince yourself and others that you've made it better.
Let's face it: buzzwords ruin everything. "Agile is a turn-key solution to invoking a paradigm shift within the DevOps world." Agile in itself is a buzzword, and if it wasn't initially supposed to be one you can bet it was put through the ringer until it was one. "Stories" and "Sprints" just add to the mess.
Thanks to using tried and tested wartsandall I got a frosty pist!
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
It's got a manifesto.
Those who have to live with it want to escape it.
It slowly destroys organizations that use it.
Despite always failing "real Agile has never been tried right".
Agile is for undisciplined developers and managers of those developers, not to mention the bending of rules that invariably happens when the business side gets involved.
The so-called business buy-in almost always means some form of compromise to the point where you end up with Agile Theatre.
Checking in daily for scrum is like being in kindergarten with show and tell every day, how glum.
We should go chasing Waterfall?
a manifesto outlining a path for the people responsible for creating wealth is abused by a few powerful people.
Everyone says it will be perfect if it were just done right.
Yes, we should switch to whatever Ron Jeffries is selling!
Let's build a complex system from the ground up using Agile!
Requirements? Bah, we'll iteratively improve our product!
Design? Not needed! That's not needed
Two years later:
"You need what? Ummm, we can't make those features work given this mass of interacting black boxes. Seems like nobody documented how they work together..."
I've worked in both a small shop (under 20 developers) and a decently large organization (more than 400 employees) although outside the dev shop. I had positive agile experiences in both places.
What I've found is that agile works given a few conditions:
1) The organization actually adopts agile, and embraces it.
2) The owners of the development both understand agile and have the political power to enforce it.
3) The devs understand agile and can thrive within it.
When all that happens, and I know that's not often, Agile can shine. I've seen it, and I've really appreciated it. I get how it can go terribly wrong, but it can and does work, if the environment allows it.
Velociraptor = Distiraptor / Timeraptor
I have found agile to be a great tool for micromanagers. Because the business doesn't actually know how to abandon BDUF, they still do it (gotta have time lines and designs and schedules and all this certainty, despite being "agile"). Then they cram scrum and sprints and shame-filled standups down their developers throats with micromanaging PMs. The one I worked with was a narcissist to boot. I'm convinced Agile can only work if administered by people with software engineering experience (which is far too rare in software engineering management; so many seem to me PMPs and Industrial Engineers).
I have no idea what you're talking about, but it sure isn't Agile.
It'll destroy your team's productivity, but only because "THAT ISN'T REAL AGILE!!!!!!!!111111111111"
Agile needs to be put up against a wall, yes.
we're talking about minimizing that risk. If you're having that much trouble it's because nobody's managing the queue. But at least there _is_ a queue. There's something written down that can be post mortemed. The alternatives I've seen is to write a massive design document and have at it.
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
Stop believing that if you could only find that one perfect methodology, your mediocre team of developers will create greatness. It has never worked in the past, and "agile" (however you define it) is no different. Project managers and business types are addicted to this fantasy, because accepting the reality would lead to extreme cognitive dissonance.
As always, there are no silver bullets. Hire smart people, give them autonomy (they will adopt their own methodologies as needed), keep teams small, and design solutions that are as simple as possible (but no simpler). Domain knowledge and close communication with the end users helps. But all that is no guarantee of success either.
Bingo, useless managers trying to justify their existence with bullshit & buzzwords.
Bad managers will not use Agile as an empowerment tool and instead simply mimic the rituals but not realize the benefits. Bad developers will use Agile as an excuse to do whatever they want rather than focus on the output of value for the end user, often in service of avoiding future rework or in the name of faux quality features that doesn't actual add significant value.
I've seen both ruin many an effort. If managers would focus on building a high functioning team, empowering them, and building a continuous improvement cultures and developers would focus on understanding and delivering value to the company then Agile works better than anything else out there at least currently.
BTW, bad managers and developers also screw up waterfall and any other methodology you want to work with.
Part of the problem is the idea that with sufficiently detailed procedures, the village idiot can do theoretical physics as well as Einstein. In fact, no amount of procedure will make that happen. Quite the contrary, all that procedure means that if you ever do hire Einstein, his output will closely resemble that of the village idiot.
Consider one of the popular union tactics, the "rulebook strike". That's where they destroy productivity and punish the employer by having their members actually follow all the workplace rules and procedures rather than doing the right thing (TM,. pat. pend.). It works.
And use common-fucking-sense. Enough with trying to adhere and conform to buzzword driven fads.
Because most don't actually do agile.
Agile doesn't help developers. It doesn't make them better programmers. It doesn't produce better code. Agile is not for the benefit of developers. Agile improves information flow to project managers. It allows for better business decisions.
Theoretically if a project is going south you can even abandon the whole project and move all the resources onto something that has a chance of success. But I've never seen Agile used in this way in the real world, perhaps the sunk cost fallacy is too strong in business culture.
If you want a hint on how little value Agile offers to developers. Look at the top open source projects, look at a 100 of them, I don't care. You won't find them using Agile, you may even hard pressed to find them using bits and pieces of Agile. And I think it's because coders don't enjoy it. Coders won't use Agile unless someone is paying them, but they'll write code for free.
People who use hairy pooper terms like that can immediately be dismissed for being the morons they are.
I've supposedly been doing agile for years, but I've never once worked on a self-organizing team who could build software without working with several external groups. And all of those external groups are set up to work waterfall. You've got the UI designer who wants to design the whole experience up front. You've got the data modeler and DBA who both want to know exactly what data you will be using up front. You've got the architect who wants the full design documented so they can spend 10 minutes looking at it and give you an approval. You've got the project manager who wants to know exactly how long all the development is going to take. So you end up having to do big-design-up-front in order to work with all these external groups.
A lot of companies say they want developers to do agile, but they need to realize that agile requires changes throughout the organization. It's not something that developers can just do by themselves.
"... we're going screw around everyday acting all busy."
When you don't know how to swim, splashing water all around seems like a great idea.
But but but my deep learning?
I was on a team that "used agile" for while. The thing is, our development workflow "before agile" already addressed the main ideas in the agile manifesto, so in practice what happened is that our development workflow was unnecessarily modified (disrupted?) to include more "agile practices" like pair programming and other buzz words (user stories, rigid application of TDD, et cetera). We didn't see much (any?) real benefit. It eventually got abandoned. Can't say I miss it.
I've got no problems with the ideas in the agile manifesto. I'm just not convinced that the practices and culture that often gets included are always worthwhile.
At every place I've worked, including the company I now own, the developers haven't been the ones that decided on the development process. The fact that they haven't decided has either been because no one actively decided, and management provided a default choice, or because management actively made a decision regarding the development process (either due to business needs, or basically arbitrarily.)
So, I believe the question of whether or not developers should abandon Agile is based on the false pretense that developers typically are able to make a decision. I don't believe that they are able to decide which development methodology they subscribe to, in general.
Agile doesn't deliver what the business wants which is to turn coding into non-creative work where you know almost exactly how long it takes to get from A to B and exceptions have explanations like traffic accidents or construction work. Nothing ever will but it won't stop them from trying so the best Agile can do is shield the developers from impossible tasks and meaningless meetings so they can spend time on actually doing development.
The first shield is the product owner, a ton of people want things and they'll go through all sorts of channels with competing priorities and sneaking in pet features. Shut them down, make that one channel in and one non-developer resource they can talk to if they're not happy with what they're getting. And no, there's no point in re-prioritizing things daily once every two weeks is fine for everything but hair-on-fire emergencies. The second shield is the scrum master, I'm currently one and my main job the way I see it is to maximize the number of hours my team members actually get work done on the things they're supposed to be working on. Particularly all fuzzy meetings called to discuss things where I say "You figure out what you want first from a business perspective, then let's talk solutions" or that are more or less status/re-planning meetings where I say "The quickest way to get it done is to let the ones working on it work on it."
It's not particularly Agile-specific, reality it's about two simple things, what should I be working on and let me be so I can do my f*cking job. Whether it actually works better for planning than iterative waterfall, meh... I've always said you should try to think and explain as far ahead as reasonable, like is this part of the functionality/structure you'd like to have in the end. You don't build a skyscraper by building a one-story building and then building one more story on top, if you know it's going to need to support 50 stories then tell us now.
Live today, because you never know what tomorrow brings
Programmers that donâ(TM)t understand the business needs, business people who at best inaccurately describe what is needed, managers who donâ(TM)t get either. And everything has to get done now, or yesterday.
Only if you blockchain.
Agile is great at providing predictability out of a mediocre workforce which, however unpolitically correct it is, makes up the majority. It's horrible, demoralizing, and unproductive for top performers. Good managers will figure out how to remove the top performers from the process or work out an "understanding" with the more astute top performers that they only need to pay lip service to the process.
Poettering! Don't try to sneak away.
Have gnu, will travel.
Most people donâ(TM)t really understand most of what they say or think. Ask a manager what Agile is. Ask a developer what REST is or browse your codebase for the ten different implementations of something called a strategy pattern or a factory pattern. Ask yourself, honestly, how much do you really understand about things you talk about or follow? How much do you really understand that diet youâ(TM)re on or how to run the country that you think is making so many mistakes? Our brains fill in all these blanks for us, all the time. We go through life imagining that we have a coherent, complete view of whatâ(TM)s going on around us but we see little and understand less. No matter which methodology we try to push, very few people will really grasp it. Most people will read about it i their lunchbreak or hear about it at some pizza and beer fuelled âdev meetupâ(TM) or maybe even do a course in it and then steamroll it into their organisation and write âimplemented [some methodology]â(TM) on their six month review, get a gold star.
But I've been on 3 projects in the last 40 years (I'm retired now) that had daily meetings. All 3 failed for different reasons (hardware issue, company died before project was done, what I just said except for a chip, not a printer).
What did these 3 have in common? The daily meeting absolutely killed morale. For the first, us software types had a daily meeting where the hardware guys would mumble, the second was at 7 AM daily, even on a Saturday morning (I was in my 20's and still half drunk from the night before, and got sucked into the project when it was failing because "you understand this Unix stuff"), the third was flat out an incompetent manager who could not remember anything day to day.
For the first, no reason for us software types to be there as there was no hardware.
For the second, 7 AM on Saturday morning? You'd have been better off letting me roll in at 9.
For the third? There was no fixing that. The manager was 100% incompetent and could not be fixed.
A key concept in just about any programming task is you need to be doing software engineering, not just being a code monkey pumping out "work units". Just about anything where you assign code monkeys to do it or you yourself do not have a clue about what it actually means to be a software engineer, well it is going to go badly. When you have code monkeys doing 'agile' well monkeys do fling poo and this usually means they fling poo at a faster rate, making more of a stinky mess. The key things that must be adhered to even if say your original vision is like 30 lines of code, because everything grows and evolves is:
1. Do you have a modular design?
2. Does this modular design cohere to best practices, especially if there is any chance of all of this script / program / application growing to a significant size? Especially if you are looking at more than a couple thousands lines of code, you really need to start investing in an industry standard framework. When you get into the 10k+ line applications any application without an industry standard framework is a doomed one. I have gotten into 10M+ line applications with a proprietary one of a kind in house framework and people just give up and resign because it is just not maintainable and it is super plagued with problems due to this in house one of a kind framework. I am sure when they started, the idea was for a much smaller application, but software are just ideas put into a computer and ideas grow over time.
3. Are you using version control? If you are not using Git or something better (if you can find something better, which if you say yes today you are wrong), well there are going to be problems. Even with Git there are going to be problems, especially if you are inexperienced and dork it all up and/or your coworkers dork it all up, and especially if you don't have hook scripts to prevent clueless developers from dorking it up for everyone else. However without this central ledger, your project is doomed. Even by yourself it is really best to use version control like Git. Otherwise especially in a team, you are all driving around your bulldozers with no windows to look out and you are probably working off of your Pangia copy of the code base and/or actively fudging up the source files that another developer is also actively fudging up. Have actually gone onto job sites like this and those code monkeys did not understand why nothing worked and at this I could see remnants of the original software engineers' code where they did use version control, which is why the application worked at one point in time before the company fired them and brought on cheaper code monkeys to do the job, only to later bring on people like me to try to bail them out.
4. Do you have a real project management system, especially one that ties into your version control system? And at this are you and your coworkers using it right? I find most of the time the answer is no and so of course things are going to go wrong. Don't have the proper coordination or burn all of your time trying to do it manually when there is software automation and you are not smart enough to use a project management system, then you are probably not smart enough to write code that works. Just saying. And when your company is too stupid to understand this, then your coworkers are probably also going to be too stupid to figure this out and so you are screwed and know why you are screwed while the rest of the company ignorantly implodes in around you and leans on you even harder because do you think ignorant foolers like that are going to take responsibility or just blame everything on you?
5. Do you have real coding standards for your project(s)? Like are you going to agree on how to go about naming your variables so they are something that makes the code readable and use standardized naming conventions? So instead of you use the variable X and your coworker uses the variable R and between the two pieces of code you just assign the other person's X to your R and s/he will as
Developers should abandon their tendency to be cargo cultists. Don't do things just because that's the way it's always been done. Don't do things just because someone labelled them Best Practice. Don't do things just because other people have done it and it worked out for them.
The only method that works is to try it out and see where it leads, be super observant about where the pitfalls start appearing, and give yourself enough leeway to try something else if it isn't working out.
Those who do not learn from commit history are doomed to regress it.
Fickle, fickle...
https://www.youtube.com/watch?...
putting the 'B' in LGBTQ+
Cue the chorus ... "you're not doing it right!"
Yes, they should.
This answer is somewhat foreshortened over my previous attempt - for some reason slashdot lost my previous draft when I logged in.
... cos eyeballs is how he makes money. He spoke at our organization and isn't really a dynamic speaker or terrific evangelist. His best days are behind him so he's deprecating the old buzzword and sell the new buzzword.
GIVE UP and let someone else do it
so by definition it can't fail.
But seriously despite the asinine definition that is illogical that the Agile Manifesto gives to this garbage, it's ridiculous to ruin the lives of programmers to push them to complete work before one or two daily meetings. Where I work now, we have four daily meetings, and if you don't have something done then our CEO requires you to wear a pink skirt and sing Total Eclipse of the Heart. Also,. Agile requires that you intentionally ruin any long term planning since you don't think long-term but instead think of sprints. Making software is a marathon, but according to Agile you work people to death for two weeks, abuse them, insult them, insult them, and then repeat that process every two weeks. It's all about abusing people as much as you can legally without being charged with a crime.
Incremental Software Development was around for 30+ years before Agile came along. What changed?
Agile was a salesperson's hip excuse to change his mind on a regular basis and call it "agile". The truth is that salespeople never know what the heck they want built and the biggest bang for the buck has to do with optimizing requirements (the salespeople) not the developers. We could build software 10x as far, but it'll still be the wrong software and it'll get thrown out. Agile does not change that. If anything, it helped things move in the wrong direction.
I always thought the Agile Manifesto was satire. You mean people actually took it seriously?
Let's move on to the next fad.
"When 'Agile' ideas are applied poorly, ...
When are they not?
It must have been something you assimilated. . . .
IE it sounds great in theory but when it comes time to implement it they NEVER implement it correctly.(Which is pretty much what gets said of communism.) Of course I find it telling that one of the big proponents has a communist sounding moniker of "Uncle Bob".
Did you know 80 to 90% of the moderators on slashdot wouldn't recognize a troll even if one dragged them under a bridge.
First, I think that everyone should know by now that Agile was nevera meant for developers, it was meant for management making developers do their Jobs and the management's job and passing responsabilities to developers, and developers will do whatever management push.
Second: Most methodologies do not hice importance to research and learning, they always think that pushing seconds will get things done, orden that everything can be solved with tools or consulting.
Sometimes management makes me think that developers and programmers are just type monkeys or that they were born knowing everything.
We are doing a project where problem is that requirements are very specific mandated partly by laws and legacy interfaces but requirements are still unknown. Documents have 50% wrong info and experts of domain don't know their domain or remember wrong or there are bugs in the law itself there is also old data that is corrupted but still needs to be saved and fixed. This makes architecture hard and it takes a long time to dig out the details and those details constantly change by new disciveries.
More than few months but necessary and worth the effort to stabilize current system..
There is a huge thread about it on Michael O. Church:
https://michaelochurch.wordpress.com/2015/06/06/why-agile-and-especially-scrum-are-terrible/
The original blog post, https://ronjeffries.com/articl..., doesn't actually suggest abandoning agile. Yes, those words are in the post. But hen Ron Jeffries goes on the explain that developers should instead...follow agile principles. I'm confused.
Ron Jeffries thinks corporate versions of Agile miss the mark because they "impose" a process. He says that each team should be able to use whatever process they want.
That sounds nice, kind of like free love in the 60's. The problem is that both produce unwanted results. For example, Extreme Programming was, and still is, a stupid idea. Sorry, two people can't use a single keyboard efficiently. Given total process freedom, some teams might choose this approach anyway. Boundaries must be imposed.
The fact is, a good team will be successful regardless of the process. A bad team will be unsuccessful regardless of the process. IT'S NOT THE PROCESS! It's the PEOPLE!
Hire the right people, and they'll usually have no trouble convincing management to go along with their proposed process changes.
I've lived through the waterfall era. Now I work in a large corporation that uses what Ron Jeffries might call faux-agile. It's Scrum, "imposed" by management. It actually works, the team is happy, and gets a lot done. I'll take this faux-agile any day, rather than go back to waterfall!
I've spent most of my life writing code and working projects some in hindsight I probably had not business attempting myself.
Before I begin work on a new project I collect requirements and use them to determine what tools I need to steal or invent in order to facilitate requirements. I usually spend months just on tooling.. writing meta programs of all kinds to facilitate anticipated flows, improving APIs and frameworks before any real work is done at all.
On number of occasions I've spent months doing nothing but thinking about problems and then designing complex systems to solve them in a generalized manner. This was out of necessity as piecemeal route to what customers want is simply beyond my capability as one developer to implement within the time available to me. Everyone wants everything and I had no choice but to find a way to give it to them.
These systems have over time have proven useful to myself and customers and I don't regret doing it for one second.
Everything I hear about Agile is sprinting and scrumming doing little shit, release often and never thinking holistically about what the fuck it is your trying to do. It seems to be designed for code mills working small projects for one off clients.
I am diametrically opposed to everything Agile stands for and refuse to waste my time working anywhere it is practiced.
So when the request came in to add a historic visualisation to the project, was this a new, out of the blue requirement, or was this always lurking as a nice to have feature that was hard, so had kept being pushed down the stack?
If it's a new out of the blue requirement, then there are millions of things that could have come along that would have been next to impossible to implement in the current system, but also, millions that would have fitted nicely (assuming there was some degree of thought and planning). The team should be able to push back on totally impossible to add features, and if that's not the case, then the company is not following any agile practice. You can't bolt it on at a team level and expect to see all the benefits. Turning it around, what sort of approach would allow any new requirement to be implementable?
Alternatively, it's been on the list of features and has kept been pushed back. This is then a team problem, and it's your responsibility to keep raising this. This is probably the most valuable part, getting visibility of the overall direction of a project, and being able to access and vocalise your concerns. If you didn't feel empowered to bring this stuff up, again, that's not agile.
So, badly implemented agile is a problem, as is badly implemented just about any process. Whether agile was the best fit for your project or for your company, that's a very different question, and agile is clearly not the right solution for everything, I've worked in plenty of secretive companies where agile is a problem as information is intentionally withheld from the developers, and this causes a massive mismatch which makes agile painful. If you company sees and understands these limitations, it can still work once you accept the inefficiencies.
Agile is a good concept - I've included the Agile Manifesto in my courses for years. The problem is: Agile is no better than the people implementing it.
I've just witnessed this (again) in a recent project. The PM had just gotten a promotion, but he had to finish this project. He used Agile as an excuse to basically abdicate (or maybe he was always a lousy PM), and he let the developers and the customer talk together directly. The customer thought this meant that all of their ideas were flowing into the project every two weeks. The developers thought the customer was changing requirements every two weeks. The result was inevitable: a project that is 3/4 finished everywhere, totally finished nowhere, and is now likely to land both companies in court.
Crappy management is not saved by Agile. Given good management and a good development team, any methodology can work - pick the one best suited to the project and the people.
Enjoy life! This is not a dress rehearsal.
Agile is like communism: in theory a good idea, but the system quickly goes off the rails if the group or individuals do not behave in a 'good' way. First problem I often see is that analysis and design is skipped and/or not documented. The customer comes up with an idea in a meeting, this is put in a story ticket in a very simple sentence "as a [rolename] I want to do [interaction] to obtain [new feature]". But the details are never written down. Developers will write some unittests, but just enough to test some new functions here and there in different components. Testers and end users will go through a couple of scenarios by hand to test a new feature or bug. Imagine you arrive as a newcomer on such a project. What happens is that you need to be brought "up to speed" by a poweruser who explains what the application does, and for every ticket you take up you have to get extra information from your team members to get some more detailed idea of what a part of the system does and how it was implemented. Second problem I often see in "agile " projects is codebases that are very messy, with questionable design patterns, several half-finished attempts to do a high level restructuring, ownership of code ("I do not now how this part works, ask X"). Last problem I see often: self-organization gone wrong: Teams that have ran into trouble can get very defensive and have bureaucratic "definition of done" procedures ("a pull request needs to be approved by three co-developers", "unit test code coverage of all new code must be at least x% " ) or block any attempt to innovation using office politics. OTOH some teams have cowboy programmers that check in exotic libraries or "refactor" code (= have their own opinion about everything, throw away other peoples code and even think they now better how the business should work )
Put it on the blockchain.
Why does the link go to a blog post that describes a blog post? Just link to the original blog instead of the worthless infoq site that does nothing but regurgitate somebody else's article.
In other news, Lenin regrets that so many countries implemented communism wrong,
and made life worse for everyone instead of better.
Lenin is sad but hopes that these mis-implementations will not reflect poorly of REAL communism.
Agile is not for developers, but for project management/execution. If a company lets the developer decide if they want to be agile or not, something is wrong.
You have to know what you're doing and why. There is no free lunch. Management expects it to come out of development because they can do "computer magic", but it wont happen. Agile Software Development methods try to mitigate the sideeffects, but if nobody plays along agility becomes a trainwreck.
You have to know what you are doing and agility has to be a part of company culture. If it isn't, if will fail, plain and simple.
Positive example:
Sipgate is a company that does it right.
We suffer more in our imagination than in reality. - Seneca
The real worth of XP was in the fact that adhearing to extreme programming strictly, showed where the culture and environment needed changing to allow xp to work. But all that happened was XP got changed to fit in with current state of things.
I have always advocated running far away from any place that claims to practice Agile. It's always been bad.
If you introduce it in an organization which has to deal with complex, poorly written legacy code, it is doomed. You can't estimate anything, every task that is enforced by the agile system to be short and simple still takes ages, the developers run away.
who want to tell all their executives buddies at the next conference about how they use the right buzzwords and have new filler for their CVs but in reality want it to basically be government level bureaucracy
like production deploys used to be something I'd do in about an hour on my own and in going on 10 years, never had a single problem
new VP comes in talking about Agile and that person's judgement is that now deploys should involve 6 other people and take all day
The problem was that the manifesto was common sense and stating plainly how good teams already behaved.
The problem is they and a whole lot of people *thought* that with a plainly spoken set of words, it would be possible to go out and fix the whole industry, which was and still is beset by a whole lot of nonsense in processes and tools.
They were half right, the short document that was easy to understand did resonate with a lot of people and the idea that the way things are being broken resonated with a lot of people, thoughout these organizations.
Two major problems happened. One is that the same traits that drove those teams to create terrible processes and abuse tools are still there, and to some extent doom those teams to always landing in the same place, perhaps changing terminology to comply with the fad (big-A Agile). Call their "status meetings" "Scrum", call their "requirements" "stories", "milestones" becomes "sprints". Change the words and 'poof' they are "Agile".
The other complicating factor is the tools and consultancy business. "Individuals and interactions over processes and tools" is not something that is a profitable stance. So that goes by the wayside and consultants revel in making money reinforcing the above behavior. Consultants know these companies ultimately are spending the money to feel better about the way *they* want to work, and they are happy to oblige. Enough change to be annoying and feel like *something* has changed, but leaving that organization structurally the same, the way management clearly had made it in the first place. On tools, well that is a mess. When asked if my team was "Agile" I replied "yes" (mainly in hopes to deflect the 'transformation initiative") and they asked "Oh, so your team has been paying for Atlassian software then?". Because we didn't happen to be using Atlassian, it was deemed we *must* not be 'Agile' and we had to undergo the bs training and migrate all our stuff to Atlassian tools and in general waste a whole bunch of time. Worse than that, they assigned folks to "help" us be Agile in an ongoing capacity, and demanded we declare 6 months worth of plans for Sprint content and get mad at us when we prioritize responding to a customer request over made-up dates for 'nice to have' backlog items,. When I point out "Responding to change over following a plan" was part of the manifesto, the ostensibly Agile-focused helpers say that's not part of Agile, it wasn't in any of their training, and that they got Agile certification so they should know.
XML is like violence. If it doesn't solve the problem, use more.
Agile is way too much dogma at companies ive seen it practiced at.
Developers will write some unittests, but just enough to test some new functions here and there in different components.
Also will say that teams have a very bad habit of saying "100% coverage" and then saying "we don't need a QA team, auto testing takes care of all of it". To the extent that my team does unit tests, I don't claim that to management for fear that management will can the QA team, which is comprised not of programmers but people from the target industry, that give functional as well as "this was a dumb idea" feedback.
As to the rest, it doesn't really matter if it's called "Agile" or not, it's the same sort of things you would see in software development before Agile came along. It's the hellish behavior that the folks originally wanted to "fix". The reality is that a bad team will be a bad team, and no matter what they are told, they will find a way to create that same horrendous dynamic using the terminology to fit the "project management fad of the day". When someone sees this and tries to fix it with another promising sounding fad, it too will degrade to what you see today.
The original Agile was simply:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Which has always been pretty obvious to anyone.
The problem with the first point is *not* was company leadership wants to be true, they want processes and tools and to be able to toss aside one person for another at will. Also, as a consultant there's more money to be had selling them "Agile tools" than just telling people to work together. So branded-Agile tosses that.
The problem with the second point is that it requires developers intimately understand the user situation and to not be so lazy as to avoid doing the work. In practice "it can be fixed in documentation" remains the "easy way" to cheaply meet schedule.
The third point is simply unrealistic, sadly. Yes from getting a quality product, this is important, but that collaboration taken to the extreme will cause the scope of needed work to grow endlessly. This is of course ok for engagements that are also effectively "limitless", but for project-driven engagements this sadly doesn't work.
Responding to change is the one point everyone would *love* to claim to be a champion of, but managers are accustomed to forecasts, and deviations from plan break forecasts, and as such management really hates this. Of course so do many developers. It's distracting to react to changes in plans and some people just aren't wired that way.
XML is like violence. If it doesn't solve the problem, use more.
Overall a great slashdot discussion, with interesting comments. As a programmer, who since many years work mainly as product owner in a reasonably large project (~100 devs, and some 100 more in related SAFE trains), I think you mention many of the problems I perceive we have. We've adopted SAFE on top of mainly scrum based ideas in an attempt to get teams to cooperate better. Of course there have been/are deadlines that are hard to meet while trying to balance new features versus addressing various "debts" we have since going live with the first customer. I wouldn't say we've derailed, it's still bearable.... and the issues are not mainly due to people being lazy or caring about keeping their jobs. In the end most people try to do their best given what they are told to do and what's measurable. It's more a combination of prioritizing (end user) features with a culture of not documenting requirements or design/architecture, and the impact from how of "agile" has been interpreted. At team level there are unit tests and DoDs, but cross team refinement/design, testing, integration, delivery is a challenge. Of course it would be a challenge with waterfall, RUP, etc too... but by pushing too much onto each "self-organized agile team" the whole setup/development has become inflexible and slow.
An agile development loop
1) Build some sort of minimal, tested functionality.
2) Get feedback to see how it worked out.
3) Choose what the next incremental step in functionality should be.
4) Add the incremental functionality cleaning up any resulting cruft, test, and release.
5) Goto 2 in a short periodic interval.
I see two fundamental problems with this plan
First no two steps take the same time. By forcing a fixed interval either you cause either idle time, not getting done, or herculean effort to pull in the schedule. None of these are a good, sustainable development environment.
Second, complex system design is neither bottom up nor top down, it's both. This program seems focused on bottom up with a peephole looking at only the next step. This is certain to paint one into a corner. Some amount of planning (architecture?) might be useful to both prevent technical do-overs and provide the customer a better idea of how this next release fits into the overall desire. Of course if there are no clues as to where the project is leading, then bottom up with the peephole providing all the feedback it can is the best way to go.
Incremental development is a great old idea, but the agile process needs to be agile in itself. Without somebody wisely choosing the what and how of the next step, it will result in a random walk.
Anyone here have experience with Agile in IT? Not software development I was in a Lean/Agile large corporation and while Agile was implemeted very well in software development, a few years after they've tried apply this in IT. While some element worked well, some other couldn't. I've left this org a few years ago and now I'm living kinda the same thing somewhere else and again, I'm not sure Agile apply that well in IT. For example, deliver something quick instead of the final product. While this make sense to fail fast or deliver in smaller blocks, it often result in supporting 2 services doing very similar thing (file server, print server, proxy, etc.) instead of one, both being incomplete and finishing the new one is often pushed back while starting another quick delivery on another service.
That has always been management question. They seem to think programming is all about coding when in reality coding is a small part of creating a large scale system. Agile is all about coding and that is what is wrong with it.
--
.nosig
I've been Agile exposed in so many different ways I can barely remember what the hell Agile really is supposed to be anymore. The worst thing that can happen to developers is "We're running or own take on Agile", because "our own take" means "negatively effective".
I've got colleagues who have been required to go to 10-14 hours of ceremonies each week because they don't need a scrum master and PMs murder them with meetings where they demand to be heard for hours for no reason other than the PMs have nothing better to do with their time. Hell, I have colleagues in that situation right now where I work.
I know of other teams that (and this continues to be a complete disaster) that have an open door policy on requirements. Work gets tabled all the time because the manager wants the internal customers to feel super special and any new requirement that comes along can out-prioritize something that is 99% complete. Makes the manager appear great (somehow) but the devs look like idiots because they never finish anything. Thankfully everyone I knew in this company has vacated...
My boss had been running a relatively successful Kanban but was forced to move to Agile Scrum recently due to some guy's decision up the ladder. As a team we've made the transition relatively effortlessly in the mind space. I mean, before I'd assign work to my team based on requirements that may not fit into sprints, and it worked very well, since I knew their skills very well. I could time manage the whole thing without a lot of thought and everyone was busting out good work left and right. The only difference now is I have to fit all that into sprints, which makes things harder. I'm not supposed to give out anything that would split an iteration, and therefore I either have to spent a lot of time cleverly breaking up projects so that work can continue, or give out 1-2 day assignments just to take up my developers' time.
As I'm the senior/lead/architect of the project this is definitely the wrong way to do things. All the above reduces MY time to develop from about 36 hours a week to 25-28 because I have to play scrumbag, as well as all the other rolls, and we've been saddled by a tools that doesn't' work so well. But I do a damned good job insulating my team from PMs and other managers (ours is really good at wasting time, too, but at least understands Agile).
This sig isn't original enough, it's time to come up with something witty...
Isn't its methodologies - it's the fundamental premise that it's a solution for everyone and every thing.
If you're building custom solutions for anyone (consumer, SMB, Enterprise) - Agile is likely your friend. Go with Agile.
If you're building a consumer facing web application - Agile is possibly your friend, it depends on how clear a vision you have. If you're not sure - go with Agile.
If you're building a PRODUCT (something you expect to use unchanged - excepting, of course, new additions and features) for the Enterprise - Agile is NOT your friend - but it is most certainly the friend of the integration team who will be deploying your PRODUCT into that enterprise.
Agile is hugely beneficial in the right scenarios - usually a scenario where the people who want something don't know what it is they actually want - they just know they need something fixed.
Agile is hugely detrimental in the wrong scenarios - for example when you have a company that hires 'Agile Product Managers' who are NOT domain experts; ergo, they have no idea what is or is not good for the target market verticals.
The other problem with Agile is that they created (somewhat accidentally) a strawman argument to establish themselves - that if it's not agile it's some kind of horrifying version of 'waterfall.' In other words, a black and white situation that's simply bullshit.
I've run teams where Agile was the only reasonable approach - and it worked well for us. I've run teams where Agile would have been a disaster for us and a waterfall/spiral type of approach worked well for us.
Tools in a toolbox people - just like operating systems, languages, patterns, testing methodologies - et cetera. Right tool, in the right place, at the right time.
Know them all (or as many as you can) - know their strengths and (sometimes more importantly) their weaknesses.
The really interesting time is when you build a startup and as the company matures, so does everything inside of it (technology, operations, organizations, processes, et cetera.) You may spend 90 days head down and very NOT agile, and then at seed round embrace Agile because it's right for you. You may be agile for a year or two until you close an enterprise deal - and then perhaps you re-evaluate using Agile - or modify it.
The point is (that I am very poorly making) - You need to know when Agile, and/or some particular aspect of Agile, is or is not appropriate for you and either embrace it or distance it. Don't fall for marketing hype, or the legions of people who cover their incompetencies (primarily in the world of Product Management) by hiding behind it.
Loading...
It is the most corrupt and abusive work environment I have ever experienced.
Our management is really big on "statements of corporate values" and "principles for moving forward." Translation: buzzwords and BS.
A couple of years ago "agile" one of their buzzwords became one of their buzzwords. Every year we are forced to watch a short video about our values (mainly because our bosses keep having to plead the Fifth Amendment to avoid prosecution). The video includes a short section on what "agile" means to us. That section makes it clear no one involved in the process has the slightest idea what agile methodologies are. They just like how the words sound.
Management has made it clear what agile means to them: Employees have to jump over many hurdles put up by management to accomplish anything for the veterans; employees will have to run around many roadblocks erected by managers to provide the most basic benefits to vets.
"Extreme Programming" suffered because it was a terrible name which conjured up visions of being thrown out of an airplane at 40,000 feet and trying to program a parachute on a laptop on the way down. "Agile Programming" suffers from being too good a name not to be co-opted by by every management drone who ever mouthed a buzzword.
At Veterans Affairs "agile" is nothing but a way to justify more abuse of the employees and use that abuse to cover management's corruption and incompetence.
Agile is perfect for those who cannot decide and won't commit. They can push decisions to the next iteration, call it agile and iterative, and never have to decide anything...and never get anything done. Other bad aspect of Agile is that many misread the manifesto and determined that it means "no documentation". I work in a supposedly agile dev team and I haven't seen a written requirement or any acceptance criteria in years. Devs just start building a ton of disjointed stuff that they have to rework later with great effort. It is baffling that we are still successful with this utter chaos.
I will tell you about my company's dalliance with Agile:
Just shy of 2 years ago we went fully Agile with our (circa) 50 developers.
Our software improved significantly in that time with release after release having less bugs (I work in App support) Our Dev teams were much happier, we had barely any people leave (IIRC it was less than 5%)
The stakeholders were happier, as they were seeing less bugs (and more existing bugs squashed)
The Support team was happier as less bugs were creeping in and our platform was much more stable.
About a 9 months in and our first scrum master got fired - he stood up to management and pushed back whenever they tried to pressure the dev teams into taking on more work.
12 months in and the second scrum master leaves through frustration and management's "constant meddling"
(e.g. Dev showcase to product owner and senior manager.. At the showcase this manager tells the team to rework their code as the had "used the wrong names for the database columns, at another meeting he forced the dev teams to hard code some functionality to "get it delivered" on time - costing us much more work later on to remove it)
After the last scrum master left it was announced that we were no longer doing Agile and going back to something akin to what we had before.
Nowadays management promise the "moon on a stick" to customer in obviously unrealistic timescales that our dev teams now regularly fail to meet. Our code is far poorer than it was, many more show-stopping bugs, we have lost many of our "old guard" devs and the dev teams are now full of contractors who stay for 6 months and then leave for more Agile working environments.
For my company Agile worked really well for everyone except management who felt they had lost control over the development teams.
For his current thinking: https://www.youtube.com/watch?...
After outlining the history of the creation of the Agile Manifesto, Dave Thomas outlines some basic problems with the Agile industry (including selling fear and also pushing complex IT systems to organize work that they can charge lots of money for). He says "the values have been totally lost behind the implementation". He says we need to distinguish between the implementation (Agile/Scrum/Lean/Kanban/etc) and the specification (Agility). He says "No rules are universal (except for this one)" and that "all rules are contextual". He espouses holding close to the value of "Agility" involving figuring out where you are, taking a small step towards your goal, re-evaluating and adjusting your understanding based on what you learned, and then iterating. He suggests choosing between alternatives delivering similar short-term value based on which keeps more options open to make future change easier -- outlining Dave's Rule of Design: "A good design is easier to change than a bad design." He calls for courage at the individual, team, and company levels to know you are going to make mistakes in order to find out what needs to be done -- and to work hard to make sure those mistakes small and correctable.
A shorter summary text version:
"Agile Is Dead (Long Live Agility)"
https://web.archive.org/web/20...
"The word "agile" has been subverted to the point where it is effectively meaningless, and what passes for an agile community seems to be largely an arena for consultants and vendors to hawk services and products. So I think it is time to retire the word "Agile."
I've collected more related ideas on this High Performance Organizations Reading List:
https://github.com/pdfernhout/...
A 21st century issue: the irony of technologies of abundance in the hands of those still thinking in terms of scarcity.
Software engineering is littered with failed magic bullets. Fact is, devising good algorithms and implementing them correctly is beyond most programmers.
my limited set of empirical data strongly suggests
Has there ever been a more insightful and simultaneously less self-aware sentence uttered in all of history?
That's the story of your entire goddamn life. Profoundly ignorant and still absolutely sure of your conclusions.
Confidence is not competence pastor peen.
Agile is a buzzword for foolish managers to believe will save their companies. But in reality the definition for Agile should be "just do it and we'll make it up as we go". Great planning it isn't. Great management is never there. Simply put. It's a rodeo for the cowboy programmer.
Customers are tired of being beta testers for your broken code
Agile software development is rarely practiced correctly. In my experience it's another buzzword for companies to put on their marketing materials:
IMO Agile is the excuse our company uses for not having proper documentation, development and (especially) testing practices. It seems to be the same with every other company I've heard "practicing Agile."
of committing lots of resources to it and wasting a bunch of time.
At least that is what seems to be popular nowadays.
Agile is all about small steps and short term goals.
What can you do in 1 day or 1 week:
You cannot write a Compiler in 1 week.
You cannot write a Database System in 1 week,
You cannot write a Game in 1 week.
In fact there is practically NOTHING that you CAN write in 1 week that will make a profit for the company that is paying you to attend all of these Agile Scrum meetings.
The only thing you can do in 1 week is small enhancements for existing products.
What happens when some other [smarter] company spends the year or more needed to write the next social media site or killer app.
Answer: YOUR company goes out of business.
Blame it all on Agile and short term thinking.
Maybe small projects can be managed with AGILE, but anything with more than 10 developers, the wheels come off real quick. And its based on management wanting to slave drive the developers into a time box that in most cases is impossible or unreasonable. Next the process is always bastardized into some other form that is usually reflective of an out of control scrum-master, also playing (poorly) architect. Not one single project I have worked with AGILE has been a success, it is usually abandoned and waterfall takes over.
I see you have no experiences with scrum on you resume. Why is that? Well my previous employers had no use for eleborate systems like that and it didn't exist before I got there. Writes down: *Knows no modern development techniques. Thanks for your time. Don't call us, we'll call you.
Nietzsche says that if they do, agile should abandon them.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
I've always referred to the poor implementation of agile as "lightweight agile." Typically, I see teams start the agile process with good intentions, yet just implement a hackie scrum implementation. This inevitable leads to the "get shit done" method of software development. Managers, chickens, chiming in with ad-hoc requests or screaming faster. Plus, lightweight agile, lead to people getting away w/ not doing work - typically poor performers. If you're not metric driving with your agile implementation your not doing real agile.
Agile in the hands of managers is a disaster, and its managers who obsess over it the most. Agile is belng used by managers to focus on the box. Everything has become about the box. Meeting Sprints with mediocre code > slipping to produce quality code. Don't track down the bug if it will mean you miss a sprint, try to work around it instead. Success is measured by hitting these points. Even if the task hasn't been done before.Estimate how long it willl take and be accurate wi4th your estimates! Yeah, Agile has been co-opted by managers and TPMs. At this point, everything regresses to this paradigm. It's the corporate way, and the beancounters ultimatey control everything. No matter what the supposed intent is.
And so we serve the process first and foremost.
sorry for the typos, i had to complete that post before standup this morning
Asking people to estimate how long a task will take, when that task has never been done before (at least in the org), is concentrating on the box rather than the task, and it leads to sub-optimal outcomes. IMHO.
Agile doesn't work because most management teams embrace it as the latest management buzz word. Not only do they not understand it, they make no effort to do so. In fact, they drive their people to embrace Agile, and then they continue to demand status quo in management processes, organization structure, and reporting mechanisms. And when the do commit to Agile they often demand it be "modified" to support various sacred cows, dooming it to failure.
In my experience, no sizeable legacy enterprise has successfully implemented Agile, and that is a shame.
Partly true. That's the fourth agile pillar of responsiveness is more important than strict adherence.
I try an analogy of travel plans for a large group event. Building a big travel plan for everybody to get to the party won't work: people are coming from all places, some from home, some from work, some from distant cities. Instead, clearly communicate the destination and let each traveler be responsible for getting there.
Agile software DOES need planning. Everybody needs to understand what the destination is going to be. However, the plan needs to be flexible, responding to changes versus following the plan.
When you're driving and you encounter construction you don't follow your GPS's directions to drive through the construction barrier or off the cliff. You reroute because you value responding to change over following the plan and you understand that sometimes you need to deviate from the plan. But that doesn't mean you ignore your final destination. You may not follow your planned route but your destination remains the same.
Going through the manifesto... (1) We want everyone to be at the destination, and we care more about the fact that the people are treated as people than that they be there; if someone needs accommodations we make the accommodations because people are more important than process. (2) We want to make sure we have the destination. If the event were a big party it would suck if everyone got there and we discovered a a bunch of todo items like "rent the venue" and "hire the caterers". The plans are nice, but we need to actually make progress toward the destination rather than just making progress towards plans. (3) Helping people get to the destination is more important than details of how they get there. If individuals have different needs in order to get to the event, try to accommodate those needs. (4) We should help people reach the destination following whatever route works for them. If they need to change their route to reach the destination we should help them.
All of this is predicated on having a clear destination that everyone understands. When I've seen Agile fail that's been the biggest failing, there was no shared understanding of what was expected. When I've seen Agile succeed it was when everyone (or at least the key people) had a clear shared vision of the destination.
//TODO: Think of witty sig statement
Every "agile" house I've ever worked in has been complete chaos. The process is never implemented fully, the pieces of agile that are the most important are never there, and all it ever ends up doing it leading to more open panel free form meetings that run for hours, which means less development time on any given project. It's a joke. Needs to go.
This signature has Super Cow Powers
I think the problem with Agile, is that there's a language barrier with it.
People just don't speak it. So, I've taken the liberty of translating the Agile core principles into plain english so that common developer folk can understand what's being said when people talk about this stuff. I think using these principles, we'll all find ourselves being more productive, and building cogent end to end solutions and rich synergies in the enterprise.
1. Tell the customer what they want to hear.
2. Be disorganized and chaotic.
3. Pretend you’re working.
4. All tasks will either be written by or for idiots.
5. Let the loudest most incompetent people run the show.
6. Determine how many meetings your developers are capable of sitting through without losing their sanity. Require them to sit through twice that number of meetings.
7. Make sure the software works well enough for superficial demos at the end of the sprint is the primary objective.
8. Tell everyone about how hard you’re working.
9. Feign a commitment to excellence.
10. Maximize the amount of things that never get done — super important.
11. Have you ever seen Lord of the Flies? Yeah, like that, only in business casual.
12. Have meetings where you discuss your feelings.
This signature has Super Cow Powers
You don't build fighter jet systems or railway control systems in Agile.
Software quality is not a crime.
Kriston
Agile, Spiral, Waterfall, blah, blah, blah, blah. Whatever. Yaaaaaaaawn.
Here we all are with the same unsolved problems (since the 1970s):
1. Businesses can't express requirements, and engineers can't elicit them.
2. No-one knows how to formally validate or verify.
Mind you, that mess generates enough dollars to go around for everybody so why try harder?