12 ms·

I just don't get it why developers like Scrum. The whole thing was designed to give non-technical people more power over the ones who spent a lifetime honing th

by zeroc8 6y ago

I just don't get it why developers like Scrum. The whole thing was designed to give non-technical people more power over the ones who spent a lifetime honing their craftmanship. Standing around a table in the morning like assholes is not my idea of fun. Same for the "product owner" concept. If I develop something, I am the owner. I generally hate being micromanaged and being assigned microtasks that gives "them" total control over my workday while I have no idea what "they" are doing the whole day. Scrum was the reason why I left my last company and I'm much happier now in my new company, where we do not have any process at all, just a common goal. Instead of standups, the team gathers for a coffee in the morning. If I want to spend 3 days learning a new framework that might do the product good, nobody cares. The only thing that counts is the endresult. That means we are beating the product into submission until its good, even if it means rewriting the thing three times and missing deadlines. So no more Scrum for me. Never.

shinycode 6y ago
Amen to that
lloydjones 6y ago
100% agree with this.
jamesrr39 6y ago
I found this really depends how "scrum" is implemented. Personally as a developer I like several features of scrum: - regular retrospectives, for improving the process - regular demos, for having a continuous process showing value and that we are aligned with the companies goals (anybody who thinks the development team have done nothing for the last x months can simply be pointed to the demo recordings page on the intranet) - some kind of short regular meeting throughout the sprint to update the PO ("daily standup", but does not necessarily need to be daily, or standing up), who can reset expectations, as opposed to announcing at the last minute it won't be ready. - and a regular planning session with the product owner to work with them to figure out how to bring value to the business quicker, push back on things that aren't that valuable, etc. But of course this really depends on how the process is implemented and the environment you're in. If retrospectives and demos are often cancelled because "we need to ship this feature to this customer now!", if the daily standups become all about "why is this not done yet, how much longer will it take" rather than an honest peer-to-peer "are we on track for delivering this, what does the PO need to find out/inform stakeholders of/what blockers are there" and the PO doesn't include development staff in the backlog refinement and just dumps tasks on the development team, then yes, you will have an experience that sucks. So as a developer, I like doing scrum when it is implemented in a way that the dev team and PO are viewed as peers and we don't skip any of the meetings. And I hate doing scrum when it's essentially just being given a load of tasks that I have no say over, no retrospective to improve things, etc. YMMV (depending greatly on the setup/environment you are working in, I think) (edit for formatting)
- mattmanser 6y ago
  Otherwise known as "I like doing scrum when it's not scrum but a totally different, less onerous, process I've incorrectly identified as scrum"
  - Mauricebranagh 6y ago
    If you think SCRUM (done well or at least competently) is onerous then I am afraid your not doing SCRUM properly
    - occz 6y ago
      No true Scrumsman?
      - WJW 6y ago
        Every time this topic comes up on HN it devolves into "if you think it's bad you are not doing it correctly". Perhaps everyone is indeed doing it wrong, but when 90+% of the intended audience is "doing it wrong" it might also be the case that the system is either too difficult too learn for most teams or the system does not match the incentives imposed by the environment it is typically deployed into.
        BlargMcLarg 6y ago
        To add onto this: the argument of "you're doing it wrong" would never pass a usability or safety test, but this gets conveniently glossed over whenever the Scrum debate comes. Trying to wave the point away just makes matters worse. If that crowd believes this point is moot, they should actually defend why the 90% doing it wrong doesn't have any significance.
        benji-york 6y ago
        > If that crowd believes this point is moot, they should actually defend why the 90% doing it wrong doesn't have any significance. I have a lot of sympathy for this perspective. I also notice that 90% of everyone does everything wrong. I don't know how to reconcile those two observations.
frobisher 6y ago
I see what you mean, and perhaps many/most standups feel pedantic. But more generally, even in the total absence of "managers" and non-techies, communication is a good thing? Teams not individuals create great projects. Adhoc comms are great, but catching up with other technical folk casually over coffee daily for a couple mins (not more!) seems like a good idea? Perhaps it's more the pedantic _format_ or feel of most standups that are what's terrible?
- mattmanser 6y ago
  Teams are supposed to be self-organising in Agile. When you implement an anti-agile process such as SCRUM and don't let the developers choose how to communicate, then no, it's not true that more communication is better.
  - hvidgaard 6y ago
    Scrum is only anti agile if you read the guide and think it must be done exactly by the book. Scrum dictate Planning, Review, Daily and Retrospective. How you do planning, review daily and retrospective is fluid and often adapted during retrospective. When you start you do it by the book and morph it into what suits the team and organization best.
    - mattmanser 6y ago
      Individuals and interactions over processes and tools It's the first thing in the agile manifesto. The FIRST. And yet here you are talking about processes and tools and claiming it's still agile.
      - azangru 6y ago
        > And yet here you are talking about processes and tools First, the Agile Manifesto is not rejecting "the items on the right". It recognizes their value. Second, the four principles of the Agile Manifesto are extremely general. It does not offer any recommendations on how to achieve the "items on the left". Scrum has a set of concrete recommendations for doing that. Third, scrum respects all the "items on the left" of the Agile Manifesto. It emphasizes the importance of "individuals and interactions", of "working software", of "customer collaboration", and of "responding to change", and offers a framework for achieving them.
fn1 6y ago
> The whole thing was designed to give non-technical people more power over the ones who spent a lifetime honing their craftmanship. Interesting that it's never mentioned that Jeff Sutherland and Ken Schwaber, the creators of SCRUM both come from the military. In my experience SCRUM delays and systematizes everything and kills creativity. Kind of like the military.
- WJW 6y ago
  > In my experience SCRUM delays and systematizes everything and kills creativity. Kind of like the military. Systematizing everything and killing creativity is an essential part of making software projects less risky for companies. One of the largest risks to many software projects is the "bus factor" risk, where one employee leaving will scupper the entire project because they were the only ones who knew how it worked. If you have large sums of money riding on the success of a project, it makes sense to invest some time in processes that can mitigate the effect of one team member leaving. It's no surprise that these processes mimic the military, armies are entirely built around the idea that anyone can die at any moment without much impact on the mission.
