1. Ability to plug and play bodies (PM, Dev, BA, offshore/outsource)
2. Having those bodies held accountable individually
3. Predictable process over progress or quality.
4. Layers of management.
Programming is a young profession. On the other hand, design and engineering and automation are old, and the giants got that way by following pcurve's list, more or less, not by inventing or implementing Agile. Therefore the higher people go in management and therefore the more abstracted they get get from the front line, the more likely they are to completely uninterested in Agile, as that's just not how big companies are run, even if it works for a ten person startup. So there's going to be a push from the top to call it whatever you want but when you interface with the exec suite you'll talk in terms of micromanaged waterfall because that's how we build jet engines here, or mining machines, or run a worldwide communications system, or whatever.
The reality is that agile is a philosophy, and there are some processes (like Scrum describes) that happen work well with it: but if you don't embrace the philosophy, the processes won't do anything.
This sounds a bit hand-wavey, but it has parallels to software itself: if you fix bugs without understanding their cause, you're doomed to keep "fixing" the same bugs over and over (since you're just fixing the symptoms). Likewise, if someone makes a feature request "I need a button here", and you just put a button where they ask without first asking "why?" and understanding the need, you end up building the wrong things and wasting everyone's time and money.
Personally, I'd say the most important things about implementing an agile process that seem to me to be the cause of many people's problems with agile are:
* Implement retrospectives, with the power granted to the team to change the process in whatever way makes sense
* Stop building systems or components, and start thinking about everything as user stories
Retrospectives are where you define YOUR agile process. When we started at my company, I think we did some fairly significant changes to our process at every retro for the few months, and often when someone new joins the team, process changes start coming up at retros again.
Building User stories is what really breaks out agile from waterfall. You still have to define the system to some degree (to have a sane architecture), but you don't have to actually build it. "As an administrator, I need to be able to create a new user" can be fully implemented before any code to edit or delete the user is written. Like most things, this is of course not black and white: if you don't define the system as a whole enough, you'll rewrite every feature over and over, or have an un-maintainable mess.
However, do it properly, and you get working (if incomplete, from a market perspective) software faster. The real benefit comes from doing the most risky things first, getting user feedback, and failing fast. You don't want to find out that the data model you built can't support the insertion speed you need and needs to be changed after you've already started to build the reporting UI.
Perhaps it should be quoted more:
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.
>Individuals and interactions over processes and tools
Which implies a few things, not least the default excuse for failed Agile-managed projects: "You did not have the right people." Well, duh. With the rightest people you can transcend any methodology. Conversely, piling on the process won't save your ass if you have the wrong people.
You have to have good people using good tools, and the wisdom to know if that's good enough.
Good luck selling that to upper management.
On the contrary, quick iterations are about reducing the risk of building the wrong thing. Of course in the normal "blaming" corporate culture this won't work, because departments are always competing over budget and deliverables that are not "perfect" will be used as ammunition against the department where the product came from.
It may work better for customer-facing products ("Market Fit" is a thing), but It may be harder to sell it for internal products ("Functional Fit"?)
This one I don't understand. Isn't it sort of the antithesis of the first core principle of the Agile manifesto? Shouldn't it be a _good_ thing that the processes are bent or ignored when appropriate.
I've seen offices with Gold stars for employees and these huge whiteboards filled with different milestones and benchmarks for projects. It looks great, but the difference is the work isn't getting finished. I feel like agile can create a smoke screen (if you're not careful) where you're too busy seeing how successfully you're on track with agile and miss the opportunities or failures that are happening in the real world to your product, instead of inside your process. You can be in great shape as far as agile goes, and still be losing customers because your work comes months too late.
To me, process should never be more important than product. I come from a graphic design background where process is very important to ensuring consistent results, but you can never fetishize the design process over the results it produces or else you end up with mediocre, commoditized design that is indistinguishable from the worst stuff coming out.
You couldn't pay me enough to deal with agile in the workplace, I feel like you'd have to toss an extra 50k on the top nd I doubt anybody would pay me an extra 50k just to deal with it, so I'll continue working with non-agile folks who manage to get stuff done, like professionals! Opportunity doesn't wait for standups, timeboxing (telling people when they are allowed to talk or not), and micromanagement.
I joined Pivotal Labs a skeptic. Now I'm a proselyte.
In my opinion, process should _always_ be bent and ignored when appropriate. This doesn't mean that you shouldn't be disciplined, or that you should ignore process. Additionally, I think that questioning the process should be encouraged. To which, the author also says:
> Team members reject Agile methodologies openly, as they do not want to be pushed out of their comfort zones.
To me, there's a fine line between rejecting something because it pushes you out of your comfort zone and rejecting something because it gets in the way of doing work. The fact that the author doesn't bring up the possibility that there are many valid reasons for rejecting methodology leads me to believe that he may himself be lumping anyone who disagrees with him into this category, which can be very dangerous. One shouldn't ignore the process just because you don't feel like it, but you also shouldn't blindly follow the process just because someone says that's the only way to stay disciplined.
But in before-mentioned cases, accepting more responsibility wasn't considered appropriate by the individuals: Why would you want to do more work under the risk of being blamed?
Command & control structures have a great advantage: Blame goes up…
A team is working in Scrum mode – all systems GO, everything looks fine – when a deadline is approaching.
To meet this deadline at all costs, management decides to gather a task force including member from various other teams, thus overriding the Scrum process.
>Team members reject Agile methodologies openly, as they do not want to be pushed out of their comfort zones.
I can't say I'd feel bad if a failed, Agile approach was not in my comfort zone.
There is no "True Scotsman" argument against Agile, IMO because there is no such thing as "true Agile". The best description I've heard of Agile is that it is the bare minimum amount of project management you can do on a project and still be successful. Beyond that, it's all about what works for each team. The entire f-ing point of Agile is that it's a generic framework you can adapt to many different business contexts.
But there are still common reasons Agile methodologies fail. I don't know how many of these are really failures of "Agile" or just common mistakes that new teams in general make. But it doesn't really matter, because the two situations are often inextricable from each other.
If Agile is so nebulous as a concept that it can't be defined (only vaguely described, at best), then perhaps it cannot fail. But it also cannot succeed, as it apparently doesn't exist.
There may be teams for whom these management methodologies work, and good for them. I am genuinely curious about how much the success or failure of these methods have been studied.
And you're right; when defined this way, Agile cannot fail. Agile isn't a magic bullet for your development team - at its core, Agile is a method by which dev teams can more or less self-organize around a set of generally agreed-upon processes. But it's up to each Agile team to develop those processes themselves.
I have yet to see an Agile team fail because their Agile process failed. I have seen Agile teams fail because the team was too inexperienced to provide their own direction. I have seen Agile teams fail because the dev lead wanted to play dictator. I've seen Agile teams fail because their business counterparts kept changing the requirements and demanding impossible things of the dev team.
I've never seen an Agile team fail because they couldn't figure out how to assign user stories or because they had no concept of release management. Sure, those things might be a disaster, but usually (after enough times going through some painful manual process) some developer steps up and says "Hey, I think I know a better way we can do this..." And those problems almost never endanger releases because Agile teams are by their very nature empowered to solve problems. Sure, the solution may have been inefficient and non-repeatable, but it worked.
I tend to find that if you line up 4 developers and ask them what agile is you'll get a minimum of 5 definitions.
And yes, I agree that the term Agile is largely meaningless at this point. Partly because nobody knows what it means, and partly because it's so ubiquitous there's no point calling it out on its own anymore.
I've had people claim that they do agile. No retrospectives or any kind of feedback loop in their processes. No modification of work tracking either. All of that customization was from the top. Basically breaking several core tenets right there... But I digress.
We really need to accept that delivering is difficult to do. Creating new teams is a _hard_ thing to do. Delivering a project on time when the team wasn't formed at the beginning and had no input into the timeline is difficult. No matter what methodology you use there are things that can kill the project.
In theory, christianity is a simple religion that strongly values charity, sacrifice for others, and selflessness. Yet when you look at people practicing christianity you see practices that go against these values. How can that be?
Agile sounds great on paper, the tough part is actually acting in a way that's truly agile, without acting in an 'agile way'.
I've encountered extreme resistance from devs who have already made their mind about Agile ("just let me write some fucking code") and fought against the leanest of agile principles ("Hey, how about we try to only plan for 2-3 weeks ahead, aim to have something demoable, and then have a retrospective to see what we could do differently next time around?" "Pass.")
Fact is, too many developers think their job is to write code. It's not. It's to solve a customer problem. And if that problem can be solved with code, great. But since 99% of the time the customer doesn't know what their problem is, doesn't know how to explain it, or will change their mind once they see it, that is why agile principles were declared - to help developers deal with this challenge.
I've noticed that in practice everyone benefits from agile except the devs... The managers have new and extremely elaborate play acting to perform, dominance to new authority to vigorously enforce, and extensive new paperwork and reports and whiteboards to shuffle. The snake oil salesmen obviously love selling snake oil. The marketing and HR folk have a new feature nobody can deny they use because nobody knows what it is, its like being "customer focused" or "empowered", it means nothing and sounds nice therefore everyone does it. Customer svc has a great excuse, well, sure you have a bug, but now we have agile so surely there will never be any bugs in the future. The customers are told things will get better because of Agile and when things invariably get better for whatever reason, it was because of the wise application of agile and their wisdom in selecting an agile supplier. But what do the actual devs get out of it? Nothing, really.
Everything that happens around a plastic christmas tree is really cool and fuzzy and happy and the best thing to ever happen and the nicest time of the year and watch us drinking cups of eggnog while you stand there as a plastic christmas tree. And that's nice ... for everyone around the christmas tree. But with some empathy for the point of view of the plastic christmas tree itself, all the foolishness related to christmas, is kinda irrelevant to itself in it's tree-i-ness. The plastic christmas tree is having a lot of things done to it and around it but it is not affected in any way.
On a good team, a manager is worth their weight in goal, and will work tirelessly to remove road blocks from devs.
The agile manifesto was written by developers for developers. But these developers were builders who liked building and solving customer problems. Not people like you who seem to think everyone in the company is useless and just gets in the way of devs who do the only real work. If that is really the only experience you know, I urge you to work hard to find a better job.
Any philosophy or process is only as good as the people attempting to practice it.
Agile is not a standard. There is no class, there are no tests, and there is no governing body to determine whether you are agile or not.
As such, it's just a marketing term around best practices in iterative and incremental development. Along with XP and the latest hotness in CI/CD/DevOps/etc, it's where you go to see how the cool kids are doing it.
Since it's "cool stuff that works most of the time in hi-tech teams", the real question here is this: are you trying new stuff? If so, are you trying stuff that seems to work for a lot of people?
If you are not, then, by definition, you are not "doing agile" (or however you want to phrase it). If you are, good for you! You still might suck, but at least you'll suck in different and interesting ways.
So in this case the writer is correct. The "No True Scotsman" label does not apply. There are no Scotsmen to begin with.
ADD: And of course the flip-side to my argument is also true. Don't get me started with the folks who think that simply because you're doing various Agile practices you should automatically be succeeding -- or the folks that think "if we were only doing Scrum the right way". I've had a lot of headaches there.
Tools exist to get work done. If the work is not getting done, use a different tool. "Agile" is simply the sign over the place in the hardware store we go to get certain kinds of tools. We understand and apply tools expertly, but we do not do work by spending all of our time and energy being focused on tools. Instead, good tools allow us to focus our time and energy on the problem.
Tell that to agile advocates who are always quick to point out that when a project using Agile fails, it's never Agile's fault, it's always because the team didn't apply Agile correctly.
It's the text book definition of "No True Scotsman".
Most Agile teams fail for reasons outside the development process. Ineffective leadership, lack of experience, poor product focus, etc. These teams would have failed with a waterfall model too; it would have just taken longer to realize it.
To be fair, it isn't often the individual developer who "falls" for it. These management methodologies are imposed on them, and the developer has to learn to roll with it. You may not be in a position to determine whether or not a project manager was sent off for "Scrum master certification".
Or maybe they have identified Agile for what it is: a snake oil methodology that's completely unproven, which sometimes works, sometimes doesn't and, regardless of the outcome is never blamed if the project fails.
Bit like a religion.
And what are the advantages? Little Joe over there in the corner can feel brave enough to speak up about his problem once a day? Seriously? Is this a process for the socially inept? Is that what we're trying to solve here? Disrupting the coding flow? Allowing the manager to be even more lazy in his contact with the team by limiting it to a few minutes a day (closer to 30 than 5)? Having it replace those couple of hours you could have spent designing your app with a few months of 16 hour bug-tracking right before release? Oh, please ... I think it's time to acknowledge the process doesn't work, that anyone can come up with hundreds of points showing why it doesn't, and that it's time to ditch this resource-wasting process altogether.
Agile is, if it is anything, a set of values for selecting what you do, not a set of things you do. And a weakness in the Agile literature is that there is a lot that talks about things you could do (and a lot of it conflicts), but there is a lot less about how you make the values of the Agile manifesto concrete in selecting and adapting what you do (while its not specifically "Agile", there's a lot written on this that is applicable in an Agile context in the Lean methods literature -- Lean and Agile are directed at largely similar values, but Lean has stronger roots in process engineering and seems to have more focus on understanding why things work and how you know that they work.)
> I think it's time to acknowledge the process doesn't work
Sure, if you don't actually do it, it doesn't work.
For example, you could say: "I've worked at over a dozen places claiming to be linux shops, but they don't have linux installed anywhere. I think it's time to acknowledge linux doesn't work."
Does this mean that agile itself is bad? No, it can and does work. It's just much harder to do correctly than it seems (eg: it takes more than reading a book, putting a Kanban board up, and having a daily "standup" meeting).
Still agile doesn't claim to be a silver bullet. It's a loose collection of ideas about how to adapt to change and communicate better during development. Its just about strategies to contain the mess. Thats it.
On my teams I've seen great benefits from some things like sprint reviews but it has not magically produced high quality code or made customers love every product. We didn't try to saddle it with that expectation though. For me its enough that it's less painful than gigantic specs that are never quite correct but more visble than everyone just winging it and it gives us some checkpoints to tweak the process regularly to improve the way we work. That's an improvement imo.
If you treat it as a religion then yes it's going to be a big disappointment. The same is true for any methodology.
Is this a common line of thought? I recently started working for a company that follows Agile and I thought it was generally accepted as the "next step" so to speak in software development. I didn't know that there was any resentment for it. Care to elaborate? Do others feel this way as well?
In reality, every "Agile" place I've worked for really uses Agile-for-name-value-only, which amounts to daily half-hour long status reports on what you did yesterday and project deadlines that come from on high that have to be ratified pro forma by the engineering team.
Yes, I know that's not true Agile. Just like the USSR wasn't true socialism! Agile can never fail, it can only be failed.
EDIT: To add:
If the success metric you're using is: From the client's perspective, do they get what they asked for, when they were promised, for the price they agreed to?
Then I've seen a majority of "Waterfall" like projects succeed. And the ones that don't typically "fail fast" in the analysis phase.
I've never seen an Agile project meet that bar. By the time they're canned they're usually already way over budget and while a team might imagine they've "delivered value" the projects are (IME) canned specifically because it became evident they would most likely be handed over to another vendor and the delivered version scrapped entirely at some point.
I also find it frustratingly comical that projects are routinely compared to assembly line work (Toyota assembly line philosophies) when they have a lot more in common with the design and development phases of car production. Agile in the small perhaps, but overall an incredibly structured process with a lot of planning and analysis. Unless you want a car launch 3 years late that costs 50% more than you promised. Nobody wants an "Agile" car (unless you've already set aside your deposit for a Tesla Model 3 I suppose ;-) ).
If I were a client, there's no way I'd ever give a anything bigger than a low six figure project to an Agile shop. For a process intended to lower risk, I've only seen it do the opposite.
agile approach brings quite a few aspects that developers like and they just feel right (or at least better), but frankly, it's overhyped. just another tool/approach to certain set of situations, in certain conditions
I work in Pivotal Labs.
I happen to be working on such a project with one of the world's largest financial firms. Across the hall from me is another team working with that company. Behind me are three teams working for a retail giant, in front two teams working for a large insurer.
In the same office I've seen everything from iphone scroller games, to startup apps, to microservice migrations, to entire product categories, being created this way.
Collectively, Pivotal Labs has helped develop thousands of products for hundreds of clients with a collective business value in the billions.
I invite you to visit any of our offices to see it for yourself. Email me: firstname.lastname@example.org and I'll set it up.
I'm not hostile to agile per se - it clearly does work. But not where I am, it's just another fad which will eventually be replaced by some other magic methodology.
There will always be resentment towards agile. There are too many botched attempts at making a methodology work from well-meaning but inept individuals that have effected lives and workplaces.
What's insane is the marketing around Agile and more specifically Scrum.
The resentment isn't resentment - it's people who have actually used something other than Agile listening to this made-up history and the catastrophizing of up-front planning, and seeing it for the nonsense it is. Agile isn't right for many or even most organizations, and it's failure doesn't seem like the problem of a good idea bungled in the wrong hands. Just very inexperienced people suckered in by good marketing into picking an inferior tool.
All that being said there are many good things about agile. It's helped bring a human focus into the industry, and introduced some decent ideas. For a fairly balanced look I'd see .
The rationalization drive implies failure needs an excuse. Sometimes Agile is the least strongly defended possible victim. Therefore Agile is bad.
Agile is complicated. The simplest components to explain are also the most trivial. Something that's only trivial is invariably foolish. Therefore Agile is bad.
"Most people" are experimenting with Agile. Half of managers / devs are below median by definition. Its a very realistic prediction that half the time, Agile will result in below median performance. Therefore Agile is bad.
Every other silver bullet for the past 50+ years has been a scam. Agile is a silver bullet. No one can explain why this silver bullet is any more likely to be real than the last couple dozen fads. Therefore Agile is bad.
Agile only seems to scale to a narrow range of team size. Things that don't scale up, or down, are stereotypically seen as bad by programmers, no matter if the stereotype is applicable or not to the situation under discussion (that's why its called a stereotype or bias). Therefore Agile is bad.
Sometimes Agile is implemented as a sub-scheme where the overarching style remains micromanagement or seagull management or simple chaos. If the cake is a lie, a thin layer of Agile flavored frosting isn't going to make the overall dish taste good. Coverups are inherently bad. Therefore Agile is bad.
Agile is impossible to define and really popular. Grok that. At least some of the bottom half of the median will simply use the word as a checkbox without ever implementing it. Essentially managers who "have no idea whats going on" will sometimes describe themselves as Agile as false advertising. Therefore Agile is bad.
Related to most of the above, the odds of finding a shop actually successfully implementing true Agile are low. Therefore statistically if an employer says they're agile that's a sign for applicants to avoid them. And that means the best people will successfully avoid agile, with all kinds of secondary effects. Therefore Agile is bad.
Probably best idea is something using kanban. Map the existing process using kanban. Find bottle necks, and fix the process. Start changing bits to it. Start using TDD, maybe user stories, maybe add "sprint" planning meetings.
You might not be implementing "true agile", but its better than complete disaster trying to enforce everything suddenly.
Also this comment he stated in the comments makes me uncomfortable.
"being uncomfortable committing to an outcome that’s time-boxed"
" sticking to a 5-to-9 mentality "
You shouldn't really being "commiting" to a time box. Its a guess, not a commitment. You use velocity to get better at the guess. If you miss, oh well lets get better at it next time by adjusting the story points in a sprint.
He makes sound like he expecting people to work overtime to meet a commitment. This is not recommended in scrum. You should have a normal work time mentality and work requirements should fit into normal hours. If you miss the "guess", you should adjust the next sprint to not include as much. If you work overtime to meet the commitment, you re-enforce the idea that it is ok to commit a overloaded amount of work to a sprint. Bad. Bad. Bad. That can be abused.
I love how this equates critical thinking and complacency.
See? I can do it too.
I think it's important that people are openly (not overly) critical of trends. It can help people make more informed decisions. The problem then lies with others trying to wade through vocal idiots masquerading as experts and legitimate information hidden in the cruft.
Otherwise painfully high number of failure points are true in the place I'm working, so a good article to show the management on the next scrum meeting (some point in the next two months) :)
Something a bit better could preserve headings, bold words etc.
Firefox's Reader Mode sometimes works, although not on this site.
Your comments have been breaking the HN guidelines by being uncivil and unsubstantive. We ban accounts that do this repeatedly. Please read the rules and post civilly and substantively, or not at all: