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).<p>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 <a href="https://micromath.wordpress.com/2011/11/06/andrew-wiles-on-doing-mathematics/" rel="nofollow">https://micromath.wordpress.com/2011/11/06/andrew-wiles-on-d...</a>).<p>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.<p>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.<p>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>P.S. I am tired of the YADIW excuse. Let's have a nice honest discussion about how it can be fixed.
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.
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.<p>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.
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.
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.<p>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].<p>Or they do the opposite, and go full "Lord of the Flies", providing no structure at all.<p>Both approaches yield poor results. You want to provide structure, but then grant autonomy over that structure to those beholden to its results.<p>If you want to "be Agile", your organization needs to push a great deal of control <i>and trust</i> 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.<p>[1] I am hereby defining this as "Possible on paper, but not in reality".
<i>Very productive individuals that don’t work as a team</i><p>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.
I am in a big project which assembles 45 teams and all of them shall adopt Scrum (for various reasons). My observation is that <i>all</i> 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. <i>All</i> 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.<p>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.
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.<p>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.<p>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.
(The linked article is a piece of content marketing and not the reflections of an individual expert in the field.)<p>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.<p>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.
<i>Complicated tasks get deprioritized</i><p><i>Features over robust code</i><p>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.<p>This is OK for webcrap, but not OK for systems that have strong internal consistency or time constraints.
The only right way to do 'great engineering' is by not having any middle management.<p>The only right way to do great engineering, is by first asking <i>what</i> we ought to be engineering, not re-implementing the same shit over and over again, like we do web frameworks in every new language.<p>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.
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.
Scrum, Kanban, scrumban, tickets with predefined checkins... all can work.<p>"Formal scrum" only exists to sell books, certs, classes; but more importantly to give justification or a "fix" to failed project managers and leaders.<p>A process will not fix a team that has bad teamwork, is not productive, and/or has bad communication/leadership/management.
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.<p>To me it feels scrum is the person switching jobs constantly and saying people don't get it.
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.<p>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.
> Build a team to do scrum, don’t expect scrum to build your team.<p>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.
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.<p>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.<p>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.<p>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.<p>[0] <a href="https://agilemanifesto.org/" rel="nofollow">https://agilemanifesto.org/</a>
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.<p>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.<p>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.<p>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.<p>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.<p>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.
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.
I work in systems engineering, automation, devops and that kind of stuff.<p>I've seen colleagues in development at other companies do this daily standups and all this scrum thing.<p>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.
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.
99% of teams are doing Scrum wrong most likely.<p>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”.<p>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.<p>Does that sound like it’s liberating for engineers or something that ruins them?<p>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.
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.<p>0: <a href="https://kitemaker.co" rel="nofollow">https://kitemaker.co</a>
Once there was great scrum master, no managers, felt like a team, no missed sprints.<p>Once there were no managers, team crumbled in internal politics but was bearable.<p>Once there was micromanagement, all fails to developers, all prizes for management, each sprint failed, that was hell.
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.
The main problem I've seen with scrum is that everything can get put into the backlog, and the backlog becomes infinite.<p>Then, development becomes ticket driven instead of engineered.<p>I have seen scrum used successfully where an engineering process was placed in front of the backlog ala Feature Driven Development.<p>There is a ticketing system, but it is kept separate from the work planning system.
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.
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.
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.
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.<p>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.<p>"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.