15 ms·

Does scrum ruin great engineers or are you doing it wrong?

150 points by Lilian_Lee 6y ago

gtirloni 6y ago
I think it's similar to when someone switches jobs frequently and complains about every company they've worked at. At some point, you have to realize it's you not them. To me it feels scrum is the person switching jobs constantly and saying people don't get it.
- baq 6y ago
  Yeah, no. Scrum is a tool. You can implement it wrong or be very strict with it which kind of isn’t agile, but it’s always a people problem. Scrum tells you 1) to analyze the way your team works, 2) make improvements, 3) talk to each other. If that sounds reasonable, it’s probably because it is. The mythology of scrum being evil is misguided, I wonder how much of it is caused by engineers forced to use JIRA configured by somebody who doesn’t work with the team.
  - supercanuck 6y ago
    No true scrum.
loopz 6y ago
Easy: Is the output great engineering because of scrum, or despite it?
awinter-py 6y ago
or both
deleted 6y ago
[deleted]
samdwilson 6y ago
I wish blog posts like this had examples of things they actually did. It would make it a lot more informative to learn from an example.
Yhippa 6y ago
How about letting developers pick or come up with their preferred way of working instead of mandating Scrum?
- kitotik 6y ago
  The only potential result of a competently run scrum process is exactly that - a process that was designed by the team. If you are stuck in some weird cargo cult that doesn’t allow the team to iteratively change the process, you should call bullshit.
  - rightbyte 6y ago
    If scrum is any process designed by the team the term is worthless. Sadly, scrum as I have seen it has been consultants preaching to the commoners how their rigid process is going to make them agile. Scrum is just flawed from the foundations for anything but very routine work where you can somewhat estimate subtasks duration with any accuracy. But if your job is that easy you hardly need any fancy process anyway.
    - kitotik 6y ago
      > If scrum is any process designed by the team the term is worthless. SCRUM is a handful of tactics that a team can start off with to design and implement the “right” process for a given team. For example, I’ve been on several teams where through the use of retrospectives, daily stand ups were abandoned and replaced with other means to keep the team in sync. > Sadly, scrum as I have seen it has been consultants preaching to the commoners how their rigid process is going to make them agile. That sucks, but sadly this is the most common case. Very few organizations actually want agility, as they are culturally and practically top-down hierarchies that require command-and-control structures to function. These consultants are generally brought in by middle-management who are grasping at straws without any real buy in from the c-suite. > Scrum is just flawed from the foundations for anything but very routine work where you can somewhat estimate subtasks duration with any accuracy. But if your job is that easy you hardly need any fancy process anyway. I couldn’t disagree more. For “routine” work that is predictable, what value does agility provide? It’s either done correctly or not. Agility is only useful in dynamic environments when outcomes are hard to predict and there is limited prior art to reference.
waschl 6y ago
I am in a big project which assembles 45 teams and all of them shall adopt Scrum (for various reasons). My observation is that all those teams which have a sustainable pace with regards to architecture, technology, quality, output, social behavior, etc have done so while adopting and embracing Scrum in a clean way since the beginning of their existence as a team. All teams severely struggling with their content of work, output and collaboration have also severe issues with regards to Scrum-adoption, and show anti-patterns similar to the Stackoverflow thread creator‘s. However I would say the root causes (which we discussed in maaaany meetings) are certainly neither caused by Scrum nor increased by it, but individual mindset, dysfunctional team dynamics, pressure, weird contracts, etc. and would be there under any other or no process framework. I am no Scrum fanboy (I think), but this experience and also from former projects make me quite sure to not blame Scrum in the first place when I see struggling teams, but trying to understand the underlying problems and solve those.
- waschl 6y ago
  One more thing: In answer to Scrum advocates claiming its about doing it right I would disagree and replace it with understanding what is really (really REALLY) the purpose and idea behind it. Don’t worship the cult and don’t fight it because it’s the perfect target of rants, but see the motivation behind it and acknowledge that there may be reasons why it makes sense how it is to some degree. This doesn’t only apply to Scrum but to any other interaction of humans.
  - dboat 6y ago
    Could you explain what you mean by the real purpose and idea behind scrum?
    - mongol 6y ago
      In short I would say, applying ideas from the agile manifesto while providing cadence and some predictability. But that is a personal opinion.
    - waschl 6y ago
stx 6y ago
In my experience it has been that people expect scrum to be a magic bullet. Things are not going well... it will be better when we change to the new orgs process. Only the real reason its not going well is because of lack of planning and poorly written stories. The how you fix that is much more complicated.
moksly 6y ago
I work in the public sector of Denmark, and I’m involved with both developing and procuring solutions. We have quite a lot of them, around 300 for our 10.000 employees, and from a buyers perspective things like Scrum and agile rarely makes a lot of sense. It’s down to the old triangle of time, features, money, which agile and through it scrum mandates at least one has to be flexible. Only that’s now how you buy software. No one is going to give you an unlimited amount of money of time for an uncertain amount of features, and almost nobody has the time to act into your Scrum schedule to prioritise stuff. Because of this, it’s not really how you sell software either. As a result Scrum often becomes a wrapped in a business side that’s very much unified or waterfall process in companies pretending to be agile. I’m not saying it happens everywhere, but I don’t think I’ve ever been involved with a procurement or development process you could truly call agile. That doesn’t mean you can use scrum, but it does mean that you should be careful about how you do so. If you have a bunch of guys working on different CRUD web-applications, does it really make sense to have them do a stand up every morning? Probably not. But maybe the kanban board still works well. Based on my own experiences you have to be careful and “agile” about how you build your processes to suit your changing needs, but going full strict scrum, is probably never going to work unless you’re a major tech company.
- GordonS 6y ago
  > We have quite a lot of them, around 300 for our 10.000 employees, and from a buyers perspective things like Scrum and agile rarely makes a lot of sense > No one is going to give you an unlimited amount of money of time for an uncertain amount of features In a customer project I worked on recently, the consultancy I work at had a contract based on the number of story points - something like, "we will deliver 200 story points in phase 1". Now, because a story point is a relatively nebulous thing, there is of course a lot of room on both sides to fiddle things, but actually the customer was pretty happy with it. The actual scrum teams were completely miserable, but that's a separate point altogether :)
onion2k 6y ago
Very productive individuals that don’t work as a team I refuse to have those people on my team. One person who's twice as productive as everyone else sounds great, but if that person's work doesn't fit well and makes everyone else's work harder it always been a net loss in my experience. I'd prefer my team works well together than have some "brilliant loner" join it.
- metalliqaz 6y ago
  It's a matter of management. Brilliant people can be very useful. Even team players may not work with all other team players. Gotta find the right fit.
- donw 6y ago
  Agreed. What happens when the genius leaves? Can other people extend or maintain their work? Is there a lasting benefit to the organization? Does their work enhance the capabilities of other contributors? From my experience in working with "very productive individuals that don’t work as a team", the answer to these questions is "no". The reality is that a large chunk of generating economic value stems from being able to get along with other people. The richest blacksmith in the Old West wasn't the one that was the most brilliant artisan. They were the one that knew the value of a customer, how to cultivate a long-term relationship with one, and how to get more.
- dbt00 6y ago
  This can flow both ways. I've had great engineers on my team that people were scared to approach because most of those conversations resulted in the questioner discovering they were wrong about something or missing some knowledge. Ideally people who are afraid of that are coached up to be happy to learn instead. That only works if the great engineer is also excited to learn and help. If they call people stupid or fail to listen to all the details because they prejudge the situation, then they're more of the "brilliant jerk" archetype -- but they often aren't as brilliant as they think they are.
- apabepa 6y ago
  Yes I agree for the general case and I have seen this problem many times where management refuse to see the problem with anti-social loners holding too much of the competence in a team. It can also depends on what kind of software you are working on. Some parts might require a 'brilliant mind' to push through a spike solution for certain areas. This individual should not really be in a "normal-happy-scrum-team" though, that would be a punishment both for the team and the individual...
