After two rants, and a lot of research, I feel somewhat informed. And I have come to a --preliminary-- conclusion for me:
I am not compatible with pure Scrum.
That's more or less it.
In a more refined way:
Their findings should be eye-opening:
Interestingly enough, it is the experienced developers that seem to hate agile. The question has been raised: Does Scrum make sure lazy developers do any work but at the same time hinder experienced developers to follow their well-developed intuition? Or rather bluntly: Does Scrum force the 3s to be 5s and limit the 9s to be 6s?
Should that stop you from doing Scrum? No. Should you allow anyone to shoehorn Scrum onto you? Absolutely not. Because Scrum (and probably agile in general) only works with a tightly knit, highly committed team involving only fully stable, confident but also highly cooperative members whose concept of professional growth is team- and product-holistic.
All team members must also be strongly able to commit themselves to the task list of a sprint and nothing else. If you have such a team, you are very lucky. If you don't, Scrum will fail and it will potentially leave you with (at least some) team members that will never work in software development ever again.
As a note: Whatever criticism I write here, the answer will be: What you describe is not agile. What you describe is not Scrum. What you describe is a bad implementation, pseudo-agile. When you read exactly this same answer for the 15th time, you start to think about what those particular types are not getting (because obviously Scrum has and causes problems).
Some agilists compare doing Scrum to driving a formula 1 car: It's fast, but hard to master. In my opinion, it is also downright reckless. The car you are driving does not protect the team even if it claims to do so. Scrum is a control and management method that in many, many implementations removes trust from the (individual members of a) team while giving them the illusion of control.
My opinion: Scrum is only good if you severely need to limit the team's creativeness, because they would get nothing done, otherwise. Scrum is seemingly designed to weed out so called "cowboy" or "submarine" coders in favour of a very rigid, strict protocol of total transparency and hyper-frequent communication. Also, the individual team member is seen as valuable only in the context of the team, almost no literature on Scrum ever mentions the individual developer. Given this, Scrum is aggressive collaboration to a fault.
My suggestion: Change the car to something that does protect your team and its creativity. Because your team is valuable.
Scrum seems to treat software development as a commodity. It requires developers to deliver creative skillsets on call, that is whenever needed during the process.
In a more refined way:
- Proponent: Scrum is hard.
- Opponent: Scrum is fragile.
- Proponent:Scrum is fast and efficient
- Opponent: It can be. It also downplays risks for individual developers, devalues their work, limits professional growth, and tends to fail spectacularly with a big bang.
- Proponent: If Scrum does not work for you, you are doing it wrong.
- Opponent: Scrum exposes problems but provides no fixes. It also comes with its own big set of built-in problems that proponents frequently refuse to even perceive.
- Proponent: The Scrum team spirit is the only way of working.
- Opponent: If it works. It's also dangerous and mentally over-taxing for many individuals. It is liable to amplify mental health issues without having a clear path to deal with such problems. The all-or-nothing approach advocated by so many proponents only shows that they have complete disregard for individual employee's needs and skills.
- Proponent: Scrum encourages cooperation and cross-functionality.
- Opponent: That's actually its main fault.
It tries to introduce a clock-like piece-work mechanism into software development and even makes the developers the architects of their own demise.
It wants developer's knowledge to broaden and not to deepen. It opens up a path down the very slippery slope that turns the individual developer into a replaceable cog.
Their findings should be eye-opening:
- Agile is accepted mostly by younger developers who like the cooperative teamwork.
- Experienced developers often feel devalued by implementation of agile methods. Their attachment to "their work" is forcibly reduced. Individual achievement is completely replaced by team achievement.
- Recognition and appreciation for individual knowledge is reduced. Experienced developers feel particularly unacknowledged.
- Time buffers are lost. The team is constantly working under pressure. The ability to juggle timelines (smearing) is lost.
- Transparency without trust. Aggressive transparency and publicity becomes a burden for team members. In-team conflicts increase. Team becomes detached from the process and follows it purely ritually ("Potemkin-Scrum").
- Teams run ever faster without the ability to slow down. Project management "forgets" to introduce explicit slowdown periods.
- Individuals (and the team) are disempowered: No room for self-organized learning. The process feels like working a production line.
Interestingly enough, it is the experienced developers that seem to hate agile. The question has been raised: Does Scrum make sure lazy developers do any work but at the same time hinder experienced developers to follow their well-developed intuition? Or rather bluntly: Does Scrum force the 3s to be 5s and limit the 9s to be 6s?
Should that stop you from doing Scrum? No. Should you allow anyone to shoehorn Scrum onto you? Absolutely not. Because Scrum (and probably agile in general) only works with a tightly knit, highly committed team involving only fully stable, confident but also highly cooperative members whose concept of professional growth is team- and product-holistic.
All team members must also be strongly able to commit themselves to the task list of a sprint and nothing else. If you have such a team, you are very lucky. If you don't, Scrum will fail and it will potentially leave you with (at least some) team members that will never work in software development ever again.
As a note: Whatever criticism I write here, the answer will be: What you describe is not agile. What you describe is not Scrum. What you describe is a bad implementation, pseudo-agile. When you read exactly this same answer for the 15th time, you start to think about what those particular types are not getting (because obviously Scrum has and causes problems).
Some agilists compare doing Scrum to driving a formula 1 car: It's fast, but hard to master. In my opinion, it is also downright reckless. The car you are driving does not protect the team even if it claims to do so. Scrum is a control and management method that in many, many implementations removes trust from the (individual members of a) team while giving them the illusion of control.
My opinion: Scrum is only good if you severely need to limit the team's creativeness, because they would get nothing done, otherwise. Scrum is seemingly designed to weed out so called "cowboy" or "submarine" coders in favour of a very rigid, strict protocol of total transparency and hyper-frequent communication. Also, the individual team member is seen as valuable only in the context of the team, almost no literature on Scrum ever mentions the individual developer. Given this, Scrum is aggressive collaboration to a fault.
My suggestion: Change the car to something that does protect your team and its creativity. Because your team is valuable.
Scrum seems to treat software development as a commodity. It requires developers to deliver creative skillsets on call, that is whenever needed during the process.
What I think Scrumnuts repeatedly get wrong:
- The One True Method Everything agile, everything according to Scrum rules. To deviate is to fail.
This is repeated in posts and comments all over. I won't even comment on it. - When it does not work, blame is shifted to the people.
Either did they not follow the god-given process or they were unwilling to embrace and carry the necessary change. It is never the process itself that is broken, it's always something with the people involved. And it is never the process that needs fixing, it's always the people that need to change. It's never Scrum that fails, it is always you (whatever part in the team you have) that failed Scrum. Does that sound wrong to you?
More moderate agile enthusiast know that this is not true, but even those have their corners of dogma.
However, the more often I read stuff like the above, the stronger this sounds like esothericism. If your team commits to it, so be it. If, however, even only one of the good people doesn't, you probably should reconsider your strategy.
In his --now infamous-- post Giles Bowkett also points out another interesting point:
To be fair to Scrum, it's not intended to work that way, and there's an entire subgenre of "Agile coaching" consultants whose job is to repair broken Scrum implementations at various companies. This is pure opinion, but my guess is that's a very lucrative market, because as far as I can tell, Scrum implementations often break.
The last sentence probable makes the point: Scrum is hazardous and reckless. It's like a World War II German Tiger tank: You move a large machine (the product) forward with a huge motor (team velocity). As long as the transmission box (the development team) holds, everything's fine. If/When only one of the the transmission gears (an individual developer) cracks, the whole thing falls apart and the ammunition stockpile often blows up (developer burnout). The solution is to replace (dead) crew members (fire developer, hire new developer).
The whole method is actually designed to make the latter possible with as little cost as possible. If following that argument, the only rational reaction to Scrum from a software developer is to tell it to die in a fire (which some have done). - When problems surface, Scrum is claimed to be only the messenger.
Charlie does not like to talk about what he did every day. He's a very good coder, mind you. He makes clean designs, delivers testable and tested code. But he likes to work alone and we cannot have that. In Scrum, Charlie's a problem. So am I because I like to code first and cleanup later, but I feel too much social pressure to deliver because of the daily standup. Linda is also in trouble. She likes to work from 11 to 19 because that's her time. The daily at 9 is a real problem for her. Martin is quite the engineer. We usually give him the tough nuts to crack, because he comes up with really good solutions. We try to avoid having him do UI work, because he hates UI work (he's not that bad at it, however. He just hates it with passion.). Well, but the product manager does not allow for a story "Martin fixes every potential problem he sees in existing code, while we do the final UI stuff" (because it does not start with "the user wants ...").
These problems surface with Scrum, but instead of providing solutions, Scrumnuts often wash their hands of it and blame people. It's just the same fad, now with "people are important" stickers tagged on. The sticker doesn't make things true. And hey, some of these problems are because of Scrum. But that's heretics in the minds of Scrumnuts. Agile is perfect.
However, if you read the blogs of some Scrum evangelists, you read stuff like this:
"Oh, I had a sceptic once. I told him to talk to upper management, if he wants to."
"I had a resistor, who thought himself too good for the daily standup. We gave him a good opportunity outside of our company."
Threats and coercing people into compliance? These people should be banned from having responsibility for employees ever again in their lives. Does Scrum protect the employees? Maybe even less than some of the older stuff ... - The Team is EverythingScrum emphasizes the team
probablyto a fault. This goes beyond ignoring personal needs (see below for that), but the organization enforces a team-holistic sense of progress and achievement.
Scrum proponents repeatedly claim that a goal for them is for everyone to be able to keep their individuality, but that only the team effort counts. While this might work for some projects, it will utterly fail for others. And it requires a certain type of people.
To give some of the aggression back that some Scrumnuts lash out with: Scrum requires you to maintain an (excessive) level of groupthink. It requires you to severely limit personal wants and needs in favor of an abstract product that you still need to identify with. Sounds like applied schizophrenia. In this light, Scrum is also outright dangerous and reckless, as it requires developers to not utilize important resources that provide resilience against work related stress.
Scrum actively discourages silos. And the silo begins when you have an expert on a team where only the one single expert can to a certain type of work. Scrum drives another nail in the coffin for the sense of personal achievement. The "agile overachiever" is seen as an anti-pattern. In Scrum, if you are smart, you need to play dumb, because otherwise your team will hate you. Scrum deliberately keeps individuals below their professional potential under the assumption that the concerted team effort is the only relevant measurement of productivity. It actually looks like that the short-term view of the sprint planning is also applied to developer's careers: They are supposed to go on forever in the same cycle without long term goals. Individual achievement in Scrum is abstract and the concept is actively discouraged.
As for planning: Scrum seems to do the worst of the worst: Frequent planning by planning by committee. Planning by committee is inherently problematic, it gave us ASN.1 (first version), C++ and the WS-* standards. Planning actually works best when everyone has their own ideas and they are mashed together later. The frequent re-planning based on the product backlog means that the product owner seems to be the only one maintaining the long term view. This has all the rails laid out to be both an insult to senior developers as well putting architecture back on a single person's shoulders and that person is then probably non-technical Technical debt in Scrum projects is rampant.
Scrum cannot deal with even the slightest personal deficiencies without pathologizing and putting down blame. And the agile proponents are very happy to put blame onto people that cannot adopt to the process. Here is an interesting little study by Frankfurt's Goethe Universities' Information Science Institute: Have a vulnerable or anxious developer, and things go down the drain. It's in line with proponents "Scrum exposes problems", but it is also in line with "Scrum does nothing to fix or work around this" (formulated "not Scrum's job" by proponents).
Maybe that is also why agile is so much a young developer's game: Young developers are malleable. If they never experienced another mode of working, they probably can be made to like Scrum (even if it actually might f*ck them over in the long run). Older developers with their own ideas and maybe well-honed processes cannot be molded into a Scrum team. And because of the high transparency required, they might actually feel akward and downgraded. See in above's study under "vulnerable".What Scrumnuts seem to commonly forget: It's also Scrum's process that emphasizes certain problem areas and makes their absence a (hard) requirement. One could argue that Scrum is only for certain types of people. Even worse: Scrum proponents actually suggest you "fix people" (or rather they need to fix themselves), when they do not fit the process. To put in bluntly: Scrum can only deal with certain types of cogs and because of its high spin, it heavily reduces the amount of variance in the cogs it can accept.
The Scrum Master is supposed to be the buffering factor to make sure the machine does not spin out of control because of some grain of sand. Does that work? Obviouslynot alwaysquite often not. - Waldorf dance
Daily standups. Two week sprints. Deliver working software as early as possible. I think all but the last feel like forced rituals.Bob and I are working on the CRUD interface for objects A, B and C. We read Dave's database specification and Bob will do the REST interface while I build the UI basically in lockstep with him finishing another of the views. We talk multiple times a day. When Dave needs to do a change to the DB that affects us, he pings us before and after.
We feel stupid at the daily scrum because everybody knows what we are doing and we also know which strings to pull when we are stuck.
Also, we had to split the interface into three parts, because it takes us 6 weeks to get done (there are a lot of views). It's not that bad, we can deliver the partial interface to the customer every two weeks. But it's still idiotic and we would actually be faster when we did the think in one large batch instead of three smaller ones with a planning meeting in between.
But the juniors like it. They like being part of a qualified team. And they like the mini steps, because they don't need to think to much during a sprint. Just test, code and integrate. Maybe Bob and I are getting old. - Failure to manage communication and a drive to inefficient, stressful crossbar communicationScrum's typical communication channels function essentially like a forced burst on a crossbar switch. You repeatedly, frequently have bursts of communication It's like a daily radio call back home to base every day, but every station phones in at the same time and you have to listen to everybody else, too. This is meant to avoid information silos.
It also has multiple downsides: It ignores the need and ability to structure a project into parts that can be independently worked upon. Scrum just claims, you don't need that structure. "Cross functional" in this interpretation means "anyone on the team can do any task".
The process ignores the fact that this high-frequency broadcast communicationcan beis very taxing and stressful to certain types of developers. Also, people have a natural inclination to become experts in certain areas. Scrum requires the whole team to think about the complete system all the time so that everybody is up to date. Scrum trivially denies any requirement for channeling communication within the team. Scrum assumes that everybody needs all information all the time and enforces this by violent transparency.
This causes a conflict of interest and Scrum's solution to this conflict demonize one side of the it ("silos", "submarines", "cowboys", "rogues"). In its attempt to solve the information silo problem, it causes collaborative overload. Scrum's process reduces the ability of the individual to control the flow of information from and to them. In fact while Scrum might improve team autononomy, developer autonomy is forcibly reduced via peer pressure.
<rant mode>By all means, if you are an attention deficit hipster that cannot think ahead for more than a few days, cannot plan and implement a larger feature by yourself and instead need constant chatter from your co-workers to keep you going: do Scrum. If you actually like to get things done (i.e. you actually have a maker's schedule), if short, frequent interruptions stop you from getting stuff done, avoid Scrum like the plague.</rant mode> Side note: There is nobody that benefits from too-frequent interruptions and too-frequent crossbar communications. If your project requires an attention deficit teenager, you are welcome. If it requires somebody who can actually get things done on their own, avoid Scrum.
- Reducing Freedom
Goodbye Home Office. Goodbye Remote Work. A co-located team is all but a requirement. Flexible work hours? Conflict with the daily standup at 9, so they have become illusionary.
While newspapers still publish articles about the new, free workers that work wherever they want, at least the lower layers of the IT service industry has already backpedaled. Scrum is basically a 9-to-5 job with a rigorous drill. Personal freedom is gone, self-management is gone. It's replaced by team pressure and daily check-ins with the sprint clock.The developer is treated like a tool to get a task done, nothing more.
- Ignoring personal needs.
Even the proponents tell you: Scrum only works when everyone commits to it. One bad apple ruins the thing. Anything less than total commitment seems to break the process. You are recklessly driving at high speed and ignore the risk of driving too fast. And it seems to be so easy to drive too fast.
I tell you what: I'm not my job. I am still learning to switch off after a 8-9 hour day, but I am learning. I'm also not my team. I am me. I want to get better myself and I want to prove myself. Scrum either ignores this personal need or even frank out tells you to stuff it. If you pin a zealot to the problem, they will either answer with answer #1, above (that's not Scrum, that's not agile) or wiggle themselves out of a straight answer.
When you research, most of them are project managers/product owners, so their opinion seems a little biased.
I don't want to work at the bloody UI stuff that Linda is so much better at. But here I am, midget stepping my way through a an interface storyline like some mentally retarded junior and reporting to the team every one or two steps (stories should be measured in hours or at most days). It's degrading. Don't do this to your senior developers. Give them their freedom back, they earned it.
What do you do with the excellent engineers that have a hard time with total transparency? The standard answer is that these people need to change, because Scrum/agile cannot handle them at all. But the desire and need for autonomy aren't going away anytime soon.
Self-determination theory even claims that the need for autonomy is fundamental. Scrum focuses so much on the team that the individual easily gets lost in the framework up to the point where there is actual aggression against individuals from peers.
How do we find room for individuals in agile? As far as I see it, Scrum is basically the open plan office of project management. Read up on "Open Plan Syndrom" (1, 2, 3, 4) if you like.
A quote I found is Scrum/agile builds "great teams of people, not teams of great people", but that is also a problem. How do you integrate individual needs into a team? Of course, you can always wiggle out of it and say that the individualists are simply non-teamworkers and thus not suited to the job. But where is the room for individual growth? Where is the senior engineer? The claim seems to be, that these people cannot exist any more. Scrum thrives on the team holistic buy-in into the product they are building. Or on "I only have to think once every two weeks during the planning meeting" persons, that can simply switch off their overarching goals for the duration of the sprint. Choose your poison, I personally can drink none of those.
There has been a shift in the agile community to consider personality types when hiring agile team members. Most of it is amateur psychology slaved to the corporate interest. For developers, you need highly skilled people that thrive on team achievements, willingly limit their personal goals and like to communicate while still getting their own stuff done in time. Again: If you have a team consisting of such people, consider yourself very lucky. Again: Scrum puts up the soft skill bar for everyone involved very high. Scrum proponents seem to consider this a challenge that must be mastered (I must learn to be a better communicator), but you cannot (and should not try to) change personality types. In short: you need certain types of people for a Scrum team. Evidence seems to suggest these peopleare quite raredon't exist ... and that you actuallly may not want them to deliver a quality product.
But I'm circling around. Scrum seems to have no room for experienced, qualified persons with the ability and need need to work autonomously. Where do those go now? Scrum is exacerbating the shortage of developers by making qualified, intelligent, autonomous developers practically unemployable.
Scrum encourages your knowledge to broaden (do different parts of a project), but not to deepen (become an expert in a certain field). Scrum makes you into a cog for high-speed industrialized development without yielding you, individually sufficient benefits in return. - Anger and Aggression
These are really two words that need to be associated with Scrum advocates. Scrumnuts are angry and they aggressively make their point. It makes me think they are stuck in groupthink mode and we already know where the problem is, there.
Scrumnuts are angry: Angry towards silos and (wannabe) rockstar coders, that the team members (may) have worked with, angry towards (seemingly) non-communicative team members, angry towards bad management with bad planning, angry towards (perceived) non-transparency.
Whereever it comes from, Scrumnuts often have an aggressive need for total transparency and control (knowledge is power). Even --it seems-- anger towards people with fluctuating productivity and anger towards introvert "non-teamers". It shows itself in aggression against anyone not understanding the "path to deliverance".
And because pressure from above sucks, this pressure is replaced with peer pressure. Some think peer pressure is good. But peer pressure is probably the most stressful type of pressue one can apply and Scrum has no proper checks to prevent it becoming straight peer oppression. Scrum actively pulls the stops and then blames the victims.
There is even Aggressive Scrum now. By Jeff Sutherland, the same guy who's critique on Miles Bowkett's "Why Scrum Should Basically Just Die In A Fire" reads like he's talking to a retarded five year old from a bad neighbourhood. Ladies and gentlemen, these are the people trying to drive your development strategy. And guess what: They are aggressive, condescending, and arrogant as fuck. Exactly what the manifesto does not want them to be.
This anger and aggression seems to culminate in a demand for control and violent transparency. I think (badly implemented?) Scrum/agile is part of the increasing burnout problem for software developers. It violates sensitive team members and provides no solutions to solve the problem.
"Grow a thicker skin". Warning, Dichotomy up front and behind. Scrum as currently applied is an outcrop of modern management methods that try to push down responsibility as much as possible. In exchange it reduces personal freedom, replacing it a with an intangible illusion of the same. Practiced Scrum is a very bad deal for the individual developer.
Brad Johnson compares Scrum to cold war communism, complete with watchful neighbours ready to rat you out to the regime. But in Scrum, you need to rat out yourself on a daily basis. - Ignoring Chronemics
All project management methods work best when dealing with monochronic personalities. Those have a natural inclination to slice time and work into tiny chunks and allocate time slots. They also like to do one thing at a time and then procede to the next item on their list. Scrum is made for these people.
Polychrones? Not so much. They like to juggle multiple tasks at a time, moving from one to the other (they are NOT necessarily multitasking, mind you). They see time as something that flows forward. Polychrones hate timeboxes and time slots, working in timeboxes makes them very, very uncomfortable. They might understand about deadlines, but for them, time and work are a continuum. Polychronicity can be measured. One scale is the (older) "Polychronic Attitude Index" (PAI), the other is the "Inventory of Polychronic Values" (IPV).
Paul Graham calls the difference the "maker's schedule" and the "manager's schedule". Both are tendencies, so the pure monochrone and a pure polychrone does not exist, which is also outlined in Paul Graham's notion that there seem to be different modes of operation for the same person for different types of work.
Polychrones' needs are strongly violated by the small-scale timeboxed task assignments. While they may be able to adopt to deadlines and they --indeed-- are actually those that are more adaptive to changes and more communicative, polychrones struggle with time management in the workplace in general (western work culture is heavily monochronic) and with "Do one thing at a time in small parcels" in particular. And because polychrones are often relational people, peer pressure ("the team is everything") makes them suffer all the harder, seriously increasing their risk for burnout.
Scrum's distributed task list is perfect for monochrones and has absolutely no room for polychronic "creator" types. In this, Scrum is basically the team version of David Allen's "Getting Things Done", which was never verified to work and also totally ignored individual personalities. And as with GTD, Scrum causes pain and suffering for some personality types. In the long run, it relegates them to small scale (freelancer) projects or
Scrum takes away the buffers required for some personality types to work effectively. It even declares the people that needs those buffers dysfunctional or unwilling.
Remember that all of these problem statements can be answered by "you are not doing it right".
The sprint should leave you room to experiment, to make mistakes to work at your own pace. You should feel pressure to finish the sprint, but not too much. And in theory you are able to set your own pace (but in practice the team probably dictates your pace).
For some, work is best done as a marathon. For some it's rather interval training. Adoption is only possible to a certain degree and Scrum uses peer pressure to adopt a monochronic working style.
While peer pressure is effective in increasing productivity, for many it is also the most stressful type of pressure that can be applied. Thinking in terms of principle #1 (deliver working software), it seems people forget principle #0: Protect your team! Protect every individual member! Interestingly enough, the manifesto fails to state exactly that ...the highest priority is explicitly stated to get stuff out the door.
The daily scrum should not be judgemental. But have one judgemental team member and one sensitive to criticism the whole thing breaks down no matter how excellent the sensitive member is. Who's to blame? The aggressive transparency advocator. Who are you going to fire? The sensitive team member, because he/she is not performing well. Scrum is applied team dictatorship. Hello again decimation.
Scrum --when it works-- is speeding up the development process to go faster. It also very heavily reduces the margin for error. You need a certain mentality in everyone involved. You need highly monochronic people. You need confident people. You need non-aggressive people. You need highly agreeable team members able to chunk along with small scale tasks. Fail one, Scrum fails miserably.
Product owners and scrum masters should not be aggressive. They should use their interpersonal skills to make their point but otherwise leave the team alone. In a matter of sense they are team members with special tasks.
In theory and for some teams that all works well. It practice, when it fails, it seems to fail horribly, leaving qualified individuals burned out and psychologically scarred. As noted: You are driving a formula 1 car and when such one wrecks, it wrecks hard.
Hammered into every agile enthusiasts mind with a chisel should be the first premise: Protect your team and protect its members!
Recommended Reading:
The sprint should leave you room to experiment, to make mistakes to work at your own pace. You should feel pressure to finish the sprint, but not too much. And in theory you are able to set your own pace (but in practice the team probably dictates your pace).
For some, work is best done as a marathon. For some it's rather interval training. Adoption is only possible to a certain degree and Scrum uses peer pressure to adopt a monochronic working style.
While peer pressure is effective in increasing productivity, for many it is also the most stressful type of pressure that can be applied. Thinking in terms of principle #1 (deliver working software), it seems people forget principle #0: Protect your team! Protect every individual member! Interestingly enough, the manifesto fails to state exactly that ...the highest priority is explicitly stated to get stuff out the door.
The daily scrum should not be judgemental. But have one judgemental team member and one sensitive to criticism the whole thing breaks down no matter how excellent the sensitive member is. Who's to blame? The aggressive transparency advocator. Who are you going to fire? The sensitive team member, because he/she is not performing well. Scrum is applied team dictatorship. Hello again decimation.
Scrum --when it works-- is speeding up the development process to go faster. It also very heavily reduces the margin for error. You need a certain mentality in everyone involved. You need highly monochronic people. You need confident people. You need non-aggressive people. You need highly agreeable team members able to chunk along with small scale tasks. Fail one, Scrum fails miserably.
Product owners and scrum masters should not be aggressive. They should use their interpersonal skills to make their point but otherwise leave the team alone. In a matter of sense they are team members with special tasks.
In theory and for some teams that all works well. It practice, when it fails, it seems to fail horribly, leaving qualified individuals burned out and psychologically scarred. As noted: You are driving a formula 1 car and when such one wrecks, it wrecks hard.
- Scrum aggressively exposes "problems" that hinder its own implementation.
- Scrum does nothing to handle these problems. In fact it cannot handle many of these problems without forcing people into modes of operation they are not comfortable and compatible with. Scrum is also likely to trigger insecure personalities into a downward spiral (think OCPD insecure overachievers).
- Scrum proponents assume that (semi-)public exposure even of personal problems is a good thing always.
- More general, everything that hinders the implementation of Scrum is a labelled an impediment in an often very aggressive and downright hostile language ("resistor", "defunct", ...). Critics of Scrum are told to shut up, because they hurt the (consulting) collective and take away revenue.
- Scrum is aggressive communication and transparency within a team leaving (too) little personal space for individual team members. Scrum
can beis emotionally and mentally taxing without offering sufficient rewards to the individual.
Scrum works only with a certain type of developer. It views all other types of developers as dysfunctional, disgusting, and mentally dysfunct.
Scrum pulls the stops and safeties and gives little in return, exposing team members to serious (mental) health risks.
Scrum is highly fragile.
Recommended Reading:
- Good Agile, Bad Agile by Steve Yegge
- Manifesto for Half-Arsed Agile Software Development by Kerry Buckley
- Why Scrum is Designed for Misuse by Michael Sutton
- Scrum is like 20th-century politics (part 2, 3) by Brad Johnson
- Keeping the Flock together - Home-Office and Remote-Work is out again by Nikolas Reuter (in German)
- Should you distrust Agile? by Greger Wikstrad
- Heisenberg Developers by Mike Hadlow
- Why Scrum Should Basically Just Die In A Fire by Giles Bowkett
- Collaborative Overload by Rob Cross
- Agile for the Introvert by Rob Friesel
- The Failure of Agile by Andy Hunt
- Thoughs on Scrum by landon
- Agile is the New Waterfall (and its followup) by Amir Yasin
- Rhetorical Questions From a Developer by
- Scrum - A Substitute for Having an Architecture? by Tim Boudreau
- When Scrum Hurts: Mob Architecture by John Sonmez
- Agile is a Quality Anti-Pattern by David Gelperin
- Three Failings of Scrum and the Old School Solution by Laurence Gellert
- Scrum: Agile madness by Jilles van Gurp
- Why Software Development Methodologies Suck by Jez Humble
- Agile Ruined My Life by Daniel Markham
- Manifesto for FRAgile Software Development by m4i3