- Mauricebranagh 6y ago
  Your basing this on what military / historical experience? At the sharp end of a military I certainly see SCRUM/RAD/DSDM as analogous to the ww2 German style of pushing tactical decisions down to a lower level rather than rigid command from above ala the French.
- humbleMouse 6y ago
  Another thing nobody talks about much is that Executives and VP level people love to hire people from the military, because they do exactly what you tell them and rule with an iron fist. Im sure there are ex-military people who are chill, but ive seen some insane ones running tech verticals in the past.
ozim 6y ago
I have totally opposite experience from what you wrote. We have fast changing application and we use scrum and sprints to fend off business people. Because one day they want one thing, next day 10 things more. With sprint I can tell them to go away and make priorities because team is not capable of handling those 10 more tasks. Which in turn makes it predictable for business people because they know my team will be able to put those 10 things in next sprint (if those are soooo important, which later always turns out not really) and have it ready in production in 4-6 weeks. With product owner and "refinement meetings" I don't have business/sales people coming to me with stupid ideas and trying to force me to implement something. They have to put more work in it so that I get structured stream of work, of course it is not always perfect but better than random sales hitting you with something by your desk. What is important I have my team "burn down rate" which helps to communicate it clearly and they cannot argue with the number. Other important part is that estimations are done by dev team and I think important part is that our management is not arguing with the estimations. They show trust in developers and are not trying to push down estimations or improve burn down. So in my view my team has more power over the process not the managers. What managers/sales get form it is clear information that they can use in their work. Unfortunately I don't think it is the case for much companies.
- gregoriol 6y ago
  It seems like your team is at war within your own company. You are actually building a wall! That doesn't feel right, and doesn't feel any more positive than what the previous comment was describing.
  - lifeisstillgood 6y ago
    Perhaps think of it more as a cell wall - some things can pass through by osmosis, but ti is a much more controlled thing.
  - pulse7 6y ago
    I don't see it as a wall, but defined order (how new tasks are put into the queue) instead of chaos (when sales people come directly to the developer's desk and order new requests without others involved)...
gregoriol 6y ago
Your experience is not about Scrum, but about a poorly implemented management: the process or tools proposed by Scrum (or Agile) is there to help the team, and allow to do, make their magic, not to micro-manage and assign tasks. Your previous team clearly failed at it, or we should say it succeeded at using a trending keyword to make their own agenda. Your new team example doesn't seem much better to me: even-though the freedom you like is what should be, the lack of process can't work in any reasonable even middle-size team. The process is not about slowing you down or giving power to management: it should be there to help you as a team member keep the vision and target, and sharing. How would you know how to collaborate with others on the team if you don't have any way to know what they are doing or how would you improve your creativity if you don't have any feedback on what you are doing?
lifeisstillgood 6y ago
But, ironically, you are being 'Agile' in this new role. I mean the term is sooo elastic it is hardly meaningful, but if you have a high skilled team, with clear shared concrete goals, producing code at pace, where the code is the measure of progress then that meets pretty much all the things that got written down in the Manifesto. The fact that the manifest is just an observation of what we all know - how it feels to do really good work in a team, well, great. The problem with Agile / work / life is that its hard to get all those pieces together and just as hard to maintain. I think Programmer Anarchy is closest to the right idea. Get a bunch of (skilled) programmers together and give them a direction. But it is called anarchy to emphasise the idea you cannot have non-programmers in charge, or an organisational hierarchy getting in the way. Changing that is what derails almost all Agile projects - its why Acqui-hires fail to keep the esprit d'corps, its why startups slowdown as they grow, its why steam engines were great before the factories, its ... humans aren't good at letting emergent order handle their day to day lives. tl;dr - its not Agile or Scrum. Its us - its the difficulty of organising humans, its the constant fight against entropy, its scale and centralised planning vs letting the market decide. We should all probably live and work under the Dunbar number, and allow markets to find where value is created. I see ledgers as enabling that. The supply chain will set us free.
Nursie 6y ago
> The whole thing was designed to give non-technical people more power over the ones who spent a lifetime honing their craftmanship. Standing around a table in the morning like assholes is not my idea of fun The morning standup works great when it's all technical people. Keeps the team up to date with each others' progress and cuts down on "I spent three weeks being stuck" problems. Here's what I'm doing, and what I'm doing next, here's what I need a little help on. When management get involved and the meeting starts with jira thrown up on the screen, sure, then it's terrible. > If I want to spend 3 days learning a new framework that might do the product good, nobody cares. The only thing that counts is the endresult. Here's the problem with that, not every schedule can take that 3 day lag, and someone has to make a decision about whether the product actually needs that new framework, or if it's going to be good enough without. Maybe you're great at making those decisions, but I've seen many times when people end up going off down rabbitholes either just chasing something shiny, or through a sense of perfectionism that actually holds back release.
- zeroc8 6y ago
  The morning coffee also works great. I really do not understand why there is a need for formalism here. There is a meeting for what's planned for the week. There are the informal gatherings, like lunch. And if someone is stuck with something, he or she just asks for help. Easy as that.
  - Nursie 6y ago
    It helps to give a forum to bring up being stuck, and an opportunity for others to hear it when they're not caught up in the middle of their own stuff. Plus some people don't know when to ask for help, or when they're (for instance) duplicating effort. Informal gatherings are not an appropriate venue - if this stuff only comes up then, then lunch gatherings are now work, and they're mandatory.
    - atomashpolskiy 6y ago
      > Plus some people don't know when to ask for help, or when they're (for instance) duplicating effort. This is the gist of it. Some people just have this (very sincere) belief that everyone else are clueless idiots and need to be nurtured, protected and helped. This is the spirit of our age, and Scrum in particular is just another manifestation of this belief.