mharroun 6y ago
Scrum, Kanban, scrumban, tickets with predefined checkins... all can work. "Formal scrum" only exists to sell books, certs, classes; but more importantly to give justification or a "fix" to failed project managers and leaders. A process will not fix a team that has bad teamwork, is not productive, and/or has bad communication/leadership/management.
PaulKeeble 6y ago
In the one place I saw Scrum work really well it wasn't because of scrum we succeeded it was the amazingly talent team that groked their goals and understand how to build software well. The complete lack of an enforcer manager was a huge win, being connected directly into your customers and letting them drive what they needed and balancing it with the engineering, that worked really well. They executed well despite scrum and ultimately used Kanban with on need for the biweekly meetings since they were releasing many times a week. Scrum was a small part of a package of process, the important bit that made that possible was the engineering processes not the task management ones. The business needed to work out what matter most to it and the developers certainly helped more as their expertise in the subject matter grew but what made it all slick was the automation and engineering. Engineering is where the time goes on a software project and doing that well is what matters. As an industry we focus so much on something that is a few hours of effort a week on planning and tracking and yet the big time goes into the actual work. If you spend a lot of time doing planning and tracking and not producing software you are doing it wrong regardless of whatever process you say you are using. Scrum is not remotely sufficient, it ignores all the important bits.
- jariel 6y ago
  "being connected directly into your customers and letting them drive what they needed and balancing it with the engineering," Lucky you however, letting 'raw' Engineers interface with customers is usually a disaster. Engineers build tech, the company builds products, and they are very, very different things. A lot of pieces in there - support, training, docs, price, risk, leverage, IP, know-how, relationship management, legality, confidentiality. Experienced Engineers who have a lot of exposure to Product, Sales etc. can do this, there's usually a role there for a highly technical person to support sales. If it were only a matter of 'the customer saying we need XYZ and Engineers doing that' then great, but it's almost never that.
  - PaulKeeble 6y ago
    You need the right customers. We were really lucky the lady in charge of the business team learnt enough of how the development worked to sit in that middle ground between her team of experts and ours to guide the direction well. I would say she and our engineering principle were what made things work well. If you are working with generic customers out there in the world then its much harder to utilise customer focussed requirements.
fjfaase 6y ago
Great article, but it does not mention management attitude. If upper management does not have the right attitude towards Scrum, Scrum will fail. If upper management does not guard the role of the Scrum masters, select capable Scrum master and allow them to function correctly, Scrum will crumble into another tool for micro-management which frustrates developers and destroys productivity. I also have seen that often it are the more ambitions (and less technically talented) developers that opt for role of Scrum master as a stepping stone to a management role. These type of Scrum masters will starting act like top-down managers, who no longer fulfill the role of a Scrum master, namely provide a safe environment for the team to function optimally.
- mindcrime 6y ago
  Great article, but it does not mention management attitude. If upper management does not have the right attitude towards Scrum, Scrum will fail. If upper management does not guard the role of the Scrum masters, select capable Scrum master and allow them to function correctly, Scrum will crumble into another tool for micro-management which frustrates developers and destroys productivity. BINGO. The "problem with scrum" isn't usually scrum itself, but the management and culture of the company. And bad management and toxic culture will, in my experience, lead to the same results no matter what process / methodology you nominally employ. To me, most criticisms of scrum reduce to a (legitimate) claim that "scrum isn't a magic bullet that will fix the fucked up management and toxic culture at this shitty company."
  - AnimalMuppet 6y ago
    In fact, scrum is something the messed-up management has tried to use as a magic bullet, rather than actually fixing themselves.
donw 6y ago
The problem with Scrum is that most practitioners have no idea why their tools exist in the first place, under what conditions those tools apply, and what to do when their tools fail. Nearly every -- but not all! -- "Agile" environment I have worked in was pure cargo cult, with none of the requisite cultural infrastructure required to actually make any of it work, and often with a very strong centralization of control that made local iteration... unpossible[1]. Or they do the opposite, and go full "Lord of the Flies", providing no structure at all. Both approaches yield poor results. You want to provide structure, but then grant autonomy over that structure to those beholden to its results. If you want to "be Agile", your organization needs to push a great deal of control and trust fairly far down in the corporate hierarchy. Doing this successfully requires that organizations build the structures required for both appropriate oversight and cultural promulgation, and few companies even recognize the need for this, much less have the tools to do so. [1] I am hereby defining this as "Possible on paper, but not in reality".
alexashka 6y ago
The only right way to do 'great engineering' is by not having any middle management. The only right way to do great engineering, is by first asking what we ought to be engineering, not re-implementing the same shit over and over again, like we do web frameworks in every new language. Great engineering is completely unrelated to scrum. It is only in the delusional mind of a middle manager that his existence and thoughts are at all relevant to the success or failure of any project on this planet.
- bickeringyokel 6y ago
  You'll have to define middle management, if you're including product management, then your statement would be pretty contradictory. Can't know what you ought to build if to don't know what your customer wants.
  - alexashka 6y ago
    Everyone knows what the customers want, it's quite trivial. Most problems people try to solve using technology/engineering, are actually an attempt to bypass dealing with the real issues, which are almost always political. One trivial example of this is children starving to death or dying of diseases we have medicine for. I'm sure there'll be another 'app' created for yet another charity or foundation. Another trivial example of this is all the middle management and technical bullshit mobile development sweatshops go through, hiring separate developers for iOS and Android, getting them to coordinate and sync their work, working out the peculiarities of the two platforms, etc, etc. All of these problems are solved at the political level of mandating that all mobile platforms have to support a shared set of protocols, libraries and frameworks. All this 'fin tech' investment bullshit - it's a political problem, not a technical problem. It's an endless list of insanity - 99% of IT work is useless trash, as are almost all other forms of work done in office buildings. It'd take a trivial amount of investment (less than a trillion) to automate away most office jobs worldwide but we don't do it, because we're stuck with a political decision to continue wage slavery. Again, political problem, not technical.
- danjac 6y ago
  While "middle manager" is often nowadays a negative term, having a good manager between yourself and the upper management/customer can be a godsend. They can act as a bullshit filter, they can deal with bureaucratic busywork, they can get you whatever resources you need, fight for more funding/people for your team, help out with HR stuff and so on. You need these people so you can get on with "great engineering".
kevsim 6y ago
This is something I think a lot about because I'm working for a small startup [0] building an issue tracker and trying to take on the likes of Jira. We discuss a lot about exactly how much scrum we should support "natively" in the tool (sprints, story points, etc.) because we've seen scrum go wrong and turn into a mess of micromanagement and misaligned incentives a number of times. At the moment we've opted to make it very un-scrum and our early adopters aren't complaining. Teams need to work hard to find a process that actually works for them - tools and scrum master trainings can't dictate that for them. 0: https://kitemaker.co https://kitemaker.co
js8 6y ago
We use Scrum at work and I have to say, I am pretty annoyed by it. I think it is fundamentally rooted in the idea that ideal software development is just a continuous production of small improvements to the code. And from this come all its micromanagement failure modes (which there are plenty). I think in reality, SW development done right is nothing like that. It is highly discrete when it comes to output, because it takes time and experimentation to come up with the correct way to approach a problem, but if you do it right, you save yourself an incredible amount of time. It's more like mathematics, where it takes time to discover that things are actually rather easy (this quote comes to mind https://micromath.wordpress.com/2011/11/06/andrew-wiles-on-doing-mathematics/ https://micromath.wordpress.com/2011/11/06/andrew-wiles-on-d...). Of course, if you look at the project from the longer time perspective, it can appear as continuous production of improvements. But it has a kind of quantum nature, if you decrease the scale of time, you will see less continuity and more discrete bursts of code production. There is something like uncertainty principle that on certain scale, it's pointless to try to predict things, because making the correct prediction (which is needed at least to define thing DONE) will take as long as doing the thing in the first place. I don't consider myself special, but it is possible that Scrum ruins great minds because they seek conceptual clarity (we sometimes humbly call it "lack of technical debt"). I am not sure how to make that work with Scrum. Perhaps if everything was done three times, punctuated by a team discussion, each time with shorter code. Second thing that I dislike the most about Scrum is that it threw away (or at least "conveniently" renamed) pretty much everything that was ever known about project management. Of that, probably the formal estimation methods (replaced in Scrum by intuition for some reason) are the biggest loss. (I think it comes from the fact they actually realized the quantum nature of development is a problem.) To me, that is a huge red flag that it is, in fact, a snake oil. P.S. I am tired of the YADIW excuse. Let's have a nice honest discussion about how it can be fixed.
- rawoke083600 6y ago
  >that ideal software development is just a continuous production This ! Can't agree more... Scrum always made me feel like a production-line-worker making shoes... No craft nor space to discovery/explore problem solving. Urg and all those damn meetings and pulling numbers out of thin air ! What a waste of time those meetings were !
