371–380 of 382 posts
I read through a lot of detailed analysis of Scrum's shortcomings in the comments here, but little in the way of "Instead".
If anyone cares to share his/her vision: based on your experience, what would be a (nutshell) model for a better system?
Thanks <3
Earlier quoted context omitted.
Great job distilling the essence of scrum into three bullet points, I wouldn't disagree with those. Here's the common pitfalls as I see them: 1. Sprints offer flexibility but unless you educate the whole company waterfall + gantt charts are what the business side wants 2. Unless you educate all members of a scrum team on what the retrospective is, and let the developers drive it, you won't be effectively improving pr…
That last point is simply working software _over_ documentation, meaning that in a world of finite resources what would you rather have? A pile of requirements and technical design docs _or_ a working product? All teams need to determine the right amount of documentation that maximizes total output of working software, but agility was--in part--a response to analysis paralysis and high overhead of many software imple…
While design documentation tends to be anti-agile (but sometimes useful to avoid wasting more time on miscommunication and mistakes), end user documentation is, for all practical purposes, part of the valuable software product, as it enables end users to do what they want to do.
Unfortunately, being able to neglect end user documentation makes many outfits treat it as a useless luxury, either because they are only judged on software (e.g. passing a test instead of having satisfied users) or because they don't care (e.g. many introverted hacker/artist open source maintainers). It's purely delusional agility, like driving fast by not stopping for fuel.
Earlier quoted context omitted.
Sure, but the PM is there for a reason and the PM has roles. There is overlap with what developers can be doing, but we are trained/encouraged to punt to the PM for such decisions, questions, and suggestions. I get it, but it's now how I do my best work, proxying questions and discussions through a gatekeeper.
IME the PM works best when acting as a shield from random questions or future things or other not-important-this-instant distractions, but shouldn't block direct clarifying questions or feedback from you to a stakeholder. I'd keep them in the loop, but the ones I've worked with haven't wanted to just be a glorified "I deal with the goddamn customers so the engineers don't have to!" middleman for basic things like tha…
Let's do a little thought experiment where we try to stay within the scrum universe, but try to solve the main problem (developers being disempowered by scrum) by modifying the scrum framework. As the author states, "So Scrum has a master, product has an owner, but no-one is empowered to advocate for development priorities." Let's add another role to scrum called the craft master. This individual has excellent techni…
Earlier quoted context omitted.
I think you are entirely right that the "sell books and consulting" is a major driver of what Agile became. I got involved in the Agile world circa 2000, but by 2010 or so my main feeling was increasing horror: http://agilefocus.com/2011/02/21/agiles-second-chasm-and-how... One of the especially interesting things to me was that at the beginning there were a variety of different methods. People behind them got togeth…
> "If you go by actual behavior, it turns out the highest priority at most companies is not actually to improve, to get better at making things for users. It's instead to make managers and executives feel like something is being done without disturbing the power hierarchy. Low-end Scrum fills that need adequately, letting you move marginally in the direction of agility, apply some new labels, and declare "mission acc…
I work on 3-12 month projects in an agency, we don't really do Scrum. It's mostly some version of waterfall, and occasionally dual-track agile. Generally the process of determining what to build is squeezed into the cracks. I just recently built about 40% of a prototype for a SaaS in a couple weeks with fractional team input, and then had to lay out the rest of the flows in a week. After that, more needs popped up (I can only imagine the shitshow that development will be). This is the worst case scenario.
In less-worse cases, it seems like this becomes an issue of how to compare a requested change's value to its cost. Without enough data, this can be really hard to actually know well enough to have a grounded position on. It seems like consensus here is to focus on the cost of the change, rather than the potential value.
It also seems like there's little faith in managers. I don't totally know what it's like out there for ya'll though.
Earlier quoted context omitted.
> “Scrum requires the TEAM to be cross functional for the product it develops. It does not require each TEAM MEMBER to be cross-functional.” 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 examp…
> It’s naive to approach this in some letter-of-the-law way 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, operati…
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.
Earlier quoted context omitted.
> It’s naive to approach this in some letter-of-the-law way 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, operati…
> "The principle of a cross-functional team is widely explained and described." 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, regar…
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.
Earlier quoted context omitted.
> "The principle of a cross-functional team is widely explained and described." 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, regar…
> are completely subverted for convenience of managers and business people. 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 a…
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.
Earlier quoted context omitted.
> are completely subverted for convenience of managers and business people. 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 a…
> “What does that show, again? Nothing. Your argument was about 'machine learning 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…
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.
Earlier quoted context omitted.
My quip on scrum/agile is that it "ensures mediocre results from mediocre teams." Its just a methodology in the end. It can help keep those that tend to have wandering minds focused, but for high performing teams the overhead slows them down. The assumption of a standard programmer is just never a reality as well. I actually saw a startup try to go full religious agile and only hire "full stack" developers to try to…
"Agile" is completely independent concept from "full stack" or "homogenized" development.
To combat this, this individual decided to try to reduce the specialization as much as possible. Everyone would do everything was the thought process, so no one could ever hold anything up.
This was a non-technical founder of a now dead startup, but it died of the much more typical problem of market fit- they did launch, and the site worked. It may be interesting to mention he was also using entirely offshore development teams.