cauliflower99 6y ago
Sounds like zombie scrum. A good scrum team will be self-driven. Micro-management from external sources is an anti-pattern and usually means you have a poor scrum master who doesn't understand that their job is to protect their team.
mmcnl 6y ago
I think the goal of scrum is exactly what you are striving for: to only have the end result count. If you can achieve this without a process, that's great. However, that puts a big responsibility on the developer: you need to weigh development effort against business benefits and really try to understand the customer. If you are up for it and capable of it, that's great, then you don't need scrum or any framework. You are then the owner, period. However, in my experience, most developers do not really care about the business side of things. Also there expertise is often not in prioritizing development efforts to maximize business value. So I can completely understand what you are saying, but most developers are not you (in my experience) and they do not naturally own the things they create.
Malisman 6y ago
Heheh, you are clearly doing it wrong. 1) Non-technical people outside do not get the power. On the contrary its the team that gets much more power. The team is in charge of doing the planning, etc. If the team says: "we will deliver in 2 weeks", manager has no power to force them. Unless he says something like: "ok, in that case I do not need it and do this one instead - that will bring more money". 2) You do not have to stand for the daily. Some teams do it so it involves a little bit of exercise. But you can just as well lean or sit with your coffee and casually share your progress. Like a kitchen talk. 3) Product owner does not OWN your code you fool :D You are the owner. Product owner commands the product. So if you implement a message queue thats great, you can be proud. But was it really needed? Does it bring any money, stability, a value in general to the product? That is something that usually you cannot answer, because you are focused on the quality of the code and do not care about the bullshit numbers right? But in case you do, you are aware of the whole situation, the market, all the customers etc. and you engage in that part, then you are super senior team member, you are self-organized and you actually do not need a product owner. That is like endgoal for Scrum. To create such teams (with such great and senior team members). 4) Scrum does not prevents you from rewriting the code until its perfect. Like where did you get that twisted idea? Scrum even says that tech debt (bad code, needs refactoring, etc.) is incredibly dangerous and should be avoided! Simply put, if you and/or people in your team and around are assholes that push just for the deadlines (and bureocracy) and do not care about the quality, that is completely 100% on you/them, not on Scrum. Scrum tells you NOT to do it and gives you the power to resist people that are trying to force you to do it like that. Scrum encourages you to share the knowledge and work with others to produce better quality and make your day more easier, comfortable without micromanaging, etc.
- anaerobicover 6y ago
  Everything you said is great, but it's not how it plays out for a lot of developers. The people and the politics don't go away because some rules have nominally been adopted. Politically adept people¹ in manager/PO roles will continue to pretend they're following the rules while doing whatever they damn well please. And when what they please is to micromanage or worse, the developers haven't suddenly gained people savvy because of these rules. They will have just as much trouble fending off the problems as before. Possibly more, in fact, because the (Scrum) rules can be used as cover. Or lead the developers to believe they're protected by the rules, so they don't need to be aware of politics. --- ¹"Sociopaths" if you will, but in the "Gervais Principle" meaning, not the DSM.
g051051 6y ago
I've never met an actual, real developer (not manager or business wonk) who actually liked Agile. At most, people seem to tolerate it.
- NotPavlovsDog 6y ago
  I don't like Agile when it's sold as such. I absolutely refuse to discuss Agile with certificate peddlers. SAFe is the worst of the bunch, with expiring certificates, they make money on renewal. I'm a developer now managing product. if you apply a historical analysis perspective, Agile has either influenced our process, or our process may be described as post-Agile. We have a backlog, organized by priority. We have self-organizing teams. Teams make their own planning and own their backlog. I, as the person responsible for product, take time meeting the people involved in making the product work in the market. Such as legal, finance, etc etc. The team does not have to participate in this, but they are welcome to. What I have fought hard for is to not have management push tech stacks at teams. Developers get to decide, unless there is a legacy situation, and then they get to decide if they want to work with it. And we have a clearly defined org culture. That's as in who gets paid more, promoted, and why. The developers have a higher-than average salary (algo for market value known to all and published internally), a % set bonus from total net, and an option to go for a higher % of bonuses by forgoing some of their salary. Some people like a known salary, some prefer a chance for a higher pay-out with more risk involved. I'm writing a master's thesis on project management at the moment, part-time, and have had to do entirely too much reading up on Agile and project management history. Like I wrote, we can absolutely be classified as Agile. We just don't have it pushed down our throats, and we have a realistic culture - our part of the business is dependent on excellent developers, we treat them with respect, give them decision-making power, offer a share of the profits, and expect them to care about the product as a whole and their part in it. If the "Agile" you have been exposed to does not treat developers with respect, nor establish a mutually beneficial organizational culture, the market will sort the organization out, as long as developers remain a crucial part of the equation.
- lukeasrodgers 6y ago
  I am a real developer who likes agile, nice to meet you :)
DocTomoe 6y ago
Actually, SCRUM was designed to make software dev teams less dependant on management. The problem you describe arose when consultancies decided that this is something that can be wrapped in a powerpoint lsidedeck and sold as "more results faster" to top management for $$$. That being said, I do not think from your description you have experienced either SCRUM nor Agile.
swiley 6y ago
It forces junior engineers to communicate which is great when you're still learning. Also some people really need "microtasks." IMO: Agile produces worse software but when done correctly with a reasonable boss the work environment it produces is much simpler socially.
snarf21 6y ago
One thing I've learned over a long career in software is that a "bad" process that is followed precisely with top to bottom buy-in will always out perform the "best" process with lots of exceptions and lukewarm buy-in. If you want something like Scrum or agile to work, you must have technical project managers that are independent and, quite frankly, they need to be assholes holding both the tech side and the business side equally accountable.
gjmacd 6y ago
I came from the company that virtually invented Scrum (Easel Corp / Jeff Sutherland) -- showing my age now, I assure you -- it wasn't invented to give non-technical people the power over developers. In fact, it was quite the opposite. It was created to help developers ensure that their lives could be validated in the timebox of work that was required of them. No offense, but you need to probably work in a better Scrum environment. Sounds like you haven't experienced Scrum properly.
- mempko 6y ago
  Exactly. As far as I know, scrum doesn't have managers. Just don't tell that to the managers ;-)
  - gjmacd 6y ago
    as soon as he went all "the managers", i knew he'd been poorly educated around Scrum. The funny think about Scrum is that upper management doesn't like it. They'd rather operate in a waterfall approach because they can blow up roadmaps and not have any trace of the offense. With Scrum, you can do the "Ok, but that will require you remove X points from this Sprint and replace that work." Which has a check and balance on that sort of problem when someone wants something unplanned or changes scope on things. Scrum's s a tool to ensure that you have some level of "management" for the management but also it demonstrates how developers aren't always magicians. That's what people who don't like Agile/Scrum don't quite get.