kevsim 6y ago
I interviewed a long time ago at a med tech company in Boston where Jeff Sutherland, one of the inventors of scrum, was the CTO (I believe). I had recently been through scrum master training at my current job and was quite keen to see how scrum was applied in the place where the guy who invented it was working. I asked my first interviewer how they used scrum on their team and his answer was that they didn't use scrum. I was pretty shocked. Then he explained that scrum didn't fit well with their team and the way they worked best together, whereas on some other teams they were really happy with scrum. Made me realize that's there's no one size fits all process for software teams. Some of these "pre-baked" processes can help teams depending on their composition and maturity, but teams/companies really need to find the way of working that works for them.
- Areading314 6y ago
  If you read his book, you'll see that he repeatedly drives the point home, that Scrum is not a set of pre-baked processes, but a philosophy around measurement, prioritizing, and continuous improvement. The cargo cult meetings and processes are more a product of the "Agile movement" that is championed by mediocre middle managers.
  - danjac 6y ago
    That's the problem though: any philosophy that cannot be implemented by a "mediocre middle manager" (i.e. most managers in most companies) is doomed to fail. And if it requires an "amazing" manager to succeed, the question is whether it's down to the philosophy or the manager.
    - sergeykish 6y ago
      But there are no managers in SCRUM. It is doomed to fail once methodology is thrown out and replaced with manager. I've been on SCRUM presentation in 2007. They explicitly stated - we help forming the team and go away.
      - danjac 6y ago
fergie 6y ago
(The linked article is a piece of content marketing and not the reflections of an individual expert in the field.) Typically for this type of article the merits of "Scrum" are debated without Scrum first being defined, thereby making any reasonable appraisal impossible, and inviting a "your doing it wrong" conclusion. At this point I am genuinely unsure whether this is some sort of master-level content-marketing trolling which is expertly crafted to goad engagement from senior engineers, or whether it is just sloppy, misguided, business-school nonsense.
- bosswipe 6y ago
  It is blog spam that rips the content from the decent stackexchange discussion here https://softwareengineering.stackexchange.com/questions/410482/how-do-i-prevent-scrum-from-turning-great-developers-into-average-developers/ https://softwareengineering.stackexchange.com/questions/4104...
- jevgeni 6y ago
  It's a decent article. Defining "scrum" in a debate-club fashion here is meaningless and is actually a valid strategy to discredit any criticism of it. 1. Scrum being a "philosophy" itself isn't clearly defined. 2. Different orgs practice Scrum differently, hence the more specifically you define Scrum, the less of the practice falls under that definition. 3. Best definition in this context is "set of practices most orgs call Scrum", which might as well be omitted. And all of that has no bearing on the fact, that if team leadership busts out Scrum boards and Jira tickets more often than discussing problems, teaching/promoting knowledge and figuring out the best product design, then it's probably a mediocre shitshow.
mrich 6y ago
As a manager you should think hard about what aspects of scrum are important to you and where you can let loose. This will heavily depend on the makeup of your team - how many experienced developers are there who don't need hand holding? How many of them will still deliver without some oversight? How many of them can mentor? How many inexperienced people do you have, how many will be onboarded in the next year? Things like that determine and change your development process.
- MattGaiser 6y ago
  > what aspects of scrum are important to you and where you can let loose. Scrum explicitly does not permit that. A criticism that didn't make it into that answer. https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-US.pdf https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum...
  - mindcrime 6y ago
    Two thoughts: 1. There's a lot of stuff that is often thought of as "part of Scrum" that really isn't. To the extent that the parent post you're replying to is referring to these things, then he/she is spot on. Things like Jira tickets, story points, planning poker, velocity, two week sprints, yadda yadda yadda. 2. Scrum™ doesn't permit you to do certain things... while truly saying you are doing Scrum™. But nobody has any real authority to mandate that you do Scrum™ to the letter, as opposed to an in-house "little-s scrum" version. And if that is what works better for you, you should do it. The goal is delivering working software, not adherence to the Scrum Guide for its own sake.
doctor_eval 6y ago
In my company we hired a CSM (certified scrum master) and we definitely did Scrum by the book. But we didn’t do it right, in the sense that after 2 years our productivity was worse than when we started. In my experience, Scrum can easily become a series of little waterfalls, rather than bring a flexible and needs based approach to building complex products. This lead me to see that Scrum is not really Agile, where by “Agile” I mean [0]. Scrum is a process and Agile is a mindset. Some teams are able to hold both ideas in their head at the same time. But in my experience across multiple large customers and projects, teams think that by doing Scrum they are being Agile, and this is not the case at all. Scrum is no more a solution to the social and political problems of a project than is waterfall or the spiral model (which Scrum mimics IMO) or anything else. A good team will succeed regardless of the project management methodology and a bad team will most likely fail. Scrum is not the problem nor the solution. It’s management’s job to ensure that the teams are working well, that people have room to succeed and fail, and that the project management methodology suits the needs of the project. That’s certainly where I failed my business for a few years, until I worked it out. [0] https://agilemanifesto.org/ https://agilemanifesto.org/
deleted 6y ago
[deleted]
29athrowaway 6y ago
Very few people care to read the official Scrum documentation. It is not a long read. Some posts on HN have more words than the Scrum Book. As a result of not reading the documentation, not many understand what Scrum is and what they're criticizing. I have been in that situation myself at some point. One day, I found myself so frustrated that I read the Scrum book over and over again until I could complete the certification assessment with passing score, just to understand if Scrum was to blame for the problems I perceived. What I learned in the process was that scrum does not recognize the role of a project manager and it does not make distinctions between development team members. The development team is defined as self-organizing and empowered to make decisions to a very reasonable extent. The problems described here often start when some the self-organization and autonomy of the development team is taken away. This can take many forms, like adding roles like project managers or by redefining existing roles, such as making the scrum master role absorb responsibilities from the development team. Those adjustments are suboptimal and almost inevitably result in an imbalance of power between product and engineering, and that's a really bad idea that will often result in engineering disasters. Some companies create engineering holidays such as hackathons, where engineers can take the time to work on neglected aspects of projects. But then, in many companies, product people have started to intervene those events as well, perpetuating engineering frustration.
Animats 6y ago
Complicated tasks get deprioritized Features over robust code An effect is "birth defects are forever". An early design mistake is very difficult to correct in a scrum-like "agile" process. The incremental nature of the process favors patching around it. This is OK for webcrap, but not OK for systems that have strong internal consistency or time constraints.
- xtracto 6y ago
  I disagree with this sentiment, well at least I disagree that it is SCRUM's fault. I think this is a problem that resides higher up. I have been in teams that to take the time to solve technical debt and even generate technical wealth. The best approach that has worked for me is to divide the development available time per sprint in: 33% new product features, 33% existing product maintenance, 30% Solve Technical debt (or 20% tech debt, 20% product debt with a 30-30-20-20 split). With this I try to show that the problem of development teams NOT fixing their crap i not an issue of the Agile/SCRUM process (or any other process), it is an issue of management that prefers to ignore the mounting technical debt (until it explodes and you have the Github downtime, or LinkedIn leaks or the fact that changes become slower and slower due to codebase complexity).
  - JoeAltmaier 6y ago
    Hm. That sounds like a process issue. Which is what SCRUM etc are part of. So its not process, but changing process will fix it? SCRUM + technical debt management is the cure? Then SCRUM was missing something. I put the blame squarely on the process, whether its SCRUM or whatever.
    - mindcrime 6y ago
      Then SCRUM was missing something. Scrum is missing a LOT of things, because it's very specifically intended to not be highly prescriptive. The whole idea is to iterate, use empirical feedback, and evolve your process to match your context. Right near the beginning of the Scrum Guide it reads Scrum is not a process, technique, or definitive method. Rather, it is a framework within which you can employ various processes and techniques. Scrum makes clear the relative efficacy of your product management and work techniques so that you can continuously improve the product, the team, and the working environment.
