15 ms·

A brief list of what Scrum gets wrong

• deleted 9y ago
  [deleted]
• OnlyRepliesToBS 9y ago
  Consultant-driven-development gets you billable hours, above all. But keep telling us it's for product quality.
• evfanknitram 9y ago
  Meh... All of these items are more or less misinformed so I'm just going to bring up one. > Because all product decision authority rests with the “Product Owner”, Scrum disallows engineers from making any product decisions and reduces them to grovelling to product management for any level of inclusion in product direction. The product owner is part of the scrum team. She or he is responsible for the backlog but if she has trust in the engineers she can let the engineers add their own things to it. I think OP just works in a bad place.
  • prepend 9y ago
    Right, I felt the same way. I think the accurate title for this post is “Why working for, with, and being an asshole is the wrong way to build software.”
    • teunispeters 9y ago
      Oh I'm with that. "Why aren't I getting the attention, focus and control I want?" Especially credit. You get credit in the git logs etc. If you want visibility outside the team go start your own. I have worked in multiple companies that worked very well with this, in several different teams. Or to give a much more serious response : this article seems to be very unprofessional, about trying to defend unprofessional behaviour as "normal".
      • evfanknitram 8y ago
        What kind of 'credit' are you talking about? The scrum guide talks about roughly 1hour/week for the scrum team to show stakeholders (such as upper managers and customers) what has been done. Any engineer can at any time reach out to people in the company to demo what has been created, if there's interest. So I'm not sure what point you're trying to make with starting your own company if you want visibility outside the team.
  • kasey_junk 9y ago
    If OP worked in a “good” place where product managers & engineers trust each other to do those tasks, what value does Scrum bring? The process is there to account for the places where the people fail. If a requirement of a process is unfailing people then it’s not a valuable process.
    • evfanknitram 9y ago
      Not sure if you are joking but unfailing people is no requirement of scrum. Scrum requires the people participating in the process to at least have some fundamental grasp of the process though. If the actors can't be bothered to learn this, then of course it won't work. If you don't know what values scrum brings over for example traditional waterfall, then the scrum handbook is a good place to start to learn.
      • kasey_junk 8y ago
        I've worked on agile projects for 20 years. I was using agile before the manifesto was published. The opposite of 'not scrum' is not 'waterfall'. Further, I don't disagree with anything Ken Schwaber outlines in his writings on scrum. The problem is, on the ground, that is not what scrum is. Ken has been fighting that battle for at least 10 years. If the process is just as often implemented incorrectly as correctly, that is a failing of the process. And in this case that is the most damning thing you can say about scrum. More often than not, people do it wrong. I'm tired of that excuse.
        • evfanknitram 8y ago
          > The problem is, on the ground, that is not what scrum is. The companies I have worked on who claim to use scrum does not suffer from the issues OP brought up. So I question your statement. I also have >20 years experience. > If the process is just as often implemented incorrectly as correctly, that is a failing of the process. That's bs. That would be like putting a tractor driver in a Cessna and when the plane crash clamr that Cessnas are inherently unsafe to use. Yes, scrum requires buy in and some basic level of competence. If one or both of these are missing in an organization and they still say they use scrum then that can hardly be blamed on scrum.
  • matthewmacleod 9y ago
    I think OP just works in a bad place. Nailed it. My team's product owner is as much part of the team as any of the engineers. Her role includes balancing the need to deliver products with the need to build reliable and scalable software, and to make those arguments to other parts of the company on the team's behalf. Since we're all skilled professionals, we're able to trust each other to make good decisions, and if I say "we cannot proceed until we have done <necessary technical work>" then that is taken seriously and work is prioritised as required. I'm baffled by the awful environments that people apparently work in where this is not the case.
    • organicmultiloc 9y ago
      I've never worked at a place where I've been allowed to say no, I think scrum working the way in which you describe is more the exception than the rule.
      • Izkata 9y ago
        The trick that apparently gets lost somewhere along the line is that you don't just say "no", you say "not yet, this first" or "can't, but can do this instead" or... Either give the product owner a reason and a way to work towards what they want, or an alternative that (hopefully) is just as good.
        • PaulRivers 8y ago
          No it's not lost. It gets the same though longer winded results of saying "no". The b.a. product owner complains to your manager that you're not a team player and you get into trouble with your boss. Even if that didn't happen you're never going to win, because the b.a.'s have no other job than playing this verbal judo, while you also have to spend your time getting conplex technical things to work. You're like someone who goes to a karate class twice a werk fighting against someone who's life is dedicated to training.
      • cbsmith 9y ago
        I'm not sure how any methodology would work in such an environment. It isn't the norm for any successful engineering team.
• nulagrithom 9y ago
  Don't tell me why Scrum sucks. That's really not useful to me. Show me a better system instead.
  • afterburner 9y ago
    Regardless of system, you still need good quality managers.
    • mmcnl 9y ago
      In the case of scrum, the role of the Product Owner is extremely important. In theory, the PO should have both a solid background in product development and business development so that the backlog can be correctly prioritized, in order to make sure that the development team can keep on working on the right stuff without discussions. In practice this is rarely the case and the PO often is just some non-technical person that is assigned to do stakeholder management, which puts additional stress on the team, contrary to the goal of keeping stress away from the team.
  • prepend 9y ago
    “You don’t understand man. Everything sucks and people don’t get it. Step 1) destroy. Step 2) repeat step 1.”
  • teknologist 9y ago
    Hire better, more responsible engineers then you won't need a passively micro-managing set of processes to get things done.
    • nadezhda18 9y ago
      feels like you have not yet had problems with bad management. Bad management can drive into the ground even a great team with very responsible engineers. They will try to fight the restrictions, burn out, and then simply give up by quitting. This is the story that keeps unfolding again and again in front my own eyes at my work, alas.