AlunAlun 6y ago
> If I develop something, I am the owner. Funnily enough, it's precisely this attitude which has led to the creation of the product owner role, and Scrum in general. Most developers I know are emphatically NOT good product people (despite what they may think). A good product owner is quite difficult to find, as they need to combine: i) a user-centric view of what the product needs to be, ii) a business-centric view of what needs to be released, and when, iii) a developer-centric view to make the 'best' product, from a programming perspective, and looking towards the long-term. > That means we are beating the product into submission until its good, even if it means rewriting the thing three times and missing deadlines This is all well and good until a competitor launches before you (with an inferior product), takes all your market share, and when you eventually launch you're having to play catch-up trying to steal clients. Meanwhile the competitor is reinvesting their initial revenue in making their product better to match yours, which means they keep their clients, keep getting revenue, investment etc. You may have a better product, but you'll end up going bust.
- Woden501 6y ago
  +1 to your third point especially. I'll even add that Agile development can be a big bonus in any market that has the potential for rapidly changing needs. Even if you don't lose out to your faster competition you may still end up releasing to a market that's no longer looking for the solution that you "perfected". Agile development allowing you to release a functional product as soon as possible, and adding to it as resources allow means you can pivot your development to meet new demands instead of bogging yourself down trying to produce the perfect solution to a problem that continues to evolve.
- carmen_sandiego 6y ago
  I think it's possible to have rapid releases without all the typical trappings of scrum. See: Facebook, who are decidedly not bust. Maybe the answer is just 'hire better engineers'. Where better means they're good at the product decisions too.
cybernoodles 6y ago
I really haven't experienced this sentiment. It sounds like you had a bad experience. Scrum can be amazing depending on who is implementing it. Even 7 years ago at AWS, micromanagement wasn't and couldn't afford to be a thing, yet we were most definitely a Scrum team. It was what held us together despite the lack of management. Yeah there would be arguments between PMs and devs, but that is healthy, and most often the PMs lost said arguments. Everyone was placed adjacent to one another, and I adjacent to the project manager, which gave ample time for arguments, but in a way that was better for the team as a whole. It introduced a sort of democracy with continual meetings to ensure that we were working efficiently at any given time.
JTKJTK 6y ago
I don't want to be "that guy" but everything you're describing above is not a symptom of Scrum per se but of a toxic working culture. Scrum does not suggest micromanagement or assigning tasks, the goal is for the team to be given a goal and work out what is needed to be done to achieve it. The team works together, no passing back and forth. As for the PO being a "they" that's something that needs to be addressed. I'm not going to assume ill intent on your part, so let's assume this is again a symptom of a poorly performing team rather than you (or the PO) being unreasonable. But also bear in mind that the PO going off doing "stuff" is generally supposed to be all those things that get in the way of development, e.g. talking to stakeholders & customers, addressing prioritisation problems and trying to prevent the team being overwhelmed with too many goals at the same time. I'm definitely not saying that micromanagement doesn't happen but I'm saying that you could take your new company's approach (no processes, just let the devs do anything) to the old company and you would have many more problems. It all, as ever, boils down to working culture and practices, and a company that is agile in name only. You can't fix that by splitting things into 2 week chunks and making people talk to each other once a day.
- zeroc8 6y ago
  We do have a process. But it's less formal. Weekly meetings, priority lists, technical discussions, business discussions. If a problem comes up, we just talk to each other. It's easy and makes for a pleasant environment.
opportune 6y ago
Agree completely, for a period of time I was working scrumless and quite happy with it. Got a new manager and some new tech leads join and suddenly we need several stand ups, scrums, and checkins because they don’t know how else to figure out what’s going on. It sucks. I’ve never witnessed “I’m having trouble on this” -> “Oh I ran into that before, have you seen X” in an official Scrum. Official Scrums are just status updates for your manager/other authority figure. We’re also cargo culting other processes (sprint planning) that don’t even fit in with how our company does planning - we do everything quarterly, most tasks aren’t really re-assignable - so it’s just a shaming session for people who underestimated task lengths or are running behind.
zoomablemind 6y ago
I see the Product Owner role the most critical for the success of Scrum in general. This is for PO's simple yet not given properties - vision about the product, vision of success, and the ability to express this. Everybody else in Scrum is depended on the PO's abilities. One can train to improve the expression and prioritization skills, but it's very hard to train to develop or (even to appropriate) a vision about the product and the success. This becomes even more acute in corporate environment, most PO are recast from former Project or Product Managers, who by definitions are Managers, not visionaries, nor intended customers of the product. As a result, that critical element - the product vision - simply cannot be shared. It's just another "Quarterly Goal" in disguise - "the stonk must up!". So the corpo-Scrum has a greater chance to devolve into shared lack of vision and collaboration theater. One could paraphrase "Show me your PO, and I will tell what your Scrum is".
SergeAx 6y ago
> If I develop something, I am the owner. How do you, as a product owner, coming up with new features? How do you, as a product owner, prioritize one feature over other?
wayeq 6y ago
by any chance is your new company hiring?
Zedronar 6y ago
> in my new company, where we do not have any process at all, just a common goal. Instead of standups, the team gathers for a coffee in the morning. If I want to spend 3 days learning a new framework that might do the product good, nobody cares. The only thing that counts is the endresult. That means we are beating the product into submission until its good, even if it means rewriting the thing three times and missing deadlines. So no more Scrum for me. Never. I love this. Mind sharing the name of the company?