jyriand 6y ago
What i don’t like most about scrum is the sprints. Doesn’t matter if it’s one or two weeks long, we never have a successful sprint, the velocity chart looks like random numbers, and we spend hours on debating what the story points really mean. Sprints are artificial deadlines that don’t really make any sense, developers don’t care, business people don’t care. A project i could complete in a month will take at least three months, because of the processes we have to follow. Instead of refactoring and thinking about overall design i have to worry about getting the task done by the end of the sprint.
- mathw 6y ago
  I raised a similar idea with my team a while back and we stopped doing sprints as an experiment. We haven't restarted. It has been mentioned a small number of times, but the consensus is always that we don't think it will help. For our team, for what we do, how our work arrives and the nature of the systems we're maintaining and developing, sprints were just artificial lines in the sand.
- sergeykish 6y ago
  SCRUM highlights project management problems. If everything works its only overflow is a two hours boring retrospective. Morning meetings is 5 minutes maximum (status ok), estimation - about an hour. Last sprint day is a lazy day - no new tasks allowed, refactor what you can, make presentations etc. Never heard of successful one week sprints, two weeks looks optimal. Sprint purpose is to show there is no hidden debt ("almost done, oh, no, three weeks more"). Roll out is a bonus. Failed sprint should be an exception. It as marker, to resolve it you have to resolve real issues: * team got to much points to implement properly * no need to fight on story points, ±1 should not matter much * you can't have two week story, commit something
  - C1sc0cat 6y ago
    I have worked very successfully with one day sprints and an end of day catch up - though the was with RAD/DSDM.
- woutr_be 6y ago
beaker52 6y ago
The thing I personally see that corrupts Scrum the most are external stakeholders. They're usually applying time pressures and defining work items to be worked on. The team then has no ownership and no control, resulting in an unhappy and unmotivated team that's constantly disappointed with itself for not delivering and often isn't really invested in what's being asked of them. If you want teams to care, they need to own it. When teams care, things happen faster. The catch is that you can't make them care about what you want done. You need to treat the team like the "10x rogue developer" giving them freedom to pursue what they want to pursue, steered by the product owner, shielded from external stakeholders. A product owner that mandates as _part_ of a team "we need to do X by y because Bob from marketing wants it" has a losing battle on their hands. I really think the best person to be prioritising is the leader of the moment. Sometimes it's the strongest Dev, sometimes it'll be the product owner, sometimes it'll be the scrum master, sometimes it'll be a UX designer. It could be anyone, that everyone believes in. The next week/month/quarter it'll naturally be someone different, or maybe it's still that same person, if everyone is on board then there's no issue, right? That's not to say there's should be bitter infighting either, only that everyone should follow the herd. This way, the majority of people believe they're working on the right thing, and social pressures get others pushing in the same direction too.
sergeykish 6y ago
Once there was great scrum master, no managers, felt like a team, no missed sprints. Once there were no managers, team crumbled in internal politics but was bearable. Once there was micromanagement, all fails to developers, all prizes for management, each sprint failed, that was hell.
danjac 6y ago
While there may be success stories out there (and usual arguments apply for No True Scotsman), a company that proudly states "we're a scrum shop" is at this point most likely shorthand/signal for "we love meetings and micromanagement" and is to be avoided if possible.
C1sc0cat 6y ago
No and Yes
leto_ii 6y ago
> Build a team to do scrum, don’t expect scrum to build your team. This is a very important takeaway I think. A development methodology can work to organize the processes of an already (relatively) well working group. Expecting process standardization to fix dysfunctional human interaction is just putting the cart before the horse. Scrum will not build trust between coworkers or between workers and management. It will not allow non-technical management to suddenly develop an understanding an appreciation for technical difficulties.
mem0r1 6y ago
I almost can't believe that it's 2020 and people are still disscussing or even worse "utilizing" Scrum. Pretty much all good and excellent Software engineers I know who had to deal with it at various companies hated it.
znpy 6y ago
I work in systems engineering, automation, devops and that kind of stuff. I've seen colleagues in development at other companies do this daily standups and all this scrum thing. From the outside it really looks like somebody constantly asking "are you done yet?" And pressuring people into delivering. It really looks like something invented to serve companies and management more than developers.
deleted 6y ago
[deleted]
richliss 6y ago
99% of teams are doing Scrum wrong most likely. Scrum has been ruined by many different groups (large consultancies, certification bodies, the misinformed, bloggers etc.) and there is a movement called the Scrum Pattens movement trying to fix the damage and to make it more explicit. If you want to do Scrum properly read “A Scrum Book”. Scrum is not a process it’s process design framework- you start with Scrum as a framework to then, through inspecting and adapting, add what works for that team (and no other team) and discard/replace what doesn’t through experiments and retrospectives. Does that sound like it’s liberating for engineers or something that ruins them? Note: Kanban is also not a process but a system for continuous improvement. 99% of teams doing that are doing it wrong too most likely.
- dragonwriter 6y ago
  > Scrum is not a process it’s process design framework Scrum as defined in The Scrums Guide is a very specifically defined process with a few degrees of freedom, not a process design framework. Now, if your approach was actually Agile (unlike the many groups that do Scrum, either as defined in the Guide or some variation they've cobbled together from other sources and still call “Scrum”, and think that by doing so they are therefore Agile), any canned process will be at most a starting point and input into what works for your team. But that is very much not Scrum as it has been propounded from the beginning, including by it's creators. > Kanban is also not a process but a system for continuous improvement Kanban is a very specific process element related to flow visibility and management.
  - mindcrime 6y ago
    Scrum as defined in The Scrums Guide is a very specifically defined process with a few degrees of freedom, not a process design framework. Scrum as defined in the Scrum Guide prescribes very little. It's not much more than "Have a development team, a scrum master, and a product owner, have a product backlog, have developers plan their work, and work in time-boxed increments." Nearly every other aspect of how work gets done is unspecified and can (and should) be evolved by the team based on empirical observation. My observation is that people have a tendency to adopt a version of scrum that is based on certain "default settings" that everybody sort of assumes are required, when they aren't actually. Two week increments, for example. I've heard so many people complain about scrum mandating two week increments, when it doesn't actually. Or people complain about "velocity", and "story points" which are likewise not part of scrum at all.
bJGVygG7MQVF8c 6y ago
As a vendor of thought leadership, it's 100% in my interest to treat as exogenous the likelihood that my framework / best practice / etc will be implemented as I intend it to under ideal circumstances. As a consumer of thought leadership — a sensible and responsible one, that is — I'm compelled to treat such concerns as endogenous to the framework / best practice / etc, and predict outcomes accordingly. "You're doing it wrong" doesn't explain anything. At best it's the start of a conversation, at worst it's intentionally used to elide the costs of whatever it is you're selling.
tomohawk 6y ago
The main problem I've seen with scrum is that everything can get put into the backlog, and the backlog becomes infinite. Then, development becomes ticket driven instead of engineered. I have seen scrum used successfully where an engineering process was placed in front of the backlog ala Feature Driven Development. There is a ticketing system, but it is kept separate from the work planning system.
sunstone 6y ago
Scrum is a process for large companies to force some group consistency across their 1000's of developers. Think of it as the minimum viable group behaviour. Naturally talented and effective team oriented developers know what to do naturally and don't require the explicit framework.
Fire-Dragon-DoL 6y ago
Scrum has its flaws, but even though is marked as a "process framework" and the guide states you should evolve the process to fit your company (it is part of the agile movement), it's considered a big red flag diverging from it even a little, which completely invalidates the "people over processes" part of the manifesto.
blargmaster33 6y ago
It's ALL ABOUT THE BACKLOG! A properly groomed backlog with clear requirements/acceptance criterias and guidelines from a software architect will make scrum teams highly efficient! Having the SA an the PO beeing 2-5 sprints ahead of the team creating a backlog that is ready for the team is a wonderful thing to behold. A competent SA will with input from the team leader be able to estimate on the feature level allowing reasonable time estimates to be given to the management. Grooming the backlog is a FULL TIME job.

150 points by Lilian_Lee 6y ago

I think it's similar to when someone switches jobs frequently and complains about every company they've worked at. At some point, you have to realize it's you not them. To me it feels scrum is the person switching jobs constantly and saying people don't get it.

baq 6y ago
Yeah, no. Scrum is a tool. You can implement it wrong or be very strict with it which kind of isn’t agile, but it’s always a people problem. Scrum tells you 1) to analyze the way your team works, 2) make improvements, 3) talk to each other. If that sounds reasonable, it’s probably because it is. The mythology of scrum being evil is misguided, I wonder how much of it is caused by engineers forced to use JIRA configured by somebody who doesn’t work with the team.
- supercanuck 6y ago
  No true scrum.

loopz 6y ago

Easy: Is the output great engineering because of scrum, or despite it?

awinter-py 6y ago

or both

deleted 6y ago

[deleted]

samdwilson 6y ago

I wish blog posts like this had examples of things they actually did. It would make it a lot more informative to learn from an example.

Yhippa 6y ago

How about letting developers pick or come up with their preferred way of working instead of mandating Scrum?

kitotik 6y ago
The only potential result of a competently run scrum process is exactly that - a process that was designed by the team. If you are stuck in some weird cargo cult that doesn’t allow the team to iteratively change the process, you should call bullshit.
- rightbyte 6y ago
  If scrum is any process designed by the team the term is worthless. Sadly, scrum as I have seen it has been consultants preaching to the commoners how their rigid process is going to make them agile. Scrum is just flawed from the foundations for anything but very routine work where you can somewhat estimate subtasks duration with any accuracy. But if your job is that easy you hardly need any fancy process anyway.
  - kitotik 6y ago
    > If scrum is any process designed by the team the term is worthless. SCRUM is a handful of tactics that a team can start off with to design and implement the “right” process for a given team. For example, I’ve been on several teams where through the use of retrospectives, daily stand ups were abandoned and replaced with other means to keep the team in sync. > Sadly, scrum as I have seen it has been consultants preaching to the commoners how their rigid process is going to make them agile. That sucks, but sadly this is the most common case. Very few organizations actually want agility, as they are culturally and practically top-down hierarchies that require command-and-control structures to function. These consultants are generally brought in by middle-management who are grasping at straws without any real buy in from the c-suite. > Scrum is just flawed from the foundations for anything but very routine work where you can somewhat estimate subtasks duration with any accuracy. But if your job is that easy you hardly need any fancy process anyway. I couldn’t disagree more. For “routine” work that is predictable, what value does agility provide? It’s either done correctly or not. Agility is only useful in dynamic environments when outcomes are hard to predict and there is limited prior art to reference.

waschl 6y ago

I am in a big project which assembles 45 teams and all of them shall adopt Scrum (for various reasons). My observation is that all those teams which have a sustainable pace with regards to architecture, technology, quality, output, social behavior, etc have done so while adopting and embracing Scrum in a clean way since the beginning of their existence as a team. All teams severely struggling with their content of work, output and collaboration have also severe issues with regards to Scrum-adoption, and show anti-patterns similar to the Stackoverflow thread creator‘s. However I would say the root causes (which we discussed in maaaany meetings) are certainly neither caused by Scrum nor increased by it, but individual mindset, dysfunctional team dynamics, pressure, weird contracts, etc. and would be there under any other or no process framework. I am no Scrum fanboy (I think), but this experience and also from former projects make me quite sure to not blame Scrum in the first place when I see struggling teams, but trying to understand the underlying problems and solve those.

waschl 6y ago
One more thing: In answer to Scrum advocates claiming its about doing it right I would disagree and replace it with understanding what is really (really REALLY) the purpose and idea behind it. Don’t worship the cult and don’t fight it because it’s the perfect target of rants, but see the motivation behind it and acknowledge that there may be reasons why it makes sense how it is to some degree. This doesn’t only apply to Scrum but to any other interaction of humans.
- dboat 6y ago
  Could you explain what you mean by the real purpose and idea behind scrum?
  - mongol 6y ago
    In short I would say, applying ideas from the agile manifesto while providing cadence and some predictability. But that is a personal opinion.
  - waschl 6y ago

stx 6y ago

In my experience it has been that people expect scrum to be a magic bullet. Things are not going well... it will be better when we change to the new orgs process. Only the real reason its not going well is because of lack of planning and poorly written stories. The how you fix that is much more complicated.

moksly 6y ago

I work in the public sector of Denmark, and I’m involved with both developing and procuring solutions. We have quite a lot of them, around 300 for our 10.000 employees, and from a buyers perspective things like Scrum and agile rarely makes a lot of sense. It’s down to the old triangle of time, features, money, which agile and through it scrum mandates at least one has to be flexible. Only that’s now how you buy software. No one is going to give you an unlimited amount of money of time for an uncertain amount of features, and almost nobody has the time to act into your Scrum schedule to prioritise stuff. Because of this, it’s not really how you sell software either. As a result Scrum often becomes a wrapped in a business side that’s very much unified or waterfall process in companies pretending to be agile. I’m not saying it happens everywhere, but I don’t think I’ve ever been involved with a procurement or development process you could truly call agile. That doesn’t mean you can use scrum, but it does mean that you should be careful about how you do so. If you have a bunch of guys working on different CRUD web-applications, does it really make sense to have them do a stand up every morning? Probably not. But maybe the kanban board still works well. Based on my own experiences you have to be careful and “agile” about how you build your processes to suit your changing needs, but going full strict scrum, is probably never going to work unless you’re a major tech company.

GordonS 6y ago
> We have quite a lot of them, around 300 for our 10.000 employees, and from a buyers perspective things like Scrum and agile rarely makes a lot of sense > No one is going to give you an unlimited amount of money of time for an uncertain amount of features In a customer project I worked on recently, the consultancy I work at had a contract based on the number of story points - something like, "we will deliver 200 story points in phase 1". Now, because a story point is a relatively nebulous thing, there is of course a lot of room on both sides to fiddle things, but actually the customer was pretty happy with it. The actual scrum teams were completely miserable, but that's a separate point altogether :)

onion2k 6y ago

Very productive individuals that don’t work as a team I refuse to have those people on my team. One person who's twice as productive as everyone else sounds great, but if that person's work doesn't fit well and makes everyone else's work harder it always been a net loss in my experience. I'd prefer my team works well together than have some "brilliant loner" join it.

metalliqaz 6y ago
It's a matter of management. Brilliant people can be very useful. Even team players may not work with all other team players. Gotta find the right fit.
donw 6y ago
Agreed. What happens when the genius leaves? Can other people extend or maintain their work? Is there a lasting benefit to the organization? Does their work enhance the capabilities of other contributors? From my experience in working with "very productive individuals that don’t work as a team", the answer to these questions is "no". The reality is that a large chunk of generating economic value stems from being able to get along with other people. The richest blacksmith in the Old West wasn't the one that was the most brilliant artisan. They were the one that knew the value of a customer, how to cultivate a long-term relationship with one, and how to get more.
dbt00 6y ago
This can flow both ways. I've had great engineers on my team that people were scared to approach because most of those conversations resulted in the questioner discovering they were wrong about something or missing some knowledge. Ideally people who are afraid of that are coached up to be happy to learn instead. That only works if the great engineer is also excited to learn and help. If they call people stupid or fail to listen to all the details because they prejudge the situation, then they're more of the "brilliant jerk" archetype -- but they often aren't as brilliant as they think they are.
apabepa 6y ago
Yes I agree for the general case and I have seen this problem many times where management refuse to see the problem with anti-social loners holding too much of the competence in a team. It can also depends on what kind of software you are working on. Some parts might require a 'brilliant mind' to push through a spike solution for certain areas. This individual should not really be in a "normal-happy-scrum-team" though, that would be a punishment both for the team and the individual...

mharroun 6y ago

Scrum, Kanban, scrumban, tickets with predefined checkins... all can work. "Formal scrum" only exists to sell books, certs, classes; but more importantly to give justification or a "fix" to failed project managers and leaders. A process will not fix a team that has bad teamwork, is not productive, and/or has bad communication/leadership/management.

PaulKeeble 6y ago

In the one place I saw Scrum work really well it wasn't because of scrum we succeeded it was the amazingly talent team that groked their goals and understand how to build software well. The complete lack of an enforcer manager was a huge win, being connected directly into your customers and letting them drive what they needed and balancing it with the engineering, that worked really well. They executed well despite scrum and ultimately used Kanban with on need for the biweekly meetings since they were releasing many times a week. Scrum was a small part of a package of process, the important bit that made that possible was the engineering processes not the task management ones. The business needed to work out what matter most to it and the developers certainly helped more as their expertise in the subject matter grew but what made it all slick was the automation and engineering. Engineering is where the time goes on a software project and doing that well is what matters. As an industry we focus so much on something that is a few hours of effort a week on planning and tracking and yet the big time goes into the actual work. If you spend a lot of time doing planning and tracking and not producing software you are doing it wrong regardless of whatever process you say you are using. Scrum is not remotely sufficient, it ignores all the important bits.

jariel 6y ago
"being connected directly into your customers and letting them drive what they needed and balancing it with the engineering," Lucky you however, letting 'raw' Engineers interface with customers is usually a disaster. Engineers build tech, the company builds products, and they are very, very different things. A lot of pieces in there - support, training, docs, price, risk, leverage, IP, know-how, relationship management, legality, confidentiality. Experienced Engineers who have a lot of exposure to Product, Sales etc. can do this, there's usually a role there for a highly technical person to support sales. If it were only a matter of 'the customer saying we need XYZ and Engineers doing that' then great, but it's almost never that.
- PaulKeeble 6y ago
  You need the right customers. We were really lucky the lady in charge of the business team learnt enough of how the development worked to sit in that middle ground between her team of experts and ours to guide the direction well. I would say she and our engineering principle were what made things work well. If you are working with generic customers out there in the world then its much harder to utilise customer focussed requirements.

fjfaase 6y ago

Great article, but it does not mention management attitude. If upper management does not have the right attitude towards Scrum, Scrum will fail. If upper management does not guard the role of the Scrum masters, select capable Scrum master and allow them to function correctly, Scrum will crumble into another tool for micro-management which frustrates developers and destroys productivity. I also have seen that often it are the more ambitions (and less technically talented) developers that opt for role of Scrum master as a stepping stone to a management role. These type of Scrum masters will starting act like top-down managers, who no longer fulfill the role of a Scrum master, namely provide a safe environment for the team to function optimally.

mindcrime 6y ago
Great article, but it does not mention management attitude. If upper management does not have the right attitude towards Scrum, Scrum will fail. If upper management does not guard the role of the Scrum masters, select capable Scrum master and allow them to function correctly, Scrum will crumble into another tool for micro-management which frustrates developers and destroys productivity. BINGO. The "problem with scrum" isn't usually scrum itself, but the management and culture of the company. And bad management and toxic culture will, in my experience, lead to the same results no matter what process / methodology you nominally employ. To me, most criticisms of scrum reduce to a (legitimate) claim that "scrum isn't a magic bullet that will fix the fucked up management and toxic culture at this shitty company."
- AnimalMuppet 6y ago
  In fact, scrum is something the messed-up management has tried to use as a magic bullet, rather than actually fixing themselves.

donw 6y ago

The problem with Scrum is that most practitioners have no idea why their tools exist in the first place, under what conditions those tools apply, and what to do when their tools fail. Nearly every -- but not all! -- "Agile" environment I have worked in was pure cargo cult, with none of the requisite cultural infrastructure required to actually make any of it work, and often with a very strong centralization of control that made local iteration... unpossible[1]. Or they do the opposite, and go full "Lord of the Flies", providing no structure at all. Both approaches yield poor results. You want to provide structure, but then grant autonomy over that structure to those beholden to its results. If you want to "be Agile", your organization needs to push a great deal of control and trust fairly far down in the corporate hierarchy. Doing this successfully requires that organizations build the structures required for both appropriate oversight and cultural promulgation, and few companies even recognize the need for this, much less have the tools to do so. [1] I am hereby defining this as "Possible on paper, but not in reality".

alexashka 6y ago

The only right way to do 'great engineering' is by not having any middle management. The only right way to do great engineering, is by first asking what we ought to be engineering, not re-implementing the same shit over and over again, like we do web frameworks in every new language. Great engineering is completely unrelated to scrum. It is only in the delusional mind of a middle manager that his existence and thoughts are at all relevant to the success or failure of any project on this planet.

bickeringyokel 6y ago
You'll have to define middle management, if you're including product management, then your statement would be pretty contradictory. Can't know what you ought to build if to don't know what your customer wants.
- alexashka 6y ago
  Everyone knows what the customers want, it's quite trivial. Most problems people try to solve using technology/engineering, are actually an attempt to bypass dealing with the real issues, which are almost always political. One trivial example of this is children starving to death or dying of diseases we have medicine for. I'm sure there'll be another 'app' created for yet another charity or foundation. Another trivial example of this is all the middle management and technical bullshit mobile development sweatshops go through, hiring separate developers for iOS and Android, getting them to coordinate and sync their work, working out the peculiarities of the two platforms, etc, etc. All of these problems are solved at the political level of mandating that all mobile platforms have to support a shared set of protocols, libraries and frameworks. All this 'fin tech' investment bullshit - it's a political problem, not a technical problem. It's an endless list of insanity - 99% of IT work is useless trash, as are almost all other forms of work done in office buildings. It'd take a trivial amount of investment (less than a trillion) to automate away most office jobs worldwide but we don't do it, because we're stuck with a political decision to continue wage slavery. Again, political problem, not technical.
danjac 6y ago
While "middle manager" is often nowadays a negative term, having a good manager between yourself and the upper management/customer can be a godsend. They can act as a bullshit filter, they can deal with bureaucratic busywork, they can get you whatever resources you need, fight for more funding/people for your team, help out with HR stuff and so on. You need these people so you can get on with "great engineering".

kevsim 6y ago

This is something I think a lot about because I'm working for a small startup [0] building an issue tracker and trying to take on the likes of Jira. We discuss a lot about exactly how much scrum we should support "natively" in the tool (sprints, story points, etc.) because we've seen scrum go wrong and turn into a mess of micromanagement and misaligned incentives a number of times. At the moment we've opted to make it very un-scrum and our early adopters aren't complaining. Teams need to work hard to find a process that actually works for them - tools and scrum master trainings can't dictate that for them. 0: https://kitemaker.co https://kitemaker.co

js8 6y ago

We use Scrum at work and I have to say, I am pretty annoyed by it. I think it is fundamentally rooted in the idea that ideal software development is just a continuous production of small improvements to the code. And from this come all its micromanagement failure modes (which there are plenty). I think in reality, SW development done right is nothing like that. It is highly discrete when it comes to output, because it takes time and experimentation to come up with the correct way to approach a problem, but if you do it right, you save yourself an incredible amount of time. It's more like mathematics, where it takes time to discover that things are actually rather easy (this quote comes to mind https://micromath.wordpress.com/2011/11/06/andrew-wiles-on-doing-mathematics/ https://micromath.wordpress.com/2011/11/06/andrew-wiles-on-d...). Of course, if you look at the project from the longer time perspective, it can appear as continuous production of improvements. But it has a kind of quantum nature, if you decrease the scale of time, you will see less continuity and more discrete bursts of code production. There is something like uncertainty principle that on certain scale, it's pointless to try to predict things, because making the correct prediction (which is needed at least to define thing DONE) will take as long as doing the thing in the first place. I don't consider myself special, but it is possible that Scrum ruins great minds because they seek conceptual clarity (we sometimes humbly call it "lack of technical debt"). I am not sure how to make that work with Scrum. Perhaps if everything was done three times, punctuated by a team discussion, each time with shorter code. Second thing that I dislike the most about Scrum is that it threw away (or at least "conveniently" renamed) pretty much everything that was ever known about project management. Of that, probably the formal estimation methods (replaced in Scrum by intuition for some reason) are the biggest loss. (I think it comes from the fact they actually realized the quantum nature of development is a problem.) To me, that is a huge red flag that it is, in fact, a snake oil. P.S. I am tired of the YADIW excuse. Let's have a nice honest discussion about how it can be fixed.

rawoke083600 6y ago
>that ideal software development is just a continuous production This ! Can't agree more... Scrum always made me feel like a production-line-worker making shoes... No craft nor space to discovery/explore problem solving. Urg and all those damn meetings and pulling numbers out of thin air ! What a waste of time those meetings were !

kevsim 6y ago

I interviewed a long time ago at a med tech company in Boston where Jeff Sutherland, one of the inventors of scrum, was the CTO (I believe). I had recently been through scrum master training at my current job and was quite keen to see how scrum was applied in the place where the guy who invented it was working. I asked my first interviewer how they used scrum on their team and his answer was that they didn't use scrum. I was pretty shocked. Then he explained that scrum didn't fit well with their team and the way they worked best together, whereas on some other teams they were really happy with scrum. Made me realize that's there's no one size fits all process for software teams. Some of these "pre-baked" processes can help teams depending on their composition and maturity, but teams/companies really need to find the way of working that works for them.

Areading314 6y ago
If you read his book, you'll see that he repeatedly drives the point home, that Scrum is not a set of pre-baked processes, but a philosophy around measurement, prioritizing, and continuous improvement. The cargo cult meetings and processes are more a product of the "Agile movement" that is championed by mediocre middle managers.
- danjac 6y ago
  That's the problem though: any philosophy that cannot be implemented by a "mediocre middle manager" (i.e. most managers in most companies) is doomed to fail. And if it requires an "amazing" manager to succeed, the question is whether it's down to the philosophy or the manager.
  - sergeykish 6y ago
    But there are no managers in SCRUM. It is doomed to fail once methodology is thrown out and replaced with manager. I've been on SCRUM presentation in 2007. They explicitly stated - we help forming the team and go away.
    - danjac 6y ago

fergie 6y ago

(The linked article is a piece of content marketing and not the reflections of an individual expert in the field.) Typically for this type of article the merits of "Scrum" are debated without Scrum first being defined, thereby making any reasonable appraisal impossible, and inviting a "your doing it wrong" conclusion. At this point I am genuinely unsure whether this is some sort of master-level content-marketing trolling which is expertly crafted to goad engagement from senior engineers, or whether it is just sloppy, misguided, business-school nonsense.

bosswipe 6y ago
It is blog spam that rips the content from the decent stackexchange discussion here https://softwareengineering.stackexchange.com/questions/410482/how-do-i-prevent-scrum-from-turning-great-developers-into-average-developers/ https://softwareengineering.stackexchange.com/questions/4104...
jevgeni 6y ago
It's a decent article. Defining "scrum" in a debate-club fashion here is meaningless and is actually a valid strategy to discredit any criticism of it. 1. Scrum being a "philosophy" itself isn't clearly defined. 2. Different orgs practice Scrum differently, hence the more specifically you define Scrum, the less of the practice falls under that definition. 3. Best definition in this context is "set of practices most orgs call Scrum", which might as well be omitted. And all of that has no bearing on the fact, that if team leadership busts out Scrum boards and Jira tickets more often than discussing problems, teaching/promoting knowledge and figuring out the best product design, then it's probably a mediocre shitshow.

mrich 6y ago

As a manager you should think hard about what aspects of scrum are important to you and where you can let loose. This will heavily depend on the makeup of your team - how many experienced developers are there who don't need hand holding? How many of them will still deliver without some oversight? How many of them can mentor? How many inexperienced people do you have, how many will be onboarded in the next year? Things like that determine and change your development process.

MattGaiser 6y ago
> what aspects of scrum are important to you and where you can let loose. Scrum explicitly does not permit that. A criticism that didn't make it into that answer. https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-US.pdf https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum...
- mindcrime 6y ago
  Two thoughts: 1. There's a lot of stuff that is often thought of as "part of Scrum" that really isn't. To the extent that the parent post you're replying to is referring to these things, then he/she is spot on. Things like Jira tickets, story points, planning poker, velocity, two week sprints, yadda yadda yadda. 2. Scrum™ doesn't permit you to do certain things... while truly saying you are doing Scrum™. But nobody has any real authority to mandate that you do Scrum™ to the letter, as opposed to an in-house "little-s scrum" version. And if that is what works better for you, you should do it. The goal is delivering working software, not adherence to the Scrum Guide for its own sake.

doctor_eval 6y ago

In my company we hired a CSM (certified scrum master) and we definitely did Scrum by the book. But we didn’t do it right, in the sense that after 2 years our productivity was worse than when we started. In my experience, Scrum can easily become a series of little waterfalls, rather than bring a flexible and needs based approach to building complex products. This lead me to see that Scrum is not really Agile, where by “Agile” I mean [0]. Scrum is a process and Agile is a mindset. Some teams are able to hold both ideas in their head at the same time. But in my experience across multiple large customers and projects, teams think that by doing Scrum they are being Agile, and this is not the case at all. Scrum is no more a solution to the social and political problems of a project than is waterfall or the spiral model (which Scrum mimics IMO) or anything else. A good team will succeed regardless of the project management methodology and a bad team will most likely fail. Scrum is not the problem nor the solution. It’s management’s job to ensure that the teams are working well, that people have room to succeed and fail, and that the project management methodology suits the needs of the project. That’s certainly where I failed my business for a few years, until I worked it out. [0] https://agilemanifesto.org/ https://agilemanifesto.org/

deleted 6y ago

[deleted]

29athrowaway 6y ago

Very few people care to read the official Scrum documentation. It is not a long read. Some posts on HN have more words than the Scrum Book. As a result of not reading the documentation, not many understand what Scrum is and what they're criticizing. I have been in that situation myself at some point. One day, I found myself so frustrated that I read the Scrum book over and over again until I could complete the certification assessment with passing score, just to understand if Scrum was to blame for the problems I perceived. What I learned in the process was that scrum does not recognize the role of a project manager and it does not make distinctions between development team members. The development team is defined as self-organizing and empowered to make decisions to a very reasonable extent. The problems described here often start when some the self-organization and autonomy of the development team is taken away. This can take many forms, like adding roles like project managers or by redefining existing roles, such as making the scrum master role absorb responsibilities from the development team. Those adjustments are suboptimal and almost inevitably result in an imbalance of power between product and engineering, and that's a really bad idea that will often result in engineering disasters. Some companies create engineering holidays such as hackathons, where engineers can take the time to work on neglected aspects of projects. But then, in many companies, product people have started to intervene those events as well, perpetuating engineering frustration.

Animats 6y ago

Complicated tasks get deprioritized Features over robust code An effect is "birth defects are forever". An early design mistake is very difficult to correct in a scrum-like "agile" process. The incremental nature of the process favors patching around it. This is OK for webcrap, but not OK for systems that have strong internal consistency or time constraints.

xtracto 6y ago
I disagree with this sentiment, well at least I disagree that it is SCRUM's fault. I think this is a problem that resides higher up. I have been in teams that to take the time to solve technical debt and even generate technical wealth. The best approach that has worked for me is to divide the development available time per sprint in: 33% new product features, 33% existing product maintenance, 30% Solve Technical debt (or 20% tech debt, 20% product debt with a 30-30-20-20 split). With this I try to show that the problem of development teams NOT fixing their crap i not an issue of the Agile/SCRUM process (or any other process), it is an issue of management that prefers to ignore the mounting technical debt (until it explodes and you have the Github downtime, or LinkedIn leaks or the fact that changes become slower and slower due to codebase complexity).
- JoeAltmaier 6y ago
  Hm. That sounds like a process issue. Which is what SCRUM etc are part of. So its not process, but changing process will fix it? SCRUM + technical debt management is the cure? Then SCRUM was missing something. I put the blame squarely on the process, whether its SCRUM or whatever.
  - mindcrime 6y ago
    Then SCRUM was missing something. Scrum is missing a LOT of things, because it's very specifically intended to not be highly prescriptive. The whole idea is to iterate, use empirical feedback, and evolve your process to match your context. Right near the beginning of the Scrum Guide it reads Scrum is not a process, technique, or definitive method. Rather, it is a framework within which you can employ various processes and techniques. Scrum makes clear the relative efficacy of your product management and work techniques so that you can continuously improve the product, the team, and the working environment.

jyriand 6y ago

What i don’t like most about scrum is the sprints. Doesn’t matter if it’s one or two weeks long, we never have a successful sprint, the velocity chart looks like random numbers, and we spend hours on debating what the story points really mean. Sprints are artificial deadlines that don’t really make any sense, developers don’t care, business people don’t care. A project i could complete in a month will take at least three months, because of the processes we have to follow. Instead of refactoring and thinking about overall design i have to worry about getting the task done by the end of the sprint.

mathw 6y ago
I raised a similar idea with my team a while back and we stopped doing sprints as an experiment. We haven't restarted. It has been mentioned a small number of times, but the consensus is always that we don't think it will help. For our team, for what we do, how our work arrives and the nature of the systems we're maintaining and developing, sprints were just artificial lines in the sand.
sergeykish 6y ago
SCRUM highlights project management problems. If everything works its only overflow is a two hours boring retrospective. Morning meetings is 5 minutes maximum (status ok), estimation - about an hour. Last sprint day is a lazy day - no new tasks allowed, refactor what you can, make presentations etc. Never heard of successful one week sprints, two weeks looks optimal. Sprint purpose is to show there is no hidden debt ("almost done, oh, no, three weeks more"). Roll out is a bonus. Failed sprint should be an exception. It as marker, to resolve it you have to resolve real issues: * team got to much points to implement properly * no need to fight on story points, ±1 should not matter much * you can't have two week story, commit something
- C1sc0cat 6y ago
  I have worked very successfully with one day sprints and an end of day catch up - though the was with RAD/DSDM.
woutr_be 6y ago

beaker52 6y ago

The thing I personally see that corrupts Scrum the most are external stakeholders. They're usually applying time pressures and defining work items to be worked on. The team then has no ownership and no control, resulting in an unhappy and unmotivated team that's constantly disappointed with itself for not delivering and often isn't really invested in what's being asked of them. If you want teams to care, they need to own it. When teams care, things happen faster. The catch is that you can't make them care about what you want done. You need to treat the team like the "10x rogue developer" giving them freedom to pursue what they want to pursue, steered by the product owner, shielded from external stakeholders. A product owner that mandates as _part_ of a team "we need to do X by y because Bob from marketing wants it" has a losing battle on their hands. I really think the best person to be prioritising is the leader of the moment. Sometimes it's the strongest Dev, sometimes it'll be the product owner, sometimes it'll be the scrum master, sometimes it'll be a UX designer. It could be anyone, that everyone believes in. The next week/month/quarter it'll naturally be someone different, or maybe it's still that same person, if everyone is on board then there's no issue, right? That's not to say there's should be bitter infighting either, only that everyone should follow the herd. This way, the majority of people believe they're working on the right thing, and social pressures get others pushing in the same direction too.

sergeykish 6y ago

Once there was great scrum master, no managers, felt like a team, no missed sprints. Once there were no managers, team crumbled in internal politics but was bearable. Once there was micromanagement, all fails to developers, all prizes for management, each sprint failed, that was hell.

danjac 6y ago

While there may be success stories out there (and usual arguments apply for No True Scotsman), a company that proudly states "we're a scrum shop" is at this point most likely shorthand/signal for "we love meetings and micromanagement" and is to be avoided if possible.

C1sc0cat 6y ago

No and Yes

leto_ii 6y ago

> Build a team to do scrum, don’t expect scrum to build your team. This is a very important takeaway I think. A development methodology can work to organize the processes of an already (relatively) well working group. Expecting process standardization to fix dysfunctional human interaction is just putting the cart before the horse. Scrum will not build trust between coworkers or between workers and management. It will not allow non-technical management to suddenly develop an understanding an appreciation for technical difficulties.

mem0r1 6y ago

I almost can't believe that it's 2020 and people are still disscussing or even worse "utilizing" Scrum. Pretty much all good and excellent Software engineers I know who had to deal with it at various companies hated it.

znpy 6y ago

I work in systems engineering, automation, devops and that kind of stuff. I've seen colleagues in development at other companies do this daily standups and all this scrum thing. From the outside it really looks like somebody constantly asking "are you done yet?" And pressuring people into delivering. It really looks like something invented to serve companies and management more than developers.

deleted 6y ago

[deleted]

richliss 6y ago

99% of teams are doing Scrum wrong most likely. Scrum has been ruined by many different groups (large consultancies, certification bodies, the misinformed, bloggers etc.) and there is a movement called the Scrum Pattens movement trying to fix the damage and to make it more explicit. If you want to do Scrum properly read “A Scrum Book”. Scrum is not a process it’s process design framework- you start with Scrum as a framework to then, through inspecting and adapting, add what works for that team (and no other team) and discard/replace what doesn’t through experiments and retrospectives. Does that sound like it’s liberating for engineers or something that ruins them? Note: Kanban is also not a process but a system for continuous improvement. 99% of teams doing that are doing it wrong too most likely.

dragonwriter 6y ago
> Scrum is not a process it’s process design framework Scrum as defined in The Scrums Guide is a very specifically defined process with a few degrees of freedom, not a process design framework. Now, if your approach was actually Agile (unlike the many groups that do Scrum, either as defined in the Guide or some variation they've cobbled together from other sources and still call “Scrum”, and think that by doing so they are therefore Agile), any canned process will be at most a starting point and input into what works for your team. But that is very much not Scrum as it has been propounded from the beginning, including by it's creators. > Kanban is also not a process but a system for continuous improvement Kanban is a very specific process element related to flow visibility and management.
- mindcrime 6y ago
  Scrum as defined in The Scrums Guide is a very specifically defined process with a few degrees of freedom, not a process design framework. Scrum as defined in the Scrum Guide prescribes very little. It's not much more than "Have a development team, a scrum master, and a product owner, have a product backlog, have developers plan their work, and work in time-boxed increments." Nearly every other aspect of how work gets done is unspecified and can (and should) be evolved by the team based on empirical observation. My observation is that people have a tendency to adopt a version of scrum that is based on certain "default settings" that everybody sort of assumes are required, when they aren't actually. Two week increments, for example. I've heard so many people complain about scrum mandating two week increments, when it doesn't actually. Or people complain about "velocity", and "story points" which are likewise not part of scrum at all.

bJGVygG7MQVF8c 6y ago

As a vendor of thought leadership, it's 100% in my interest to treat as exogenous the likelihood that my framework / best practice / etc will be implemented as I intend it to under ideal circumstances. As a consumer of thought leadership — a sensible and responsible one, that is — I'm compelled to treat such concerns as endogenous to the framework / best practice / etc, and predict outcomes accordingly. "You're doing it wrong" doesn't explain anything. At best it's the start of a conversation, at worst it's intentionally used to elide the costs of whatever it is you're selling.

tomohawk 6y ago

The main problem I've seen with scrum is that everything can get put into the backlog, and the backlog becomes infinite. Then, development becomes ticket driven instead of engineered. I have seen scrum used successfully where an engineering process was placed in front of the backlog ala Feature Driven Development. There is a ticketing system, but it is kept separate from the work planning system.

sunstone 6y ago

Scrum is a process for large companies to force some group consistency across their 1000's of developers. Think of it as the minimum viable group behaviour. Naturally talented and effective team oriented developers know what to do naturally and don't require the explicit framework.

Fire-Dragon-DoL 6y ago

Scrum has its flaws, but even though is marked as a "process framework" and the guide states you should evolve the process to fit your company (it is part of the agile movement), it's considered a big red flag diverging from it even a little, which completely invalidates the "people over processes" part of the manifesto.

blargmaster33 6y ago

It's ALL ABOUT THE BACKLOG! A properly groomed backlog with clear requirements/acceptance criterias and guidelines from a software architect will make scrum teams highly efficient! Having the SA an the PO beeing 2-5 sprints ahead of the team creating a backlog that is ready for the team is a wonderful thing to behold. A competent SA will with input from the team leader be able to estimate on the feature level allowing reasonable time estimates to be given to the management. Grooming the backlog is a FULL TIME job.