In a functional scrum team everyone on the team should be empowered to advocate this. In turn the product owner should be receptive to technical improvement because it is in the interest ultimately of the overall project success.
“No true Scrum team would do X.”
“No functional team would disempower people...”
At some point though, Agile & Scrum cannot be propped up like that.
When the same failures happen again and again all across the industry, it’s time to admit that the tool facilitates that failure.
The tool (Agile & Scrum) is the correlate here. Somehow it’s always showing up co-located with these problems, but we’re never honest enough to step back and admit maybe, sometimes, with enough evidence, correlation can be related to causation in this case.
If the ecosystem in which scrum (or any process) is embedded is hostile then it will fail. But so will everything else, in time.
First it’s “no true Scrum implementation would have property X.”
Now it’s “any observable badness of Scrum was just ambient badness of an already bad company bleeding into Scrum.”
That's not the point. Scrum does not say anything how good your organization is. Scrum won't fix these problems.
Thus you can have a great Scrum setup and still fail.
Of course you can have bad management and a 'true scrum implementation'.
Your mistake is to assume that Scrum fixes all kinds of management practices or that 'true scrum' also means all kinds of other things, which it does not.
It's also unlikely that specifically bad management practices are especially caused by Scrum - it might have some negative effects in some organizations - it might have positive effects in some other organizations.
Scrum is simply not sufficient to be successful - if we want to be successful Scrum might be a good tool in a certain domain, but we also need to address the other issues/topics/practices/processes. Most of that stuff is very independent from using Scrum or not.
I'm saying adding Scrum to already-bad management practices is like throwing gas on the fire. Scrum doesn't help.
Also, if Scrum is only some kind of special snowflake process that only works when applied in sociologically perfect companies, well then it's useless.
I'd rather use custom, ad hoc, duct-taped together management practices that get the job done even in the midst of bad corporate sociology.
What? Scrum fixes all bad management practices?
> I'm saying adding Scrum to already-bad management practices is like throwing gas on the fire.
There we need evidence that it is actually so. Haven't seen any convincing data for that.
> Scrum doesn't help.
The sentence before claimed something else: Scrum makes it worse, quickly.
> Also, if Scrum is only some kind of special snowflake process that only works when applied in sociologically perfect companies, well then it's useless.
True, but that's not the case. Scrum can be used with advantage in average to good companies - but the reality is that good software product development is not that easy and has many ways to fail - for example the software could have a huge security problem, it could have architectural problems, it might not earn enough money, etc. - nothing which the scrum process will fix. There are many areas on the management and other levels, which scrum does not address: payment, office, product, market, hiring, ethics, ...
Scrum is really on a tiny framework addressing a few basic things in small team organization.
> I'd rather use custom, ad hoc, duct-taped together management practices that get the job done even in the midst of bad corporate sociology.
Personally I'd rather work in a company willing to learn how to successfully develop software in some reproduceable way.
What are you saying here? I was questioning your original statement that I mistakenly thought Scrum should fix bad management practices. I do not think that, and no part of that is a criticism of Scrum. The criticisms are other things. Your follow-up just seems confused about your own parent comment.
> "There we need evidence that it is actually so. Haven't seen any convincing data for that."
I've seen a lot of that evidence, in threads like this, in the original post, and also empirical evidence in my own work experience with Scrum as both a developer and a manager across several organizations of various ages and sizes. I'm not asking anyone to take my word for it though. I'm happy to look into randomized controlled studies about effectiveness of engineering teams with or without Scrum. Much like with open-plan offices, I'm confident the evidence shows zero efficacy (despite huge planning overhead costs and time wasters) for using Scrum even after controlling for whatever confounders you think are the scapegoats for Scrum's badness.
It's a good thing we don't have to worry about what you've seen as our standard of evidence for discussing this topic, and we're free to make useful written arguments and discussions, like the linked post in the OP, that also appeal to important qualitative aspects of the problem, like how developers are disempowered, or how management always misuses Scrum-related progress tracking data.
> "The sentence before claimed something else: Scrum makes it worse, quickly."
This is pedantic to the point of making me suspect you're just trolling to argue with anyone who doesn't like Scrum. Yes, indeed, two different sentences claimed two separate but compatible and related things. Shocking!
> "True, but that's not the case. Scrum can be used with advantage in average to good companies"
You're demanding evidence but then just making equally unsubstantiated claims in the opposite direction. What's to say that instances of well-delivered software you've seen weren't done in spite of Scrum rather than because of it. That would need evidence too. And particularly because Scrum requires a far-reaching and globally prescriptive implementation (e.g. do team planning exactly this way and exactly on this timeline, estimate your workload exactly like this, use exactly these meetings, etc.) it strongly suggests the burden of proof is on Scrum proponents to explain why this is better than customized, individually and organically developed workflows that teams use because they are demonstrably working for them.
> "Scrum is really on a tiny framework addressing a few basic things in small team organization."
This is abject nonsense. Even a framework that did nothing but prescribe that teams must do some form of estimation every X weeks would be hugely overbearing bloatware. Scrum goes so much further, prescribing a huge overhead of different meetings, a bunch of specific named positions that have to have specific responsibilities in teams, and overbearing principles that superficially look small in writing but really are huge bureaucratic nightmares, like mandating that all teams should be cross-functional, which is totally disconnected from business realities in many cases, especially for teams whose sole business value is highly specialized domain area.
> "Personally I'd rather work in a company willing to learn how to successfully develop software in some reproduceable way."
This presumes that there always exists some "reproducible way", and that it is one-size-fits-all for the a whole company. You're just denying the premise that customized, situation-specific or team-specific workflows could be the right way.
It's fine if you want to deny that claim as a personal preference or opinion, but you're just taking that as your own assumption, and then tacitly basing various claims about the superiority of Scrum on this built-in, hidden assumption.
'evidence' found in Hackernews posts?
> I'm confident the evidence shows zero efficacy
this will surely help with selecting evidence, given that you know already the findings.
> This is pedantic to the point of making me suspect you're just trolling to argue with anyone who doesn't like Scrum. Yes, indeed, two different sentences claimed two separate but compatible and related things. Shocking!
How about deciding what you want to say: a) scrum makes it worse or b) scrum does not help?
> This is abject nonsense.
Really? Before we have worked with RUP and Agile RUP. Compared to that Scrum is tiny.
> like mandating that all teams should be cross-functional, which is totally disconnected from business realities in many cases, especially for teams whose sole business value is highly specialized domain area.
The team should be cross-functional based on the product the team develops.
> This presumes that there always exists some "reproducible way"
This actually presumes that I identify successful practices which can be applied in many projects. We did.
> You're just denying the premise that customized, situation-specific or team-specific workflows could be the right way.
No, I'm not denying it, but when my team had success with Continuous Integration, I probably would use that in the next project - when applicable. It would also be a surprise if in a new project I would need to start from scratch to completely redesign workflows and team communication, without any prior knowledge/practices applicable.
I've worked for a few decades in software projects and in software consulting - often I was responsible for project and team setups. Often developing new stuff. I can easily imagine that other domains work differently.
Both!
> "Really? Before we have worked with RUP and Agile RUP. Compared to that Scrum is tiny."
Nuclear submarines are tiny because aircraft carriers are large. And this means submarines are a good investment.
> "The team should be cross-functional based on the product the team develops."
This is ignoring reality in many cases. A team might develop something domain-specific, like a natural language processing algorithm, but then later the product requires a web service and a front-end. As a result, management requires specialist machine learning researchers to spend their time writing front-end widgets, because "Scrum says to be cross-functional" (and don't even think of saying the no-true-Scotsman reply, "but that means they're doing Scrum wrong!" Scrum leads them to that type of thinking).
In many cases, the different functionalities for a single product should absolutely not be embedded in the same team. Rather, much like in software design, it's important to separate concerns, and have teams with modular and clearly defined boundaries between their different and complementary skills. Then for a single product, parts of it will be worked on by different teams that each have specialized skill in one area, and can operate independently of each other because it's not muddied by an artificial requirement for "cross-functional" skills.
Some other times, Scrum-like cross-functionality is good. That's why Scrum is wrong to unilaterally prescribe it for every product and every situation. Sometimes it's good, sometimes it's bad, and teams need to be empowered to customize according to whatever the case at hand needs, not the unilateral model that Scrum tries to impose.
> "This actually presumes that I identify successful practices which can be applied in many projects. We did."
But then what do you say to people who have identified successful practices over decades that conflict with Scrum and are mutually exclusive with Scrum's approach. Scrum worked for you. Great. It didn't work for me.
What's your reaction to that fact? If your reaction is to say, "well then you did Scrum wrong, because it always works" then you are just denying the premise that any other solution could be possible, and it absolutely is a No True Scotsman fallacy.
Can you at least admit that some people have earnestly tried Scrum in a situation when Scrum is advertised to work, like iterative software development, and they did not "do it wrong" yet still found that it didn't work for their team?
Strange,
>Nuclear submarines are tiny because aircraft carriers are large. And this means submarines are a good investment.
Not sure what this has to do with Scrum or the low complexity of Scrum, which fully can be explained in a small book or a week of training.
> This is ignoring reality in many cases. A team might develop something domain-specific, like a natural language processing algorithm, but then later the product requires a web service and a front-end. As a result, management requires specialist machine learning researchers to spend their time writing front-end widgets, because "Scrum says to be cross-functional"
Management actually meant: we don't want to spend more money. They fooled you.
Basic knowledge: a NLP developer is not a front end developer. Yes, you can add and remove people from teams during the runtime of a project.
If your management is too dumb or you are too easily fooled by management, don't blame Scrum.
> In many cases, the different functionalities for a single product should absolutely not be embedded in the same team.
True. But that has nothing to do with Scrum.
> Rather, much like in software design, it's important to separate concerns, and have teams with modular and clearly defined boundaries between their different and complementary skills. Then for a single product, parts of it will be worked on by different teams that each have specialized skill in one area, and can operate independently
Sure, this is how silos in big companies try to work. For small teams this is overkill.
> of each other because it's not muddied by an artificial requirement for "cross-functional" skills.
This is not an artificial requirement. Small teams with cross-functional skills make communication more effective. If you have large problems, then you need to scale that. But that is all basic knowledge.
> Some other times, Scrum-like cross-functionality is good. That's why Scrum is wrong to unilaterally prescribe it for every product and every situation.
Again, basic knowledge.
> Sometimes it's good, sometimes it's bad, and teams need to be empowered to customize according to whatever the case at hand needs, not the unilateral model that Scrum tries to impose.
Scrum does not impose an unilateral model for all projects. You can develop in all kinds of ways and Scrum might not be applicable to your domain/setup. You can even take elements of Scrum - just don't call it Scrum - a daily standup meeting can be useful in many projects.
> But then what do you say to people who have identified successful practices over decades that conflict with Scrum and are mutually exclusive with Scrum's approach. Scrum worked for you. Great. It didn't work for me.
Then don't use it. Simple as that.
> Can you at least admit that some people have earnestly tried Scrum in a situation when Scrum is advertised to work, like iterative software development, and they did not "do it wrong" yet still found that it didn't work for their team?
I already said that you can do perfect Scrum and still fail. You can also succeed without Scrum. It's just more likely to succeed with Scrum in situations like small team (10 people), product development, changing requirements, responsive customer, etc. etc.
Also if your team does not like banana, don't feed them banana.
Earlier you made a disingenuous comparison of the relative bloat of RUP and Agile RUP in comparison to Scrum. The relative overhead costs of Scrum compared to those other methods don't matter. Only the overhead of Scrum compared to low-overhead and low-formalism methods that deliver the same business outcomes.
> "Basic knowledge: a NLP developer is not a front end developer. Yes, you can add and remove people from teams during the runtime of a project."
Scrum, despite not explicitly saying it in any formal documents, facilitates managers in avoiding adding or removing of the right specialized people, by creating an expectation that every engineer ought to be trained as a full-stack engineer, and using language that makes it sound like every team ought to cover every possible domain.
> "If your management is too dumb or you are too easily fooled by management, don't blame Scrum."
How is this relevant? No one mentioned dumb management nor workers who are fooled by management. We are talking about how Scrum encourages and facilitates this kind of behavior, even among earnest management and fully-aware teams. It seems like more of the same No True Scotsman fallacy for you to presume it can only be caused by "too dumb" management or teams being "fooled". Yet again, in your description, the bad stuff cannot happen in a "real" Scrum setup, only in a "bad" one where people are either dumb or foolish. Defining away your problem.
> "True. But that has nothing to do with Scrum."
False, Scrum explicitly holds it as a principle that teams should always be cross-functional. Scrum doesn't allow the possibility that e.g. front-end work for a wide variety of products should be separated into a single front-end team, and corresponding backend work separated into different backend-specific teams. It advocates that all teams working on projects with front-end and backend needs should be both front-end and backend teams. This is very much a direct problem with Scrum itself.
> "Scrum does not impose an unilateral model for all projects."
This is one of the defining properties of Scrum. A unilateral choice for sprint length, format and frequency of planning meeting, details of required story point estimation, daily stand ups, required retrospective, etc. Scrum doesn't allow omitting these things when they are not useful. There is a tiny amount of customization allowed (e.g. t-shirt sizes instead of story points, or 3-week sprints instead of 2-week), but it's meaningless in terms of what a team actually needs to customize (which is stuff like dropping estimation all together, and e.g. only hold occasional retro meetings scheduled in an ad hoc way at the team's convenience, not enforced every X weeks as part of a sprint).
> "It's just more likely to succeed with Scrum in situations like small team (10 people), product development, changing requirements, responsive customer, etc. etc."
My experience is the opposite... that adding Scrum in exactly those situations just means we have to do extra boilerplate work to get the same end product finished on time, and that Scrum is not more likely to succeed than other methods.
This is false. Scrum requires the TEAM to be cross functional for the product it develops. It does not require each TEAM MEMBER to be cross-functional. Even 'full stack' (a concept not from Scrum) does not mean 'expert on everything'. Full stack means able to work with front- and backend frameworks for websites. A 'full stack' developer for example will not be expected to be a NLP or a ML expert. The full-stack-developer might have no idea about automated performance tests and he/she usually will not have deep UX skills.
I usually use 'T-shaped' or π-shaped as a requirement for team members. Horizontal skills enable the person to work in a Scrum team with all the added stuff (like automated testing, software repositories, task system, continuous integration, ...). Vertical skills add depths in one or two fields: backend development with Java, frontend development with JavaScript, agile testing, business analysis, database admin/programming, cloud infrastructure, etc.
Looks like you are setting up strawmans - another fallacy.
It’s naive to approach this in some letter-of-the-law way. Whatever you want to argue that “Scrum says” the reality of what it facilitates & encourages (which is the attenpt to push everyone towards full-stack responsibilities) is different.
> “A 'full stack' developer for example will not be expected to be a NLP or a ML expert.“
This is just not how it plays out in big corporate Agile. They absolutely try to combine specialized skills with front end skills. I work in ML & I can’t tell you how many times I see job ads for “machine learning engineer” requiring experience in React, devops tools, highly specialized database internals, etc., with job descriptions listing all manner of wishlist full stack competencies in addition to PhD-level skill in some machine learning domain. How these places keep thinking the drives and interests required for this can coexist in a single person, I don’t know, but they keep it up. Always in a “fast-paced Agile environment” too.
The principle of a cross-functional team is widely explained and described. Basically everyone will tell you the same story. Even Wikipedia:
https://en.wikipedia.org/wiki/Cross-functional_team
> A cross-functional team is a group of people with different functional expertise working toward a common goal. It may include people from finance, marketing, operations, and human resources departments.
The companies I work for are able to understand that.
> I can’t tell you how many times I see job ads for “machine learning engineer” requiring experience in React, devops tools, highly specialized database internals
Zero?
I've just searched on monster.com for "machine learning engineer". Hits: 300+ Then I searched for "machine learning engineer" and "react". Hits: zero.
Combinations "machine learning engineer" and "scrum": 8 hits.
I fear your 'many times' is not backed up by reality.
You are completely side-stepping the entire point and it's extremely disingenuous. You're acting like because the specific words in a Scrum principle says "cross-functional team" that it must mean everyone who uses scrum practices it in the most charitable, idealized way.
Instead, in real companies, terms like cross-functional team, regardless of any dictionary definition or intention in theoretical Scrum, are completely subverted for convenience of managers and business people. In particular, it's taken to mean that if a team needs more expertise in a skill area, it's fine to require training or expect self-learning in that area from existing staff, regardless of how wildly inappropriate it would be given their skill set. And because Scrum doesn't do anything about this, other than to vaguely encourage "cross-functionality", the problem shows up all the time in companies that use Scrum and is often amplified by it, with middle managers pushing back that e.g. my ML team ought to be trained in Javascript so we are "cross-functional" to write frontend GUI stuff.
When it comes to people with marketing skills, finance skills, etc., then of course they see them as separate domain specializations worthy of new headcount to grow the team's skills. But they lump all of software and information technology into a single huge bucket.
> "The companies I work for are able to understand that."
Your experience has been fleetingly uncommon then, to such a degree that it does not generalize to common or average situations, and therefore we ought to discount your experience as too much of an outlier from most of the industry.
Since you boasted about looking on job search engines for these crazy pan-everything job ads, yet you clearly did not actually look for them, let me do it for you and definitively prove you very, very wrong on it.
I searched for results containing both 'TensorFlow' and 'Scrum' on Indeed, sorted by newest, and just walked down the list of results.
< https://www.indeed.com/jobs?as_and=tensorflow%20scrum&as_phr... >
Here are some specific ads:
- < https://www.indeed.com/cmp/Thor-Incorporated/jobs/Big-Data-2... > This one contains desired skills directly managing scrum teams, IoT expertise, tons of BI database systems, tons of machine learning frameworks, among much else.
- < https://www.indeed.com/viewjob?jk=a6693cf7a3422b247&from=ser... > (This one is for a full-stack web developer that also needs experience in machine learning frameworks, cloud-based devops tools, "LEAN and Agile/Scrum", and about a dozen specific frameworks.
- < https://www.indeed.com/viewjob?jk=abe4938edc06babe&from=serp... > (This one specifically names Agile, Scrum, JIRA, and Trello, amongst also listing specific deep learning frameworks, Node.js, Flask, and .NET, familiarity with healthcare data, 5+ years of ETL experience, and demonstrated front-end experience.)
- < https://www.indeed.com/viewjob?jk=c231123cf951f128&from=serp... > (This one lists half a dozen databases, half a dozen cloud frameworks, Spark, Storm, BigQuery, Theanos, Tensorflow, Keras, Python, R, Scala, C++, Java, Ruby, Angular, React and then finally lists as the final item, "Drive agile software development practices (Scrum, Kanban, XP, test-driven development, DevOps)")
- < https://www.indeed.com/viewjob?jk=4f7f9564892a1c9a&from=serp... > (This one lists front-end, Javascript, and Angular experience for a front-end role, specifically says, "Experience with an Agile development / SCRUM approach", and then also says "Experience working in a cloud based environment, such as the Google Cloud Platform (GCP), or the Amazon Cloud and using languages such as Jupyter and TensorFlow", which indicates a bad mistake (calling Jupyter and TensorFlow 'languages'), despite the fact that Deloitte is a huge company that could easily invest more into better effort on recruiting ads.
There are so many more, 80 results I found on Indeed just with 'tensorflow' and 'scrum', without even trying more generic search terms or looking on other sites.
Most likely you did not even search for this, or else just engaged with confirmation bias when one or two job ads didn't match the pattern.
But regardless, as anyone with experience in machine learning will tell you, it is extremely common for companies to try to require you to have front-end skills or train you to have them and then give you crap projects that are only aspirationally focused on machine learning, or just use machine learning as crappy hype signalling.
> "I fear your 'many times' is not backed up by reality."
No, you're just in a rush to use confirmation bias to defend scrum without deeply looking into the points that Scrum critics make. This claim is trivially disproved, even just from the links above.
That's again is fully independent of Scrum.
> we ought to discount your experience as too much of an outlier from most of the industry.
He, now you are 'we' and suddenly I'm alone. Nice trick.
> I searched for results containing both 'TensorFlow' and 'Scrum' on Indeed
You are shifting topics, that's extremely disingenuous. Your argument was about a 'Machine Learning Engineer' and 'react' knowledge.
Let's look at the job ads:
'Solution architect' - not a 'Machine Learning Engineer'
'job not found'
'Data Engineer' - again not a 'Machine Learning Engineer'. no 'react'.
'CTO - again not a 'Machine Learning Engineer'.
'Frontend Developer' - again not a 'Machine Learning Engineer'.
You also generally seem not to understand job ads. If they list as desired skills a, b, c, d, e, f, g, h, ... then usually an interesting SUBSET is required. These skills are often mentioned so that they appear in searches and to signal people a range of interesting technology.
> I found on Indeed just with 'tensorflow' and 'scrum',
What does that show, again? Nothing. Your argument was about 'machine learning engineers' doing front end development with react. Stick with your original argument.
> extremely common for companies to try to require you to have front-end skills or train you to have them and then give you crap projects that are only aspirationally focused on machine learning, or just use machine learning as crappy hype signalling.
Now we are back to front end development. If your 'machine learning engineers' have to do 'frontend development', they should look elsewhere. The topic is in high demand and there are lots of better employers which have actual 'machine learning' projects for engineers.
Yes, the linked roles required experience with TensorFlow and other machine learning frameworks for specific job functionality focused on machine learning engineering.
Please re-read my comment above because it refutes your earlier comment, in which you claimed that jobs ads requiring combining inappropriate cross-functional skill groups while specifically also mentioning Scrum don’t exist, and offered disingenuous claims about trying to look it up, when just a cursory search already showed your claim to be wrong.
Here you are again disingenuously acting like the specific job title words are the only part that matters — that’s ridiculous. It’s obvious from the linked job ads (which were just the first ads in the list, selected just by clicking links 1, 2, etc. from the results, i.e. there are many more) are intended to function as machine learning engineers in various ways if you read the job descriptions.
In fact it seems you are again trying to dodge the problem with another No True Scotsman fallacy. Now you’re saying “no real machine learning engineer role can have a title such as xyz..”
This seems to be your go-to defense for everything. Just look at examples that clearly and unequivocally refute what you are saying, then turn around and try to claim that no “real” example would be like that. Just trying to define the outcome you want (“Scrum isn’t disempowering” or “machine learning job ads don’t require front-end skills”) by defining the premise to already have that outcome baked in (“Scrum is by definition empowering, so disempowerment only happens when not correctly doing Scrum” or “real machine learning engineer job ads don’t have other titles or list front-end technologies, so any examples which do must not be “real” examples.”)
> “If your 'machine learning engineers' have to do 'frontend development', they should look elsewhere. The topic is in high demand and there are lots of better employers which have actual 'machine learning' projects for engineers”
This just speaks to your lack of knowledge of this part of the job market, and how tons of large companies staff up on machine learning staff without anything more than a hype-driven, aspirational understanding of machine learning, and no actual statistics projects to offer the people hired. Often a hugely credentialed machine learning engineer is tasked to babysit Tableau dashboards or get added to PagerDuty for answering 2 am alerts for failed Spark jobs.
Only in very few companies and very few teams do these workers actually get approval from pointy headed managers to spend time on research or modeling at all.
Again, I’m glad for you that your experience with ML has been an incredibly unlikely, pleasant outlier with a company that magically always does Scrum “the right way” (and where Scrum is never to blame when they don’t), and where, despite all industry trends, they give good statistics and modeling projects to machine learning engineers (whose specialties are perfectly respected).
This is such a fairy tale scenario though that your experience is inapplicable to reasoning about the more general case of how Scrum itself begets and amplifies and tacitly permits all sorts of bad practices that it ought to be expected to reduce. And your experience is inapplicable to reasoning about how Scrum’s endorsement of cross-functionality is inextricably linked to the way managers assume any engineer, of any specialty, should take on cross-functional software responsibilities.
At this point I do not have confidence that you are participating in the comment thread sincerely, and you are merely attempting to shallowly gainsay whatever I say without actually looking into it.
Maybe you can’t stand not having the last word or can’t deal with it when someone refuses to not call you out on your shallow arguments, I’m not sure what the motivation is. But either way, at this point you’re cherry-picking isolated comments and then rephrasing them as repeated No True Scotsman fallacies in which no “real” example of what I describe is allowed, by definition for you, to contain the bad characteristics you seek to deny, like Scrum’s inherent flaws or the way engineers functioning in a directly machine learning capacity are often forced to also have cross-functional skills in front-end frameworks, devops, etc.
You’re welcome to have the last word if you want it in some follow up to this comment with the same cherry-picking and gainsaying.
But since I have lost confidence that you’re discussing this in good faith, and you are without sincere willingness to look into my points, I’m not going to reply again, and you’re welcome to criticize that choice of mine as well. If I thought you were being sincere instead of yet another No True Scotsman attempt to define away the problem, I would continue. I don’t believe that, so I am disengaging.
Your example was explicitly about 'Machine Learning Engineers' with 'React' skills. For that you have presented zero evidence so far.
> I’m not going to reply again
I think that's fine, since your last posts were not able to back up your claims around Scrum leading to making 'Machine Learning Engineers' to work as 'React' programmers. None of the positions you presented were actually for 'Machine Learning Engineers'. Instead you presented job offers for CTOs and Solution Architects - two very different positions. Since you could not provide evidence for your original claim, you came up with a different selection of positions and skill requirements.
For some reason you project all kinds of project failings from staffing to task selection to the Scrum methodology, instead of looking to yourself, your team and your management.
I've seen it work very well. I've seen it work badly. Where it has worked badly it was because the process was not fully understood, badly implemented and not iterated upon. For reasons I can detail on reflection. These are explicable and fixable reasons that given the right company ecosystem and desire to honestly reflect upon them and fix them could have been fixed. A bad process tout court would never see highly effective result in some cases.
Even if it’s a good norm in theory, if it doesn’t survive contact with human sociology in practice, then it’s disingenuous verbal gymnastics to say “but the norm itself is good, it was just misapplied constantly and nobody, despite huge effort, could stop it from being misapplied.”
And Scrum is misapplied so often that this clearly applies, and renders whatever “spirit” of “true” Scrum irrelevant.
> "And Scrum is misapplied so often that this clearly applies ..."
It's not about always being misapplied. Just that it's misapplied so often that in the larger scale decision making, it's a problem with Scrum.
I don't deny there are isolated examples in which Scrum is applied well and works well. I also don't care, unless those examples represent the majority of cases in most average companies.
We are probably at the point of trading ancedotes, but I'd say in the majority of cases where I have seen it applied it has worked more than it has not. Even a poor implementation has yielded some benefits. And those pieces that have not worked there are reasons why.
My feeling, as I have mentioned elsewhere is that this burden of proof is on Scrum and Scrum proponents to back up the claim that it facilitates better business outcomes than would otherwise have been obtained without Scrum.
The reason I think it's fair that Scrum has the burden of proof is that it is so far-reaching and overbearing in its degree of prescripting exactly the manner of working.
Scrum as a system is responsible for micromanaged enforcement of exactly one set of meetings, exactly one cadence of work, special new positions with Scrum-specific job duties, constraints on team structure, like cross-functionality and minimizing specialization, that there must be some form of aggregateable workload estimation, etc., all which are part and parcel with every Scrum implementation I've heard of (meaning that whether all these prescriptions are explicitly listed in some Scrum manifesto or not, they are absolutely a part of Scrum).
Given all this costly overhead and one-size-fits-all prescription, I think it's very fair to say, "prove it." If I know that my team works really well in our own ad hoc way that is tailored to our specializations, our current workload, our preferences, the way we jell as a team, etc., then why should I agree this other way is definitely, empirically going to be better?
I'm not saying any other team should use the custom methods my team has found to be productive. But why would we need to give them up for a system nobody has proven to be better, and many people have argued to be worse?
But what are you comparing Scrum to? Define your specific objections and propose an alternative.
> "No one cares whether you approve of Scrum or not."
If you don't want to participate in a discussion about it, why are you? Statements like this are useless. We're talking about high-level evaluation of Scrum.
It's like you would read the original post in the OP, which is a qualitative discussion. And instead of formulating reasonable discussion points, you'd just leave a comment saying, "No one cares what you think."
At that point, I mean, your opinion's decided. Why are you even here? What is the goal? To shoot down anyone who tries to analyze Scrum in a bigger picture sense and just give them a raspberry?
Sure.
- When working on a team whose primary outputs are highly specialized research, the necessity to have planning meetings, standups, retrospectives, etc., according to a single fixed schedule causes a lot of problems. A better practice is to allow the length of a sprint to be variable and to be different for different individual team members depending on what they are working on. Elminate overhead that's not helping by discontinuing a fixed-cycle planning meeting (e.g. don't do it every X weeks, rather just arrange planning meetings in an ad hoc way whenever enough items reach a state where a group planning meeting makes sense.) If your team is working on projects that need a longer time to ruminate and develop at the moment, then cancel the retrospective meeting and just do it later after some other milestone. Basically, treat these things like collegial, flexible, malleable tools whose timelines and cadence flexibly changes all the time in response to current projects.
- When working on fundamental research, notions of incremental progress are not useful. You might spend weeks on a problem and have no demonstrable new functionality. You may not even have any research or documentation to share. You might only be able to say, "I worked extremely hard on methods X, Y, and Z, and I appear no closer to know whether they could work or not. Need more time." So in this situation, estimating story points is absurd, and reporting velocity is at best a nuisance but more often harmful because you can count on upper management questioning it with inappropriate comparisons to the way velocity works for iterative software work. Later on, maybe several weeks later, you might have a breakthrough on the tough research project, and now you are at a point where you need to productionize the supporting software that wraps it, and you do get value from estimating time to completion and using iterative cycles of incremental, demonstrable units of functionality. So once again, it should be flexible. Many times, there is no use whatsoever to estimate story points, so don't do it. Don't use a concept like velocity for these case-by-case situations at all. Then later, if you find value in switching back to an estimation-and-velocity approach for productionizing it, then do so.
I could go on, but the general idea is that it should be highly flexible. No fixed set of meetings that must happen every sprint no matter the work context. No enforced policy of always estimating story points or always tracking velocity. That's no flexible, it's rigid because it says you always have to do it that one way, and leaves no room for situations when that one way is not useful, or when it adds costly and time-wasting overhead during periods of work that don't benefit from it.
These things should be left up to the team to decide, based on what type of work the team does, how it varies over time, what feels low-overhead and liberating, what facilitates productivity for that team.
> "You're comparing Scrum to a phantom."
No, I'm not. And I have not been at any point in earlier comments either. Your comments are just needlessly antagonistic while constantly deflecting without dealing with the fundamental problems of Scrum.
> "Otherwise it's just a complaint with no useful contribution."
Complaints are often useful contributions all on their own. It's foolish to claim that complaints have to always be accompanied by candidate solutions to be useful. No. Knowledge of the details of the complaint is useful all on its own. Regardless though, this is still a lazy mischaracterization of anything I have been writing.
Of course one could argue that the improvements were the result of some other phenomena. But it certainly seems that the equation seems to have worked and turned teams around. Scrum wasn't in the mix before and now it is things are much improved.
By the way I'd in no way advocate a one-size fits all solution. Sometimes other techniques might be as effective or more effective. I'd not say you should agree another way is definitely better if your team is humming along. Why would I?
Hey, if Scrum is working for some team, I would be the last person to ask them to change it. I know how much I hate it when I have a workflow that is succeeding and then management arbitrarily makes me switch to Scrum. So I would not want to do that to people who are doing great with Scrum.
The reason I feel the need to deeply question it though, is that most managers don't express the attitude you expressed. Most often they see a workflow as something they need to enforce unilaterally, and that it should function to commoditize the underlying teams.
Given that this is how it's practiced almost everywhere, it's fair to ask why is that? Is there anything intrinsic to Scrum that makes that mistake easier? Or at least, is there something Scrum lacks which would make that mistake harder?
And then to finally ask if someone is advocating for everyone to be happy switching to Scrum, and advocating that every possible problem with Scrum is not Scrum's fault but always just the misapplication of Scrum (like they are interpreting a religious text or something), then I think it's fair for me to say, "prove it" and ask for evidence that the extra operational overhead of Scrum is empirically shown to be cost-effective.
I don't know if there is anything intrinsic to Scrum that makes this more common as imposition but there are certainly risks involved in it that can push a negative power dynamic that is certainly possible in any undemocratic workplace. I'd have to reflect on this a bit more before answering.
But in a couple of cases I've seen it was sought by the team "from below" to protect the quality of their work, make work more enjoyable and self-organised and basically work to more reasonable timescales. There is something to scrum being a toolbox you can use and having a brand. It means you can ask for a process and people know what you mean. Rather than say "I wish work was better".
Yep, I fail to understand the problem with this. A product owner who doesn't respond to pressure for technical quality is a bad product owner – end of story.