Which is exactly why Agile In Their Own Words exists.
Most everything else that’s been written about agile has been pure propaganda that you’re not allowed to question. There needs to be other viewpoints that are critical of agile.
“This agile witch hunt has to end, but it never will unless we start politely asking for the things we want.
i know for a fact that 90% of engineers dislike agile but many don't even imagine there can be an alternative, and most who do are terrified to say anything. Just look at the other answers to this question, most are from the very non engineers that have imposed this nonsense in the first place.”--Anonymous,
I'm willing to admit it. I went from a job that was "Agile" to non-Agile, and it was glorious. Then they added it, and it was not, and it was visible how much less productive we were.
I once had a project where I regularly sat with the end-users of my software. I’d look over their shoulders and observe where they were losing time to something I could automate away.
They were happy with the result. I was happy I could act as a force multiplier for an entire team.
That’s what Agile is supposed to be.
Everything else is some weird cult.
Like… Jesus just told everyone to treat each other the way they themselves would like to be treated. The specific dress code of the bishops in the Vatican? That’s not the message. But I guarantee you that the dress code is enforced by some busybody.
But then does it have to be called "Agile", or can we keep the older "common sense"?
I tend to think that at university, we were pretty good at self-organizing for group projects. We had to be efficient because of deadlines, and it worked well.
Then I joined a company, where some people (usually not the best developers, obviously) felt good telling everybody else how they should work. Introducing processes, reading all sorts of agile books, copying Spotify's processes, using the management tools they saw in a Netflix blog. Those were the managers.
And every time I ask a manager: "so, this process... is it to make you more productive, or is it meant to make me productive?", they say "it is making you more productive". Why would they believe me when I say it does not? Their job depends on it.
If I was in the position to select CVs of applicants, I would put a rule that would delete all CVs that contain "agile coach".
That's probably the most useless (and counter-productive) role I can imagine. Usually people who can't build anything interesting themselves, but realised they are good at bullshitting others.
> Everything else in the "agile" cult is bullshit.
IMO the fundamental problem with the manifesto is the question, who is the customer? "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software."
My customers don't want "early and continuous delivery". I hate App Store apps that release new versions every week with cutesy uninformative release notes like "We've improved the software for you". That's bullshit. And users don't want "early" half-baked buggy crapware; they want their software to Just Work™.
The Agile Manifesto seems designed for contractors or for wage-slaves to middle-managers. Replace "the customer" with "the end user" and it doesn't sound so great anymore. But nobody seems to care about the users of the software.
let me translate that, "we rushed our previous release to meet some arbitrary deadline to make some manager look good, but here's a release to finish some of the issues we knew were left incomplete while we all collectively held our breath that not enough people would run into the known issues"
How many times do we have to work evenings and weekends for a bullshit deadline, and then see that the user doesn't start using the feature for another 4 months, if they ever actually use it?
> My customers don't want "early and continuous delivery". I hate App Store apps that release new versions every week with cutesy uninformative release notes like "We've improved the software for you". That's bullshit. And users don't want "early" half-baked buggy crapware; they want their software to Just Work™.
Prior to Agile delivery, updates came once every 3 or 4 years and software languished in-between releases. If software shipped with a bug, that bug stayed around for a long time, unless it was lucky enough to get fixed in a service pack.
For large dev houses those service packs were complicated and hard to ship, because their entire organizational structure was based around big bang releases.
Competitor comes out with a killer feature? Well users of your software weren't going to get it for literally years, during which time a fair number of them might very well defect to the competitor's software.
And a lot of software you use gets updated all the time, you just don't notice. Performance bugs get fixed, memory leaks patched, and UI quirks, that you may not have run into, are removed.
> Prior to Agile delivery, updates came once every 3 or 4 years and software languished in-between releases. If software shipped with a bug, that bug stayed around for a long time, unless it was lucky enough to get fixed in a service pack.
Windows releases, Office releases, Visual Studio releases.
I started my career in the mobile (originally Windows CE) compiler team. Releases were a big deal, support contracted lasted seemingly forever. (Ironically, internally the mobile compiler team was actually very agile, with weekly full test passes happening, the compiler always being in a shippable state, and development occurring in what would now be considered modern practices.)
Microsoft was getting destroyed because they were very non-agile. As soon as the iPhone came out, Apple started releasing a new OS every year, and back then OS updates had significant developer API improvements. Windows Phone couldn't complete with that. I remember how lacking the camera API was soon as instagram types apps with filters came along, Windows Phone went from amazing to instantly behind the curve.
Look at what happened to Hotmail when GMail came out, it took Microsoft years to catch up just with the storage space increases, UI improvements took even longer. Microsoft ended up losing their top spot in the webmail game.
Internet Explorer (eventually Edge) was tied to OS releases. Even when MS started to invest in their browser again, being tied to OS releases meant it could never complete with Chrome releases happening every few months. Edge would have a big release, pull ahead on benchmarks, then 6 months later be out of date and behind the curve again.
Agile forces code to always be in a shippable state, which is a good thing. It doesn't let code become bug ridden and then say "we'll fix it sometime later".
That forcing function alone is a huge improvement.
> Agile forces code to always be in a shippable state, which is a good thing. It doesn't let code become bug ridden and then say "we'll fix it sometime later".
Is it Agile, though, or is it Internet? Because having the possibility to send regular updates over the Internet seems to have permitted to ship buggy software quickly, and pretend that it will be improved later. That's faster, but I feel like software is lower quality today than it was years ago.
> Prior to Agile delivery, updates came once every 3 or 4 years and software languished in-between releases. If software shipped with a bug, that bug stayed around for a long time, unless it was lucky enough to get fixed in a service pack
It still would if you had to go print CDs. The internet changed all that of course. Now we have a business model based on continuous sales (like app stores instead of big launches) and subscriptions.
Agile’s term “customer” is actually very ambiguous about whether it’s trying to define the relationships between developers and employers or developers and users who buy the software.
“The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” — This becomes an excuse not to write anything down, which cripples the folks working on the project (charitably) starting six months from now, or (uncharitably) not in the right clique.
“Not putting anything in writing” is an ages-old power-wielding technique. It’s easily to move the goal posts back when there’s no authoritative written record of what the goals are.
The problem is, like the Bible, all of these can be interpreted in a number of ways. It’s no wonder it’s spawned dozens of religious sects in corporations.
Actually I think the principles are bullshit. They're full of holes you could drive a truck through.
Every team I have ever been on has had zero idea how to run an effective Agile team. They don't know Agile, Scrum, Kanban, they've never had project management experience, they don't understand why they need estimations, work limits, reports, continuous improvement, stakeholder management, or really any concept out of "Me write code good!" Left to their own devices, teams are shit at communication, shit at process, avoid anything difficult, and end up needing some clueless outside manager or contractor to force them into a process so they'll get something meaningful done on time and actually report it to someone outside their group.
If everyone on the team has had real Agile training, and actually practiced it before, then they can manage their own team effectively according to the principles. But that team does not exist. Managers don't understand these principles either, and won't ask for the things that ensure the principles are followed. Really everyone is just fucking clueless and doesn't care.
idk ive worked in both systems and they have their positives and negatives but the overriding factor by a million miles is quality of management. nothing works if you have mismatched management for the scale of the task & company. Every system works if you have the right management.
It's much more important to stick to dogma when you have 200 guys that need to coordinate. Anyone overmanaging your team of 6 sticking tightly to agile is wrong. But similarly doing cowboy type anything goes "requirements are a suggestion" type stuff causes disasters on the regular at larger companies resulting in knots that are far too large to untie
I do not hate it (Agile / SCRUM). I just plainly refuse to participate in twisted distortion of reality and wet dream of imbecile self serving managers (there are actually very good managers as well but I am not talking about those). No complaints from my clients. I make it a condition - no onsite work and no agile for me. Do no care what they do inside. I might have lost couple of deals but so far I have no shortage (fingers crossed).
I love agile I think the fundamental underlying principle is sound. Iterate quickly, be flexible, focus on doing a thing and change when it isn't working.
The problem is not and never had been agile. It is the "agile" industry which spun up around it to bilk clueless management, out of money and give Execs reasons to transfer a couple thousand quid to their buddies for agile consulting services.
Agile is brilliant precisely because it is so concise and clear and there isn't that much more beyond the manifesto to understand.
Unfortunately it was mangled, tortured and twisted into a Frankenstinian nightmare that made everyone suffer. The good news is that right around the time everyone was getting wise to the fact that the entire agile industry was built on sand DevOps popped up to be the new buzzword of which the kingdom of jargon will be grown out of. And the cycle continues.
The manifesto is concise, but I wouldn’t call it clear. I think that’s why “agility coaches” have their niche.
You can’t really teach beliefs, which is why it’s formatted like an agreement. Everyone is supposed to at least think they share these ideals, and make choices that align with those beliefs. But that’s much too introspective to be marketable as meta-work, so people have started reading between the lines to explain away specific meetings or processes. Because “agile” as a concept is so unclear, it’s easy to expand on, creating the weird Frankenstein situation you’re talking about.
I've been in too many situations where agile was touted, but it was just something to cover up the lack of longer term planning. Treating everything like a fire and running about being agile is also a sign of bad leadership
> It is the "agile" industry which spun up around it to bilk clueless management
Scrum is the epitome of this. It's a half-measure that combines the worst of waterfall and agile. You have (almost always) pointless ceremonies that do little more than satiate management's cargo cult of productivity (yes, I do know what it is academically designed to do). Furthermore, given that its more similar to waterfall than kanban, it often gets watered down for execs and becomes even worse.
I have come to realize that unless you're doing something that approximates kanban or chaos/anarchy, then you're probably not doing agile.
Agile is universally applied, which is the failing. SOmewhere in those comments is the gem of the whole thing:
- It's good for interfaces. Specifically, ones that are ill-defined
And therefore, agile is great for moving around widgets, changing CSS / colors / fonts, adding a widget or two, improving validation on fields, maybe splitting a page into multiple. Notice how all those tasks are palpable, pretty simple, well constrained, evolutionary, and steadily improved? Perfect for Agile.
It might be good for some microservice development, but it also tends to make microservice interactions unstable and explode their numbers, and destabilize the apis.
Research, deeply difficult code, inherited codebases, large refactors, architectural migrations (monolith --> microservices, major version updates to platforms, move to cloud), are AWFUL for Agile.
Aside from that, story points, burn charts, velocity charts, fixed sprints, tend to be square peg round holes and big hammers. I can't count the number of times I simply had a "8" ticket that would cross two or three sprints before it was done, and eventually managers just accepted it when I explained what needed to be done. And really, that was still to confining for major major tasks.
Also, QA gets completely squeezed, because the agiles I've seen all assume the QA is done in the same sprint the dev occurred. Wow is that dumb. Because the dev runs long, the QA gets shrunk. Really the QA should occur in the following sprint once the dev deadline is achieved.
There has to be a middle ground. Either you are doing 6-12 month waterfalls, or doing 1-2 week sprints? Come on people. How about 1-2 month checkins?
Sometimes I wonder if software dev orgs could vastly benefit from a bunch of attached "dev assistants" that help write the documentation, track tasks, tickets, etc, and alleviate devs from having to do all that paperwork / distraction. They can function as safe sounding boards, or keep an eye on a bigger picture as the developer dives deep into the tech details.
Managers wouldn't stoop to this. SCrummasters ... kind of ... devalue managers a bit at the interface point with engineers, but not enough to get this sort of bookkeeping.
Like, if you are shelling out 200k for an engineer, wouldn't you rather they work as much as possible on the tech stuff, and leave the bookkeeping to some cheaper person?
The frustrating thing about “I Hate Agile” is that… there’s no such thing as “The Agile”. I was once talking to a developer who told me they hate “Agile” because how they have to stay later and work more hours. They also thought “Agile” meant a ping pong table. I was speechless.
Any team that is dogmatic in how they develop software will always have a difficult time.
Teams should ask what problem they’re trying to solve, and whether “agile” has some tools they could try to improve their problems.
As someone who worked both as a developer/engineer and as a project manager, the simple answer is a lot of novice (polit word for idiot) PMs choose agile and try to force it on a team just because they heard X famous company applied it or their previous company applied it in some project and worked, but at the end of the day, it is just a tool like any tool you use, it might work in some specific occasion, but definitely it is not the best for everything, and you as a PM who’s getting paid for that specific task, it’s your responsibility to know this, customize it or even create a new approach to achieve the end goal. I have seen and heard so much horror stories of how some PMs are abusing it, or misuse it due to lack of training and knowledge, I remember a friend once said they had a meeting to discuss meetings.. or when some PM try to apply scrum for some niche engineering project with small team where scrum assumes everyone in the team can do the same task, and your engineers have completely different disciplines to start with, list goes on.
I call this "cargo cult management", where they pick up the trappings of an effective team, but do nothing to take on the mindset. If your meeting is an hour and a half long, and each person speaks for 10 minutes a piece, then it ain't a standup. And that's OK. Trying to force agile onto a team that only does ongoing manual processes is doomed to failure, and its OK to say that out loud. Not every task must be conceptualized as a story, and it's OK to admit that.
I worked for a company where the story points of all the separate teams were brought up to management, who would then convert that to time in order to bill customers.
Instead of time-sheeting, they were using agile story points, without understanding that the whole damn point is that one point in one team could be worth ten points in another team.
One of the best things about CI was knowing who would deliver and who wouldn't and who knew their stuff was so important they could break everyone else's.
I just see the agile management processes as an attempt to get the same insight outside of the code base.
I wonder if this is the result with tech's obsession with certificates. There was a time circa 2009-2014 when everyone and their mum were Scrum masters.
And a lot of those comments sound like whoever is handling project management uses Agile as a dogma rather than a toolbox to be modified as needed.
I don't think I've ever come across a project that uses "pure" agile. It'd be pretty insane. Right now I use a mixed approach that uses:
* Requirements
* User stories
* Use cases(IBM style)
* Planning Poker
* UML
* Sprints(Both 1 week and 4 week sprints)
* Burn-Down charts
And a bunch other I'm probably forgetting.
It also sounds like their project managers aren't actually managing them, but rather delegating the management to their developers.
I used to have a producer that said that every second an engineer wasted faffing about in JIRA was a second not spent solving an issue, so he tried to automate reporting as much as possible and wanted us to only raise an alarm if something didn't go as planned.
I quite liked this approach and I'm planning on using a modified version for a future project, so I guess I'll soon find out if it works :D
Use common sense, and organize your team in a way that works.
Students tend to learn to do that in university group projects. Then they join the industry and we tell them "you need to gather everyday at the same time for what we call a 'stand-up', where we talk to each other". Guess what? The students were communicating without having to make formal stand-ups, and it worked.
I’d say that it depends on who you ask when it comes to what’s „common sense“ and what’s „a way that works“.
What I have seen working is:
- Have somebody who is responsible for understanding the customer from a business perspective and be able to explain that to developers in the form of prioritized development items.
- Try to build something that works to confirm your assumptions and manage risk, ideally on a short-ish cycle of a few weeks. Always keep a working product. In some projects this is not (immediately) possible - in that case, it’s probably better to run a traditional waterfall-project, with the tradeoffs that come with it.
- Get together regularly to talk about less immediate topics and improve the work process.
- Plan and make forecasts using actual data from the past, not wishful thinking.
And that is basically Scrum. For me this is common sense, I wouldn’t know why you would do it in another way.
How it’s implemented in practice differs and it seems a lot of places don’t implement it very well. So far I haven’t heard many good suggestions from the developers suffering under these implementations on how to make it better though, hence my question.
The devil is in the details. The problem is the cargo cult that goes with Agile. You can take any example that works and say "this is Agile!". But in practice, what happens with Agile is that some people come with their book that they treat like a bible, and try to apply it without question.
I have had teams where we were communicating really well, but still we had a 40min standup everyday where we would basically say "as you already know, <blah>". Still we were doing standups, because the bible says we should. We could have used that time for a coffee with the team instead.
I have had teams where people were working on very different things, so nobody would listen to the others during the standup, and during the planning, it was 10 times a 1-on-1 with the team lead because nobody really cared about the tasks of the others. Everyone but the team lead was losing their time. But the team lead found it useful (obviously).
It should be bringing you closer to the work. The only “agile” (adjective) way of working I have seen work is where people whole-heartedly believe in the principles listed here: https://agilemanifesto.org/principles.html
If people actually believe that, you should be MORE aware of customer needs, what the market your company exists within is doing, and why things have to be done.
It’s not great if you don’t want to have to worry about outside factors like that, but then you need to expect the many extra managerial and planning layers that will worry about those factors for you.
IMHO, the problem is that we as an industry don't seem to accept that tasks estimates are wrong most of the time. Because it's hard to estimate, and because managers don't believe developers. Also managers have an incentive to give unreasonable deadlines to developers (developers under pressure are admittedly faster, but not necessarily making a good job), and developers have an incentive to write quick hacks to make their managers happy.
There are methods that work and that don't require institutionalized estimation-bullshit. For instance:
- You write a mobile app for a customer. Discuss the requirement with them, say what is "easy" and what is "much harder than they imagine" (they probably don't want that, it's orders of magnitudes more expensive than they expect). Then work hard on limiting the scope of the project with the customer and start working. Meet every 2 weeks with the customer, show the progress and get paid. Decide the next step with the customer and go for another 2 weeks. This is the closest I can imagine to the typical Agile cults, except that it doesn't involve estimation dances ("Fibonacci points or T-shirt sizes?") and all the "velocity" crap.
- You need to write bigger software than a small app. In that case, just build it slowly, and start selling it when it is ready instead of selling promises based on estimates (again: estimates are wrong). Estimates here lead to over-promising, then there is no need to design the software properly, everyone makes hacks and rushes and makes a bad job.
Since I started involving myself in more complex application modernization projects, I lean towards Domain-Driven Design.
DDD and agile don’t like each other much at all until you’re in the implementation side of software engineering. The discovery and modeling activities are very hard to quantify so reporting tasks and progress is very difficult.
So the challenge is to get managers to be flexible in how they manage aspects of application modernization.
> The discovery and modeling activities are very hard to quantify so reporting tasks and progress is very difficult.
Agile has nothing to do with things being easy to quantify (except insofar as it is in part a response to the fact that they aren’t, generally, in software development.)
Obsession with quantification and detailed estimation is something Agile was a response against (but which has defeated Agile values even in most places that say they are “Agile”.)
DDD may be an excuse for (it does not seem to me to actually require) big upfront design, rather than the more fluid minimal units of independent value many approaches in the agile space prefer, but that’s a different issue than quantification.
There’s a practical side that the agile manifesto ignored which has been proven over and over. Management simply refuses any project management that doesn’t have clear goals and reporting mechanisms.
The only “process” that works in our industry is “hire the right people and get the F out of the way.” everything is bs.
live and work long enough in this industry and you’ll go through myriad of “processes” and “manifestos” and other bs all created to hire tens of thousands of incompetent people to tell 100’s of thousands of (mostly) incompetent people how they should do their work
I talked to someone less than a week ago who works at a very large software company: their products are huge monoliths that take days to build, where the customers need to plan their upgrades months ahead of time because they can't afford downtime. Everything has to be documented and incorporated into the manuals, and there are five or six layers of people between any possible users and the developers. They need to support seven or eight versions at any given point in time.
They work in fixed-length sprints with daily standups. They assign bugs to specific people who then have to write user stories about the bugs before beginning work on them. Product features are planned out quarters in advance.
Software development methodologies are political in nature (see: definition of politics). There is no best implementation of a political system, but there are working examples, some have more success than others, and some are implemented better than others.
I find it really funny when people complain about politics, when those people have never and will never do anything to fix the problem they're complaining about. Like complaining that it's too hot outside, but still sitting there in the heat.
And what's really funny is the only people who comment on it are the people who have no clue how it works.
> And what's really funny is the only people who comment on it are the people who have no clue how it works.
What do you know? Because somebody is not in a position to change the political system, or is not able to propose a better system, does not mean that they can't see problems.
I hate the "I don't want criticism, I want solutions" idea. Identifying and acknowledging a problem is the first part of finding a solution. Those who refuse criticism are just denying the problem.
If what you're complaining about is decades old, somebody already identified it, many times over. And almost without fail, whoever is complaining, is complaining because they want someone else to fix it. Lazy, annoying, and useless. Either move on to solutions or admit you're just whining to whine.
> Either move on to solutions or admit you're just whining to whine.
For a political system, you need to convince many people if you want it to change. You can't just "move on to solutions".
For agile in a company, in my experience the developers are not the ones bringing the processes, and they don't really have a choice. And even then, again in my experience, juniors tend to get excited about everything that looks new. So part of the team will think that estimations are a good idea in principle. Until they do it long enough to realize that the whole methodology is a big joke.
Talking about agile, whether it’s praise or complaints - is mostly useless, because parties don’t share a common definition of what it is and what is being discussed.
Some think Jira means agile, others think exactly the opposite, that use of Jira is an affront to agile. Some think that you don’t need requirements in agile, others think that without requirements there’s no agile.
It’s been my experience with similar threads in the past - that even the commenters weighing in on the subject will ultimately fail to agree on a common set of definitions and will end up with varying and often contradicting interpretations.
A fertile ground for a ministry err… a consulting business offering thought leadership.
I dont see many suggestions of a better way to do things. We can always find the flaws in the way things are but that doesnt mean they’re not optimal. When I learned this the first time it was just either agile or waterfall, if agile is so bad are we saying that waterfall would be better for all these situations?
My opinion is that agile needs to be agile, in that we have to adapt ways of working based on the team’s situation, what were working on, how well resourced we are … and have agility to change how we do things to optimise our work based on those constraints.
Too many companies try to “do Agile” in a prescriptive way and lose sight on being agile in the process. The concept is solid, but the implementations are all over the place. I’ve definitely seen agile work well, but I’d confidently say most companies aren’t doing it well.
Just last week I had a client request that I create a “user story” for my access to a system so I could actually work on the project. It can get crazy out there.
One of the problems with agile is that it demands that every act of developer productivity be couched in a user story, a user-visible unit of change.
And the catch-22 is that only things that “deliver value” can be user stories, only things that are user stories can easily get into backlog, and only by doing things in the backlog can a developer prove they’ve done actual work that justifies them continuing to have a job at the company.
So to get around this restriction for something that isn’t a user-facing feature, devs have to be creative and you end up with these completely insane-sounding user stories like “As a user whose data is stored in the database, I would like the database schema to be overhauled so it can support a many-to-many relationship”.
Agile fails because it gives management fine-grained control over developers’ todo lists.
87 comments
[ 3.9 ms ] story [ 168 ms ] threadMost everything else that’s been written about agile has been pure propaganda that you’re not allowed to question. There needs to be other viewpoints that are critical of agile.
“This agile witch hunt has to end, but it never will unless we start politely asking for the things we want.
i know for a fact that 90% of engineers dislike agile but many don't even imagine there can be an alternative, and most who do are terrified to say anything. Just look at the other answers to this question, most are from the very non engineers that have imposed this nonsense in the first place.”--Anonymous,
Everything else in the "agile" cult is bullshit.
They were happy with the result. I was happy I could act as a force multiplier for an entire team.
That’s what Agile is supposed to be.
Everything else is some weird cult.
Like… Jesus just told everyone to treat each other the way they themselves would like to be treated. The specific dress code of the bishops in the Vatican? That’s not the message. But I guarantee you that the dress code is enforced by some busybody.
But then does it have to be called "Agile", or can we keep the older "common sense"?
I tend to think that at university, we were pretty good at self-organizing for group projects. We had to be efficient because of deadlines, and it worked well.
Then I joined a company, where some people (usually not the best developers, obviously) felt good telling everybody else how they should work. Introducing processes, reading all sorts of agile books, copying Spotify's processes, using the management tools they saw in a Netflix blog. Those were the managers.
And every time I ask a manager: "so, this process... is it to make you more productive, or is it meant to make me productive?", they say "it is making you more productive". Why would they believe me when I say it does not? Their job depends on it.
Anyone I’ve had to work with who has “Agile” in their title has at best done nothing, and at worst slowed everyone to a crawl.
The base ideas though, I totally agree with.
I think things fall apart (ironically) when “agile coaches” put processes before individuals.
That's probably the most useless (and counter-productive) role I can imagine. Usually people who can't build anything interesting themselves, but realised they are good at bullshitting others.
> Everything else in the "agile" cult is bullshit.
IMO the fundamental problem with the manifesto is the question, who is the customer? "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software."
My customers don't want "early and continuous delivery". I hate App Store apps that release new versions every week with cutesy uninformative release notes like "We've improved the software for you". That's bullshit. And users don't want "early" half-baked buggy crapware; they want their software to Just Work™.
The Agile Manifesto seems designed for contractors or for wage-slaves to middle-managers. Replace "the customer" with "the end user" and it doesn't sound so great anymore. But nobody seems to care about the users of the software.
let me translate that, "we rushed our previous release to meet some arbitrary deadline to make some manager look good, but here's a release to finish some of the issues we knew were left incomplete while we all collectively held our breath that not enough people would run into the known issues"
at least, that's how i interpret it
How many times do we have to work evenings and weekends for a bullshit deadline, and then see that the user doesn't start using the feature for another 4 months, if they ever actually use it?
Nope, we care about money :-). My feeling is that software has been becoming worse every year since I started writing code (that's 20 years).
Prior to Agile delivery, updates came once every 3 or 4 years and software languished in-between releases. If software shipped with a bug, that bug stayed around for a long time, unless it was lucky enough to get fixed in a service pack.
For large dev houses those service packs were complicated and hard to ship, because their entire organizational structure was based around big bang releases.
Competitor comes out with a killer feature? Well users of your software weren't going to get it for literally years, during which time a fair number of them might very well defect to the competitor's software.
And a lot of software you use gets updated all the time, you just don't notice. Performance bugs get fixed, memory leaks patched, and UI quirks, that you may not have run into, are removed.
This is all nonsense.
Did you experience that, or did you read it in one of your Agile bibles? Genuinely interested.
Windows releases, Office releases, Visual Studio releases.
I started my career in the mobile (originally Windows CE) compiler team. Releases were a big deal, support contracted lasted seemingly forever. (Ironically, internally the mobile compiler team was actually very agile, with weekly full test passes happening, the compiler always being in a shippable state, and development occurring in what would now be considered modern practices.)
Microsoft was getting destroyed because they were very non-agile. As soon as the iPhone came out, Apple started releasing a new OS every year, and back then OS updates had significant developer API improvements. Windows Phone couldn't complete with that. I remember how lacking the camera API was soon as instagram types apps with filters came along, Windows Phone went from amazing to instantly behind the curve.
Look at what happened to Hotmail when GMail came out, it took Microsoft years to catch up just with the storage space increases, UI improvements took even longer. Microsoft ended up losing their top spot in the webmail game.
Internet Explorer (eventually Edge) was tied to OS releases. Even when MS started to invest in their browser again, being tied to OS releases meant it could never complete with Chrome releases happening every few months. Edge would have a big release, pull ahead on benchmarks, then 6 months later be out of date and behind the curve again.
Agile forces code to always be in a shippable state, which is a good thing. It doesn't let code become bug ridden and then say "we'll fix it sometime later".
That forcing function alone is a huge improvement.
Is it Agile, though, or is it Internet? Because having the possibility to send regular updates over the Internet seems to have permitted to ship buggy software quickly, and pretend that it will be improved later. That's faster, but I feel like software is lower quality today than it was years ago.
It still would if you had to go print CDs. The internet changed all that of course. Now we have a business model based on continuous sales (like app stores instead of big launches) and subscriptions.
Which allows us to ship bad software and hope that we will fix it later (spoiler: we never really do, it usually stays pretty bad).
Every team I have ever been on has had zero idea how to run an effective Agile team. They don't know Agile, Scrum, Kanban, they've never had project management experience, they don't understand why they need estimations, work limits, reports, continuous improvement, stakeholder management, or really any concept out of "Me write code good!" Left to their own devices, teams are shit at communication, shit at process, avoid anything difficult, and end up needing some clueless outside manager or contractor to force them into a process so they'll get something meaningful done on time and actually report it to someone outside their group.
If everyone on the team has had real Agile training, and actually practiced it before, then they can manage their own team effectively according to the principles. But that team does not exist. Managers don't understand these principles either, and won't ask for the things that ensure the principles are followed. Really everyone is just fucking clueless and doesn't care.
It's much more important to stick to dogma when you have 200 guys that need to coordinate. Anyone overmanaging your team of 6 sticking tightly to agile is wrong. But similarly doing cowboy type anything goes "requirements are a suggestion" type stuff causes disasters on the regular at larger companies resulting in knots that are far too large to untie
Unfortunately very few. Which is probably why people hate agile in the first place. The problem is not agile per se, it's the management.
The problem is not and never had been agile. It is the "agile" industry which spun up around it to bilk clueless management, out of money and give Execs reasons to transfer a couple thousand quid to their buddies for agile consulting services.
Agile is brilliant precisely because it is so concise and clear and there isn't that much more beyond the manifesto to understand.
Unfortunately it was mangled, tortured and twisted into a Frankenstinian nightmare that made everyone suffer. The good news is that right around the time everyone was getting wise to the fact that the entire agile industry was built on sand DevOps popped up to be the new buzzword of which the kingdom of jargon will be grown out of. And the cycle continues.
You can’t really teach beliefs, which is why it’s formatted like an agreement. Everyone is supposed to at least think they share these ideals, and make choices that align with those beliefs. But that’s much too introspective to be marketable as meta-work, so people have started reading between the lines to explain away specific meetings or processes. Because “agile” as a concept is so unclear, it’s easy to expand on, creating the weird Frankenstein situation you’re talking about.
Scrum is the epitome of this. It's a half-measure that combines the worst of waterfall and agile. You have (almost always) pointless ceremonies that do little more than satiate management's cargo cult of productivity (yes, I do know what it is academically designed to do). Furthermore, given that its more similar to waterfall than kanban, it often gets watered down for execs and becomes even worse.
I have come to realize that unless you're doing something that approximates kanban or chaos/anarchy, then you're probably not doing agile.
- It's good for interfaces. Specifically, ones that are ill-defined
And therefore, agile is great for moving around widgets, changing CSS / colors / fonts, adding a widget or two, improving validation on fields, maybe splitting a page into multiple. Notice how all those tasks are palpable, pretty simple, well constrained, evolutionary, and steadily improved? Perfect for Agile.
It might be good for some microservice development, but it also tends to make microservice interactions unstable and explode their numbers, and destabilize the apis.
Research, deeply difficult code, inherited codebases, large refactors, architectural migrations (monolith --> microservices, major version updates to platforms, move to cloud), are AWFUL for Agile.
Aside from that, story points, burn charts, velocity charts, fixed sprints, tend to be square peg round holes and big hammers. I can't count the number of times I simply had a "8" ticket that would cross two or three sprints before it was done, and eventually managers just accepted it when I explained what needed to be done. And really, that was still to confining for major major tasks.
Also, QA gets completely squeezed, because the agiles I've seen all assume the QA is done in the same sprint the dev occurred. Wow is that dumb. Because the dev runs long, the QA gets shrunk. Really the QA should occur in the following sprint once the dev deadline is achieved.
There has to be a middle ground. Either you are doing 6-12 month waterfalls, or doing 1-2 week sprints? Come on people. How about 1-2 month checkins?
Sometimes I wonder if software dev orgs could vastly benefit from a bunch of attached "dev assistants" that help write the documentation, track tasks, tickets, etc, and alleviate devs from having to do all that paperwork / distraction. They can function as safe sounding boards, or keep an eye on a bigger picture as the developer dives deep into the tech details.
Managers wouldn't stoop to this. SCrummasters ... kind of ... devalue managers a bit at the interface point with engineers, but not enough to get this sort of bookkeeping.
Like, if you are shelling out 200k for an engineer, wouldn't you rather they work as much as possible on the tech stuff, and leave the bookkeeping to some cheaper person?
Any team that is dogmatic in how they develop software will always have a difficult time.
Teams should ask what problem they’re trying to solve, and whether “agile” has some tools they could try to improve their problems.
There is a religion called "The Agile", I would say. Agile coaches are their priests.
Instead of time-sheeting, they were using agile story points, without understanding that the whole damn point is that one point in one team could be worth ten points in another team.
If nobody can do it right then it doesn't matter if the methodology produces utopia when applied correctly; nobody will ever get there.
One of the best things about CI was knowing who would deliver and who wouldn't and who knew their stuff was so important they could break everyone else's.
I just see the agile management processes as an attempt to get the same insight outside of the code base.
And a lot of those comments sound like whoever is handling project management uses Agile as a dogma rather than a toolbox to be modified as needed.
I don't think I've ever come across a project that uses "pure" agile. It'd be pretty insane. Right now I use a mixed approach that uses: * Requirements * User stories * Use cases(IBM style) * Planning Poker * UML * Sprints(Both 1 week and 4 week sprints) * Burn-Down charts And a bunch other I'm probably forgetting.
It also sounds like their project managers aren't actually managing them, but rather delegating the management to their developers.
I used to have a producer that said that every second an engineer wasted faffing about in JIRA was a second not spent solving an issue, so he tried to automate reporting as much as possible and wanted us to only raise an alarm if something didn't go as planned.
I quite liked this approach and I'm planning on using a modified version for a future project, so I guess I'll soon find out if it works :D
Students tend to learn to do that in university group projects. Then they join the industry and we tell them "you need to gather everyday at the same time for what we call a 'stand-up', where we talk to each other". Guess what? The students were communicating without having to make formal stand-ups, and it worked.
- Have somebody who is responsible for understanding the customer from a business perspective and be able to explain that to developers in the form of prioritized development items.
- Try to build something that works to confirm your assumptions and manage risk, ideally on a short-ish cycle of a few weeks. Always keep a working product. In some projects this is not (immediately) possible - in that case, it’s probably better to run a traditional waterfall-project, with the tradeoffs that come with it.
- Get together regularly to talk about less immediate topics and improve the work process.
- Plan and make forecasts using actual data from the past, not wishful thinking.
And that is basically Scrum. For me this is common sense, I wouldn’t know why you would do it in another way.
How it’s implemented in practice differs and it seems a lot of places don’t implement it very well. So far I haven’t heard many good suggestions from the developers suffering under these implementations on how to make it better though, hence my question.
The devil is in the details. The problem is the cargo cult that goes with Agile. You can take any example that works and say "this is Agile!". But in practice, what happens with Agile is that some people come with their book that they treat like a bible, and try to apply it without question.
I have had teams where we were communicating really well, but still we had a 40min standup everyday where we would basically say "as you already know, <blah>". Still we were doing standups, because the bible says we should. We could have used that time for a coffee with the team instead.
I have had teams where people were working on very different things, so nobody would listen to the others during the standup, and during the planning, it was 10 times a 1-on-1 with the team lead because nobody really cared about the tasks of the others. Everyone but the team lead was losing their time. But the team lead found it useful (obviously).
Maybe in a properly run shop it works and I have just had poor luck.
If people actually believe that, you should be MORE aware of customer needs, what the market your company exists within is doing, and why things have to be done.
It’s not great if you don’t want to have to worry about outside factors like that, but then you need to expect the many extra managerial and planning layers that will worry about those factors for you.
There are methods that work and that don't require institutionalized estimation-bullshit. For instance:
- You write a mobile app for a customer. Discuss the requirement with them, say what is "easy" and what is "much harder than they imagine" (they probably don't want that, it's orders of magnitudes more expensive than they expect). Then work hard on limiting the scope of the project with the customer and start working. Meet every 2 weeks with the customer, show the progress and get paid. Decide the next step with the customer and go for another 2 weeks. This is the closest I can imagine to the typical Agile cults, except that it doesn't involve estimation dances ("Fibonacci points or T-shirt sizes?") and all the "velocity" crap.
- You need to write bigger software than a small app. In that case, just build it slowly, and start selling it when it is ready instead of selling promises based on estimates (again: estimates are wrong). Estimates here lead to over-promising, then there is no need to design the software properly, everyone makes hacks and rushes and makes a bad job.
DDD and agile don’t like each other much at all until you’re in the implementation side of software engineering. The discovery and modeling activities are very hard to quantify so reporting tasks and progress is very difficult.
So the challenge is to get managers to be flexible in how they manage aspects of application modernization.
Agile has nothing to do with things being easy to quantify (except insofar as it is in part a response to the fact that they aren’t, generally, in software development.)
Obsession with quantification and detailed estimation is something Agile was a response against (but which has defeated Agile values even in most places that say they are “Agile”.)
DDD may be an excuse for (it does not seem to me to actually require) big upfront design, rather than the more fluid minimal units of independent value many approaches in the agile space prefer, but that’s a different issue than quantification.
live and work long enough in this industry and you’ll go through myriad of “processes” and “manifestos” and other bs all created to hire tens of thousands of incompetent people to tell 100’s of thousands of (mostly) incompetent people how they should do their work
They work in fixed-length sprints with daily standups. They assign bugs to specific people who then have to write user stories about the bugs before beginning work on them. Product features are planned out quarters in advance.
You know, Agile.
Is this a thing? I can’t imagine a build step that takes more than a couple hours for even the largest project.
I find it really funny when people complain about politics, when those people have never and will never do anything to fix the problem they're complaining about. Like complaining that it's too hot outside, but still sitting there in the heat.
And what's really funny is the only people who comment on it are the people who have no clue how it works.
What do you know? Because somebody is not in a position to change the political system, or is not able to propose a better system, does not mean that they can't see problems.
I hate the "I don't want criticism, I want solutions" idea. Identifying and acknowledging a problem is the first part of finding a solution. Those who refuse criticism are just denying the problem.
For a political system, you need to convince many people if you want it to change. You can't just "move on to solutions".
For agile in a company, in my experience the developers are not the ones bringing the processes, and they don't really have a choice. And even then, again in my experience, juniors tend to get excited about everything that looks new. So part of the team will think that estimations are a good idea in principle. Until they do it long enough to realize that the whole methodology is a big joke.
Some think Jira means agile, others think exactly the opposite, that use of Jira is an affront to agile. Some think that you don’t need requirements in agile, others think that without requirements there’s no agile.
It’s been my experience with similar threads in the past - that even the commenters weighing in on the subject will ultimately fail to agree on a common set of definitions and will end up with varying and often contradicting interpretations.
A fertile ground for a ministry err… a consulting business offering thought leadership.
My opinion is that agile needs to be agile, in that we have to adapt ways of working based on the team’s situation, what were working on, how well resourced we are … and have agility to change how we do things to optimise our work based on those constraints.
Just last week I had a client request that I create a “user story” for my access to a system so I could actually work on the project. It can get crazy out there.
And the catch-22 is that only things that “deliver value” can be user stories, only things that are user stories can easily get into backlog, and only by doing things in the backlog can a developer prove they’ve done actual work that justifies them continuing to have a job at the company.
So to get around this restriction for something that isn’t a user-facing feature, devs have to be creative and you end up with these completely insane-sounding user stories like “As a user whose data is stored in the database, I would like the database schema to be overhauled so it can support a many-to-many relationship”.
Agile fails because it gives management fine-grained control over developers’ todo lists.