• amarkov 9y ago
  Respectfully, I'm not sure the author understands what he's talking about. He's arguing for the no-op process where engineers determine all their own tasks and priorities - and I mean, I'd like that too. But there's a fundamental difficulty in aligning each engineer's personal goals with those of the company, and some amount of management or organizational design has to go towards addressing it. Engineers won't just naturally align with the organization if nobody rewards us for doing so. > Do managers or Product Owners track and estimate every task they engage in with little or no say in what they work on? > Are they required to present burn down charts that show that they are on target to finish? > Are they required to do bi-weekly sell-off meeting to justify their activities? These things are in fact the primary responsibilities of managers and product owners.
  • bassman9000 9y ago
    Engineers won't just naturally align with the organization if nobody rewards us for doing so. Hoes does Scrum reward the engineer for such alignment? edit: grammar
    • rossdavidh 9y ago
      Theoretically, Scrum is a way to say 'work on this, because it's what aligns with the organization'. But, of course, whether it really does or not depends on who is implementing it and how.
      • bassman9000 9y ago
        Scrum telling you how to align with the organization is not rewarding the engineer in any way. Orthogonal concerns. How does Scrum reward the engineer, in a way that it does it better, and more profoundly, than other methodologies?
        • amarkov 9y ago
          When you let engineers run around doing our own thing, we never have to show that the work we're doing is the most productive use of company time. We just have to show that it plausibly could be. Nobody will hesitate to reward the well-liked engineer with a cool sounding project, even if other things would really be more important. As the author noted, Scrum solves this problem by making number of story points completed the primary tool for a team to measure its productivity. If the cool-sounding project isn't important enough to take other items out of the sprint, there's no way to offer a post-hoc justification for doing it anyway. It has no story points, so work on it is considered non-productive.
• firewalkwithme 9y ago
  I am getting real tired of methologies and agile movements all together
• jack9 9y ago
  This seems like a coded endorsement of Agile processes.
• badprose 9y ago
  "Scrum is probably the worst way to build software, except for all the others."
  • walshemj 9y ago
    Well having done RAD/DSDM (including projects presented at the IEE) some of the bizarre rules based things scrum gets up to seem sub optimal (to be kind). I have even done very successful hybrid projects that used Waterfall for design and built the system using RAD in 12 weeks - including doing a physical delivery.
• codingdave 9y ago
  > Because all product decision authority rests with the “Product Owner”, Scrum disallows engineers from making any product decisions and reduces them to groveling to product management for any level of inclusion in product direction. Only if your Product Owner sucks. Their job is to communicate with all stakeholders, which includes letting the engineering staff have their say. If the engineers feel left out, the product owner isn't doing their job. > Scrum, in accounting for all the engineer’s time in a tightly managed fashion, discourages innovation — which typically occurs spontaneously and outside of any schedule or system of good predictability. It doesn't. That is why there is a 'focus factor' baked in, to allow for their time to not be tightly managed. > Scrum encourages “least amount of work possible” solutions — to conform to it’s strict predictability requirements. No, it doesn't. The scope of a task becomes a negotiation point for assigning stories into sprints. Sometimes you do something quicker to make the sprint work. But that shouldn't be the default answer. It should just be a talking point. Most of the time, the engineers dictate the effort required to complete a feature, and if they always pick the quickest easier way.... well, then that is a problem that needs to be resolved with the team. I could go on for every point. But I'm not seeing a single shred of evidence that this author actually understands Scrum. They seem to have been exposed to poor scrum teams, focusing completely on processes and documents, not the communications, negotiations, and discussions that are truly the heart of scrum... admittedly put within a defined structure. I'm not saying Scrum is perfect. It isn't, but you definitely are going to hate it if you have never even seen it done well.
  • nadezhda18 9y ago
    > > Scrum, in accounting for all the engineer’s time in a tightly managed fashion, discourages innovation — which typically occurs spontaneously and outside of any schedule or system of good predictability. > It doesn't. That is why there is a 'focus factor' baked in, to allow for their time to not be tightly managed. Can tap into my experience and say that it does discourage innovation and has nothing to do with focus. While doing innovation and research, your path is fuzzy and unpredictable and does not fit into a predefined scope that the team has to commit on at the beginning of the sprint. While doing research or innovating, you never know if you can deliver business value - your research may succeed... or may fail, which is often the case. Meanwhile, in the predefined sprint scope, everybody is clear what tangible business value it will bring, everything is clear and no room for wiggling and straying away. Edit: I am not talking about occasional research tasks, which seem to fit well into Scrum structure. I was talking about the innovation as a project that requires a big chunk research to be done.
• wnevets 9y ago
  I've found that "certificated scrum masters", "certificated project managers" and their ilk are the problem. Anyone who says we must follow a specific process because that is how agile development is done is missing the point. The actual agile manifesto makes a lot of sense IMO. http://agilemanifesto.org/ http://agilemanifesto.org/
  • bassman9000 9y ago
    Does it? E.g. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Everyone has deadlines. Either customer imposed ones, or the market running against you. At some point, you'll have to meet them. When do you stop accepting changes and deliver? Can you welcome last minute disruptive changes? Sure. But the market won't wait for you to implement them. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Some tasks require longer attention spans. This is the classic technical debt accumulation choke point. Now, iterations + deadlines make sense. But does it have to be a fixed 2/3 week period, always? Where the flexibility in that? Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. To be fair, I've only seen Scrum. But this point is in direct contradiction. Scrum is about diluting the individual. Everyone is a replaceable resource. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. This is just wishful-thinking, the Agile Point. The only remotely close way of doing this is turning everyone into cogs in a machine. No, thanks. Weren't we valuing the individual? Continuous attention to technical excellence and good design enhances agility. And takes time. Ops, sprint's time is over. I guess that refactoring can wait. The best architectures, requirements, and designs emerge from self-organizing teams. Some of the most successful products and projects (Linux, Python, Apple) revolve around strong leadership. There are definitely good ideas in this manifesto. Ideas that have been applied for years, before even the manifesto came to be. Some others are just wouldnt-it-be-nices.
    • bendiksolheim 9y ago
      Everyone has deadlines. Either customer imposed ones, or the market running against you. At some point, you'll have to meet them. When do you stop accepting changes and deliver? Can you welcome last minute disruptive changes? Sure. But the market won't wait for you to implement them. What’s the point in delivering something both you and the customer know is wrong, when you can turn around and fix it instead? The point is delivering something of value instead of delivering something you agreed upon half a year ago. Some tasks require longer attention spans. This is the classic technical debt accumulation choke point. Now, iterations + deadlines make sense. But does it have to be a fixed 2/3 week period, always? Where the flexibility in that? The text says "couple of weeks to a couple of months", not 2/3 weeks. If a task requires a longer attention span than two months, you should probably break it down and deliver something of value earler on. As you say yourself: "the market won’t wait for you to implement them". To be fair, I've only seen Scrum. But this point is in direct contradiction. Scrum is about diluting the individual. Everyone is a replaceable resource. What a nice way of motivating people. Every person in a good team is of big value, and cannot easily be replaced by anyone else. Creating a good team requires thought and planning. If Scrum is about diluting the individual, then Scrum is far more wrong than I originally thought. This is just wishful-thinking, the Agile Point. The only remotely close way of doing this is turning everyone into cogs in a machine. No, thanks. Weren't we valuing the individual? When you motivate people, and give them tasks they like, they tend to perform their best. Turning people into cogs in a machine, as Scrum seems to like, is not a good way of motivating them. As the manifesto says: value the individual and motivate them, and they will get the job done. And takes time. Ops, sprint's time is over. I guess that refactoring can wait. And that is why you don’t care about sprints. You do one task, preferably as small as possible, and deliver it when it is done. That’s it. I have never understood why I should spend loads of time planning what I should do the next N weeks, when I can just do it instead. Some of the most successful products and projects (Linux, Python, Apple) revolve around strong leadership. Having strong leaders around a self organizing team is not necessarily problematic. Self organizing teams are more about giving the team freedom to work the way they want. A manager or leader can then contribute by removing obstacles and ensure the team has everything it needs instead of micromanaging everything. The most important part of The Agile Manifesto, in my opinion, is "Individuals and interactions over processes and tools". If you care more about the process than you do of the people in the team, you are doing it wrong. EDIT: formatting.
• sifoo 9y ago
  The Agile movement was all about dropping the process hoop jumping and focusing on solving problems efficiently, that's why it was considered extreme. Too extreme, as the one true implementation to rule them all is worse than what the agile movement was revolting against. This is how the game is played, over and over and over again; any movement that threatens the narrative is embraced, corrupted and ultimately used as a weapon against its core values.
• stefanve 9y ago
  Yeah this seems to be an excellent list on how not to Scrum. Or an what happens when scrum is used by people that don't understand the spirit list. I actually scrolled down to see if it was a joke list or had a deeper point. Scrum is actually used to make sure the dev team is part of the decision process and there is no reason not to be innovative But of course the enterprise can kill all things good
• lumost 9y ago
  Having been a manager, PM, and lead engineer this article really resonated with me. Scrum has a brief window of utility if a team isn't delivering at all, and has lost management trust. It also has a large window of dis-utility where everyone haggles over points, shows velocity as results, and leaves customers and businesses wondering what their engineers are doing. Trust your engineers to do the right thing on their own and they might just surprise you.
  • ebbv 9y ago
    What does “trust your engineers to do the right thing on their own” look like to you? And how is that stopped by SCRUM? For the way we do it, when a stakeholder wants our team to do something, they come to us with user stories and acceptance criteria that matter to them. Then we hash out the rest of it. I don’t really see a useful way we could be trusted more. The Marketing department knows best what feature it is they want on the website, and why. So they specify that part. We estimate complexity and the business weighs the priority of that feature against other stuff in our backlog and it falls into an appropriate sprint based on that and other motivating factors. Then we do the work. I don’t see a lack of trust? So I’m curious where you see it and feel it should be done better?
    • stctgion 9y ago
      Perhaps they meant when the engineers decide the the priority of the features and maybe even define some features themselves
      • ebbv 8y ago
        If your company isn’t tiny your engineers generally shouldn’t be deciding priority. Unless your company is small enough that the engineers have a clear view of all the priorities of the business all we are capable of is saying “This seems really important to us.” And then that has to be weighed by people who have the bigger picture. But outside of a very small company to me it’s a bigger crime to waste engineer time with all the meetings necessary to give them that full perspective. When I started at my current company I was the only developer and I worked directly with the CEO and our single marketing person. Back then I helped decide priority. Now the company is too big for that. I don’t have time for all the manager and marketing and business planning meetings to be able to decide priority. As far as defining features, we can propose them like anybody else but I think I already explained why usually it makes sense for them to come from whoever owns that piece of what you’re doing. But this of course again depends on the structure of your company.
• gregdoesit 9y ago
  Scrum isn't good or bad, but the way the OP (or their company) uses it seems to be a reflection of an inflexible culture. For example, the OP argues how scrum strips engineers the autonomy they need to get the job done and how it's super inflexible. When we did scrum with my team, the scrum master role was rotated among engineers, growing each of us significantly as professionals. We also made changes to the "core" of scrum after our retrospectives when we decided it was stuff that did not work for us. When management tried to use story points for tracking or forecasting we told them to forget about the whole thing. We added bugfixing sprints after we observed the bugs piling up. I can go on - we made scrum work in an environment where we were empowered to do what makes sense. The crux of the post seems to be that OP has some very rigid management and devs cannot change the mindset. Instead of complaining about scrum, I suggest the OP either try changing the culture from the team level. Or if it won't work, just get out and work at a place where there is sane management who does not drink the rigid scrum kool-aid. Luckily, there are more and more places like that these days.
  • codemac 9y ago
    > Scrum isn't good or bad. There isn't enough evidence-based science on what produces the best software -- but Scrum can be measured against other software practices, and should be.
  • jstimpfle 9y ago
    > Scrum isn't good or bad I must have heard this at least a dozen times in the last months. OOP isn't good or bad, Exceptions aren't good or bad, Scrum isn't good or bad. It makes me mad. Guys and girls! Software is not a contest in being liberal and tolerant. There are methods and techniques that are objectively better than others in reaching most of the goals that are important. You wouldn't contest a F1 driver on a bicycle - not on a race track. And engineers who really know their stuff usually agree on how to build software in a given domain. I do not know of any success stories using Exceptions on Kernels or RDBMSs or even most server software. But I know people have tried, and even they agree it was a bad idea. If you want to say Scrum isn't good or bad, depending on how you tweak it so it sucks less, then I say it's definitely bad. It's not a solid method that helps you reliably reach your goals. If you want to say Scrum isn't good or bad unless metrics are defined (that doesn't seem to be the case here), then you are right, but it's a meaningless statement.
• ebbv 9y ago
  My team does SCRUM at work and almost none of these apply to us. Sounds like the author works in a bad company.
  • wolco 9y ago
    I work for a good company but the team I was on a few years ago was using scrum. It really does promote pushing debt down the line because the product owner only cares about what they can see or measure. The debt isn't part of that set so the developer has to fight to address it. After the first battle many will stop fighting because they are measured by how well the product owner thinks that developer is implementing their roadmap and on track with the schedule they got approved. Products with heavy debt tend to get rewritten rather than fixed. So it makes sense to keep the schedule through shortcuts and push as many features as possible. Then throwaway the product and rewrite in something newer and more modern. For developers the benefit is your resume will have the latest tech and you can write sloppy non-abstracted code and not worrying about having to support the product later. Management gets increased visibility into each task with an accurately followed schedule. Not a surprise it has become so popular. If I could change one thing I would make the scrum master in charge of technical documentation. That one change would force the master into understanding the code at a lower level. That would make them the most knowledgable person on the project thus it would remove the need for daily standups because team members could go to the master at any point in the day with questions or to coordinate effort.
    • ebbv 9y ago
      SCRUM does not push for bad, tech debt laden products any more than any other development system. Managers who want you to push code out the door ASAP will do it just as much no matter the system you’re using. The solution is not to blame whatever particular form of agile you’re using; the solution is to replace the bad managers if you can’t educate them on why that’s short sighted.
    • je42 8y ago
      The development team is responsible for technical implementation. Also, the priorities are a negotiation with the product ownern. It is also in the product owners best interest that the tech debt is not piling up. In the end the PO is screwed when the product comes to halt because of the tech debt.
• raverbashing 9y ago
  Funny, while in agile teams I made several product decisions and did innovate in some occasions. You don't need everything to be "inside the project/inside the process" and even then, more things fit there than people might think.
• tootie 9y ago
  I just put my teams on scrum and they love it. Immature scrum that focuses on metrics and jira boards can be a very tough transition, but mature scrum that focuses on collective ownership and continuous improvement is heavenly.
• lillesvin 9y ago
  > It assumes that engineers cannot conduct a meeting effectively without a facilitator (Scrum Master) Scrum isn't perfect but this is certainly not true. If the team is well-functioning there doesn't need to be a facilitator of any kind present. Sounds like OP is either in a bad team or with a bad Scrum master—or both.
  • rhizome 9y ago
    If the team is well-functioning there doesn't need to be a facilitator of any kind present. This is a tautology.
    • lillesvin 9y ago
      Only if you misunderstand me. ;) What I meant was that Scrum doesn't dictate that there has to be a facilitator present but if your team isn't well-functioning it's probably a good idea to have one. I.e. if the Scrum master has done his job exceptionally well he's rarely needed.
• empath75 9y ago
  We do scrum and this doesn’t describe how it works for us at all. Our scrum master isn’t our manager and neither is our product owner, for example. And we have gone some time with minimal direction from the product owner at all, when things were going well. My main complaint about scrum was how much of my time was spent in meetings vs working.
• wilkosez 9y ago
  I agree 100%. Thankfully I dont do agile any more, but I'm close to several teams that do. My fondest memories are: No over-arching design (Implement feature after feature however the hell anyone likes) Once said features are implemented, taking the time to "refactor" (read: completely rewrite because the code was so bad) becomes a really hard sell. Thus, new features get progressively harder to implement, as you touch a deeper cross-section of the code to try and fix stuff semi-covertly, without a formal refactor. "Tech Debt" was done in sprint scheduled after phase of dev sprints. After, say, a year of development, lets fix all the problems in 3 weeks... When you're dealing with procedural php masquerading as OO, MVC with business logic everywhere it shouldnt be, and abuse of inheritance such that you cant throw an error in a command line because you're not a logged in browser user, who's had their language queried from a database, and doesnt fall back to default when the db isnt there... 3 weeks isnt gonna cut it! Introducing peer review was supposed to sort that, but bad or inexperienced devs didnt know they were doing shoddy work (it met the criteria after all..), and good devs became impediments because so many stories needed redoing. Demoralising. We were probably "doing agile wrong". But it's like a religion: open to interpretation. In my experience it's a tool used to extract maximum customer benefit at the expense of the developer's soul, under the pretence of "self managing team" - ie. "You brought it on yourself".
  • baq 9y ago
    Peer review should be a mandatory prerequisite to any process, I don't see how a team can develop quality software without it.
    • wilkosez 9y ago
      I agree, which is why I pushed for it. But it does depend on the quality of the peers, and should go beyond whether the story met the criteria or not. Feeding that back through the process is pointless when it inflates the complexity of future stories, because they are less likely to be prioritised, and the rot festers.
      • cbsmith 9y ago
• bumelant 9y ago
  This post confuses many things but firstly it doesn’t properly talk about Product Management. PM is customer centric and marketing heavy discipline and just knowing how to code and good intentions of devs may not work on competitive market. Secondly Scrum is project management framework and says nothing about software development practices and leaves them completely to the judgment of the team (including developers and PO because they collaborate heavily in Scrum).
• newscracker 9y ago
  > 7. Scrum is very management heavy. Typical teams have Product Owners, Scrum Masters, and Team Leads. Innovative, motivated teams operate better with less management, not more. > 8. Scrum is typically implemented with HORRIBLE task management tools (Jira, tfs, etc…) that enforce very bureaucratic interpretations of Scrum that waste huge amounts of developer time. Additionally, they effectively lock you into one mode of operation, no matter how ineffective. Scrum is not just management heavy. It's micromanagement heavy. If someone asked me for an account of what I did for a whole six (assumed to be productive) hours yesterday and how many story points have been burned, and wanted this every single day, I can only imagine that the person has no experience with software development whatsoever. There are productive days when a lot of stuff gets done and there are unproductive days when almost nothing gets done because it's hard to focus or because of distractions. But the daily standup meeting that's enforced would make any unproductive days as something to get publicly shamed about. On the tools, yes, whatever I've seen in Scrum dictates a lot of time spent updating the tools with estimated hours, hours spent, remaining hours, everyday. That data is rarely useful for any further estimations or to figure out what's going on. Lastly, the "story points not related to effort but related to effort" conundrum confuses developers (especially the ones who are considered to follow instructions and code whatever the user story's tasks say). Add to this a really weird concept called velocity, which is not just a measure of how many story points are completed in a sprint, but is used as a range — too low and you're not working hard enough; too high and your estimates are wrong. The only way to satisfy the Scrum master in many cases is to lie and make the velocity conform to expectations. I have no idea who was tying to prove what to whom when they came up with Scrum and Scrum certifications. The certified Scrum masters I've seen don't even know how to write a good user story or to break it into tasks. Give me low process overhead iterative waterfall any day over these schemes. Repeatedly trying to turn software developers into predictable manufacturing style widget makers is not a good idea.
  • mmcnl 9y ago
    The daily stand-up is simply about "what did I do yesterday, what will I do today and do I have any impediments". It has nothing do with productivity evaluation.
• agf 9y ago
  A lot of this article is a mix of a little bit of truth with a lot of what is just bad management. But the first few and final example are good warnings that can be applied anywhere, Scrum or not. Paraphrasing / quoting the article: "[If] all product decision authority rests with the “Product Owner” ... engineers [are disallowed] from making any product decisions and reduces them to grovelling to product management for any level of inclusion in product direction." "[If] all the engineer’s time [is accounted for] in a tightly managed fashion, [that] discourages innovation — which typically occurs spontaneously and outside of any schedule or system of good predictability." "[You] encourage “least amount of work possible” solutions [when you expect engineers] to conform to ... strict predictability requirements." "[If you] divide every task into small items that can theoretically be completed by anyone on the team .. [you] discourage engineers from taking pride in and/or ownership of their work. This lack of ownership results in ... Poor design [and] Lack of motivation ('It isn’t my thing', 'It was broken when I start working on it')" "[Don't] ignore the fact that any task that has been done before in software does not need to be redone because it can be easily copied and reused. So, by definition, new software tasks are truly new territory and therefore very hard to estimate."
  • iteriteratedone 9y ago
    I dont want to be included in product ... you tell me what to do , I do it Detail how it needs to look, how it needs to scale ... Ill decide how we make that happen and Ill tell you how long its going to take. Its not my job to decide the product, if you need an engineers input maybe you are not a good product manager. I dont need any one outside of engineering to help make implementation decisions. I just want to code and go home. Stop it with this kum by ya , 20% , everyone gets a say bs. Are you running a business or a daycare?
• talltimtom 9y ago
  This is a list of things they are doing wrong not things wrong with Excel, Visual Studio, JIRA, The Scrum Methodology or any other tool they have poorly implemented. They should seek external help in getting their usage of these simple tools back on track. I’ve seen people create horrible abominations using Excel, that doesn’t mean that the tool itself is broken or that all the effective usages of Excel are wrong. It’s the same with Scrum. If you use it right it’s awesome, if you use it wrong it’s just a different name for the same old bad project management you always had.
• mmcnl 9y ago
  Wow, this article is blatantly wrong on almost every point the author makes.
• jonstaab 9y ago
  Having personally witnessed all of these symptoms of "agile" on teams I've been on, I was pleasantly surprised to discover when I read Jeff Sutherland's book that none of these problems have much to do with Scrum, which is more of a way of thinking about building (and tearing down) processes to optimize for the things only the team can identify, than a process itself. I think the reason these sorts of bad practices crop up so often is because internalizing and applying the sort of ego-free principles of Scrum is very very hard, even for a small team (or individual). Reading that book [0] (particularly the first half) was eye-opening for me, and I recommend it to anyone who works in an "agile" environment. [0] https://www.amazon.com/Scrum-Doing-Twice-Work-Half/dp/038534645X https://www.amazon.com/Scrum-Doing-Twice-Work-Half/dp/038534... Edit: I would add that the linked article is pretty typical of things I had read online about Scrum before I read Jeff's book, and I believe are very misleading and unhelpful, as they abuse one way to solve the problems they complain about. Bad team dynamics didn't come from Scrum. Maybe Scrum failed, but that's a whole different discussion.
• enesunal 9y ago
  This list shouldn't be named "what scrum does wrong", it should be named "excuses made by engineers who don't want to take responsibility"
• hacknat 9y ago
  The biggest one for me is estimation. I grant that certain domains work on very predictable tasks, but what if you are working on a new product that is solving a lot of new problems? Practically everything should be a spike. I’m working on a new product right now and our estimates are worse than garbage as they end up just haunting us with management.
• notacoward 9y ago
  One under-appreciated shortcoming of Scrum is that it doesn't deal well with dependencies on other orgs that have their own schedules and probably don't use Scrum themselves. We ran into this at Red Hat, where the other org is an external open-source community. You do your work quickly like Scrum forces you to, submit the work upstream, where people not operating under Scrum's artificial time pressure ignore or reject it. Hardly surprising, since quick often means dirty. In any case, you have no control over how long it takes that process to complete, let alone when the new code gets into an upstream release so you can pull it back in. What always ends up happening is that developers have to take on more work in progress while code works its way through someone else's process. If it's done officially it's no longer really Scrum. If it's done unofficially it's still no longer really Scrum, and even worse the time spent shepherding patches upstream is invisible to the Scrum planning process. Maybe Scrum works when you're a passive consumer of the frameworks, libraries, etc. that you use, with no expectation that any significant time will be spent contributing back. I don't know; I haven't worked in that kind of environment for a very long time. That only seems like a tiny segment of how real development gets done, though.
  • ebbv 9y ago
    I don’t see this as really an issue. When your work is done it’s done. If it’s someone else’s work that needs to be done now before you can do something else, those should be separate issues/stories/tickets that are blocked until that external work happens. In my mind it’s no different than waiting on a design or pricing sheet or API key or any other dependency that holds up work. Yeah you might have to context switch to something else for however long you are waiting but that’s what happens. Also why the “do your work fast like SCRUM forces you too”? SCRUM doesn’t mean do your work shitty and fast. Maybe your organization wants it to but whether you prioritize speed or doing it the best you can or whatever is up to you, I don’t see that as part of SCRUM.
    • notacoward 9y ago
      > When your work is done it’s done Have you ever worked on open source? Getting code accepted upstream is not somebody else's work. It usually involves significant ongoing effort by the author on top of what they did to implement and test the code in the first place. That work is usually very interrupt-driven too, responding to review comments etc. whenever someone upstream happens to wake up, and that makes it even worse. Your "separate issue" idea is exactly how Scrum fails to account for real work in progress when open source is involved.
• nwhatt 9y ago
  A lot of these items are process points. The whole point of scrum is that the team determines and refines the process over time. Scrum is not a process but a process creation framework. I agree with most of the comments so far this is bad management.
• hacknat 9y ago
  I think more people need to talk about best fit. People shoehorn scrum into every situation, when it is perfectly valid to say that it won’t work sometimes, and others when it would work well. You wouldn’t use JavaScript to build an operating system, and you wouldn’t write your browser code in C. So why assume that one SDLC regime is right for every situation. Scrum seems to work well when estimation really is possible and there is true ownership and flexibility on the team. I have not seen Scrum work well with brand new products or situations where practically every task is an unknown and the team is defining and prioritizing features in the product as they move and discover. Which makes sense as Scrum does assume a high degree of uniformity and definition. There are situations where the product owner, temporarily, has to be the whole team.
• jadedhacker 9y ago
  The engineer here is protesting being turned into a factory worker, becoming alienated from his work, and being used towards the ends of management rather than his own. It is an indictment of capitalism's effects on workers, even highly skilled knowledge workers. What he is expressing is the inkling of the desire for a better world; perhaps one where there is democratic control of the production process by workers. A spectre is haunting software development. Developers of the world unite! You have nothing to lose but your chains.
• ataturk 9y ago
  After working on agile for a decade now, I'm ready for the new fad.
• matthewmacleod 9y ago
  This is a bad article. It conflates "bad management" with "bad process", and unfortunately pays too much attention to an idealised "official" version of Scrum. This is the first thing that anybody developing a Scrum process should discard. Let's deal with these points step-by-step. Because all product decision authority rests with the “Product Owner”, Scrum disallows engineers from making any product decisions and reduces them to grovelling to product management for any level of inclusion in product direction. This is a sign of a bad team. The product owner in a functioning Scrum team works with the engineers to establish the product direction, both at the micro and macro levels. My current product owner will involve the engineers in almost all product decisions; she is responsible for mediating between the different priorities set by different parts of the business. All product meetings are open to engineers who want to contribute. It works well, and Scrum has no embargo on this. Scrum, in accounting for all the engineer’s time in a tightly managed fashion, discourages innovation — which typically occurs spontaneously and outside of any schedule or system of good predictability. Scrum should not involve 'accounting for time'. It's entirely possible to include innovation and research within a sprint – sprints should always be a little flexible and allow for some expansion or contraction of goals specifically to support this. Longer-term innovative or research tasks should be treated like any other work – and importantly, the process should be flexible enough to accept that priorities sometimes change, and that failing to meet a sprint target because the situation changed is okay. 3. Scrum encourages “least amount of work possible” solutions — to conform to it’s strict predictability requirements. This is simply false. Uncertainty should be built into every prediction made. The goal is to assist with predictability, not to require it. By dividing every task into small items that can theoretically be completed by anyone on the team, Scrum discourages engineers from taking pride in and/or ownership of their work. Only if you have a poorly-skilled or unprofessional development team. Scrum isn't going to fix that problem. 5. Scrum is highly intolerant to modification, and it’s proponents typically espouse an all or nothing attitude in it’s implementation. Finally, a possible reasonable objection! The first thing one should learn to do when building a process is to ignore all dogma. Adapt Scrum for your particular requirements; it's still Scrum, more of less. Nobody has ever implemented Scrum precisely as described. 6. Scrum’s attitude of intolerance to self-examination is present in all of it’s practices. Only processes that operate internally to Scrum’s framework are open for modification— as for Scrum itself, it is seen as sacrosanct. See above. 7. Scrum is very management heavy. Typical teams have Product Owners, Scrum Masters, and Team Leads. Innovative, motivated teams operate better with less management, not more. Scrum involves three roles – a product owner, a scrum master, and a development team. The product owner decides what to do; the scrum master looks after the process and removes roadblocks for the others; the development team do the work. These roles can be combined where required. Frankly I'm struggling to imagine a lighter form of management. Scrum is typically implemented with HORRIBLE task management tools (Jira, tfs, etc…) that enforce very bureaucratic interpretations of Scrum that waste huge amounts of developer time. Additionally, they effectively lock you into one mode of operation, no matter how ineffective. You're entirely free to practice Scrum using whatever tools you want. Personally I have no problem with a simple Jira implementation. If it's been over-complicated, then you have implemented it badly. The whole point is to provide tools that make it easier to manage work. I use Jira, spend essentially no time using it beyond keeping track of what I'm doing and sharing knowledge about particular work. If this tool doesn't work, use something else. 9. Scrum discourages bug fixing, reduction of technical debt, and risk taking, all because of its narrow, exclusive focus on only doing items that Product Owners would interpret as valuable. The product owner must be a skilled professional who works with the development team to decide what the priorities are. If the development team believe that a particular bit of non-user-facing technical work needs to be done, then that should be taken into account by the product owner—who as a professional, will trust the development team's judgement—and appropriately prioritised. No process will fix an overworked team, or compensate for a lazy product owner. Frankly, it's not Scrum's fault. 10. Scrum is hypocritical. Do managers or Product Owners track and estimate every task they engage in with little or no say in what they work on? Are they required to present burn down charts that show that they are on target to finish? Are they required to do bi-weekly sell-off meeting to justify their activities? Product owners are accountable for their activities like anybody else. I think they'd benefit from a bit of Scrum in that! In fact, we've found that our process has worked well enough that other business units are beginning to roll out Jira to help teams understand what work they're doing. As for the other points, I've never had to present a 'burn down chart' or otherwise justify my activities to anybody. Again, Scrum will not fix a micromanagement culture. It assumes that engineers do not have task tracking systems that they already use to manage their time and therefore need time-management hand-holding. Scrum does not involve time-management. Let me say this again: "SCRUM DOES NOT INVOLVE TIME-MANAGEMENT". It assumes that engineers are not to be trusted with directing their own work. It does not do this. I am trusted to direct my own work. I agree what that work is with other stakeholders. That's Scrum. It assumes that engineers cannot align themselves with the best interest of the organization, without tight supervision. It does not do this. I am not supervised; I use Scrum to agree with the rest of the organisation what is in its best interests. It assumes that engineers cannot conduct a meeting effectively without a facilitator It does not do this. My scrum master (actually the head of development, acting in that role for multiple teams) takes care of the nitty-gritty of booking meeting rooms, setting calendar dates, preparing documentation, taking notes, finding availability, and that kind of thing. They are a helpful facilitator. If you have an alternative, that's awesome. The scrum master doesn't ned to be involved. It assumes that you can plan every facet of a software task by merely talking about it in sprint planning/backlog grooming It does not. No ticket describes every aspect of a feature. Ideally, you can do this, but we all know that things can change. Roll with it and take the obvious step of dealing with unexpected changes like an adult. It assumes that all engineers work the same way. That's just flat-out wrong. Scrum story points are supposedly meaningless, yet they are tracked, recorded and presented at many levels in an organization and often are the only metric by which a team’s performance is represented (ie. Velocity) As far as I'm aware, nobody outside my team knows anything about our velocity. It's purely a method used to help us understand how much work we can commit to in a given period. If it is being reported, you are doing it wrong. Scrum is designed to manage the weakest Engineers and consequently dis-empowers the better ones. No. Scrum is the opposite of many of the points set forth in the original agile manifesto: No justification is provided. 15. Scrum ignores the fact that any task that has been done before in software does not need to be redone because it can be easily copied and reused. So, by definition, new software tasks are truly new territory and therefore very hard to estimate. This is laughably wrong. Basically, I disagree emphatically with every single point made in this article. I have had an excellent time as part of a Scrum team; I have a clear idea of: - What I'm doing - What others are doing - How we can help each other - What the business priorities are - When particular tasks take longer than expected - How we can avoid surprises and failures I honestly can't imagine working any other way.