by zeroc8 6y ago

shinycode 6y ago

Amen to that

lloydjones 6y ago

100% agree with this.

jamesrr39 6y ago

I found this really depends how "scrum" is implemented. Personally as a developer I like several features of scrum: - regular retrospectives, for improving the process - regular demos, for having a continuous process showing value and that we are aligned with the companies goals (anybody who thinks the development team have done nothing for the last x months can simply be pointed to the demo recordings page on the intranet) - some kind of short regular meeting throughout the sprint to update the PO ("daily standup", but does not necessarily need to be daily, or standing up), who can reset expectations, as opposed to announcing at the last minute it won't be ready. - and a regular planning session with the product owner to work with them to figure out how to bring value to the business quicker, push back on things that aren't that valuable, etc. But of course this really depends on how the process is implemented and the environment you're in. If retrospectives and demos are often cancelled because "we need to ship this feature to this customer now!", if the daily standups become all about "why is this not done yet, how much longer will it take" rather than an honest peer-to-peer "are we on track for delivering this, what does the PO need to find out/inform stakeholders of/what blockers are there" and the PO doesn't include development staff in the backlog refinement and just dumps tasks on the development team, then yes, you will have an experience that sucks. So as a developer, I like doing scrum when it is implemented in a way that the dev team and PO are viewed as peers and we don't skip any of the meetings. And I hate doing scrum when it's essentially just being given a load of tasks that I have no say over, no retrospective to improve things, etc. YMMV (depending greatly on the setup/environment you are working in, I think) (edit for formatting)

mattmanser 6y ago
Otherwise known as "I like doing scrum when it's not scrum but a totally different, less onerous, process I've incorrectly identified as scrum"
- Mauricebranagh 6y ago
  If you think SCRUM (done well or at least competently) is onerous then I am afraid your not doing SCRUM properly
  - occz 6y ago
    No true Scrumsman?
    - WJW 6y ago
      Every time this topic comes up on HN it devolves into "if you think it's bad you are not doing it correctly". Perhaps everyone is indeed doing it wrong, but when 90+% of the intended audience is "doing it wrong" it might also be the case that the system is either too difficult too learn for most teams or the system does not match the incentives imposed by the environment it is typically deployed into.
      - BlargMcLarg 6y ago
        To add onto this: the argument of "you're doing it wrong" would never pass a usability or safety test, but this gets conveniently glossed over whenever the Scrum debate comes. Trying to wave the point away just makes matters worse. If that crowd believes this point is moot, they should actually defend why the 90% doing it wrong doesn't have any significance.
        benji-york 6y ago
        > If that crowd believes this point is moot, they should actually defend why the 90% doing it wrong doesn't have any significance. I have a lot of sympathy for this perspective. I also notice that 90% of everyone does everything wrong. I don't know how to reconcile those two observations.

frobisher 6y ago

I see what you mean, and perhaps many/most standups feel pedantic. But more generally, even in the total absence of "managers" and non-techies, communication is a good thing? Teams not individuals create great projects. Adhoc comms are great, but catching up with other technical folk casually over coffee daily for a couple mins (not more!) seems like a good idea? Perhaps it's more the pedantic _format_ or feel of most standups that are what's terrible?

mattmanser 6y ago
Teams are supposed to be self-organising in Agile. When you implement an anti-agile process such as SCRUM and don't let the developers choose how to communicate, then no, it's not true that more communication is better.
- hvidgaard 6y ago
  Scrum is only anti agile if you read the guide and think it must be done exactly by the book. Scrum dictate Planning, Review, Daily and Retrospective. How you do planning, review daily and retrospective is fluid and often adapted during retrospective. When you start you do it by the book and morph it into what suits the team and organization best.
  - mattmanser 6y ago
    Individuals and interactions over processes and tools It's the first thing in the agile manifesto. The FIRST. And yet here you are talking about processes and tools and claiming it's still agile.
    - azangru 6y ago
      > And yet here you are talking about processes and tools First, the Agile Manifesto is not rejecting "the items on the right". It recognizes their value. Second, the four principles of the Agile Manifesto are extremely general. It does not offer any recommendations on how to achieve the "items on the left". Scrum has a set of concrete recommendations for doing that. Third, scrum respects all the "items on the left" of the Agile Manifesto. It emphasizes the importance of "individuals and interactions", of "working software", of "customer collaboration", and of "responding to change", and offers a framework for achieving them.

fn1 6y ago

> The whole thing was designed to give non-technical people more power over the ones who spent a lifetime honing their craftmanship. Interesting that it's never mentioned that Jeff Sutherland and Ken Schwaber, the creators of SCRUM both come from the military. In my experience SCRUM delays and systematizes everything and kills creativity. Kind of like the military.

WJW 6y ago
> In my experience SCRUM delays and systematizes everything and kills creativity. Kind of like the military. Systematizing everything and killing creativity is an essential part of making software projects less risky for companies. One of the largest risks to many software projects is the "bus factor" risk, where one employee leaving will scupper the entire project because they were the only ones who knew how it worked. If you have large sums of money riding on the success of a project, it makes sense to invest some time in processes that can mitigate the effect of one team member leaving. It's no surprise that these processes mimic the military, armies are entirely built around the idea that anyone can die at any moment without much impact on the mission.
Mauricebranagh 6y ago
Your basing this on what military / historical experience? At the sharp end of a military I certainly see SCRUM/RAD/DSDM as analogous to the ww2 German style of pushing tactical decisions down to a lower level rather than rigid command from above ala the French.
humbleMouse 6y ago
Another thing nobody talks about much is that Executives and VP level people love to hire people from the military, because they do exactly what you tell them and rule with an iron fist. Im sure there are ex-military people who are chill, but ive seen some insane ones running tech verticals in the past.

ozim 6y ago

I have totally opposite experience from what you wrote. We have fast changing application and we use scrum and sprints to fend off business people. Because one day they want one thing, next day 10 things more. With sprint I can tell them to go away and make priorities because team is not capable of handling those 10 more tasks. Which in turn makes it predictable for business people because they know my team will be able to put those 10 things in next sprint (if those are soooo important, which later always turns out not really) and have it ready in production in 4-6 weeks. With product owner and "refinement meetings" I don't have business/sales people coming to me with stupid ideas and trying to force me to implement something. They have to put more work in it so that I get structured stream of work, of course it is not always perfect but better than random sales hitting you with something by your desk. What is important I have my team "burn down rate" which helps to communicate it clearly and they cannot argue with the number. Other important part is that estimations are done by dev team and I think important part is that our management is not arguing with the estimations. They show trust in developers and are not trying to push down estimations or improve burn down. So in my view my team has more power over the process not the managers. What managers/sales get form it is clear information that they can use in their work. Unfortunately I don't think it is the case for much companies.

gregoriol 6y ago
It seems like your team is at war within your own company. You are actually building a wall! That doesn't feel right, and doesn't feel any more positive than what the previous comment was describing.
- lifeisstillgood 6y ago
  Perhaps think of it more as a cell wall - some things can pass through by osmosis, but ti is a much more controlled thing.
- pulse7 6y ago
  I don't see it as a wall, but defined order (how new tasks are put into the queue) instead of chaos (when sales people come directly to the developer's desk and order new requests without others involved)...

gregoriol 6y ago

Your experience is not about Scrum, but about a poorly implemented management: the process or tools proposed by Scrum (or Agile) is there to help the team, and allow to do, make their magic, not to micro-manage and assign tasks. Your previous team clearly failed at it, or we should say it succeeded at using a trending keyword to make their own agenda. Your new team example doesn't seem much better to me: even-though the freedom you like is what should be, the lack of process can't work in any reasonable even middle-size team. The process is not about slowing you down or giving power to management: it should be there to help you as a team member keep the vision and target, and sharing. How would you know how to collaborate with others on the team if you don't have any way to know what they are doing or how would you improve your creativity if you don't have any feedback on what you are doing?

lifeisstillgood 6y ago

But, ironically, you are being 'Agile' in this new role. I mean the term is sooo elastic it is hardly meaningful, but if you have a high skilled team, with clear shared concrete goals, producing code at pace, where the code is the measure of progress then that meets pretty much all the things that got written down in the Manifesto. The fact that the manifest is just an observation of what we all know - how it feels to do really good work in a team, well, great. The problem with Agile / work / life is that its hard to get all those pieces together and just as hard to maintain. I think Programmer Anarchy is closest to the right idea. Get a bunch of (skilled) programmers together and give them a direction. But it is called anarchy to emphasise the idea you cannot have non-programmers in charge, or an organisational hierarchy getting in the way. Changing that is what derails almost all Agile projects - its why Acqui-hires fail to keep the esprit d'corps, its why startups slowdown as they grow, its why steam engines were great before the factories, its ... humans aren't good at letting emergent order handle their day to day lives. tl;dr - its not Agile or Scrum. Its us - its the difficulty of organising humans, its the constant fight against entropy, its scale and centralised planning vs letting the market decide. We should all probably live and work under the Dunbar number, and allow markets to find where value is created. I see ledgers as enabling that. The supply chain will set us free.

Nursie 6y ago

> The whole thing was designed to give non-technical people more power over the ones who spent a lifetime honing their craftmanship. Standing around a table in the morning like assholes is not my idea of fun The morning standup works great when it's all technical people. Keeps the team up to date with each others' progress and cuts down on "I spent three weeks being stuck" problems. Here's what I'm doing, and what I'm doing next, here's what I need a little help on. When management get involved and the meeting starts with jira thrown up on the screen, sure, then it's terrible. > If I want to spend 3 days learning a new framework that might do the product good, nobody cares. The only thing that counts is the endresult. Here's the problem with that, not every schedule can take that 3 day lag, and someone has to make a decision about whether the product actually needs that new framework, or if it's going to be good enough without. Maybe you're great at making those decisions, but I've seen many times when people end up going off down rabbitholes either just chasing something shiny, or through a sense of perfectionism that actually holds back release.

zeroc8 6y ago
The morning coffee also works great. I really do not understand why there is a need for formalism here. There is a meeting for what's planned for the week. There are the informal gatherings, like lunch. And if someone is stuck with something, he or she just asks for help. Easy as that.
- Nursie 6y ago
  It helps to give a forum to bring up being stuck, and an opportunity for others to hear it when they're not caught up in the middle of their own stuff. Plus some people don't know when to ask for help, or when they're (for instance) duplicating effort. Informal gatherings are not an appropriate venue - if this stuff only comes up then, then lunch gatherings are now work, and they're mandatory.
  - atomashpolskiy 6y ago
    > Plus some people don't know when to ask for help, or when they're (for instance) duplicating effort. This is the gist of it. Some people just have this (very sincere) belief that everyone else are clueless idiots and need to be nurtured, protected and helped. This is the spirit of our age, and Scrum in particular is just another manifestation of this belief.

cauliflower99 6y ago

Sounds like zombie scrum. A good scrum team will be self-driven. Micro-management from external sources is an anti-pattern and usually means you have a poor scrum master who doesn't understand that their job is to protect their team.

mmcnl 6y ago

