Programmers, Managers, Agile, and Failures: Software's Long Crisis (logicmag.io) 152
A UCLA assistant professor of Information Studies just published a short history of software engineering in Logic magazine — titled "Agile and the Long Crisis of Software."
It begins by describing Agile's history as "a long-running wrestling match between what managers want software development to be and what it really is, as practiced by the workers who write the code." When software engineering failed to discipline the unwieldiness of development, businesses turned to Agile, which married the autonomy that developers demanded with a single-minded focus on an organization's goals. That autonomy is limited, however, as developers are increasingly pointing out. When applied in a corporate context, the methods and values that Agile esteems are invariably oriented to the imperatives of the corporation. No matter how flexible the workplace or how casual the meetings, the bottom line has to be the organization's profits.
But this has major implications, the essay's conclusion argues: Could Agile even have played a role in some of the more infamous failures of the tech industry...? If a company sets a goal of boosting user engagement, Agile is designed to get developers working single-mindedly toward that goal — not arguing with managers about whether, for example, it's a good idea to show people content that inflames their prejudices. Such ethical arguments are incompatible with Agile's avowed dedication to keeping developers working feverishly on the project, whatever it might be.
This issue becomes especially pressing when one considers that contemporary software is likely to involve things like machine learning, large datasets, or artificial intelligence — technologies that have shown themselves to be potentially destructive, particularly for minoritized people. The digital theorist Ian Bogost argues that this move-fast-and-break-things approach is precisely why software developers should stop calling themselves "engineers": engineering, he points out, is a set of disciplines with codes of ethics and recognized commitments to civil society. Agile promises no such loyalty, except to the product under construction.
Agile is good at compartmentalizing features, neatly packaging them into sprints and deliverables. Really, that's a tendency of software engineering at large — modularity, or "information hiding," is a critical way for humans to manage systems that are too complex for any one person to grasp. But by turning features into "user stories" on a whiteboard, Agile has the potential to create what [software engineer] Yvonne Lam calls a "chain of deniability": an assembly line in which no one, at any point, takes full responsibility for what the team has created.
Other observations from the article:
It begins by describing Agile's history as "a long-running wrestling match between what managers want software development to be and what it really is, as practiced by the workers who write the code." When software engineering failed to discipline the unwieldiness of development, businesses turned to Agile, which married the autonomy that developers demanded with a single-minded focus on an organization's goals. That autonomy is limited, however, as developers are increasingly pointing out. When applied in a corporate context, the methods and values that Agile esteems are invariably oriented to the imperatives of the corporation. No matter how flexible the workplace or how casual the meetings, the bottom line has to be the organization's profits.
But this has major implications, the essay's conclusion argues: Could Agile even have played a role in some of the more infamous failures of the tech industry...? If a company sets a goal of boosting user engagement, Agile is designed to get developers working single-mindedly toward that goal — not arguing with managers about whether, for example, it's a good idea to show people content that inflames their prejudices. Such ethical arguments are incompatible with Agile's avowed dedication to keeping developers working feverishly on the project, whatever it might be.
This issue becomes especially pressing when one considers that contemporary software is likely to involve things like machine learning, large datasets, or artificial intelligence — technologies that have shown themselves to be potentially destructive, particularly for minoritized people. The digital theorist Ian Bogost argues that this move-fast-and-break-things approach is precisely why software developers should stop calling themselves "engineers": engineering, he points out, is a set of disciplines with codes of ethics and recognized commitments to civil society. Agile promises no such loyalty, except to the product under construction.
Agile is good at compartmentalizing features, neatly packaging them into sprints and deliverables. Really, that's a tendency of software engineering at large — modularity, or "information hiding," is a critical way for humans to manage systems that are too complex for any one person to grasp. But by turning features into "user stories" on a whiteboard, Agile has the potential to create what [software engineer] Yvonne Lam calls a "chain of deniability": an assembly line in which no one, at any point, takes full responsibility for what the team has created.
Other observations from the article:
- "Daily standups, billed as lightweight, low key check-ins, have become, for some workers, exercises in surveillance. "
- "The warts-and-all breakdown of Agile 'retrospectives' seems healthy, but I've watched them descend into a structureless series of accusations; everything depends on who's leading the team."
- One freelance developer in the article even argues that "As developers, IT professionals, we like to think of ourselves as knowledge workers, whose work can't be rationalized or commodified. But I think Agile tries to accomplish the exact opposite approach."
- "Some people I talked to pointed out that Agile has the potential to foster solidarity among workers. If teams truly self-organize, share concerns, and speak openly, perhaps Agile could actually lend itself to worker organization.
"Maybe management, through Agile, is producing its own gravediggers. Maybe the next crisis of software development will come from the workers themselves."
Agile is just a tool (Score:5, Interesting)
When building a building you look at the problem at hand and select the tool for the job, e.g. a hammer when you see a nail. But the best hammer is also quite useless if a person holds it by the head and attempts to drive a nail in using the handle.
We use agile to great effect where I work, in our department. Other departments don't. Maybe rather than blaming the various tools and methodologies we should instead focus on the fact that the world is full of shitty managers.
Re: (Score:2)
I have seen how a person says in the daily that he has not finished his task (a task that should take a week at most). This repeated for several years, before the person was finally laid of due to other reasons. The task was given to another person who finished it in a week.
I think this is the best part of agile. Everyone in the team knows that someone is not doing their job for one reason or another. This creates an opportunity to help the person or get rid of them.
I have also seem the negative effects ha
Re:Agile is just a tool (Score:4, Interesting)
Really? You said this trend repeated for several YEARS and you think that's a good example of agile working?
It is possible that the coworker was incompetent or lazy but it's just as possible that he was completely swamped with other stuff and the next dude who received the task either wasn't or was so scared of being laid off that he got to it just out of fear, possibly to the detriment of other, more important tasks.
Re: (Score:2)
it's just as possible that he was completely swamped with other stuff
If that was true, he should have said so during the daily. That is the whole point of the daily: To say what you completed, what you didn't complete, and what obstacles are holding you up.
Re: (Score:2)
...we've complained about being swamped in every goddamn meeting for a year and a half with nothing changing. I think you underestimate agile's ability to make managers sane and competent.
Re: (Score:2)
*overestimate.
Re: (Score:2)
It sounds like you're expecting Agile to fix an organisational issue.
Re: (Score:3)
That's what management thinks it do.
That's its purpose. (Score:5, Insightful)
Agile IS an organizational management tool. [wikipedia.org]
It is not a coding tool nor a software development tool - it is a team management tool.
As such, it CAN be used to manage both a handful of coders and a large company. With varying levels of success.
Primarily cause it is also heavy on marketing bullshit lingo, hiding issues behind jargon and semantics.
Thus it is a hammer looking for a nail, seeing only a nail, and trying to hammer in that nail - even if it is a light bulb, a pipe, a screw or a nail that needs to be pulled out.
Which is how you get a problem solvable in a week lingering around for months and years.
And the person describing that situation sitting in the middle of that dumpster fire going "This is fine. I love agile."
In fact, if you step away from it and look at it with a critical eye, the whole thing starts to look remarkably like a cult.
From, "well, you're not using it correctly" faith-based argument when it fails, through heavy jargon use and performative actions, creation of an internal non merit-based caste of "masters", stubbornness and proselytisation where another methodology would work better - to the surveillance and blame-shifting issues described in TFS.
Among other issues.
Sure... it might work where you actually do need only a hammer. A church will provide a shelter.
But often it is something like a finely engineered, designed and constructed to specific standards and specs is needed - like a cordless drill.
And where a healthcare system and a network of hospitals built on top of an underlying structure of logistic and science is needed - a church is beyond useless.
Re: (Score:2)
> Really? You said this trend repeated for several YEARS and you think that's a good example of agile working?
If you take 10 people with no skills and make them do something. You will fail no matter what you try.
If you take 10 skilled people, you will most likely succeed, no matter what you try.
Agile makes no difference in this, but I think agile greatly speeds things up when specifications are unclear and customer does not know what they want.
What Scrum and daily meetings provide is knowledge of what ki
Re: (Score:2)
You missed my point. If it takes a whole year to notice you've got a bad apple in the bunch despite seeing how his tasks don't progress several times a month or even week, you're so bad at management, no process strategy in existence will safe your ass.
Re: (Score:2)
It did not take a year. Management never took action because of that. He was laid off due to other reasons, not because the management was actually doing something useful. And I agree with you. Bad managers can not be fixed with agile.
But you also missed my point. For good managers, it is great tool.
Re:Agile is just a tool (Score:5, Insightful)
That may well be but us techies main gripe for decades has been that there's like one good manager in a thousand.
Agile is a tool. In the hands of someone competent, a tool enables great things. In the hands of a sociopathic nincompoop, a tool becomes a weapon of destruction.
Therefore, to most of us, agile is VERY dangerous. To the few of us who have good managers, it is a godsend.
Re: (Score:3)
"agile greatly speeds things up when specifications are unclear and customer does not know what they want"
Precisely. Agile produces crap fast under these conditions and bloodies up the water so that those issues become much harder to resolve.
Re: (Score:2)
> Precisely. Agile produces crap fast under these conditions
I agree with. And that is a good thing. You have more time to fix it. Imagine if you are doing some government project and you notice that there is a bug in the law. If you figure that out years before production, you might be able to fix the law, but if you build your product and notice it just before production, you can only try to think some sort of work-a-round.
Re: (Score:3)
Agile produces crap fast
And there's the problem. What if I don't want 'crap'?
Re: (Score:2)
And no software management will change that. All you can do is have the time of the weeding out starting more early and with less sunk cost.
Re:Agile is just a tool (Score:4, Insightful)
Then you are not fit for this world
Thanks for the late-breaking news from the "No Shit, Sherlock" department.
All I'm saying is that 1) Agile doesn't fix everything, 2) you're lucky if it fixes anything, and 3) most of the time spent 'being agile' is wasted on bullshit ceremonies and circle-jerk sessions.
Re: (Score:3)
"agile greatly speeds things up when specifications are unclear and customer does not know what they want"
Precisely. Agile produces crap fast under these conditions and bloodies up the water so that those issues become much harder to resolve.
Indeed. As if we did not already have enough hard to solve problems in the IT sphere...
Re: (Score:3)
If specifications are unclear it doesn't matter whatever method you use because you can never satisfy the customer.
Re: (Score:3, Insightful)
On one hand, that is true. On the other hand, it sounds like a daily kangaroo court, where someone points to a cow-worker, whines, "he is blocking me!", the target responds, and now you have a nice pissing contest. Standup meetings are nice for the Scrum master because they can play employees off each other and ensure they don't cooperate with each other, and always have that dagger ready for a bared back. Great for that, shitty for workers.
Agile/Scrum makes shitty products, and assumes devs are fungible
Re: (Score:2)
What I see a lot is terrible Scrum masters. It's either because they lack sufficient technical background to understand that something is wrong or because they are terrible at managing and fail to act. Acting by they way can be to discuss the issue with the whole team to discover what the problem really is. It doesn't have to be laziness of incompetence.
I don't know if in your example this was Scrum with a Scrum master, but it seems that that person wasn't the only at fault here.
I am starting to mistrust an
Re: (Score:2)
Scrum master is a no-win job. If the master has no political clout within the organization, then s/he won't be able to push the development forward. If the master does have political clout, the s/he's seen as tool of management and hence what should be technical decisions become perceived as political decisions and engineers treat those decisions with disdain and contempt.
Re: (Score:2)
Scrum master is a no-win job. If the master has no political clout within the organization, then s/he won't be able to push the development forward. If the master does have political clout, the s/he's seen as tool of management and hence what should be technical decisions become perceived as political decisions and engineers treat those decisions with disdain and contempt.
There is a dimension to the scrum master that you are overlooking. In addition to political clout, the person can have more or less respect within the group being managed. With sufficient respect, he or she will not be seen as a tool of management, no matter how much political clout he or she has.
A good manager faces in two directions: upward to represent his or her group to upper management, and downward to keep his or her group working productively. Sometimes this job is divided between two people, wit
Re: Agile is just a tool (Score:2)
Re: (Score:2)
Agile works for some products but not for others. Developing a software app with a medium sized team all co-located and under the direction of a single corporate management structure can implement agile well. When developing a large scale aerospace or military system with different corporations competing against each other for future work, itching to blame each other for delays, dispersed across the country, all getting money from different pots, having different objectives and schedules and all relying on
Re: (Score:3)
My experience of Agile is similar - everything was just tasks but nowhere was a goal to aim for. It often ended up as "Not my problem" when asking for help from someone I knew had the skill.
No synchronization between different parts of the project either so deliveries could end up as a shitstorm and people had to put in great effort to figure out why things didn't work together because the "tasks" weren't in sync.
Re:Agile is just a tool (Score:5)
Accepting that the world is a complex and difficult place precludes the notion of having fast and easy solutions you dont have to think about.
The more abstracted from the floor you become, the more desirable McSolutions become, because you stop interacting with the real world and its need for complexity in action, and you instead have more and more artificial requirements. (like "LINE GO UP!")
The shit managers are a symptom of this. The misuse of management tools for certain well defined slices of the complex world, is merely an artifact of this. It is "Well it worked THERE, it should work here too! (if I ignore that the two things are not at all interchangeable!)"
You see similar issues with inability to grasp the concept of pareto-optimality, when it butts heads with religiously operated (instead of intelligently operated) 5S or Continuous Improvement plans. (An intelligently run operation will correctly assess, and find that pareto-optimality has in fact been met, and that no further improvement without introducing a deficit can be made. Religiously operated instances, simply INSIST that MORE IMPROVEMENT, and MORE COST SAVINGS is ALWAYS POSSIBLE.)
The "LINE GO UP!" crowd has a very difficult time with reality. That is ultimately the bottom rung of this problem.
Re: (Score:2, Interesting)
I've been pondering for a bit that maybe the modern corporate structure incentivizes shit managers (the bureaucracy is expanding to meet the needs of the expanding bureaucracy).
This part really stood out to me
which pretty much defines the corporate structure. As above, so below.
Re:Agile is just a tool (Score:5)
I think the problem is deeper, at least for high tech products. They are by nature using hard to understand concepts for the bog standard CEO and middle management. The people that get beyond the first line technical group managers are good at answering fellow managers questions in a language they can understand. If you are good technically, you tend to use technical arguments to buttress your arguments. That leaves the upper level managers scratching their heads. The managers that are not so technically adept tend to use management-speak to buttress their arguments. Hence fellow managers feel like they are one of them. The consequence over the hierarchy is that good technical people get weeded out of the management ranks early on and the result is a collection of managers that doesn't understand the issues. They black box what they do not understand so that the black boxes have inputs and outputs that they can understand. It is but a short journey from there to making stupid demands to serve the inputs and outputs.
I once did a report that included a line of FFs for PUF (Physically Unclonable Functions used in generating random numbers in hardware) implementation assessing its strengths and weaknesses. The first manager that saw it wanted to know we could patent the line of FFs. With that kind of stupidity, there is no educating the management. Technology left them long ago and they are not going go to back and get a real education to fix their deficit.
Re: (Score:2)
Yes, pretty much. Add to that that developers on average are not great and you can make progress all year, but never actually get closer to the target. Or deliver something that would better not have been created. Coding is not the same as playing with Lego. But apparently a lot of "managers" and quite a few "coders" do not realize that.
Re: (Score:2)
In "my" eyes Agile is _only_ there because managment did _not_ use or give a architect the time to oversee the whole project with all (most likely) problems. It is used to do a sort of JIT (Just In Time) for the software part of a product and that does sucks.
Agile "can" be a tool for change(s) in a standard software packages on request of a client.
Re: (Score:3)
Re:Agile is just a tool (Score:5, Insightful)
The issue is that a lot of people seem to think that Agile is a substitute for employing an architect. Surely if we just get a plumber, an electrician, a bricklayer, a plasterer and a window fitter we can build a house. We will ask the future home own what they want as we go along, because they surely know what they want and how the whole thing should be put together.
Re:Agile is just a tool (Score:5)
That's an excellent (and accurate) description of how Agile works in far too many instances.
"We'll fix it during the next sprint" instead of "We'll make sure it works the first time".
Re: (Score:2)
I've seen more than one project get doomed in the first few weeks because the Agile method focused on implementing stuff rather than thinking about what the end result would look like. Architectural decisions were made that would have been extremely expensive (in terms of time) to fix later.
Re: (Score:3)
Agile actively forces teams to churn out barely-working shit, which they can proudly refer to as the "MVP", as if that's something to be proud of.
You delivered steaming pile of crap that does nothing, but look, it has a Login button! Good job, team!
Don't worry, during the retro we'll waste shitloads of time discussing in detail why we suck and why it's not our fault.
Re: (Score:2)
"We'll fix it during the next sprint" instead of "We'll make sure it works the first time".
That sounds like the sprint's scope was not clearly defined. If you're forever fixing something then maybe you should consider firing the person who decides what the minimum *viable* product looks like.
But part of it isn't bad. If you define the MVP as something that works and ensure your sprints add features in a way that functionality isn't broken there really are a shitton of bugs which are only minor inconveniences at best and users are far better of having access to the buggy software rather than waiti
Re: (Score:2)
You can also make the architects work "agile" as well and thereby sabotage their work. A main reason why I quite my last job. More than a year later, they are still desperate to hire a replacement for me, but I guess those that qualify are not interested to work under such broken conditions. I would not have been interested either. Agile was announced 3 months after I started there.
Re: (Score:3)
I am sure you have me ignored/blocked now, but I want to say that it is a real pleasure hearing you talk about technical subjects. Just please stop talking about social subjects. I can see where you are blind and it is frustrating seeing you talk about social issues. You are very smart, so this is an awkward situation.
Re: (Score:3)
I don't block anyone on here. In fact I boost the scores of a few people i disagree with but find insightful or interesting, via the friend system.
Re: (Score:2)
Re: (Score:2)
Pretty much, yes. Agile is either not needed or it does not help.
Re:Agile is just a tool (Score:5, Insightful)
If only it were "just a tool".
The problem with agile is that it's a cult. It has "ceremonies". It has its own private jargon. Curiously, the jargon seems to have been imported from, literally, another field – the sports field. Its 'sprints' and 'scrums' and 'team room' are only a communal shower short of a Gillette commercial – which seems to me the kind of thing that would warrant an explanation. I searched for one for some time, but it wasn’t until I discovered another artefact of the burgeoning arcana, CRC Cards, that it all fell into place. I’m still not exactly sure what they are, but they allegedly bridge the worlds of role-playing games and object-oriented design – which apparently is something somebody actually sought to do. And there finally is the explanation – it’s all cosplay jock-talk to bolster nerd esteem. The 'team room' is in reality a safe space where D&D geeks can gather in communion – and quite possibly in costume – to share their fantasies of athleticism by appropriating its vocabulary, if not its shared bathing. And, anticipating the question from the pale young man at the back in his Age 14+ Superman T-shirt, yes, I am saying that like it’s a bad thing: it’s infantilism masquerading as a business practice.
That's not to say that incrementalism doesn't have its place in software development or that overweaning ambition is not the perpetual bugbear of software development. But any engineering methodology that deliberately puts "build" ahead of "design" has a lot to prove and that's where virile confidence starts to become rather defensive. The story seems to be that you can't compare Agile with other methodologies because they value different outcomes, principally time to market and that Agile produces more reliable code. Well, you ought to be able to get to market quicker if you're merely aiming for the MVP and I simply don't believe the reliability story: I started writing software when bugs meant waiting for crash dumps to arrive on tape and paper-and-pencil analysis and, believe me, the avoidance of bugs was a priority as a consequence.
And if you look at how Agile is actually implemented in many organisations, it's simply a figleaf covering a sweatshop production line: you take the ticket/card, work through it and then take the next one and repeat ad infinitum. It's more only productive because it ties you to your desk, like the free food and coffee. In my many decades of writing software I have found programmers most productive when they already know what code they're going to write and most creative when planning the code that will be required. Systematised drudgery and unpremeditated coding are not in the interests of the "workers". Nor, indeed, of the managers.
Re: (Score:2)
Spot-on.
Mod parent up.
Re: (Score:2)
The problem with agile is that it's a cult. It has "ceremonies". It has its own private jargon.
You sound like an anti-dentite. 'Next you'll be saying they have their own schools...
Re: (Score:2)
Maybe rather than blaming the various tools and methodologies we should instead focus on the fact that the world is full of shitty managers.
Indeed. But agile allows crappy managers to keep up the illusion that they are actually reasonable managers a little bit longer. It is a bit like the cycle with new programming languages: With every new language, tons of developers hype it and jump on it in the desperate (futile) hope that this is finally the one great language that will make their code not suck. That, of course, never pans out but the same people do it again and again. Agile is just one more tool on the management side, that has tons of ma
What management really hears when it hears "agile" (Score:5, Interesting)
"Wait, we can kick out a level of management and the workers have to organize themselves for free? Great, let's do that!"
Re:What management really hears when it hears "agi (Score:5, Insightful)
Regardless of the degree to which Agile is used, software development shops always face some unfortunate incentives. Like, most of the time, fixing a released bug costs money but does not boost sales. So, the business maximizes profits by leaving those bugs in the product. It isn't always true of course, SOME bugs need to be fixed right away, and SOME bugs become more problematic later on in the product's life when other bugs accumulate. But even so, neither of these facts presents enough incentive for businesses to be very diligent about fixing bugs, because they make more money if they can skip out on fixing them.
The same applies to the incentive to rush features out. We all know that rushing reduces quality. But if businesses don't rush the features out, then competing businesses get to market sooner, and snap up those lucrative long-term contracts that wind up locking your business out. So, EVEN THOUGH rushing creates bugs and feature gaps and so on, it still makes business sense to rush out weak products (while, of course, having the sales team go on and on about all the great quality control practices in place).
And similar incentives plague the maintenance of internally-created development tools. On the one hand, there IS a long-term cost savings if businesses let their development teams spend bandwidth on creating their own tools that automate parts of the development process. But very often the short-term gains of getting to market sooner are actually more valuable to the business than those long term savings, and so the business has a reason to give developers little-to-no opportunity to develop and maintain such tools. This is demoralizing of course, which could cause talent to leave, so its another balancing act that businesses must perform, with incentives to make their own people unhappy in the name of profits. Sometimes developers just make these tools on their own time, which of course the business absolutely loves and celebrates since they get all the benefits with none of the costs, though it is a dangerous trend that winds up creating a culture of self-exploitation among the developers, and they burn themselves out. THIS is, I think, one of the main reason that developers are still in such high demand, supply is low due to the widespread burn-out from problems like this.
FOSS projects don't have these problems, or at least they don't really need to have these problems, but they DO have different problems to compensate.
So anyway, software development is hard. And expensive.
OMG, here we go again. It's called 'agility' ... (Score:3)
... not 'Agile'. The thing with "Agile" in it is called "agile software development":
And, no, the method with which you develop software has absolutely zilch to do with the ethics or morality of your work. I can use a knife to cut bread or stab someone. No shit sherlock.
Likewise, if you don't know what you're developing and for what purpose and do not want to figure it out, no amount of agility or rigidity will fix that. Especially if you don't listen to your developers who might have a thing or two to say where you're headed (or not headed) if you obviously have no clue.
And yes, if I'm doing Agile Software Development and I'm surrounded by deciders who have no effing idea what they're doing and couldn't care less - I leave. One could call that 'ethical' I would call it 'protecting my sanity'.
The biggest problem with all these discussions on agile software development is that the moment they start, basic common sense seems to go out of the window for 90%+ of people in that discussion. It's tiring to say the least.
Here are two of the original signers of the "Agile Software Development Manifesto" to fix your thinking and (re)introduce some basic common sense into the "agility" discussion:
Dave Thomas – “Agile” is Dead [youtube.com]
Allan Holub – The death of “Agile” [youtube.com]
You're welcome.
Re: (Score:2)
Yes, I have made that "protecting my sanity" experience as well. Of course they tried to make enterprise security architecture work "agile", which is probably not even possible in the first place. Every few months I see another job ad for my former job and it brings a big smile to my face. Has been about 1.5 years since I quit. Of course, had I know they planned to move _everything_ to "agile" before I started, I would not even have started there. Others with the qualification seem to think pretty much the
I prefer the TTTL strategy (Score:2)
Re: (Score:2)
The world is very, very good at talking. Listening? Not so much.
I find it interesting... (Score:5, Interesting)
...that even in software development people are unhappy with how agile is implemented.
I am quitting my current job as a private cloud engineer for a cloud provider because they thought it was a good idea to make us work "agile". Sure we are only plannable for 40-60% of our workweek but the problem is that when you;re not plannable 100%, planning even 40% is quite hard when daily business interrupts just about any plan you have.
Granted, agile being implemented wrongly is just a symptom of incompetent management, which is a problem that permeates our whole work.
The way they implemented agile in our business led to three burnouts in a team of about 8 and 2 people quitting and two more to come.
And I stand there watching the train wreck happening and nobody in management doing anything about it. It's just puzzling beyond belief.
Re: (Score:3)
...that even in software development people are unhappy with how agile is implemented.
That's because most of the time agile methodologies are implemented in a way which is agile only in name but not in reality, especially in large corporations.
IMHO this presentation [youtube.com] in the first 15 minutes explains the underlying problem quite well.
I worked only once in a setting which can be called truly agile not only in name but also in reality and was great, but the CEO himself was totally onboard with the concept, was technically knowledgeable and willing to structure everything in the company, from the
I think the problem is somewhere else (Score:5, Insightful)
The problem is that any advance in the way we make programmers more efficient is swallowed up by software designs adding more and more needless complexity. This kinda is the opposite of progress. Progress in computing so far has been the simplification of things.
For example UNIX made lots of things into files, so writing something to a file or an interface or another program is essentially the same thing. There is no special "printf" that only works on pipes, files or serial interfaces. This allows for highly flexible systems.
Another example is the Internet. Unlike previous data networks, the network only handles forwarding packets to a destination, routers don't need to know about connections. The result was that the resulting network was cheap and highly flexible. Compare IP with standards like X.25 and you'll see why that's a good idea.
Yet another example is "von Neumann" computing. You store your program in the same type of memory as your data so you can treat programs as data. This allows you to have compilers and loaders, effectively setting the stage for general purpose operating systems.
The list goes on, and always it has been a neat little trick that greatly reduces complexity. Now if complexity appears to be "free" as software developers are much more efficient, you'll loose the pressure to keep it simple. The result often is needlessly complex applications which become brittle and unmaintainable.
Re: (Score:2, Insightful)
The UNIX way was designed for maximum operability. However, companies tend to design code for maximum profits. This is why you have such complex beasts that are huge Jenga piles, where if one thing breaks, the entire thing collapses, and security is a joke (and a bad one at that.)
Code in general is designed to get deliverables in as soon as possible, doesn't matter if the code is copy/pasted from what first pops up on Google, doesn't matter what libraries are included, as the devs won't be held responsibl
Re: (Score:2)
Yet another example is "von Neumann" computing. You store your program in the same type of memory as your data so you can treat programs as data. This allows you to have compilers and loaders, effectively setting the stage for general purpose operating systems.
This simplfication is a security nightmare that made things much more complicated for all of us.
Re: I think the problem is somewhere else (Score:2)
Which is why no software engineer should work unpaid overtime. I go back to the tenet: software features and complexity will try to naturally fill any free time. You will not have to force adding features or making it better, there will always be natural pressure to do so, either from management, users, or simply the nature of your own desire to make it better. On the flip side you sure as hell will have to fight, barter, and claw features and complexity out of the software. Design does not dictate sche
Re: (Score:2)
Also probably the reason why software security seems to be getting worse instead of better.
Re: (Score:2)
Another example but of an entirely different kind of simplicity, is that of macos: They were big on making the interface predictable even across different programs. Compare the ratfuck (technical term) that is windows: They stole every idea that they thought would help tick a box on the desired features list, but there's no rhyme or reason to it. Not so macos.
Though macosx happened because "classic" wasn't really viable as a code base any longer. They copied "Unix" (using the term loosely, though they did get their take Unix-certified) as a foundation, and er, it's really quite a bodge. It holds up amazingly well, considering. But its big selling point is the consistency of interface, where as long as you stay on the marked paths of its garden, "it just works" to a degree seldom seen anywhere else.
Inherited of Nextstep than anything else, and it's Unixisms show though if one cares to look.
What has Agile to do with it? (Score:2)
No matter what development method you use, developers are always expected to do what the management wants. If a company sets a goal of improving user engagement, and developers think it's a bad goal, would it help if that got to them through a long chain of documents?
I think that the main reason people complain about Agile is that it's been around long enough that many people have no idea what it is to work in a world where (unlike with Agile) developers have very little feedback about what they do, because
Re: (Score:2)
At the end of the day it's management and corporate politics, no matter what is going on at the developer level.
I've worked in agile-heavy and agile-light places, waterfall places, and no coherent planning places, and the common theme has always been the competency of the immediate two layers of management above me, and their ability to functionally work within the corporate political structure.
I've had good managers who did what they could to shield us from the madness of corporate, I've had bad managers w
Daily standups and Jira-hell (Score:2)
I think âoeagileâ has gotten so popular for âoemanagersâ precisely because daily standups ARE all about surveillance for them, so is the Jira-hell of a million misconfigured Workflows, status, labels and other nicnacs that make an impossibly heavy and murky process which, again, allows the âoemanagersâ to play gotcha with developers when the devs messed up one of the million label, tagging, updating rules in Jira.
Most âoeagileâ projects barely go beyond daily standups
oblig. reading (Score:3)
Taylorism Transformed, Scientific Management Theory Since 1945 [google.com]
Taylorism rears its head in software development because of the need for estimation. But in development, everything that is automatable has been, so what you have left is always inherently harder to estimate than just say, digging a ditch. So you get these management practices popping up not to improve productivity, but to produce reports ("artifacts") specifically designed to call failure (failure to estimate) success, or otherwise construct a clear path of blame to the developer.
Re: (Score:2)
Small, fine-grained deliverables that you can track can keep the schedule from getting too far from reality. Back in the pre-agile world it was common for a developer to be given a task that took a long time, then there was no management understanding of how the task progressed until it was due and the developer said "I need more time", the management asked "How much", with the response of "I don't know" or a wild guess. These sort of blind schedu
reducing uncertainty (Score:2)
Agile is really about reducing uncertainty in development.
Small, fine-grained deliverables that you can track can keep the schedule from getting too far from reality. Back in the pre-agile world it was common for a developer to be given a task that took a long time, then there was no management understanding of how the task progressed until it was due and the developer said "I need more time", the management asked "How much", with the response of "I don't know" or a wild guess. These sort of blind schedule slips makes improving the scheduling of the development process nearly impossible, and management cares about the scheduling of the process much more than the quality of it.
Another way to reduce uncertainty in development is with milestones. Drop milestones into a task that takes a long time. These milestones must involve demonstrating something that management can recognize as hard evidence of progress towards completing the long task. If a milestone is missed management will be aware of the problem well before the scheduled end of the long task.
If you have competent people, Waterfall and agile can be combined into an effective tool. Use Waterfall for planning, scheduling
Agile is more religion than anything else (Score:5, Interesting)
I've always said that Agile looks like software engineering with all the maturity taken out of it. And nothing has changed my opinion on that.
Specifications? Who needs 'em? Just document the Minimum Viable Product!!
Architecture? What the hell is that? If it can't be done in a 2 week sprint, what the hell are we doing?
Process? Get out of here with your stinking fucking process! I'm an Agile engineer goddamnit, I value relationships over process! You cunt!
Documentation? It's all in the source code as a series of cryptic comments that only I understand and which will be valueless to anyone who comes after me! Get out of here with your unreasonable demands for design documents and architecture!
Not to mention that every Agile developer I've ever met was an arrogant crybaby who lost his shit whenever you tried to hand him a clear set of specifications.
No bozo, I don't want you to design the interface because you're a programmer (or worse, a scrum master) and like 98% of programmers your UI designs are fucking garbage, you think hierarchical menus are still the shit and understand precisely zero about the value of metaphors.
I could go on, but there's very little in the way of quantifiable proof regarding the so-called "benefits" of the Agile software development methodology. I approve of pair-programming and there's a couple of ideas in there which actually work but a lot of it is just hot fucking garbage.
Don't even get me started on standups.
Re:Agile is more religion than anything else (Score:5, Insightful)
I have seen agile-as-a-religion and pragmatic agile. Agile-as-a-religion is always a problem. For instance I know of a team that deleted over half of a project's unit tests because they did not believe they were atomic enough and did not replace them ultimately resulting in many embarrassing bugs for the customer and progress crippling "fear of the code". The worst is when a non-technical customer "gets agile religion" and runs a team of teams. One software project like this started with a bunch of open source components, you could say the project was a third of the way up the mountain at the start. But because everyone had to show customer decided progress every three weeks and it was always easier to go downhill than up, the ultimate integrations need to reach the top of the mountain never occurred and if anything after three years, the overall project was farther from the top of the mountain than it had been when it started and was ultimately a big enough disaster to make the news.
If I am leading a team, my goal with standups is to eliminate them. My requirement: That the team have it's "legs" -- that a merge-to-main is reflected as a change in production with all unit tests and minimal integration tests validating and everyone is using whatever tracking program the team is using effectively. This isn't just a technical milestone, I also see it as a team cohesion milestone and I know I need to worry if meeting this requirement drags on for more than a couple of months for a completely new project or a couple of sprints for a team inheriting a smooth running build/deploy process. I tell my teams this up front, so it is also a motivator.
Many real-world engagements are inherently waterfall. A development team bids on meeting customer requirements over a period much larger than a few sprints, sometimes years and the customer wants minimal interaction with the development team and only at specific pre-ordained milestones. Too often agile is applied inside a project like this in irresponsible ways that ultimately lead to the product not meeting specifications.
Re: (Score:2)
Anything as a religion is always a problem. Anything.
Because religions require belief and the purging of heretics. You're not allowed to question religion. You're not allowed to suggest non-blessed aproaches or actions.
The crazy part is that agile itself teaches that you should modify it to fit your needs, and explicily NOT worship the entirety of the system!
This is why religion is so fundamentally toxic and corrupting. People are desperate to make sense of the world around them and put it in order, and the
Re: (Score:2)
I've always said that Agile looks like software engineering with all the maturity taken out of it.
Yes, pretty much. Software is _hard_. Now management thinks that cannot be true and hence "agile". That makes things harder, not easier and on top of that you have a good chance of losing your best people because they have ample opportunities to work in an environment that is not kindergarten instead.
The purpose of software development methodologies (Score:3)
Re: (Score:2)
You are juxtaposing two things that can be true, but one is not the cause of the other.
Good managers can succeed with any methodology, waterfall or agile. Bad managers will fail with any methodology, waterfall or agile.
Yes, I'm sure some bad managers introduce agile to cover up their incompetence. But some good managers introduce agile and successfully use it to improve efficiency and morale in their programming teams.
I wanted to write a post (Score:5, Insightful)
I wanted to write a post about agile. But now is not the time that I have to make this decision so I'm going to postpone it until it's necessary.
I found the Holy Grail that's even better than agile, it's called being your own startup. We just do what we want and ship stuff because we have a small team and everyone is thoroughly vouched.
I've been there over 4 years and I haven't had a single objective review meeting. I've never had a formal goal setting meeting. Haven't even had a company all hands. I figure out what I want to do everyday and do it. If I want to play around learning a new library or something I just do it. It's amazing it's what agile actually is, a bunch of developers doing what they feel is necessary because they and they alone have exact knowledge on what is necessary.
For those who aren't Developers it's extremely annoying to have a group of people who don't even know your skill who think they're there to manage you and plan how you operate that skill. About as dumb as me running a surgery Ward not being able to do surgery.
The best thing I could offer for someone looking to implement agile, fire anyone you don't trust, give those that are remaining full power to do whatever they need and stop asking them for daily checkpoints or even weekly checkpoints. Watch the software flow.
Re: (Score:2)
I posted, so I can't use mod points, but I would +999 the parent. Exactly my experience.
Re: (Score:2)
Bingo.
Mod parent up.
The software industry sucks (Score:5, Insightful)
Here's a rant from an old-timer. I've been a professional software developer for over 30 years and owned my own software company for 20 of those years.
The modern software industry sucks. It's all about fads and badly-thought-out frameworks with a bazillion dodgy interdependencies. Most development nowadays is either web development, with a completely brain-dead development environment and absurd constraints (the browser is a completely weird platform) or else embedded development, which is throw-this-over-the-wall-as-quickly-and-cheaply-as-possible-and-who-cares-about-ever-fixing-bugs.
The sad truth is that you can't build good software unless you have developers who care passionately about quality, and most do not. Doesn't matter what tools or methodologies you use; if your developers don't care, the product will suck.
Additionally, software development is not a science. There's a substantial component of craftsmanship or even art. That's why the best developers are not just a bit better than the average developer; they're orders of magnitude better. Business types greatly underestimate the importance of hiring the right people. They just assume developers are interchangeable widgets, so if a project is late, you just add more widgets to the development team.
Honestly, if I could retire from tech right now, I would. I definitely will retire within the next 5 years and go back to my hobby software projects, which are the ones I truly love.
Re: (Score:2)
Re: (Score:2)
The main issue is that the software industry is more prolific and 'hot' than it used to be, and this has caused the signal to noise to go poorly.
Good software exists and good developers exist, but it's in a sea of marketers trying to manipulate the industry and an army of "people told me I could be rich by programming, even if I don't really like it" programmers.
Re: (Score:2)
Re:The software industry sucks (Score:4, Insightful)
You speak of the software industry because that is what you know. But the fads and needless change are rampant in every industry, not just software.
The Author Has Unusually Interpretations of Things (Score:4, Insightful)
First, it's not a discovery that agile (or waterfall) focuses narrowly on achieving the organization's goals--that is very much the objective. Second, ethics were never a part of software development methods. Those a business decisions. It's not agile's fault or waterfall's fault. A hammer is a hammer. You can drive a nail into wood or clobber somebody. It's not the hammer's job to decide or its fault.
Yes. A developer should have standards of ethics and quit his/her job when asked to go beyond them. However, that has nothing to do with the development methodology. It goes for anyone's job. And really, we should have laws, regulations, and incentives (positive and negative) aiming corporate responsibility in the right direction, instead of the pure and only driver being greed.
As far as giving engineers autonomy, I do see enormous largely unrecognized value in that. Boeing, for example, made great products until the management style was changed to a top-down authoritarian model. That clearly began the fall of Boeing with technical failures one after another. And I have seen this pattern in company after company. Prior, Boeing engineers had control of their own schedules and latitude to design for given goals. Engineers informed management of the schedules and resources needed to achieve goals and advised of better ideas. Now management gives the schedules and demands they meet them. Obviously quality, productivity, and innovation all suffer horrendously. Yet Boeing management has doubled-down on their top-down authoritarianism.
Engineers need latitude to solve problems. Their work is nothing like a production line in a factory. It just doesn't work that way. The same is true of software engineering and software development.
It's a joke (Score:2)
For many, many teams, Agile is a joke. There, I said it.
In a lot of cases agile just gets in the way- too many pointless meetings, lots of tedious and soul-crushing reviews that contribute little or nothing.
You spend more time dividing, "pointing", and assigning the work than it takes to do the work.
Pointless puffery and mechanistic "following The Plan" even though the the whole fucking idea is to be flexible and sometimes not follow The Plan.
I have basically banned Agile from my little team for all intents
Re: (Score:2)
Then you're obviously never done agile.
A core component of agile is to review how shit went and adjust things to make the team more productive. If you're not doing that, you're not doing agile. If it's not working for the team, that comes up in the sprint review and you embody being AGILE and address the issue.
"I don't like garlic bread that I didn't put any garlic on because it's tasteless" is what you're saying. Skipping critical parts of things and then finding that they don't work as advertised really h
Re: (Score:2)
Then you're obviously never done agile.
A core component of agile is to review how shit went and adjust things to make the team more productive. If you're not doing that, you're not doing agile. If it's not working for the team, that comes up in the sprint review and you embody being AGILE and address the issue.
Classic "your doing it wrong" excuse WRT agile never seems to go out of style.
Re: (Score:2)
One of the things that bug me about Agile is when people throw out 'no-true-scotsman' feedback to anyone that should dare claim to have a bad experience with the buzzword.
The truth is Agile, in practice, is a buzzword lost to a sea of consultancy and manager hype geared toward making it mean whatever you want. People can hear ideas and internalize them and decide how best to proceed with their own team. All the hand-wringing about how to rationalize your workflow as 'Agile' pretty much falls squarely into
Re: (Score:2)
Then you're obviously never done agile.
Always the same crap: when it doesn't work you have not done it correctly or at all. No wonder so many are giving Agile a big (and thoroughly deserved) middle finger.
Re: (Score:2)
Then you're obviously never done agile.
Then apparently neither has anyone else in my 15,000+ employee company, and that includes all of our teams, agile coaches, scrum masters, product owners, etc etc etc. I guess that also goes for most if not all of the companies I've worked for in the past who used various forms of agile.
Yup, we're all just "doin' it wrong", every single one of us.
A core component of agile is to review how shit went and adjust things to make the team more productive. If you're not doing that, you're not doing agile. If it's not working for the team, that comes up in the sprint review and you embody being AGILE and address the issue.
I don't want to blow your mind, but you can do that without all the agile shit. It's not new, it's called "Process Improvement" and it's been around forever.
Before
Agile was hijacked by some of its own authors... (Score:2)
The moment of enlightenment that occurred at the ski resort was the creation of those four values. In my mind, those are the priceless things. Agile is a set of VALUES.
The rest is unadulterated bullshit -- including the "twelve principles" (I call them the "twelve afterthoughts"). The biggest tragedy is that probably more than half of the guys went away and started creating process frameworks, tools, coaching/consulting businesses, writing books and creating process tracking software aimed at promoting th
Re: (Score:2)
Yep, it started with some folks expressing sincere frustration at professional software tripping over supremely bureaucratic nonsense, but has become the largest producer of supremely bureaucratic nonsense mixed with another camp of people claiming it justifies 'cowboy coding'.
I hate using the word 'Agile', I don't feel like I need an authoritative brand-word to appeal to or consultants to rationalize my position. Basically, just don't let ritualistic behavior tie your hands from getting the work done, and
These are why we created Agile 2 (Score:3)
Agile is amazing (Score:5, Funny)
I encourage all of our competitors to vigorously adopt it.
Re: (Score:3)
The beauty of 'Agile' is that if you are successful, Agile advocates will declare you are using Agile processes, whether you claim to or not.
Conversely, if you fail after declaring you have gone to Agile, those some advocates will say "well, they didn't do *true* Agile".
Agile is a hollow buzzword that can mean anything. Anyone sincerely trying to actually better things is better off leaving the buzzword behind. There may be some useful mindsets frequently exhibited in Agile discussions, but those can be ado
Re: (Score:3)
I have personally witnessed success in a waterfall shop. It was indeed agile, in that success was achieved through iterative, incremental releases. I'd rather tell people up front that we're going to do incremental releases, so they are expecting the reality of what will happen anyway.
Re: (Score:2)
I will accept your challenge. I have no desire to work for a waterfall shop ever. I've been there, and I hated every minute.
Scrum is Not Agile! (Score:2)
Agile, agile - it's just irrelevant (Score:5, Insightful)
If you have a good team - PM and developers - any disciplined development methodology will work. If you have weak management or poor developers, no methodology will save you.
Changing the methodology du jour every 10 years or so? That's useless consultant's selling overpriced crap to clueless CxOs. I have seen Agile projects land in court, and waterfall projects work well. Also the reverse. It's all about team quality. Improved tools have also helped. Nothing else matters.
Yes, it is a religion (Score:3)
I've been around long enough to see lots of Next Big Things in software come and go. CASE, Extreme Programming, object-oriented microcode, whatever, the buzzword list is endless, and nothing's really changed. 40 years since I started out, software is still late and broken.
But of all the fads, I've never seen one whose adherents have as much religious fervor as Agile evangelists. It's like Ayn Rand wrote a book about software development. It can't fail you, so if it's not working for you, *you* must be failing *it*.
If some or all of Agile works for you, keep that part and bin the rest. But please stop telling me that it's The Perfect Thing for my project, whether it's a kids' iPhone game or the telecom gear it talks to that's got to conform to 20,000 pages of standards and 100 countries' regulations.
Re: (Score:2)
And the alternative religion is the waterfall religion. It's proponents are equally ardent in their support of their favorite methodology, decrying those who disbelieve as not being true programmers.
The real problem is the 'requirements problem' (Score:2)
The most common approach to documenting requirements is the written word, usually in the form of user stories (see NaPiRE http://www.re-survey.org/#/hom... [re-survey.org] for example). This fact makes software engineering an outlier.
Software engineering is the only one of the five major engineering disciplines that does not have a universal process and visual blueprint for its products. Civil engineering has its architectural blueprints, mechanical has its design drawings, chemical has its mole