• vannevar 9y ago
  I'm disappointed that this throwaway list of unsubstantiated bullet points is being treated seriously, but seeing as it is, here's "A brief list of what this article gets wrong about Scrum": 1) The author makes the unfortunately all-too-common mistake of confusing agile development with software design. Agile says very little about software design, other than observing that it is incremental and iterative rather than revelatory and monolithic. Scrum, as an example of agile practice, is primarily concerned with implementation and delivery. The Product Owner can consult anyone they want in the course of designing the software, and of course that includes the engineering team. Scrum encourages the PO to seek the participation of all stakeholders in sprint planning and review, but other than that, design is left to the PO's discretion. 2. Nothing in scrum discourages innovation, and agile certainly encourages innovation to a much greater degree than the detailed spec-driven alternative. 3. There is actually a grain of truth to this one, but it confuses what happens within one sprint with the overall process of software evolution over many sprints. What the author is complaining about here is basically Scrum's version of YAGNI ("You Ain't Gonna Need It"). It's the principle of doing the simplest thing that could work first, and then elaborating on it. My 35 years of software development experience tell me that this is a sound approach. Others may disagree. 4. Scrum does not require the "dividing every task into small items that can be completed by anyone on the team". It definitely encourages dividing work into meaningful pieces with tangible, testable results. But nothing prevents a team from matching work with the team members most suited to doing it. The author seems to be complaining about working on a team in general, where the credit for the product must be shared with others. Nothing about scrum encourages 'lack of ownership' to any greater degree than any other team-based development process. 5. This is simply wrong. Scrum encourages modification and explicitly proves the flexibility for it by ensuring that you're never more than a sprint away from changing direction if it becomes clear that's necessary. And of course, if the team is really blindsided by new information, the PO can cancel the current sprint and start a new one. 6. Scrum explicitly encourages self-reflection through the retrospective that occurs every sprint. The author here is apparently ignorant of this aspect, so maybe it was not practiced in his company. 7. Scrum requires minimal management. The Scrum Master is not intended as a manager, they are intended as a way to short-circuit bureaucracy so that any impediments to the team's progress can be removed. And I've never seen any software development process of any scale that doesn't have a Product Owner or a team lead, though the titles may change. 8. There are lots of bad tools. Don't use them. Find good ones, if you need them. Scrum requires very little, a whiteboard and some sticky notes will do. 9. Scrum does not discourage (or encourage) bug fixes or refactoring. As the author notes, that's at the discretion of the Product Owner. Again, that's always true, whether you're using Scrum or some other software management system. 10. The Product Owner is responsible for delivering the product on time. Of course they are accountable, and I guarantee that if they're at all competent, they're doing far more reporting and documentation for their superiors than the team is for them. 11. Scrum assumes none of these things. Not a single one. Who has a Scrum Master at every engineering meeting, for instance? Ridiculous. The Scrum Master runs the daily scrum, which is a 15- or 20- minute daily sync up. They don't attend any other technical meetings unless someone wants to invite them for some reason. 12. Of course scrum points aren't meaningless; why would anyone bother to track them if they were? They tell the team what it's velocity is, which is useful to the team for sprint planning, and useful to management for resource planning. 13. Scrum disempowers the best developers from...what, exactly? Scrum is designed to allow devs to focus on delivering, so they don't have to guess at what's being requested, and so they get quick feedback on what they've implemented. At all times, they know how they're doing. There's nothing disempowering about scrum. 14. The Manifesto doesn't say "no processes or tools". The scrum process is very light compared to the spec-driven process that it replaced. And as noted above, it doesn't require many tools. The fact that people feel like they need ten Atlassian services to do it isn't Scrum's fault, any more than the fact that you bought a Total Gym and a ThighMaster means that fitness is bunk. 15. Any developer who truly believes that "any task that has been done before in software does not need to be redone because it can be easily copied and reused," and that any new task cannot be estimated, should really find another profession. Honestly, I think the article is a troll. For the author's sake, I hope so. If not...well, he says he's a Programmer and Dog Owner. I hope he's a really good dog owner.
• rhapsodic 9y ago
  Mediocre developers will produce mediocre results. No methodology will pull great results from mediocre developers.
• specialist 9y ago
  Pretty good list of symptoms, side effects, phenomenon. My assessment is somewhat more simple: Scrum is a strategy to reach an unspecified goal thru incremental revelation. (1) I'm old school. Raised on PMI and gantt charts. I prefer defined goals and critical paths. (2) (1) Drunken sailor's walk thru the problem space. (2) What we grey beards called "a plan".
• cbsmith 9y ago
  So much wrong here. I couldn't quite figure out the full nature of the problem (aside from working in a terrible environment), but then I saw this the author's most recent post: https://medium.com/@ard_adam/the-fountainhead-and-software-engineering-d991b269af2e https://medium.com/@ard_adam/the-fountainhead-and-software-e... Now it all makes sense.
• amai 8y ago
  Only a brief list?
• richliss 8y ago
  Another day and another post where someone who believes their companies incorrect adoption of the Scrum framework is evidence that Scrum itself is at fault and therefore creates a Strawman to attack. Scrum is a victim of Semantic Diffusion. https://martinfowler.com/bliki/SemanticDiffusion.html https://martinfowler.com/bliki/SemanticDiffusion.html You know all of those things that you're doing at work when someone says its Scrum? Chances are they're not Scrum but practices that are additional to Scrum: User Stories? Not Scrum Story Points? Not Scrum YAGNI? Not Scrum Pair Programming? Not Scrum Planning Poker? Not Scrum The list goes on. I recommend that anyone who currently hates Scrum to spend 30 minutes one lunch time and read the Scrum Guide: http://www.scrumguides.org/scrum-guide.html http://www.scrumguides.org/scrum-guide.html You may then realise how that consultancy that your company hired butchered it to sell their people to do transformation, or that old school Programme Manager changed it because he wanted more control, or that Scrum Master who joined a company who was already doing a butchered Scrum implementation and did a 2 day course and learned nothing else then espoused what they knew as Scrum when they joined a new company. This article shows the author has strong opinions on something they don't understand - That's not a good trait to have.