In one of my previous projects I lead a team of 5 talented and creative people and we did truly agile programming: everyone helped each other, asynchronous meets as needed, spontaneous pair programming, direct access to the customer (who also happened to be technical people with a clear picture in mind)... Truly a joy of a team to lead, because they really lead themselves :)
However, the management insisted that we adopt Scrum and get a Scrum Master to help us.
I objected to this and listed all of the problems I could see if Scrum was introduced: losing dev creativity and incentive, tickets taking exactly one sprint to complete instead of doing them at leisurely pace, the mistranslation coming from having one extra layer of communication (Scrum Master handling the client now).
The management response was: "that is not real Scrum, you had bad experiences because you weren't doing it right previously".
After three months, the progress slowed to a crawl, star dev abandoned ship, and customers started complaining for the first time.
Now I will just wait for someone to tell me that this wasn't real Scrum either, because we were supposed to have Product Owner talk to the client instead of Scrum Master :)
The best I can say of scrum is that it's designed to get some amount of output from an otherwise extremely dysfunctional team. If your teams were achieving nothing, it provides a modicum of accountability. So there's places where yes, scrum is an improvement.
But yes, a team of people that understand the business, and can prioritize well without needing someone to do it all for them, scrum just slows the team down. I've seen it happen multiple times in my career, and sometimes succeeded at either undoing the change, or making the jira-based work basically fictional.
> I objected to this and listed all of the problems I could see if Scrum was introduced: losing dev creativity and incentive, tickets taking exactly one sprint to complete instead of doing them at leisurely pace, the mistranslation coming from having one extra layer of communication (Scrum Master handling the client now).
And that was your big mistake. Those are real concerns, but those things are abstract and non-quantifiable. The proper way to fight scrum is to measure the time it takes to perform the scrum 'ceremonies'. It's rarely less than 30% of the total work time in a sprint. 50% seems to be very common.
In my experience even the dumbest and thick-headed management can understand that. I've always imagined if it didn't I could ask to hire more people to compensate for the time lost, but I never had to resort to that.
Granted, you still end up with a mutilated scrum at the end. But if you mutilate it right, you can fit your pre-scrum work process into the terminology of a mutilated scrum.
Ugh, swapping out a successful development paradigm midstream sounds like somebody up the chain thinks change is the same thing as progress.
In situations like this, one strategy I have used (not for Scrum, but for people who want to tinker with shit for the sake of tinkering) is to say: "Great, we welcome experimentation, this is really cool. What will we measure to decide whether this change is improving our process, and how long will the initial round of experiments last?"
Because: this frames it as something we are trying together rather than something they are dictating, but also something that is not necessarily permanent, which can be changed in the future (including changed back to the way it was), and which is oriented around measurable improvement rather than arbitrary whims. Almost nobody is willing to be the guy who says "we'll do it my way because I said so, even if it makes everything worse", and if they are, that in itself gives you some valuable information about your manager or leadership team.
My most informative experience was had at this huge auction company that I was doing frontend on. At one point, I was working on what we'd now call a component, but was at that time manually created dom elements generated with a very long series of logic branches that depended on a number of external, possibly async conditions. It was extremely hard and time consuming to test and keep all of the possible conditions loaded into my consciousness with all of the chatter in the surrounding space and some fuckhead making sales calls on his phone and typing on his mechanical keyboard—because y'know, everyone's gotta be in the same room—meanwhile the product owner would come over to add new requirements while I was trying to focus and then the scrum master would come over to ask why I wasn't done yet. This went on until my productivity and motivation ground to a halt, I burnt out, got depressed, and got fired. However, when I started at the company, it was surprisingly fine. I worked with two other guys collaboratively on some tricky frontend issues, which we solved, and it was fine.
More likely they'll just blame you, just like the sibling comment says...
Their goal was never increased productivity and developer hapiness. It was literally what they said "introducing scrum and bringing in a scrum master". Their purpose is to add and manage processes (bureucratic layers) and increase their dependants.
> After three months, the progress slowed to a crawl, star dev abandoned ship, and customers started complaining for the first time.
> Now I will just wait for someone to tell me that this wasn't real Scrum either, because we were supposed to have Product Owner talk to the client instead of Scrum Master :)
Oh wait till management finds engineers to scapegoat for their own decisions. If there is one truth about management, it is that they cannot accept "I told you so" from their reports.
I’ve developed a more nuanced view on Scrum since working as a contractor for a medium sized software company, but adjacent to their normal dev teams.
I used to have the view that Scrum is a useless batch of meetings, that sucks the life and productivity out of the dev process.
Now, after seeing it from an adjacent (but not subjugated under it) perspective, I think it is a life-sucking batch of meetings that are good for one thing: taking developers who can’t or don’t want to see the overall business/architecture picture and getting useful work out of them.
Most of us here are not in that category. I’d wager a majority of HN readers can’t help but to seek out understanding of the business, where this piece fits, what it interacts with. For us, specifying everything upfront is useless. Estimating stuff is irritating because we need the flexibility to make smart decisions during dev. Retro meetings are lies because we can’t say “stop with all this and let me work”.
But if you’re trying to make a process than can take junior devs (not junior in tenure, but junior in the qualities above) and produce an output that scales almost-kinda linearly with dev count, it sort of works.
I’d argue that you’re way better off hiring 6 devs that can go from business problem -> technical solution in their head, without all the ceremony, instead of 40 devs who can’t and 6 PMs to wrangle them.
But I can also see how a company ends up there - go through a tough hiring year, or even just make a few poor hiring decisions, and now you have people on the team who need handholding and supervision. That’s what scrum is; it feels like micromanagement because it is. It forces junior-performing devs into a productive state - maybe 5% of what you’d get out of a senior-performing dev without scrum, but it’s something non-negative.
> Not everybody knows that, but Scrum was invented to manage a team of dysfunctional COBOL programmers at a bank, not for product-led tech companies, and certainly not for startups.
> If you're mostly hiring juniors, low-skilled, unpassionate, unable to work autonomously without constant handlholding, reactive instead of proactive people, then you'll certainly need some micromanaging SDLC like Scrum.
> I’d argue that you’re way better off hiring 6 devs that can go from business problem -> technical solution in their head, without all the ceremony, instead of 40 devs who can’t and 6 PMs to wrangle them.
The problem is that finding those 6 experienced devs is _HARD_. And they're usually very expensive and know their value.
You can easily find 40 mid to low level coders and a half-dozen people who know how to run a scrum team. Maybe even some of the coders know how to do that for extra savings.
Also in the latter way you can easily have a turnover in the team without any major hassles, you can always find mid-tier coders.
But if one of the 6 highly experienced ones leaves, good luck finding a new one quickly.
A shitty car analogy: You can get a more efficient and faster car if it's 100% custom made. But if something breaks you need to manufacture the parts. Or you could make do with a less efficient and slower car, built out of highly standardised off the shelf parts.
I love https://basecamp.com/shapeup approach - tiny teams with high independence and sufficient domain knowledge working in six week periods to deliver features.
It works both ways. Every form of micromanagement will turn every dev team into a bunch of demotivated, junior performing, just here for the paycheck careless bunch of codemonkeys.
It is an assured loss for all.
Why not the opossite way? Trust people a bit above what they currently warrant, see who rises to the opportunity, and ease out the rest. This will over time elevate to a decent team.
99.9% of “Scrum” you’ll come across in the wild is cargo cult. People performing the ceremonies with no fucking idea why, in the hope that the giant eagles will come from the sky bringing gifts.
Scrum was created to help good developers communicate with management. But the problem is that management has all the power and couldn’t give a shit. If the management was qualified to “get it” you probably wouldn’t need it.
So yeah, if you’re using Scrum, you’re probably going to fail: whatever the reason that you’re doing scrum? That’s why you’re gonna fail.
I have been slaving as a cheap outsourced labor in a poor country for a large US software company. The goal of the scrum manager was specifically to prevent code monkeys from asking questions about "business/architecture picture" and to specify the tasks as narrow as possible. Anyone who asked too many questions was seen as a threat, as if they were going to communicate directly with our US masters and break the command chain.
Ok, this totally resonates. What I want to know is how I find a place to hang out with those 5 other devs.
I’ve had that “team of six motivated” come together twice organically during my career. But it never seems to last. People move on, the company gets wind of the success and either normalizes it out, or attempts to try and distribute and harvest. If I could figure out the recipe to reliably locate or create that sort of team, I think I’d be very well off.
I agree with this. In my experience: these "rituals" are a way to force the conversations that a "senior" - in your terminology - dev would naturally have.
> taking developers who can’t or don’t want to see the overall business/architecture picture and getting useful work out of them.
Maybe in theory that's the point of it, but it practice it also (and mostly) has the opposite effect: it takes all agency away from capable developers and make them impossible to see the big picture, drastically plummeting developer productivity of otherwise very capable developers.
> Most of us here are not in that category. […] For us, […] is useless.
It's not just useless, it's actually harmful.
> But I can also see how a company ends up there - go through a tough hiring year, or even just make a few poor hiring decisions, and now you have people on the team who need handholding and supervision
But most of the time it's not how it happens: it's forced top-down by manager who have no idea of how software development work, and who are genuinely convinced that it is how projects should be run.
They don't realize that it's a workaround for terrible HR that reduces productivity for everyone, because if they did they'd probably think twice (“How is my HR so poor when I'm not trying to cut on costs there? Oh maybe it's not and I should not use scrum”), they just do it because everybody else does.
> But if you’re trying to make a process than can take junior devs (not junior in tenure, but junior in the qualities above) and produce an output that scales almost-kinda linearly with dev count, it sort of works.
I don't think that's even the case. I've been brought onto teams of junior (in the sense that you talk about) developers to help fix broken, late projects. Those projects had always been managed under some sort of agile process, and they still ended up in trouble. I wouldn't even say the process "sort of" worked before then. I dunno, maybe it would have been even more of a disaster without the process, but I still don't think that lends much praise to the process.
I'm lucky that I can pick and choose what sort of projects I work on these days, and I will never work at or for a company where I'd be subject to any kind of agile garbage. Another toplevel commenter farther down mentioned a study that showed that projects managed under the "get to work and let me know when it's done" model outperformed all the others. I've always intuitively believed that model can work (though perhaps not in all situations with all types of developers), and it's nice to see some data to back that up.
>taking developers who can’t or don’t want to see the overall business/architecture picture and getting useful work out of them
That's a very charitable view... I think back over my career and it was always cargo-culting and micromanagement. I give you credit for analyzing and finding a way to make scrum work beneficially.
The thing is - if you have people who don't (want to) understand the relationship between their work and business value, you've fundamentally got a hiring / personnel problem. And I don't see how scrum (or any other methodology) ever solves that. What you've got at that point is to me the difference between "programmers" and "developers / engineers". People who are more enamored with the technology than with actually accomplishing work. The thing is, some of those people are really good so long as they can be pointed in the right direction. But that's a management thing, not really a methodology thing.
I would fully agree with your point if I weren't regularly in daily were nobody listen to what being said : e.g. discovering by themselves what was said the previous day/week as it was a new piece of important information to share.
Been on both sides of the equation as well over the past three decades. Two observations.
1) As you said, when you have a lot of junior developers (which given developer demographics is a given), you need some structure. Scrum provides that. For better or worse, the structure is helpful to people that are still a bit uncertain about how stuff works. I hate stand-ups as much as any other developer. But as a product focused CTO, I love that it gets the day started and my developers out of bed, awake and cafienated and focused on the job. Scrum's other meetings are a necessary evil. You need a platform to get them aligned with business goals. They don't naturally do this by themselves. Most importantly, a lot of developers kind of expect to this structure at this point. Providing structure to a team is important. Scrum is as good as any other structure. Not ideal with remote teams as meetings get more tricky.
2) Most scrum roles are junior management roles. And as such you get typically not very experienced people filling these roles as part of their entry into the corporate rat race. So, you get corporate politics playing out at the micro level with lots of turf fights about stuff that generally is close to irrelevant. Ranging from the right way to run meetings, the best issue tracker, etc. It's this endless friction that is causing a lot of resentment with more senior developers. Particularly in larger organizations this can get ugly in a hurry.
My strategy for containing this madness:
1) Keep teams small. Small teams are efficient teams that should not need a lot of (micro) management. And they also don't need a lot of formal roles.
2) No scrum masters. It's a bullshit role that doesn't add a whole lot of value. Especially in smaller teams. Instead I prefer to have tech leads calling the shots on their team or topic and stepping up as a leader. Part of that responsibility is leading the team in a direction that makes sense from a technical and business point of view. And the rest is about coaching people around them. It's something that happens naturally even when you don't want it to. So, I mostly just let this happen and encourage it.
3) Product ownership splits into technical and business ownership. While these can be the same person, it's better to have two equally ranked people shooting for consensus covering both business and tech. That ensures the business and tech is actually aligned. Weed out unrealistic requirements and deadlines; make sure that the technically easy yet valuable work actually gets done; ensure that business value is delivered; ensure that work gets prioritized correctly and that POs don't revert back to waterfall.
4) Management by exception. I like giving people enough room to manage themselves. I step in when that doesn't work. And I use positive re-enforcement to encourage them to do more of the right things. I'm not actually a genius; so I need smart people to tell me what the right way is to do things. Especially when those are things I'm not that good at. People closest to the problems, usually are best positioned to come up with good solutions. So let them. Fix it when that isn't working.
5) Use sprints as a predictable, calendar based umbrella for people to structure their activities around. Short enough cycles that it doesn't turn into waterfall. Long enough that we don't drown in meetings. Day to day management is Kanban based. Just generally remove uncertainty about what needs doing, who is doing it, why we're doing it, what's coming next, etc. Using continuous deployment to release stuff means that guarding quality is a constant and not a once a sprint kind of thing. Sprints are not release deadlines. Using Kanban day to day means that any high priority issues jump to the top of the stack right away. Short feedback cycles are key to keeping quality and morale high.
6) Meetings can be synchronization blocks. Any engineer knows those are bad. Business people seem to never grasp the cost of meetings (as this is all they do). It translates 1 to 1 to how teams function as well. That's why day to day work should not be blocked on meetings. We have issue trackers, slack, and other communication tools to sort out any blocking issues. Also, just talking to a person can be surprisingly effective. Scrum meetings are neatly partitioned to be about things like status updates, prioritization, estimation, and reviews. None of those meetings should be on the critical path to delivering working software. The correct way to resolve issues is direct or asynchronous communication (as is convenient).
7) Try to keep the few meetings we have a bit positive, light and friendly. It's bad enough that we have to sit through those. Conflict is what makes scrum so controversial. The constant bickering about everything and anything is just a mental drain on everyone. I try to keep that out of meetings as much as I can. Having tech leads means that they get a first shot at a decision. So, no need to have a lot of meetings about that. I use one on ones to correct a lot of things when they go wrong in meetings. Meetings are for positive re-enforcement. Call out the things that go well, inspire people to do more of the good stuff, etc.
> I think it is a life-sucking batch of meetings that are good for one thing: taking developers who can’t or don’t want to see the overall business/architecture picture and getting useful work out of them.
If I'm being onboarded at some project, I expect to be provided that description as early as possible. Compensating for broken communication by enforcing a life-sucking batch of meetings doesn't seem right.
From Peopleware: “In the 1985 Jeffery-Lawrence study [from the University of New South Wales]…they investigated the productivity of 24 projects for which no estimates were prepared at all. These projects far outperformed all the others…Projects on which the boss applied no schedule pressure whatsoever (‘Just wake me up when you’re done.’) had the highest productivity of all.”
I read 20+ books on management and leadership[1], and none of them mentioned anything like Scrum. I agree it's BS.
Interesting phenomenon happens at my place which is scrum + Safe. Our team gets publicly dinged if we "carry over" tickets between sprints, so if we finish our work with 2 days left the manager asks not to start anything new.
The process is a performance within a performance, literally getting told NOT to do more work. This is what happens when you have chart-oriented-development (particularly jira's toxic charts).
You might think this is nice to have free time to sit around, but frankly it also drains a lot of the joy out of my work, takes away my sense of autonomy and pride in my work and leads to some resentment.
I have a lot of issues with scrum and I think twitter post and the comments here touch on a lot of them, but one of my biggest annoyances with the whole thing that I hardly ever hear anyone mention is the term "sprints".
If you asked a marathon runner how to run a marathon, they're going to tell you things like run slower, make sure you conserve energy, and control your pace. They're not going to tell you to mentally break the marathon into small sections and sprint them all.
I know it seems minor (and it probably is), but it's always felt a bit telling that the recurring segment for work in scrum is named after something you cannot do repeatedly without completely burning yourself out.
I think there's a bit of selection bias here in that only people who are either very enamored or very unhappy with scrum are going to respond to a hot take on twitter.
But, that's besides the point. Scrum doesn't exist to make developer's lives easier. In my experience as a SWE in a scrum team, devs have basically always felt like our time is being wasted in meetings.
Scrum, imo, exists so that management and business stakeholders can have an understanding of how efforts are being allocated and give feedback on it. There's still plenty of ways this can go wrong, and I agree with others that the short sprint cycles of 1-2 weeks lead to the extra overhead of too many ceremonies, but I think for the average business stakeholder it probably gives a better result than waterfall.
> devs have basically always felt like our time is being wasted in meetings.
I think that's key. My experience is that I have often told my managers that "I don't need this meeting personally, so unless somebody else needs me in this meeting, I am losing my time".
Do you know what the managers usually answered? "I disagree, I think this meeting is useful for you. We are having this meeting to help you developers".
No wonder I don't respect my managers then, and now I happily waste my time in their meetings.
The meetings are good. You're getting paid during them. I managed to customise my bike, plan two international adventures, run a side business and do a year of a degree in pointless meetings in the last 5 years!
Ding! Ding! Ding! We have a winner. Tell him what he's won, Johnny!
Enlightenment came to me when I realized that companies only adopt Agile for reasons that benefit executives and management, not developers, to wit: fine-grained observability and direct control over the SDLC itself. It's really a game of Mornington Crescent: the team pretends to be playing one game when they're actually playing a different sort of game.
> management and business stakeholders can have an understanding of how efforts are being allocated and give feedback on it
I agree that devs can often mistake this need for wasted time. That does _not_ mean that Scrum is the best way to not waste time. A good project manager can get that info without so many full team meetings.
I guess one way to put it is that scrum is a clear way to lead a project (which is what entices people) but its not a great way.
>I think there's a bit of selection bias here in that only people who are either very enamored or very unhappy with scrum are going to respond to a hot take on twitter.
I'm going to get blasted for this, but you *are* doing scrum wrong.
Scrum was invented by engineers to defend themselves against incompetent middle managers. The moment you let management take the process over and warp it you are already doing it wrong.
Story points and sprints are a *self-calibrating* tool that will give you an advance warning (nicely visualized in burn-down charts) if an estimate you might have given a middle manager will be missed.
You do not "decide" how many points fit in a sprint, you just work at a sustainable pace and *measure* how many points fit in a sprint.
Nearly every single point in that tweet just screams bad management and bad engineers without any agency.
I still chuckle a bit when people get anti-scrum, because I've been around long enough when agile/scrum was the disruptive thing.
Of course in practice agile/scrum/whatever has turned into the same cargo-cult nonsense that the original promoters of the ideals were fighting against.
One thing I thought was interesting was:
> First, the most common jobs among the people who told me I was wrong were "Agile Coach" and "Scrum Master." They feel very strongly in favor of Scrum, but I'm not sure why.
It seems funny to critique people's job titles when the poster's Twitter profile reads:
I mean loudly critiquing a mainstream practice in a flippant way is pretty much the textbook approach to bring attention to yourself and establish as an expert in... teaching people about these topics. It's content marketing 101.
I got rejected from a job recently and I strongly suspect it was because I went on a rant about how awful scum was against my better judgement.
Something I've noticed in the last 3-5 years is that it's become more and more common for companies to quiz candidates on their scrum knowledge during interviews. They don't care what you think of scrum (though they may phase their questions like this) they simply want to know you know how to scrum because they scrum. And like in most places you can assume that although "scrum is flexible" it's also religiously followed in practise.
Anyway, this company wanted to know what I liked and disliked about scrum and my initial answer was kinda similar to this post – that I liked the idea of it but have never seen it work well in practise. Obviously this was a bad answer because it meant for the next 10 minutes of the interview they were asking me to expand and were trying to understand if I was a bad culture fit. Which to be fair I probably was.
But the truth is everywhere I've worked spirt ceremonies are universally hated and typically viewed as a waste of time (especially spirt reviews). Planning rarely adds much value and since estimates are often wrong you either need to be overly conservative with your estimation (rendering it useless), or you're forced to cut corners to deliver stuff on time. And even if you do estimation perfectly ACs always change and extra tickets are always brought into the spirt because "it's essential". Standup is never 15 minutes – it's 10 minutes per team member who likes to hear their own voice, and 30 seconds to those who don't and who just want to get on with their work. Don't even get me started on the team building games...
I have seen companies implement it better than others though. The place I work at the moment does it surprisingly well. We do standups which are mostly mandatory, but everything else is optional for the vast majority of the team.
Most people don’t know some history. During 1990s, a group of people made a fortune out of consulting gigs where they will be called in by their CTO friends in traditional enterprises to save the late and over budget projects. One of these people was Kent Beck. Kent will use his license to kill to turn things around and eventually generalize his rescue formula and sell it to make 100X more. His crowning glory during those days was XP or eXtreme Programming.
Like with all self-help formulas, Kent will label his solution as magic bullet for all software development problems. He will advertise it as secret medicine that cures all ills. He will be at every conference, write articles after articles, publish books.
Also, like all magic self-help formulas, it wouldn’t quite work. So, Kent will invent something new. His next prescription was TDD and when I first saw it, I thought it was a joke. But people around me started drinking cool aid and if you didn’t join them then you weren’t one of them. Again, Kent and friends will go out on massive marketing spree advertising it as secret talisman. Like all overweight desperate people in need to lose weight, people will enthusiastically start new Kent Beck diet, lose few pounds and endorse the formula. But they will soon find that they had simply traded one problem for another more uglier one.
This went on for long time. For more than two decades, these group of people kept inventing these processes, selling it as magic pill and made millions upon millions in consulting gigs, books, training, certifications and so on. They came up with Agile and 17 people in that group created “agile manifesto”. Their most aggressively marketed prescription was scrum. Like their all previous prescription, world is finally coming off of night of drinking cool aid and feeling severe headache.
I think most of these people have now sort of retired after amassing massive fortunes and hopefully we will not see more of these magic processes pushed to dumb CTOs with promises of curing all ills.
The truth is Scrum was never a magic bullet and it is downright harmful for many projects. It is useful for highly predictable projects where research component is negligible, for example, CRUD websites AND where you are stuck with unmotivated tier-3 talent who failed to get job at insurance company. For everything else, it should never have been used. It is especially going to hurt creativity, originality and novelty if you are in business of making a differentiating unique novel product. It also is very very bad choice if you already had tier-1 highly motivated team.
Scrum puts "feel good" limits around the unknown qualities of time-to-complete and "divide and conquer"
You still don't really know when it will be ready, but you now have talking points with management about a) whats been done and b) how complex it is. This builds belief: Belief there will be a solution, and Belief you can find it.
Nothing not said better by others here, but I say this as a party who was dragged kicking and screaming into the process to be an agile product manager, hated it, and got out. I totally "get" why people want this. It's very rare to be a Bell Labs, or Xerox Parc, and have pretty much complete freedom to spend budget and deliver an outcome when it's ready.
I also have worked on large s/w projects which cost $16m to fail to work, and $60m in lawsuits out the other side. I know that the alternative (a massive proscriptive playbook of minute details of functions, UML, flowcharts, you-name-it) exists and works, or not (depending on your point of view).
Really? I think scrum was the wrong name. The process itself, is fine. Talking to your co-workers builds a sense of purpose and direction.
I would have guessed more HN readers would attempt to understand the desired outcomes, how the implementation attempts to achieve them, then take the good from the bad as a source of constant improvement.
The tone on this thread has that jaded and defeatest "management sucks" attitude that I find most often in the least productive engineers regardless of how they work.
I must live in some kind of alternative reality where 80% of teams that I worked with liked Scrum (and I lead tens of teams).
The remaining teams just needed Kanban.
Not sure what everybody else is doing here, but I have seen teams where before we started doing scrum+jira all tasks were coming on Skype and discord, and stakeholders were either micromanaging (programmers managed by non-programmers) or either would forget project for 1 month and would come back to find something delivered that completely missed expectations.
After moving to proper task tracking and clear planning and review rituals, the developer satisfaction went through the roof (before that people were borderline considering quiting)
Scrum I think is pretty bad. It’s designed to work in contract shops where you have a short window deliverable for the customer, and isn’t really well designed for a more collaborative development process. Also the cargo culting meetings are pointless.
Agile in theory is great, teams should just do what works for them. End of story. But the issue is that agile and scrum are synonymous in the “agile” industry of consultants selling agile training to companies which largely drives how it’s practiced.
Kanban I think is a great organizational method though. It tracks work, shows what needs to be done and the progress. And gets out of the way.
I hope people read this person's full post. he says, "I believe in Agile, but this ain't agile."
Yeah, agile and scrum aren't the same. In my humble opinion, agile process is pretty fantastic and a lot better than waterfall (although waterfall has some elements that should be carried over to agile) or even Rational Unified Process. Yeah, Agile is taking over the engineering world (not just software) for a reason, because iterative development using small teams works.
In some cases having a formalized process/methodology helps to appear professional and hide the fact that nobody knows exactly what they're doing. I've seen it it some place - very serious software dev company delivering very serious medical software, but in fact the whole team was just faking it and trying to keep up the professional image. The developers were random people without business domain knowledge, managers were managing the work without understanding it, analysts were producing some documents that nobody understood, customer approved some scopes hoping that the specification is actually what is needed (but in vain). The team was assembled from contractors, and people rotated quite frequently so that there was no chance for them to acquire the domain knowledge necessary to talk to the customer. It was just painful to take part in it, but took me some time before i realized in fact everyone is just pretending to understand what's going on. Endless approvals and multi-step procedures required for medical stuff just made the whole thing impossible to understand and smeared the responsibility so broadly that it was guaranteed there's no single person that knows too much.
I agree it's rarely "done right", but I've been in career long enough that waterfall was still common early in career and horrible crunch time targeting some date at end of 9-12 months projects was inevitable - Scrum was a total breath of fresh air back in 2005-2006 and saved my sanity.
Basically we'd ask mgmt "what do you want next?" and they had to fuck off for the next 4 weeks while devs, ux, QA worked with no changes in plans until next demo and release. They were responsible for figuring out "when will everything be done?" etc.
I recently left a startup that said they were "doing Scrum" and it was just daily task tracking and pushing devs to overcommit to each sprint - that's not what I consider Scrum.
Anecdotes #6 and #7 in their list is a real indicator of something bad, wholly unrelated to Scrum.
> #6 We measured how much it cost to deliver one story point and then wrote contracts where clients paid for a package of "500 story points."
> #7 Management lost it when they found that 500 story points in one project weren't the same as 500 story points on another project. We had many meetings to fix this.
Agile is a cancer too: In many orgs, Agile is essentially synonymous with chaos. Zero look-ahead. Let's do it first and fix it later. Later never comes.
I believe 99% of Agile's value comes from caring about developers and letting them pride themselves with their progress.
Managers benefit from regularly reminding devs that their progress is not measured by amount of code, but working features. "Can you do a demo?"
Care about your devs, let them demonstrate progress. There, I just invented another Agile framework.
Once things become difficult, challenging, or new, it's garbage.
Projects that are taking more story points than expected are "behind schedule". No, your shitty schedule is the problem, because you were unable to estimate the difficulty of doing something new. And that's the hard thing about hard things. Maybe it will be done in 3 days or maybe you'll need 2 weeks, but you can't do that with very difficult things.
Scrum is an attempt to label Parkinson's Law: that a task will expand to fit the time it is allocated in the schedule.
With people that need to be micromanaged, and tasks that you know how to do but take time, scrum can work. This is because it basically gives you a way to measure whether you believe a junior developer is performing up to the level of expected, rather than slacking off or sandbagging.
[+] [-] lpapez|2 years ago|reply
However, the management insisted that we adopt Scrum and get a Scrum Master to help us.
I objected to this and listed all of the problems I could see if Scrum was introduced: losing dev creativity and incentive, tickets taking exactly one sprint to complete instead of doing them at leisurely pace, the mistranslation coming from having one extra layer of communication (Scrum Master handling the client now).
The management response was: "that is not real Scrum, you had bad experiences because you weren't doing it right previously".
After three months, the progress slowed to a crawl, star dev abandoned ship, and customers started complaining for the first time.
Now I will just wait for someone to tell me that this wasn't real Scrum either, because we were supposed to have Product Owner talk to the client instead of Scrum Master :)
[+] [-] hibikir|2 years ago|reply
But yes, a team of people that understand the business, and can prioritize well without needing someone to do it all for them, scrum just slows the team down. I've seen it happen multiple times in my career, and sometimes succeeded at either undoing the change, or making the jira-based work basically fictional.
[+] [-] baz00|2 years ago|reply
"The process failed because you didn't have enough project managers on board"
No the process failed because it was fucking shit and everyone went somewhere else.
The only good thing heavy processes are for are propping up employment statistics.
[+] [-] username332211|2 years ago|reply
And that was your big mistake. Those are real concerns, but those things are abstract and non-quantifiable. The proper way to fight scrum is to measure the time it takes to perform the scrum 'ceremonies'. It's rarely less than 30% of the total work time in a sprint. 50% seems to be very common.
In my experience even the dumbest and thick-headed management can understand that. I've always imagined if it didn't I could ask to hire more people to compensate for the time lost, but I never had to resort to that.
Granted, you still end up with a mutilated scrum at the end. But if you mutilate it right, you can fit your pre-scrum work process into the terminology of a mutilated scrum.
[+] [-] karaterobot|2 years ago|reply
In situations like this, one strategy I have used (not for Scrum, but for people who want to tinker with shit for the sake of tinkering) is to say: "Great, we welcome experimentation, this is really cool. What will we measure to decide whether this change is improving our process, and how long will the initial round of experiments last?"
Because: this frames it as something we are trying together rather than something they are dictating, but also something that is not necessarily permanent, which can be changed in the future (including changed back to the way it was), and which is oriented around measurable improvement rather than arbitrary whims. Almost nobody is willing to be the guy who says "we'll do it my way because I said so, even if it makes everything worse", and if they are, that in itself gives you some valuable information about your manager or leadership team.
[+] [-] brailsafe|2 years ago|reply
[+] [-] coldtea|2 years ago|reply
Their goal was never increased productivity and developer hapiness. It was literally what they said "introducing scrum and bringing in a scrum master". Their purpose is to add and manage processes (bureucratic layers) and increase their dependants.
[+] [-] nine_zeros|2 years ago|reply
> Now I will just wait for someone to tell me that this wasn't real Scrum either, because we were supposed to have Product Owner talk to the client instead of Scrum Master :)
Oh wait till management finds engineers to scapegoat for their own decisions. If there is one truth about management, it is that they cannot accept "I told you so" from their reports.
[+] [-] systems|2 years ago|reply
did they revert back to the old method, did it deteriorate so fast there was no way to stop it, was the team not very important
what happened ?
[+] [-] mwint|2 years ago|reply
I used to have the view that Scrum is a useless batch of meetings, that sucks the life and productivity out of the dev process.
Now, after seeing it from an adjacent (but not subjugated under it) perspective, I think it is a life-sucking batch of meetings that are good for one thing: taking developers who can’t or don’t want to see the overall business/architecture picture and getting useful work out of them.
Most of us here are not in that category. I’d wager a majority of HN readers can’t help but to seek out understanding of the business, where this piece fits, what it interacts with. For us, specifying everything upfront is useless. Estimating stuff is irritating because we need the flexibility to make smart decisions during dev. Retro meetings are lies because we can’t say “stop with all this and let me work”.
But if you’re trying to make a process than can take junior devs (not junior in tenure, but junior in the qualities above) and produce an output that scales almost-kinda linearly with dev count, it sort of works.
I’d argue that you’re way better off hiring 6 devs that can go from business problem -> technical solution in their head, without all the ceremony, instead of 40 devs who can’t and 6 PMs to wrangle them.
But I can also see how a company ends up there - go through a tough hiring year, or even just make a few poor hiring decisions, and now you have people on the team who need handholding and supervision. That’s what scrum is; it feels like micromanagement because it is. It forces junior-performing devs into a productive state - maybe 5% of what you’d get out of a senior-performing dev without scrum, but it’s something non-negative.
[+] [-] nivertech|2 years ago|reply
> Not everybody knows that, but Scrum was invented to manage a team of dysfunctional COBOL programmers at a bank, not for product-led tech companies, and certainly not for startups.
> If you're mostly hiring juniors, low-skilled, unpassionate, unable to work autonomously without constant handlholding, reactive instead of proactive people, then you'll certainly need some micromanaging SDLC like Scrum.
[+] [-] theshrike79|2 years ago|reply
The problem is that finding those 6 experienced devs is _HARD_. And they're usually very expensive and know their value.
You can easily find 40 mid to low level coders and a half-dozen people who know how to run a scrum team. Maybe even some of the coders know how to do that for extra savings.
Also in the latter way you can easily have a turnover in the team without any major hassles, you can always find mid-tier coders.
But if one of the 6 highly experienced ones leaves, good luck finding a new one quickly.
A shitty car analogy: You can get a more efficient and faster car if it's 100% custom made. But if something breaks you need to manufacture the parts. Or you could make do with a less efficient and slower car, built out of highly standardised off the shelf parts.
[+] [-] andrei_says_|2 years ago|reply
And here’s Dave Thomas (one of the names under the Agile Manifesto) speaking of the Agile/Scrum Industrial Complex https://youtu.be/a-BOSpxYJ9M?si=pwROU4JU9V64A39O
[+] [-] PeterStuer|2 years ago|reply
It is an assured loss for all.
Why not the opossite way? Trust people a bit above what they currently warrant, see who rises to the opportunity, and ease out the rest. This will over time elevate to a decent team.
[+] [-] lowbloodsugar|2 years ago|reply
Scrum was created to help good developers communicate with management. But the problem is that management has all the power and couldn’t give a shit. If the management was qualified to “get it” you probably wouldn’t need it.
So yeah, if you’re using Scrum, you’re probably going to fail: whatever the reason that you’re doing scrum? That’s why you’re gonna fail.
Scrum is a fantastic canary.
[+] [-] EVa5I7bHFq9mnYK|2 years ago|reply
[+] [-] travisgriggs|2 years ago|reply
I’ve had that “team of six motivated” come together twice organically during my career. But it never seems to last. People move on, the company gets wind of the success and either normalizes it out, or attempts to try and distribute and harvest. If I could figure out the recipe to reliably locate or create that sort of team, I think I’d be very well off.
[+] [-] xyzelement|2 years ago|reply
[+] [-] littlestymaar|2 years ago|reply
Maybe in theory that's the point of it, but it practice it also (and mostly) has the opposite effect: it takes all agency away from capable developers and make them impossible to see the big picture, drastically plummeting developer productivity of otherwise very capable developers.
> Most of us here are not in that category. […] For us, […] is useless.
It's not just useless, it's actually harmful.
> But I can also see how a company ends up there - go through a tough hiring year, or even just make a few poor hiring decisions, and now you have people on the team who need handholding and supervision
But most of the time it's not how it happens: it's forced top-down by manager who have no idea of how software development work, and who are genuinely convinced that it is how projects should be run.
They don't realize that it's a workaround for terrible HR that reduces productivity for everyone, because if they did they'd probably think twice (“How is my HR so poor when I'm not trying to cut on costs there? Oh maybe it's not and I should not use scrum”), they just do it because everybody else does.
[+] [-] kelnos|2 years ago|reply
I don't think that's even the case. I've been brought onto teams of junior (in the sense that you talk about) developers to help fix broken, late projects. Those projects had always been managed under some sort of agile process, and they still ended up in trouble. I wouldn't even say the process "sort of" worked before then. I dunno, maybe it would have been even more of a disaster without the process, but I still don't think that lends much praise to the process.
I'm lucky that I can pick and choose what sort of projects I work on these days, and I will never work at or for a company where I'd be subject to any kind of agile garbage. Another toplevel commenter farther down mentioned a study that showed that projects managed under the "get to work and let me know when it's done" model outperformed all the others. I've always intuitively believed that model can work (though perhaps not in all situations with all types of developers), and it's nice to see some data to back that up.
[+] [-] binary132|2 years ago|reply
[+] [-] poulsbohemian|2 years ago|reply
That's a very charitable view... I think back over my career and it was always cargo-culting and micromanagement. I give you credit for analyzing and finding a way to make scrum work beneficially.
The thing is - if you have people who don't (want to) understand the relationship between their work and business value, you've fundamentally got a hiring / personnel problem. And I don't see how scrum (or any other methodology) ever solves that. What you've got at that point is to me the difference between "programmers" and "developers / engineers". People who are more enamored with the technology than with actually accomplishing work. The thing is, some of those people are really good so long as they can be pointed in the right direction. But that's a management thing, not really a methodology thing.
[+] [-] Foobar8568|2 years ago|reply
[+] [-] jillesvangurp|2 years ago|reply
1) As you said, when you have a lot of junior developers (which given developer demographics is a given), you need some structure. Scrum provides that. For better or worse, the structure is helpful to people that are still a bit uncertain about how stuff works. I hate stand-ups as much as any other developer. But as a product focused CTO, I love that it gets the day started and my developers out of bed, awake and cafienated and focused on the job. Scrum's other meetings are a necessary evil. You need a platform to get them aligned with business goals. They don't naturally do this by themselves. Most importantly, a lot of developers kind of expect to this structure at this point. Providing structure to a team is important. Scrum is as good as any other structure. Not ideal with remote teams as meetings get more tricky.
2) Most scrum roles are junior management roles. And as such you get typically not very experienced people filling these roles as part of their entry into the corporate rat race. So, you get corporate politics playing out at the micro level with lots of turf fights about stuff that generally is close to irrelevant. Ranging from the right way to run meetings, the best issue tracker, etc. It's this endless friction that is causing a lot of resentment with more senior developers. Particularly in larger organizations this can get ugly in a hurry.
My strategy for containing this madness:
1) Keep teams small. Small teams are efficient teams that should not need a lot of (micro) management. And they also don't need a lot of formal roles.
2) No scrum masters. It's a bullshit role that doesn't add a whole lot of value. Especially in smaller teams. Instead I prefer to have tech leads calling the shots on their team or topic and stepping up as a leader. Part of that responsibility is leading the team in a direction that makes sense from a technical and business point of view. And the rest is about coaching people around them. It's something that happens naturally even when you don't want it to. So, I mostly just let this happen and encourage it.
3) Product ownership splits into technical and business ownership. While these can be the same person, it's better to have two equally ranked people shooting for consensus covering both business and tech. That ensures the business and tech is actually aligned. Weed out unrealistic requirements and deadlines; make sure that the technically easy yet valuable work actually gets done; ensure that business value is delivered; ensure that work gets prioritized correctly and that POs don't revert back to waterfall.
4) Management by exception. I like giving people enough room to manage themselves. I step in when that doesn't work. And I use positive re-enforcement to encourage them to do more of the right things. I'm not actually a genius; so I need smart people to tell me what the right way is to do things. Especially when those are things I'm not that good at. People closest to the problems, usually are best positioned to come up with good solutions. So let them. Fix it when that isn't working.
5) Use sprints as a predictable, calendar based umbrella for people to structure their activities around. Short enough cycles that it doesn't turn into waterfall. Long enough that we don't drown in meetings. Day to day management is Kanban based. Just generally remove uncertainty about what needs doing, who is doing it, why we're doing it, what's coming next, etc. Using continuous deployment to release stuff means that guarding quality is a constant and not a once a sprint kind of thing. Sprints are not release deadlines. Using Kanban day to day means that any high priority issues jump to the top of the stack right away. Short feedback cycles are key to keeping quality and morale high.
6) Meetings can be synchronization blocks. Any engineer knows those are bad. Business people seem to never grasp the cost of meetings (as this is all they do). It translates 1 to 1 to how teams function as well. That's why day to day work should not be blocked on meetings. We have issue trackers, slack, and other communication tools to sort out any blocking issues. Also, just talking to a person can be surprisingly effective. Scrum meetings are neatly partitioned to be about things like status updates, prioritization, estimation, and reviews. None of those meetings should be on the critical path to delivering working software. The correct way to resolve issues is direct or asynchronous communication (as is convenient).
7) Try to keep the few meetings we have a bit positive, light and friendly. It's bad enough that we have to sit through those. Conflict is what makes scrum so controversial. The constant bickering about everything and anything is just a mental drain on everyone. I try to keep that out of meetings as much as I can. Having tech leads means that they get a first shot at a decision. So, no need to have a lot of meetings about that. I use one on ones to correct a lot of things when they go wrong in meetings. Meetings are for positive re-enforcement. Call out the things that go well, inspire people to do more of the good stuff, etc.
[+] [-] mkl95|2 years ago|reply
If I'm being onboarded at some project, I expect to be provided that description as early as possible. Compensating for broken communication by enforcing a life-sucking batch of meetings doesn't seem right.
[+] [-] beardedwizard|2 years ago|reply
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] tuckerconnelly|2 years ago|reply
I read 20+ books on management and leadership[1], and none of them mentioned anything like Scrum. I agree it's BS.
[1] https://tuckerconnelly.com/management-leadership
[+] [-] zug_zug|2 years ago|reply
The process is a performance within a performance, literally getting told NOT to do more work. This is what happens when you have chart-oriented-development (particularly jira's toxic charts).
You might think this is nice to have free time to sit around, but frankly it also drains a lot of the joy out of my work, takes away my sense of autonomy and pride in my work and leads to some resentment.
[+] [-] superfrank|2 years ago|reply
If you asked a marathon runner how to run a marathon, they're going to tell you things like run slower, make sure you conserve energy, and control your pace. They're not going to tell you to mentally break the marathon into small sections and sprint them all.
I know it seems minor (and it probably is), but it's always felt a bit telling that the recurring segment for work in scrum is named after something you cannot do repeatedly without completely burning yourself out.
[+] [-] idkyall|2 years ago|reply
But, that's besides the point. Scrum doesn't exist to make developer's lives easier. In my experience as a SWE in a scrum team, devs have basically always felt like our time is being wasted in meetings.
Scrum, imo, exists so that management and business stakeholders can have an understanding of how efforts are being allocated and give feedback on it. There's still plenty of ways this can go wrong, and I agree with others that the short sprint cycles of 1-2 weeks lead to the extra overhead of too many ceremonies, but I think for the average business stakeholder it probably gives a better result than waterfall.
[+] [-] palata|2 years ago|reply
I think that's key. My experience is that I have often told my managers that "I don't need this meeting personally, so unless somebody else needs me in this meeting, I am losing my time".
Do you know what the managers usually answered? "I disagree, I think this meeting is useful for you. We are having this meeting to help you developers".
No wonder I don't respect my managers then, and now I happily waste my time in their meetings.
[+] [-] baz00|2 years ago|reply
[+] [-] bitwize|2 years ago|reply
Enlightenment came to me when I realized that companies only adopt Agile for reasons that benefit executives and management, not developers, to wit: fine-grained observability and direct control over the SDLC itself. It's really a game of Mornington Crescent: the team pretends to be playing one game when they're actually playing a different sort of game.
[+] [-] jayd16|2 years ago|reply
I agree that devs can often mistake this need for wasted time. That does _not_ mean that Scrum is the best way to not waste time. A good project manager can get that info without so many full team meetings.
I guess one way to put it is that scrum is a clear way to lead a project (which is what entices people) but its not a great way.
[+] [-] coldtea|2 years ago|reply
All 10 of the former?
[+] [-] Spiwux|2 years ago|reply
Story points and sprints are a *self-calibrating* tool that will give you an advance warning (nicely visualized in burn-down charts) if an estimate you might have given a middle manager will be missed.
You do not "decide" how many points fit in a sprint, you just work at a sustainable pace and *measure* how many points fit in a sprint.
Nearly every single point in that tweet just screams bad management and bad engineers without any agency.
[+] [-] IKantRead|2 years ago|reply
Of course in practice agile/scrum/whatever has turned into the same cargo-cult nonsense that the original promoters of the ideals were fighting against.
One thing I thought was interesting was:
> First, the most common jobs among the people who told me I was wrong were "Agile Coach" and "Scrum Master." They feel very strongly in favor of Scrum, but I'm not sure why.
It seems funny to critique people's job titles when the poster's Twitter profile reads:
> I teach Machine Learning and run http://ml.school
I mean loudly critiquing a mainstream practice in a flippant way is pretty much the textbook approach to bring attention to yourself and establish as an expert in... teaching people about these topics. It's content marketing 101.
[+] [-] kypro|2 years ago|reply
Something I've noticed in the last 3-5 years is that it's become more and more common for companies to quiz candidates on their scrum knowledge during interviews. They don't care what you think of scrum (though they may phase their questions like this) they simply want to know you know how to scrum because they scrum. And like in most places you can assume that although "scrum is flexible" it's also religiously followed in practise.
Anyway, this company wanted to know what I liked and disliked about scrum and my initial answer was kinda similar to this post – that I liked the idea of it but have never seen it work well in practise. Obviously this was a bad answer because it meant for the next 10 minutes of the interview they were asking me to expand and were trying to understand if I was a bad culture fit. Which to be fair I probably was.
But the truth is everywhere I've worked spirt ceremonies are universally hated and typically viewed as a waste of time (especially spirt reviews). Planning rarely adds much value and since estimates are often wrong you either need to be overly conservative with your estimation (rendering it useless), or you're forced to cut corners to deliver stuff on time. And even if you do estimation perfectly ACs always change and extra tickets are always brought into the spirt because "it's essential". Standup is never 15 minutes – it's 10 minutes per team member who likes to hear their own voice, and 30 seconds to those who don't and who just want to get on with their work. Don't even get me started on the team building games...
I have seen companies implement it better than others though. The place I work at the moment does it surprisingly well. We do standups which are mostly mandatory, but everything else is optional for the vast majority of the team.
[+] [-] telltruth|2 years ago|reply
Like with all self-help formulas, Kent will label his solution as magic bullet for all software development problems. He will advertise it as secret medicine that cures all ills. He will be at every conference, write articles after articles, publish books.
Also, like all magic self-help formulas, it wouldn’t quite work. So, Kent will invent something new. His next prescription was TDD and when I first saw it, I thought it was a joke. But people around me started drinking cool aid and if you didn’t join them then you weren’t one of them. Again, Kent and friends will go out on massive marketing spree advertising it as secret talisman. Like all overweight desperate people in need to lose weight, people will enthusiastically start new Kent Beck diet, lose few pounds and endorse the formula. But they will soon find that they had simply traded one problem for another more uglier one.
This went on for long time. For more than two decades, these group of people kept inventing these processes, selling it as magic pill and made millions upon millions in consulting gigs, books, training, certifications and so on. They came up with Agile and 17 people in that group created “agile manifesto”. Their most aggressively marketed prescription was scrum. Like their all previous prescription, world is finally coming off of night of drinking cool aid and feeling severe headache.
I think most of these people have now sort of retired after amassing massive fortunes and hopefully we will not see more of these magic processes pushed to dumb CTOs with promises of curing all ills.
The truth is Scrum was never a magic bullet and it is downright harmful for many projects. It is useful for highly predictable projects where research component is negligible, for example, CRUD websites AND where you are stuck with unmotivated tier-3 talent who failed to get job at insurance company. For everything else, it should never have been used. It is especially going to hurt creativity, originality and novelty if you are in business of making a differentiating unique novel product. It also is very very bad choice if you already had tier-1 highly motivated team.
So exercise caution!
[+] [-] ggm|2 years ago|reply
You still don't really know when it will be ready, but you now have talking points with management about a) whats been done and b) how complex it is. This builds belief: Belief there will be a solution, and Belief you can find it.
Nothing not said better by others here, but I say this as a party who was dragged kicking and screaming into the process to be an agile product manager, hated it, and got out. I totally "get" why people want this. It's very rare to be a Bell Labs, or Xerox Parc, and have pretty much complete freedom to spend budget and deliver an outcome when it's ready.
I also have worked on large s/w projects which cost $16m to fail to work, and $60m in lawsuits out the other side. I know that the alternative (a massive proscriptive playbook of minute details of functions, UML, flowcharts, you-name-it) exists and works, or not (depending on your point of view).
Really? I think scrum was the wrong name. The process itself, is fine. Talking to your co-workers builds a sense of purpose and direction.
[+] [-] beardedwizard|2 years ago|reply
The tone on this thread has that jaded and defeatest "management sucks" attitude that I find most often in the least productive engineers regardless of how they work.
[+] [-] tasubotadas|2 years ago|reply
The remaining teams just needed Kanban.
Not sure what everybody else is doing here, but I have seen teams where before we started doing scrum+jira all tasks were coming on Skype and discord, and stakeholders were either micromanaging (programmers managed by non-programmers) or either would forget project for 1 month and would come back to find something delivered that completely missed expectations.
After moving to proper task tracking and clear planning and review rituals, the developer satisfaction went through the roof (before that people were borderline considering quiting)
[+] [-] ecshafer|2 years ago|reply
Agile in theory is great, teams should just do what works for them. End of story. But the issue is that agile and scrum are synonymous in the “agile” industry of consultants selling agile training to companies which largely drives how it’s practiced.
Kanban I think is a great organizational method though. It tracks work, shows what needs to be done and the progress. And gets out of the way.
[+] [-] computerdork|2 years ago|reply
Yeah, agile and scrum aren't the same. In my humble opinion, agile process is pretty fantastic and a lot better than waterfall (although waterfall has some elements that should be carried over to agile) or even Rational Unified Process. Yeah, Agile is taking over the engineering world (not just software) for a reason, because iterative development using small teams works.
[+] [-] lafar6503|2 years ago|reply
[+] [-] gedy|2 years ago|reply
Basically we'd ask mgmt "what do you want next?" and they had to fuck off for the next 4 weeks while devs, ux, QA worked with no changes in plans until next demo and release. They were responsible for figuring out "when will everything be done?" etc.
I recently left a startup that said they were "doing Scrum" and it was just daily task tracking and pushing devs to overcommit to each sprint - that's not what I consider Scrum.
[+] [-] strictnein|2 years ago|reply
> #6 We measured how much it cost to deliver one story point and then wrote contracts where clients paid for a package of "500 story points."
> #7 Management lost it when they found that 500 story points in one project weren't the same as 500 story points on another project. We had many meetings to fix this.
[+] [-] anticristi|2 years ago|reply
I believe 99% of Agile's value comes from caring about developers and letting them pride themselves with their progress.
Managers benefit from regularly reminding devs that their progress is not measured by amount of code, but working features. "Can you do a demo?"
Care about your devs, let them demonstrate progress. There, I just invented another Agile framework.
[+] [-] blobbers|2 years ago|reply
Once things become difficult, challenging, or new, it's garbage.
Projects that are taking more story points than expected are "behind schedule". No, your shitty schedule is the problem, because you were unable to estimate the difficulty of doing something new. And that's the hard thing about hard things. Maybe it will be done in 3 days or maybe you'll need 2 weeks, but you can't do that with very difficult things.
Scrum is an attempt to label Parkinson's Law: that a task will expand to fit the time it is allocated in the schedule.
With people that need to be micromanaged, and tasks that you know how to do but take time, scrum can work. This is because it basically gives you a way to measure whether you believe a junior developer is performing up to the level of expected, rather than slacking off or sandbagging.
Personally, I hate scrum.