4 ms·
I never really understood the hype around (f)ragile (as one famous google engineer called it in a small closed circle a few years ago). I think the main problem
by axegon_ 5y ago
I never really understood the hype around (f)ragile (as one famous google engineer called it in a small closed circle a few years ago). I think the main problem is that in the past 7-8 years it has become more of an evangelism effort rather than anything.
> The important piece that gets forgotten is that Agile was openly, militantly anti-management in the beginning.
Yet here we are: The process just became an endless rabbit hole of filling jira tickets, workday schedules, and a bunch of other systems(including a shared google sheets table as it was in a company I used to work for with 5000+ employees) which easily eat up a day of your week. Detrimental if you are aiming for a deadline. And while I embraced wfh and felt insanely comfortable with it, it was used as an excuse for management to further push those things further down everyone's throats. The end result was that, at least from an engineering prespective, work became more of a marketing team meeting, filled with absurd abbreviations and processes which hold no value and only drag you down. Another problem is when you get an email from jira that someone assigned you a ticket called "Implement X in Y" with no further explanation when you click the link. It's absurd that in large companies(think 250+ people) your value is determined by how many tickets you've ticked off. "Implement X in Y" seems like just another one, but in many case those 4 words end up being 8 separate things, each of which can take several days but no one cares even if you described those in detail in the comments. You might think that story points solve that but they often don't. Imagine the following scenario: you are tasked to hook up a system to an s3 bucket to store data but you have restricted access to the aws console so you can't even create a bucket on your own. Then it turns out that the vpn is set up wrong and you can't even resolve the host if you are connected to the vpn. Then it turns out that the library you use has some bug in it or it's incompatible with some of the other libraries you use so you end up upgrading a bunch of libraries, patch up a large codebase and only then be able to get on with the s3 bucket thing. At first glance what you would assume is a 2 hour task tops ends up being a week and a half of your life. And it can be insanely demotivating when you have the same thing to report that you are working on the s3 thing in your daily scrum for a week and a half. Which is even worse when your managers have little to no tech skills beyond excel for instance. The point of my rant is that agile became the thing it was supposed to destroy - a time tracking system for the assembly line.
Edit: those things don't seem to apply for small companies/startups because... Well they are small and you get to know everyone on day one.
- jnwatson 5y agoUsing story points for evaluating developers goes against the ideals of Agile. It also makes story points useless. See Goodhart’s law.
- pjmlp 5y agoIndeed, that is why Agile has failed, the OP comment is a typical day on an "Agile" enterprise corporation.
- axegon_ 5y agoNo, I mean using story points for evaluating the complexity of a task (a lot of companies/teams use them this way at least).
- TameAntelope 5y agoI think spending too much time in a large company is damaging, possibly permanently, to a developer's ability to connect value to work. On a basic level, Story Points are there because if you can't tell me how long something will take, I don't want to give you money to go do it. Everyone has to deal with this, at every level. CEOs think about this, janitors think about this, literally everyone is constantly calculating estimated time to complete a task as a key metric about whether or not they should do the task. All a Story Point should do is make that a conversation, not an isolated person's random guess. That's it. I don't see what's harmful about that.
- axegon_ 5y agoI spent around 11 years in large companies(anywhere between 300 and 6000 employees). It highly depend on what you work on and what's your work ethic. In all honesty beyond circumstances which were outside my control, I ended up in a small company and just now I realize how much the idiotic bureaucracy truly bothered me. And I'm acknowledging that precisely agile facilitated this hell. I think you are looking at it from an r&d (still evangelistic) prospective, but now picture rewriting a truly ancient system still operating on mainframes(and the original developers and maintainers are no longer among the living) in a modern language where it's not a question if something is worth doing or who will do it-it has to be done. Figuring out how the old system works is a combination of reverse engineering and brute forcing. I've been there and trust me, in those circumstances story point is a synonym for a random number. This is a real life example and in those conditions agile doesn't only crack, it collapses and it mentally crushes on top of you cause you are still forced to stick to everything agile. What I'm saying is that agile and by implications sorry points work in some extremely specific circumstances but in the vast majority of cases it only adds multiple layers of complexity which does nothing but waste valuable time.