I think the goal of scrum is exactly what you are striving for: to only have the end result count. If you can achieve this without a process, that's great. However, that puts a big responsibility on the developer: you need to weigh development effort against business benefits and really try to understand the customer. If you are up for it and capable of it, that's great, then you don't need scrum or any framework. You are then the owner, period. However, in my experience, most developers do not really care about the business side of things. Also there expertise is often not in prioritizing development efforts to maximize business value. So I can completely understand what you are saying, but most developers are not you (in my experience) and they do not naturally own the things they create.

Malisman 6y ago

Heheh, you are clearly doing it wrong. 1) Non-technical people outside do not get the power. On the contrary its the team that gets much more power. The team is in charge of doing the planning, etc. If the team says: "we will deliver in 2 weeks", manager has no power to force them. Unless he says something like: "ok, in that case I do not need it and do this one instead - that will bring more money". 2) You do not have to stand for the daily. Some teams do it so it involves a little bit of exercise. But you can just as well lean or sit with your coffee and casually share your progress. Like a kitchen talk. 3) Product owner does not OWN your code you fool :D You are the owner. Product owner commands the product. So if you implement a message queue thats great, you can be proud. But was it really needed? Does it bring any money, stability, a value in general to the product? That is something that usually you cannot answer, because you are focused on the quality of the code and do not care about the bullshit numbers right? But in case you do, you are aware of the whole situation, the market, all the customers etc. and you engage in that part, then you are super senior team member, you are self-organized and you actually do not need a product owner. That is like endgoal for Scrum. To create such teams (with such great and senior team members). 4) Scrum does not prevents you from rewriting the code until its perfect. Like where did you get that twisted idea? Scrum even says that tech debt (bad code, needs refactoring, etc.) is incredibly dangerous and should be avoided! Simply put, if you and/or people in your team and around are assholes that push just for the deadlines (and bureocracy) and do not care about the quality, that is completely 100% on you/them, not on Scrum. Scrum tells you NOT to do it and gives you the power to resist people that are trying to force you to do it like that. Scrum encourages you to share the knowledge and work with others to produce better quality and make your day more easier, comfortable without micromanaging, etc.

anaerobicover 6y ago
Everything you said is great, but it's not how it plays out for a lot of developers. The people and the politics don't go away because some rules have nominally been adopted. Politically adept people¹ in manager/PO roles will continue to pretend they're following the rules while doing whatever they damn well please. And when what they please is to micromanage or worse, the developers haven't suddenly gained people savvy because of these rules. They will have just as much trouble fending off the problems as before. Possibly more, in fact, because the (Scrum) rules can be used as cover. Or lead the developers to believe they're protected by the rules, so they don't need to be aware of politics. --- ¹"Sociopaths" if you will, but in the "Gervais Principle" meaning, not the DSM.

g051051 6y ago

I've never met an actual, real developer (not manager or business wonk) who actually liked Agile. At most, people seem to tolerate it.

NotPavlovsDog 6y ago
I don't like Agile when it's sold as such. I absolutely refuse to discuss Agile with certificate peddlers. SAFe is the worst of the bunch, with expiring certificates, they make money on renewal. I'm a developer now managing product. if you apply a historical analysis perspective, Agile has either influenced our process, or our process may be described as post-Agile. We have a backlog, organized by priority. We have self-organizing teams. Teams make their own planning and own their backlog. I, as the person responsible for product, take time meeting the people involved in making the product work in the market. Such as legal, finance, etc etc. The team does not have to participate in this, but they are welcome to. What I have fought hard for is to not have management push tech stacks at teams. Developers get to decide, unless there is a legacy situation, and then they get to decide if they want to work with it. And we have a clearly defined org culture. That's as in who gets paid more, promoted, and why. The developers have a higher-than average salary (algo for market value known to all and published internally), a % set bonus from total net, and an option to go for a higher % of bonuses by forgoing some of their salary. Some people like a known salary, some prefer a chance for a higher pay-out with more risk involved. I'm writing a master's thesis on project management at the moment, part-time, and have had to do entirely too much reading up on Agile and project management history. Like I wrote, we can absolutely be classified as Agile. We just don't have it pushed down our throats, and we have a realistic culture - our part of the business is dependent on excellent developers, we treat them with respect, give them decision-making power, offer a share of the profits, and expect them to care about the product as a whole and their part in it. If the "Agile" you have been exposed to does not treat developers with respect, nor establish a mutually beneficial organizational culture, the market will sort the organization out, as long as developers remain a crucial part of the equation.
lukeasrodgers 6y ago
I am a real developer who likes agile, nice to meet you :)

DocTomoe 6y ago

Actually, SCRUM was designed to make software dev teams less dependant on management. The problem you describe arose when consultancies decided that this is something that can be wrapped in a powerpoint lsidedeck and sold as "more results faster" to top management for $$$. That being said, I do not think from your description you have experienced either SCRUM nor Agile.

swiley 6y ago

It forces junior engineers to communicate which is great when you're still learning. Also some people really need "microtasks." IMO: Agile produces worse software but when done correctly with a reasonable boss the work environment it produces is much simpler socially.

snarf21 6y ago

One thing I've learned over a long career in software is that a "bad" process that is followed precisely with top to bottom buy-in will always out perform the "best" process with lots of exceptions and lukewarm buy-in. If you want something like Scrum or agile to work, you must have technical project managers that are independent and, quite frankly, they need to be assholes holding both the tech side and the business side equally accountable.

gjmacd 6y ago

I came from the company that virtually invented Scrum (Easel Corp / Jeff Sutherland) -- showing my age now, I assure you -- it wasn't invented to give non-technical people the power over developers. In fact, it was quite the opposite. It was created to help developers ensure that their lives could be validated in the timebox of work that was required of them. No offense, but you need to probably work in a better Scrum environment. Sounds like you haven't experienced Scrum properly.

