That's ironic since the Agile Manifesto was originally written by software developers, in 2001. The problem is that since then - as Dave Thomas put it in his "Agile is Dead (Long Live Agility)" post
"The word “agile” has been subverted to the point where it is effectively meaningless, and what passes for an agile community seems to be largely an arena for consultants and vendors to hawk services and products."
>what passes for an agile community seems to be largely an arena for consultants and vendors to hawk services and products.
Worse. I once attended an agile community meetup, and felt like I had just stumbled upon a weird cult. It's scary to think that there are so many software developers out there who have to put up with these authoritarian doctrinaires.
As a developer who has been quite unhappy in Agile environments, I don't actually think Agile is to blame, which the article alludes to.
I think the issue with Agile is that software is a field in which is difficult to measure productivity easily. Then Agile comes along and offers the appearance of making it easy to score and and measure team and individual effectiveness. Sure it's "supposed" to be for the team to measure their own effectiveness and empower people to work more productively, but for folks in management roles, the opportunity to 'score' engineers based on Agile metrics is too attractive.
Once it becomes just a way to figure out who's not moving fast enough, or "failing to meet their commitments", of course people will hate it. It gets changed from a tool into a stick.
-- Value individuals and interactions over processes and tools
-- Value working software over comprehensive documentation
-- Value customer collaboration over contract negotiation
-- Value responding to change over following a plan
That doesn't sound like "agile" anywhere I've seen it implemented. The issue is that you need real buy-in from all levels of the company for any process. I've always said that a "bad" process executed consistency and with real buy-in will outperform any "good" process with only lip service commitment.
As a developer become engineering manager become director of product, I agree with you wholeheartedly.
But I think the bigger problem is that often developers and management (at all levels) give very little thought into "delivering value" and a lot of thought into "doing whatever they want".
I can't fault individuals (workers, management, or executives) for trying to do what's best for their careers rather than what's best for the company. As a manager, I think management's primary objectives are to set up their reports for success and to figure out how to align their reports' incentives with the company's incentives in the best possible way.
Management, I have seen, often does a terrible job 1) actually knowing what "value" is, 2) figuring out how to measure that they're actually delivering value, and 3) figuring out how to align delivering value with the worker's own incentives.
If you can't do these things, you have NO chance to do agile effectively. It's easy to go through the motions of Agile, but you will gain nothing if you can't define and measure value (and hardly any companies can -- it's not easy!)
But as you pointed out, even if you can accomplish the prerequisites, it's still INCREDIBLY difficult to attribute an engineer to value. You can execute effectively, but be on a project that turned out to be useless. Making the button green might be easy, but because of previous technical debt, making it blue might be really hard, etc...
I worked in fake agile for a few years. It took me a while to place my finger on why I never really loved everything about it, but I eventually decided that it felt like it was a façade to a management power grab. It gave the ability to micro manage workers to those who don’t understand the problems or even the product. If agile is necessary to be productive then you already have too many people involved. If it isn’t necessary then it introduces a lot of overhead for a little bit of book keeping (which isn’t inherently bad).
I was in a company that did Agile well (my first time using it). Team velocity was never used to measure the output of the team, only to better predict how much work we could fit in a sprint. The other big think was that they saw Agile as a framework, each team was free to do a different "implementation" and use different tools. Team velociyy had different units in different team and couldn't be compared.
> for folks in management roles, the opportunity to 'score' engineers based on Agile metrics is too attractive.
One nice thing about this is that the metric is visible. Then you can optimise your performance against it. Is this necessarily productive, or in the real interests of the company? Maybe, maybe not. But I look at this as a kind of a favour: if your boss is complaining "velocity is too low" well, at least you know what you're being measured by. Put some extra points on those stories. Undercommit. Make your boss happy and get them off your back. You'll be doing the same work either way.
But IMO agile is not at all about measuring productivity, I'm not sure how you'd come to that conclusion?
There is, I admit, an element of it in the sprint planning, but that is only meant to be a tool to figure out how much work can be put into the next sprint. Agile does not care what your absolute value of velocity is.
If however, some misinformed PM is obsessing over velocity then I think that is a very different issues and not really related to the essence of agile.
This is absolutely correct. For example, what is the point of a sprint in Agile ? Do what one can finish in a sprint but try and finish "modules" while maintaining quality and carry over rest to next sprint. What does management read? Finish ... modules ... current sprint?
I do think that "Agile" is to blame. In my view the Agile software methodology is like Communism or libertarianism. Whenever you point out the myriad ways that it can fail in practice, someone always jumps out to say, "Well, what you're not describing is not true Agile. True Agile has never been tried!"
You've hit the nail squarely on the head. The problem with Agile isn't Agile itself, but the fact that humans can't keep themselves from using the data it produces to their own non-Agile ends.
We moved to Kanban a few years ago and I think it's been much nicer than the "sprints" we used to do.
There is a board. The board has a prioritized list of things to do. You work on your thing until it is done. Then you pick your next task based on where the priorities currently sit.
It's really not far off from the "sprint" idea. The main difference is it is a constant re-balancing rather than an every X weeks affair.
Here's what's interesting... of all the people screaming about how much they hate "Agile", pretty much none of them are proposing any alternative. And if they did propose an alternative, how much you do you want to bet that it would look an awful lot like ... wait for it ... the Agile Manifesto?
It's been said before, even in this thread, but "Agile" as it's practiced today is not the "agile" of the Agile Manifesto. The problem is ignorant managers and consultants who don't actually know anything about how software is developed, want a buzzword to slap on to what they're doing to CYA, and will do stupid shit no matter what it winds up being called.
The problem is that the "agile" of the Agile Manifesto is underspecified to the point of uselessness. I'll quote the Manifesto in full:
We are uncovering better ways of developing software by doing it
and helping others do it. Through this work, we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value
the items on the left more.
That's it. That's all the manifesto gives us. In a real sense, any methodology at all is "not agile", since agile values individuals and interactions over processes and tools. But while that might work for a small team, it's a recipe for disaster in any kind of larger organization.
The entire category of ideas that agile occupies is utter bullshit, and the alternative to bullshit is just common sense. Hire good people, give clear instructions, and leave them alone. The problem with common sense is that you can't make six figures peddling it for a living.
* Committing to dates and then being accountable for the results
* Spending time planning, rather than "doing"
* Admitting to business leaders that much of their work time is not spent writing lines of code, but dallying in all the interesting byways of the field, favorite websites, pet projects, and random semi-related technology interests
* Sitting in meetings of any sort (sprint planner and retrospective)
* Having spoken, out-loud disagreements and negotiations in order to arrive at a consensus (sprint point estimations)
* Having their mistakes, miscalculations, lack of planning visible to everyone on a big monitor (sprint board / retro)
* Getting out of their chairs to go talk to someone else in order to remove a blocker or understand a dependency (task estimation and completion by end-of-sprint)
* Anyone involved in the process that isn't a coder (Scrum Master, Project Manager)
- Loosely estimating dates, then having management set them in stone
- Spending more time talking about things than it would take to do them ("planning")
- convincing business leaders that engineering is more than just writing code
- sitting in meetings that add little value to the team
- arguing over made up numbers for vague deliverables
- having their mistakes, miscalculations, and other normal aspects of software development enumerated and held against them, as though it was an actual problem
- having "scrum masters" come up with straw men to justify even more process
- reporting to too many non-technical managers
The last point sums most of it up though. In many orgs, Agile is used as an attempt to compensate for lack of technical leadership, as though process can obviate the need. You need some, most, or all of your management and executive team to have technical foundations, depending on how technical your product is. You wouldn't put a football coach in charge of a coal mining operation (forgive the hyperbole). The same principle applies to software.
* Committing to dates and then being accountable for the results
* Spending time planning, rather than "doing"
* Admitting to business leaders that much of their work time is not spent chiselling wood, but dallying in all the interesting byways of the ...
* Sitting in meetings of any sort
* Having spoken, out-loud disagreements and negotiations in order to arrive at a consensus
* Having their mistakes, miscalculations, lack of planning visible to everyone on a big monitor
* Getting out of their chairs to go talk to someone else in order to remove a blocker or understand a dependency (task estimation and completion by end-of-sprint)
* Anyone involved in the process that isn't a tradesman
Software developers, like everyone else, hate bad managers.
Good managers don't do "agile". They just manage. They may use techniques that fall under the umbrella of "agile", but in reality, they just do what the situation calls for.
Bad managers followed a course about the latest trendy methodology and pick only the parts that that can be directly applied, ignoring the context completely.
Books describing a process do it on an idealized case. It is like everything is perfect except for the well defined problems that need solving. But "by the book" situation is extremely rare. When it happens, it is the mythical "$methodology done right". In practice managers have to mix and match techniques for a real life situation, where nothing is perfect, but nothing is hopelessly terrible either.
I dislike Agile, but let's not operate under the assumption that removing or changing the process is going to stop "the business" from wanting more features, faster. There is no process that will make that go away.
Agile Fails for the following reasons.
1) In reality, most stories/tasks that make it out of the backlog and into sprints are the ones that were inserted by PM's, that support the short term goals placed on the PM. End result, massive technical debt in short order. Even if developers express the 'need' for refactoring, it gets delayed as the PM doesn't get fired for a messy code base, but gets fired for a late deadline.
2) Companies 'turned' to "SCRUM" and imagined/expected that by renaming meetings to "stand-ups" etc.. their productivity would increase significantly. This usually resulted in management blaming their engineering staff for their own follies.
3) Most Biz environments don't lend to a 'perfect' scrum model, as such, many organizations try to 'shoe-horn' practices in situations where it doesn't make sense. For example, an organization may not have the ability to adjust features or timelines, resulting in stories being a convenient way to blame engineers for poor decisions outside of their control (Sales selling products that don't exist and promising it yesterday, or Product demanding features that are unrealistic, etc..).
4) Another buzz word that has little functional value other than to help 'experts' get promotions, who in practice are nothing but glorified PM's with a pinch of snake-oil salesmanship.
Agile Fails for the following reasons. 1) In reality, most stories/tasks that make it out of the backlog are executed on, ones that were inserted by PM's, that support the short term goals presented to the PM.
This is a classic example of the problem we're fighting here. Agile is not a methodology and it does not mandate use of stories, a backlog, scrums, etc. Those things are artifacts of one particular methodology which purports to be an exemplar of "Agile" -- that being Scrum.
I really feel like most people saying "I hate Agile" really mean "I hate Scrum".
Agile is like HR - everyone thinks it's supposed to benefit the developer/employee. It's not. It exists to benefit the company.
Agile was created so that consultants could provide better estimates to their clients in a field that was incredibly new, at a time when methods of evaluation were based on things like construction (think Gantt charts).
Its primary focus is on communication and setting expectations, which is critical when dealing with non-technical stakeholders that think everything should take a few hours. Everything beyond that is a bunch of bullshittery to sell books, conferences, keynotes, courses and certificates.
My favorite response when Product Managers bring up that business needs to know when a feature will be done is "And I would like to know Apple's stock price in 6 months."
I really believe this accurately communicates how difficult it is to estimate software development timelines. You can't estimate unknown work, and unless you're building wordpress blogs, your work in software is unknown.
The idea referenced in the blog post that sprints are "rushing" developers is just nonsense. At least in every sprint process I've been a part of, the developers are the ones assigning effort (points/hours) to each task. The dev team is free to decide how much padding any task deserves to get the job done right -- and some padding is totally legit and expected.
If you have a large task, one that's either too complex to estimate accurately or with too many unknowns or outside dependencies, you should be breaking it up into smaller tasks.
Developers decide how many points they can do in a sprint, AND they decide how many points each task gets. There's no rushing involved here.
Except maybe for the point that humans are notoriously bad at estimating creative work and biased in the shorter side... So taking estimations as commitment is indeed a way to short-hand the one estimating. Thus the rush when you realise your naturally optimistic estimate became a deadline.
I've had one great experience working in an "Agile" team using the Extreme Programming method. I have fond memories of pair programming, starting work by writing tests with the business analysts, and focus on principles : DRY, YAGNI, no hesitation to refactor what needs to be. The driving forces were those principles. My other experiences with SCRUM, on the other hand have either been deeply dysfunctional, or just plain devolving into churning tickets. The driving force were metrics, velocity, charts.
I agree with one of the conclusions of that article (but not the title) : Agile has been taken over by SCRUM, for most people now Agile = SCRUM. However SCRUM is so successful precisely because it fits into the existing hierarchical structures, it gives the impression of control to managers who don't understand what software development is about, and it avoids having to profundly question corporate organization. It's at its core a management technique. If all implementations of SCRUM get it wrong, then SCRUM itself must be wrong.
I think an alterative way of doing things would be to create small teams that incorporate both programmers and business people, without product owner or project managers or hierarchy. The work would be focused on one specific project and driven by principles of craftsmanship. I've yet to try this idea in the real world...
The missing ingredient in 99.9999% of "Agile" shops is developers having hand in the relationship.
That's it. I realized a few weeks ago that I've been lucky to almost always work under other engineers, nearly my whole career. Magically I become a thousand times more persuasive and articulate! (I didn't, I just have an audience with better priors).
One developer-stakeholder relationship to keep in mind is Google-consumer. When was the last time Google had to endure a call from you asking about "velocity?" ...never. And this is because Google has a zillion dollars and will continue on merrily if you die tomorrow. (Yes, Google has meme problems like killing own products, releasing too many things, etc. The point is that you are not an active impediment to their development cycle)
The best way to Do Agile is to have engineers hold >50% voting stock in the company, and for the company to be in a position that it can say FU to any particular client.
Actual agile is not rocket science, nor is it magic---you still have to make tradeoffs, test with users, etc. It's just that you're doing those things from an informed point of view, compared to the alternative where decisionmaking power rests with those incompetent to wield it.
There is of course more to business than engineering. You also want >50% of the voting shares to be able to read an income statement, (and, in small-enough businesses, to understand the value-add of accounting at all!) and whatever metrics keep the lights on (CAC, etc). Yes, to effectively manage complex businesses turns out to be complex!
Devs LOVE Agile, the ideas behind Agile and the agility itself.
What devs hate is cargo cults. When management slaps "agile" sticker on your team while having no clue what Agile is about, it's called deception, misrepresentation, misinformation, and exactly what people usually "hate".
You direct your disappointment towards wrongly placed label, not Agile. Hate your incompetent management instead.
I agree with this sentiment. As the author said, agile was invented by programmers for programmers but somewhere along the way the army of scrum-certified project managers hijacked it and turned it into something we (or at least I) despise.
The worst part of it: the box-checking. The incessant, never-ending, "was this and this and this and this and this ceremony done", all of which provided no value to the product.
I think you captured my post better, so I'm just doing it as a reply:
---
"Agile" is like "xml" (or JSON.) Just following a process, or using a technology, doesn't mean you'll do it right. I'm sure plenty of us have come across hair-brained xml, or JSON, that looks like it was designed by a moron.
The same can be said for "Agile." Just because a group tries to follow it, doesn't mean that they follow it correctly or manage themselves the best way.
I'd also like to point out: All of the quote in the article could equally apply to waterfall, or any other software management model.
One of the problems with "agile" is that no one has a clear idea of what Agile is. Day-to-day, what does an "agile" team do? As a dev, I've encountered many software development methodologies that lay claim to the term "agile". I've hated every single one of them. At what point do I get to say, "Actually, no, it's the idea that's the problem not the implementations"
I hate agile. And I'm a dev. This is not a matter of hating the wrong thing or not knowing what agile is.
I literally hate agile, i think the definition of agile is loaded.
I propose a new form of project management called "Relativity." The definition of relativity based project management is effectiveness. If something is not effective don't do it, if something is effective do it. Wait aren't devs doing this anyway? Is putting a fancy word on top of this obvious concept pure BS? Is this what agile is doing? No it can't be BS. Not when people can take a class for it. Once a class is made for "Relativity based project management" you know it's no longer BS.
There was a big push for Agile in my old group at Microsoft (no names here).
It was basically micromanagement. I saw hours-long, daily meetings by PMs and managers who were digging into the "velocity" of individual developers. They would still add and remove work mid-sprint, and generally treated estimates hard commitments rather than, well, estimates. You'd get a talkin' to if they thought you were behind.
Mgt: "We need that Frobicle system done in a week."
Me: "What. This is mid-sprint. You're changing things up? And what the heck is Frobicle?"
Mgt: "Don't care. Our estimate is a week, go do it."
Me: "Repeat: What is a Frobicle? Is there a spec? Someone I can talk to? What color is it? Is it animal, vegetable or mineral?"
Mgt: "A week."
Our mandated daily stand-up was actually just a PM getting the team together in a hallway while he polled us and wrote down our status, grist for those aforesaid meetings. I got our PM to say, "Time for status" instead of "Time for standup" because the meeting was useless to our team. Eventually I just stopped going, and a few other developers did, too. We were doing our own scrums, informally and as we needed them.
Naturally there was still crunch time. I'm actually okay with that, as long as management doesn't try to deny that crunch time is happening, and limits the damage to people and the organization, and doesn't do it continuously. A bit of crunch every six months to a year is fine, while a crunch at the end of every sprint is NOT, and that's where things were headed about the time I left.
Agile is fine if it is an organic, bottom-up process. And as any of the founding Agile gurus like to profess, this was the original intention.
The problem is that it is usually implemented as a centralized, top-down imposition by management. The net result is usually just a tax on productivity to ever more process, paperwork, status updates, and meetings.
> Some of the most frequently-mentioned problems with Agile are: Agile ignores technical debt;
This isn't a problem with Agile. This is a problem with the management in your organization. I worked at an org that implemented Agile into 5 sprints. Sprints 1-4 were focused on the business work - things that deliver value to the organization. Sprint 5 was an "IT" sprint, where the developers owned the priorities and had time to fix things like technical debt. This worked pretty well.
> frameworks like Scrum are just “red tape,
Yes, companies need their people to operate in a predictable way. This isn't the wild west - you need to be accountable to the people you report to. These "red tape" processes are just regular checkpoints with various people in the org to make sure everyone is on the same page.
Waterfall had this too, except the checkpoints were every 1 - 3 months.
I think the bigger problem is that some software developers don't want to be accountable to people. They just want to do their own thing, like Joel Spolsky recommends with his staff at StackOverflow. It can work great, in the right environment. But the vast majority of companies do not operate this way.
> programmers are asked to commit to arbitrary estimates and deadlines
This has been as old as software itself. I've been on a waterfall project which had "things that needed to be done" and those things had zero detail in them. Yet I was asked to come up with a "ballpark estimate" by my PM. When I had zero idea what it was about, who it would interact with, etc.
> never get the time to think thoroughly about the features they’re creating.
So add a Spike and give it a two week estimate so you have the time to do whatever thinking / analysis you need to do to come up with a solid plan. Spikes exist for a reason - not everything on the backlog needs to be a feature.
Devs are such a special kind of people that you should just leave them alone? #sarcasm
I for one like where we are heading with things like Event Storming/Modeling. I admit I care more about solutions than spending time on perfectly describing a problem. Stop the navel gazing. IMHO. Agile tries to solve the Big Issue. Communication.
[+] [-] mirkonasato|6 years ago|reply
"The word “agile” has been subverted to the point where it is effectively meaningless, and what passes for an agile community seems to be largely an arena for consultants and vendors to hawk services and products."
(https://pragdave.me/blog/2014/03/04/time-to-kill-agile.html)
[+] [-] morningseagulls|6 years ago|reply
Worse. I once attended an agile community meetup, and felt like I had just stumbled upon a weird cult. It's scary to think that there are so many software developers out there who have to put up with these authoritarian doctrinaires.
[+] [-] jamestimmins|6 years ago|reply
I think the issue with Agile is that software is a field in which is difficult to measure productivity easily. Then Agile comes along and offers the appearance of making it easy to score and and measure team and individual effectiveness. Sure it's "supposed" to be for the team to measure their own effectiveness and empower people to work more productively, but for folks in management roles, the opportunity to 'score' engineers based on Agile metrics is too attractive.
Once it becomes just a way to figure out who's not moving fast enough, or "failing to meet their commitments", of course people will hate it. It gets changed from a tool into a stick.
[+] [-] snarf21|6 years ago|reply
[+] [-] onlyrealcuzzo|6 years ago|reply
But I think the bigger problem is that often developers and management (at all levels) give very little thought into "delivering value" and a lot of thought into "doing whatever they want".
I can't fault individuals (workers, management, or executives) for trying to do what's best for their careers rather than what's best for the company. As a manager, I think management's primary objectives are to set up their reports for success and to figure out how to align their reports' incentives with the company's incentives in the best possible way.
Management, I have seen, often does a terrible job 1) actually knowing what "value" is, 2) figuring out how to measure that they're actually delivering value, and 3) figuring out how to align delivering value with the worker's own incentives.
If you can't do these things, you have NO chance to do agile effectively. It's easy to go through the motions of Agile, but you will gain nothing if you can't define and measure value (and hardly any companies can -- it's not easy!)
But as you pointed out, even if you can accomplish the prerequisites, it's still INCREDIBLY difficult to attribute an engineer to value. You can execute effectively, but be on a project that turned out to be useless. Making the button green might be easy, but because of previous technical debt, making it blue might be really hard, etc...
[+] [-] willis936|6 years ago|reply
[+] [-] ravenstine|6 years ago|reply
[+] [-] jusob|6 years ago|reply
[+] [-] vosper|6 years ago|reply
One nice thing about this is that the metric is visible. Then you can optimise your performance against it. Is this necessarily productive, or in the real interests of the company? Maybe, maybe not. But I look at this as a kind of a favour: if your boss is complaining "velocity is too low" well, at least you know what you're being measured by. Put some extra points on those stories. Undercommit. Make your boss happy and get them off your back. You'll be doing the same work either way.
[+] [-] wdfx|6 years ago|reply
There is, I admit, an element of it in the sprint planning, but that is only meant to be a tool to figure out how much work can be put into the next sprint. Agile does not care what your absolute value of velocity is.
If however, some misinformed PM is obsessing over velocity then I think that is a very different issues and not really related to the essence of agile.
[+] [-] darkstar_16|6 years ago|reply
[+] [-] quanticle|6 years ago|reply
[+] [-] RankingMember|6 years ago|reply
[+] [-] war1025|6 years ago|reply
There is a board. The board has a prioritized list of things to do. You work on your thing until it is done. Then you pick your next task based on where the priorities currently sit.
It's really not far off from the "sprint" idea. The main difference is it is a constant re-balancing rather than an every X weeks affair.
[+] [-] mindcrime|6 years ago|reply
It's been said before, even in this thread, but "Agile" as it's practiced today is not the "agile" of the Agile Manifesto. The problem is ignorant managers and consultants who don't actually know anything about how software is developed, want a buzzword to slap on to what they're doing to CYA, and will do stupid shit no matter what it winds up being called.
[+] [-] quanticle|6 years ago|reply
[+] [-] brianwawok|6 years ago|reply
[+] [-] tboyd47|6 years ago|reply
[+] [-] dustinmoris|6 years ago|reply
Here's the true Agile Manifesto:
1. Sack all your product owners and scrum masters, because they are useless and a waste of the salaries which they get paid.
2. Reduce a development team so it's no more than 5 people.
3. Give them god admin access to everything they need to run the show (cloud, CI, dev tools, etc.).
4. Tell them what you need
5. Get out of their way until it's done.
[+] [-] watwut|6 years ago|reply
It is not management manual nor specific.
[+] [-] all_usernames|6 years ago|reply
* Committing to dates and then being accountable for the results
* Spending time planning, rather than "doing"
* Admitting to business leaders that much of their work time is not spent writing lines of code, but dallying in all the interesting byways of the field, favorite websites, pet projects, and random semi-related technology interests
* Sitting in meetings of any sort (sprint planner and retrospective)
* Having spoken, out-loud disagreements and negotiations in order to arrive at a consensus (sprint point estimations)
* Having their mistakes, miscalculations, lack of planning visible to everyone on a big monitor (sprint board / retro)
* Getting out of their chairs to go talk to someone else in order to remove a blocker or understand a dependency (task estimation and completion by end-of-sprint)
* Anyone involved in the process that isn't a coder (Scrum Master, Project Manager)
[+] [-] cloverich|6 years ago|reply
- Loosely estimating dates, then having management set them in stone
- Spending more time talking about things than it would take to do them ("planning")
- convincing business leaders that engineering is more than just writing code
- sitting in meetings that add little value to the team
- arguing over made up numbers for vague deliverables
- having their mistakes, miscalculations, and other normal aspects of software development enumerated and held against them, as though it was an actual problem
- having "scrum masters" come up with straw men to justify even more process
- reporting to too many non-technical managers
The last point sums most of it up though. In many orgs, Agile is used as an attempt to compensate for lack of technical leadership, as though process can obviate the need. You need some, most, or all of your management and executive team to have technical foundations, depending on how technical your product is. You wouldn't put a football coach in charge of a coal mining operation (forgive the hyperbole). The same principle applies to software.
[+] [-] supercanuck|6 years ago|reply
Carpenters don't like:
* Committing to dates and then being accountable for the results
* Spending time planning, rather than "doing"
* Admitting to business leaders that much of their work time is not spent chiselling wood, but dallying in all the interesting byways of the ...
* Sitting in meetings of any sort
* Having spoken, out-loud disagreements and negotiations in order to arrive at a consensus
* Having their mistakes, miscalculations, lack of planning visible to everyone on a big monitor
* Getting out of their chairs to go talk to someone else in order to remove a blocker or understand a dependency (task estimation and completion by end-of-sprint)
* Anyone involved in the process that isn't a tradesman
[+] [-] GuB-42|6 years ago|reply
Good managers don't do "agile". They just manage. They may use techniques that fall under the umbrella of "agile", but in reality, they just do what the situation calls for.
Bad managers followed a course about the latest trendy methodology and pick only the parts that that can be directly applied, ignoring the context completely.
Books describing a process do it on an idealized case. It is like everything is perfect except for the well defined problems that need solving. But "by the book" situation is extremely rare. When it happens, it is the mythical "$methodology done right". In practice managers have to mix and match techniques for a real life situation, where nothing is perfect, but nothing is hopelessly terrible either.
[+] [-] MikeTaylor|6 years ago|reply
[+] [-] zippergz|6 years ago|reply
[+] [-] arwhatever|6 years ago|reply
[+] [-] digitbuster|6 years ago|reply
[+] [-] mindcrime|6 years ago|reply
This is a classic example of the problem we're fighting here. Agile is not a methodology and it does not mandate use of stories, a backlog, scrums, etc. Those things are artifacts of one particular methodology which purports to be an exemplar of "Agile" -- that being Scrum.
I really feel like most people saying "I hate Agile" really mean "I hate Scrum".
[+] [-] tomnipotent|6 years ago|reply
Agile was created so that consultants could provide better estimates to their clients in a field that was incredibly new, at a time when methods of evaluation were based on things like construction (think Gantt charts).
Its primary focus is on communication and setting expectations, which is critical when dealing with non-technical stakeholders that think everything should take a few hours. Everything beyond that is a bunch of bullshittery to sell books, conferences, keynotes, courses and certificates.
Search for the word "consultant" or "client":
https://agilemanifesto.org/authors.html
[+] [-] ngngngng|6 years ago|reply
I really believe this accurately communicates how difficult it is to estimate software development timelines. You can't estimate unknown work, and unless you're building wordpress blogs, your work in software is unknown.
[+] [-] DHPersonal|6 years ago|reply
[+] [-] all_usernames|6 years ago|reply
If you have a large task, one that's either too complex to estimate accurately or with too many unknowns or outside dependencies, you should be breaking it up into smaller tasks.
Developers decide how many points they can do in a sprint, AND they decide how many points each task gets. There's no rushing involved here.
[+] [-] alexis2b|6 years ago|reply
[+] [-] ajnin|6 years ago|reply
I agree with one of the conclusions of that article (but not the title) : Agile has been taken over by SCRUM, for most people now Agile = SCRUM. However SCRUM is so successful precisely because it fits into the existing hierarchical structures, it gives the impression of control to managers who don't understand what software development is about, and it avoids having to profundly question corporate organization. It's at its core a management technique. If all implementations of SCRUM get it wrong, then SCRUM itself must be wrong.
I think an alterative way of doing things would be to create small teams that incorporate both programmers and business people, without product owner or project managers or hierarchy. The work would be focused on one specific project and driven by principles of craftsmanship. I've yet to try this idea in the real world...
[+] [-] invalidOrTaken|6 years ago|reply
That's it. I realized a few weeks ago that I've been lucky to almost always work under other engineers, nearly my whole career. Magically I become a thousand times more persuasive and articulate! (I didn't, I just have an audience with better priors).
One developer-stakeholder relationship to keep in mind is Google-consumer. When was the last time Google had to endure a call from you asking about "velocity?" ...never. And this is because Google has a zillion dollars and will continue on merrily if you die tomorrow. (Yes, Google has meme problems like killing own products, releasing too many things, etc. The point is that you are not an active impediment to their development cycle)
The best way to Do Agile is to have engineers hold >50% voting stock in the company, and for the company to be in a position that it can say FU to any particular client.
Actual agile is not rocket science, nor is it magic---you still have to make tradeoffs, test with users, etc. It's just that you're doing those things from an informed point of view, compared to the alternative where decisionmaking power rests with those incompetent to wield it.
There is of course more to business than engineering. You also want >50% of the voting shares to be able to read an income statement, (and, in small-enough businesses, to understand the value-add of accounting at all!) and whatever metrics keep the lights on (CAC, etc). Yes, to effectively manage complex businesses turns out to be complex!
[+] [-] rinchik|6 years ago|reply
What devs hate is cargo cults. When management slaps "agile" sticker on your team while having no clue what Agile is about, it's called deception, misrepresentation, misinformation, and exactly what people usually "hate".
You direct your disappointment towards wrongly placed label, not Agile. Hate your incompetent management instead.
[+] [-] brodouevencode|6 years ago|reply
The worst part of it: the box-checking. The incessant, never-ending, "was this and this and this and this and this ceremony done", all of which provided no value to the product.
[+] [-] gwbas1c|6 years ago|reply
---
"Agile" is like "xml" (or JSON.) Just following a process, or using a technology, doesn't mean you'll do it right. I'm sure plenty of us have come across hair-brained xml, or JSON, that looks like it was designed by a moron.
The same can be said for "Agile." Just because a group tries to follow it, doesn't mean that they follow it correctly or manage themselves the best way.
I'd also like to point out: All of the quote in the article could equally apply to waterfall, or any other software management model.
[+] [-] brianwawok|6 years ago|reply
I am neutral to slight dislike towards it. If I see someone talking about it, it usually means it is the kind of place I don't want to work.
[+] [-] quanticle|6 years ago|reply
[+] [-] crimsonalucard|6 years ago|reply
I literally hate agile, i think the definition of agile is loaded.
I propose a new form of project management called "Relativity." The definition of relativity based project management is effectiveness. If something is not effective don't do it, if something is effective do it. Wait aren't devs doing this anyway? Is putting a fancy word on top of this obvious concept pure BS? Is this what agile is doing? No it can't be BS. Not when people can take a class for it. Once a class is made for "Relativity based project management" you know it's no longer BS.
[+] [-] kabdib|6 years ago|reply
It was basically micromanagement. I saw hours-long, daily meetings by PMs and managers who were digging into the "velocity" of individual developers. They would still add and remove work mid-sprint, and generally treated estimates hard commitments rather than, well, estimates. You'd get a talkin' to if they thought you were behind.
Mgt: "We need that Frobicle system done in a week."
Me: "What. This is mid-sprint. You're changing things up? And what the heck is Frobicle?"
Mgt: "Don't care. Our estimate is a week, go do it."
Me: "Repeat: What is a Frobicle? Is there a spec? Someone I can talk to? What color is it? Is it animal, vegetable or mineral?"
Mgt: "A week."
Our mandated daily stand-up was actually just a PM getting the team together in a hallway while he polled us and wrote down our status, grist for those aforesaid meetings. I got our PM to say, "Time for status" instead of "Time for standup" because the meeting was useless to our team. Eventually I just stopped going, and a few other developers did, too. We were doing our own scrums, informally and as we needed them.
Naturally there was still crunch time. I'm actually okay with that, as long as management doesn't try to deny that crunch time is happening, and limits the damage to people and the organization, and doesn't do it continuously. A bit of crunch every six months to a year is fine, while a crunch at the end of every sprint is NOT, and that's where things were headed about the time I left.
Agile brings out the worst in management.
[+] [-] thrower123|6 years ago|reply
The problem is that it is usually implemented as a centralized, top-down imposition by management. The net result is usually just a tax on productivity to ever more process, paperwork, status updates, and meetings.
[+] [-] SamuelAdams|6 years ago|reply
This isn't a problem with Agile. This is a problem with the management in your organization. I worked at an org that implemented Agile into 5 sprints. Sprints 1-4 were focused on the business work - things that deliver value to the organization. Sprint 5 was an "IT" sprint, where the developers owned the priorities and had time to fix things like technical debt. This worked pretty well.
> frameworks like Scrum are just “red tape,
Yes, companies need their people to operate in a predictable way. This isn't the wild west - you need to be accountable to the people you report to. These "red tape" processes are just regular checkpoints with various people in the org to make sure everyone is on the same page.
Waterfall had this too, except the checkpoints were every 1 - 3 months.
I think the bigger problem is that some software developers don't want to be accountable to people. They just want to do their own thing, like Joel Spolsky recommends with his staff at StackOverflow. It can work great, in the right environment. But the vast majority of companies do not operate this way.
> programmers are asked to commit to arbitrary estimates and deadlines
This has been as old as software itself. I've been on a waterfall project which had "things that needed to be done" and those things had zero detail in them. Yet I was asked to come up with a "ballpark estimate" by my PM. When I had zero idea what it was about, who it would interact with, etc.
> never get the time to think thoroughly about the features they’re creating.
So add a Spike and give it a two week estimate so you have the time to do whatever thinking / analysis you need to do to come up with a solid plan. Spikes exist for a reason - not everything on the backlog needs to be a feature.
[+] [-] jwildeboer|6 years ago|reply
I for one like where we are heading with things like Event Storming/Modeling. I admit I care more about solutions than spending time on perfectly describing a problem. Stop the navel gazing. IMHO. Agile tries to solve the Big Issue. Communication.