mempko 6y ago
Exactly. As far as I know, scrum doesn't have managers. Just don't tell that to the managers ;-)
- gjmacd 6y ago
  as soon as he went all "the managers", i knew he'd been poorly educated around Scrum. The funny think about Scrum is that upper management doesn't like it. They'd rather operate in a waterfall approach because they can blow up roadmaps and not have any trace of the offense. With Scrum, you can do the "Ok, but that will require you remove X points from this Sprint and replace that work." Which has a check and balance on that sort of problem when someone wants something unplanned or changes scope on things. Scrum's s a tool to ensure that you have some level of "management" for the management but also it demonstrates how developers aren't always magicians. That's what people who don't like Agile/Scrum don't quite get.

AlunAlun 6y ago

> If I develop something, I am the owner. Funnily enough, it's precisely this attitude which has led to the creation of the product owner role, and Scrum in general. Most developers I know are emphatically NOT good product people (despite what they may think). A good product owner is quite difficult to find, as they need to combine: i) a user-centric view of what the product needs to be, ii) a business-centric view of what needs to be released, and when, iii) a developer-centric view to make the 'best' product, from a programming perspective, and looking towards the long-term. > That means we are beating the product into submission until its good, even if it means rewriting the thing three times and missing deadlines This is all well and good until a competitor launches before you (with an inferior product), takes all your market share, and when you eventually launch you're having to play catch-up trying to steal clients. Meanwhile the competitor is reinvesting their initial revenue in making their product better to match yours, which means they keep their clients, keep getting revenue, investment etc. You may have a better product, but you'll end up going bust.

Woden501 6y ago
+1 to your third point especially. I'll even add that Agile development can be a big bonus in any market that has the potential for rapidly changing needs. Even if you don't lose out to your faster competition you may still end up releasing to a market that's no longer looking for the solution that you "perfected". Agile development allowing you to release a functional product as soon as possible, and adding to it as resources allow means you can pivot your development to meet new demands instead of bogging yourself down trying to produce the perfect solution to a problem that continues to evolve.
carmen_sandiego 6y ago
I think it's possible to have rapid releases without all the typical trappings of scrum. See: Facebook, who are decidedly not bust. Maybe the answer is just 'hire better engineers'. Where better means they're good at the product decisions too.

cybernoodles 6y ago

I really haven't experienced this sentiment. It sounds like you had a bad experience. Scrum can be amazing depending on who is implementing it. Even 7 years ago at AWS, micromanagement wasn't and couldn't afford to be a thing, yet we were most definitely a Scrum team. It was what held us together despite the lack of management. Yeah there would be arguments between PMs and devs, but that is healthy, and most often the PMs lost said arguments. Everyone was placed adjacent to one another, and I adjacent to the project manager, which gave ample time for arguments, but in a way that was better for the team as a whole. It introduced a sort of democracy with continual meetings to ensure that we were working efficiently at any given time.

JTKJTK 6y ago

I don't want to be "that guy" but everything you're describing above is not a symptom of Scrum per se but of a toxic working culture. Scrum does not suggest micromanagement or assigning tasks, the goal is for the team to be given a goal and work out what is needed to be done to achieve it. The team works together, no passing back and forth. As for the PO being a "they" that's something that needs to be addressed. I'm not going to assume ill intent on your part, so let's assume this is again a symptom of a poorly performing team rather than you (or the PO) being unreasonable. But also bear in mind that the PO going off doing "stuff" is generally supposed to be all those things that get in the way of development, e.g. talking to stakeholders & customers, addressing prioritisation problems and trying to prevent the team being overwhelmed with too many goals at the same time. I'm definitely not saying that micromanagement doesn't happen but I'm saying that you could take your new company's approach (no processes, just let the devs do anything) to the old company and you would have many more problems. It all, as ever, boils down to working culture and practices, and a company that is agile in name only. You can't fix that by splitting things into 2 week chunks and making people talk to each other once a day.

zeroc8 6y ago
We do have a process. But it's less formal. Weekly meetings, priority lists, technical discussions, business discussions. If a problem comes up, we just talk to each other. It's easy and makes for a pleasant environment.

opportune 6y ago

Agree completely, for a period of time I was working scrumless and quite happy with it. Got a new manager and some new tech leads join and suddenly we need several stand ups, scrums, and checkins because they don’t know how else to figure out what’s going on. It sucks. I’ve never witnessed “I’m having trouble on this” -> “Oh I ran into that before, have you seen X” in an official Scrum. Official Scrums are just status updates for your manager/other authority figure. We’re also cargo culting other processes (sprint planning) that don’t even fit in with how our company does planning - we do everything quarterly, most tasks aren’t really re-assignable - so it’s just a shaming session for people who underestimated task lengths or are running behind.

zoomablemind 6y ago

I see the Product Owner role the most critical for the success of Scrum in general. This is for PO's simple yet not given properties - vision about the product, vision of success, and the ability to express this. Everybody else in Scrum is depended on the PO's abilities. One can train to improve the expression and prioritization skills, but it's very hard to train to develop or (even to appropriate) a vision about the product and the success. This becomes even more acute in corporate environment, most PO are recast from former Project or Product Managers, who by definitions are Managers, not visionaries, nor intended customers of the product. As a result, that critical element - the product vision - simply cannot be shared. It's just another "Quarterly Goal" in disguise - "the stonk must up!". So the corpo-Scrum has a greater chance to devolve into shared lack of vision and collaboration theater. One could paraphrase "Show me your PO, and I will tell what your Scrum is".

SergeAx 6y ago

> If I develop something, I am the owner. How do you, as a product owner, coming up with new features? How do you, as a product owner, prioritize one feature over other?

wayeq 6y ago

by any chance is your new company hiring?

Zedronar 6y ago

> in my new company, where we do not have any process at all, just a common goal. Instead of standups, the team gathers for a coffee in the morning. If I want to spend 3 days learning a new framework that might do the product good, nobody cares. The only thing that counts is the endresult. That means we are beating the product into submission until its good, even if it means rewriting the thing three times and missing deadlines. So no more Scrum for me. Never. I love this. Mind sharing the name of the company?