[HN Gopher] Capital One axes 1k tech roles
___________________________________________________________________
Capital One axes 1k tech roles
Author : bluedino
Score : 145 points
Date : 2023-01-21 17:13 UTC (5 hours ago)
(HTM) web link (www.theregister.com)
(TXT) w3m dump (www.theregister.com)
| fwungy wrote:
| Company I recently consulted for dropped 90% of their project
| management team to save money. Didn't hurt anything, except leads
| had to do more Jira. Pretty painless way to save money from their
| pov.
| FireBy2024 wrote:
| Aren't scrum masters usually individual contributors on the team
| as well?
| plorkyeran wrote:
| The original idea was that the ICs would take turns as the
| scrum master. I'm sure someone somewhere has actually done
| that, but it's unusual.
| nhtsamera wrote:
| It seems pretty popular in big software-centric companies
| like the FAANGs. IME the turnover is usually every couple of
| months, as the sacrificial lamb gets tired of it and other
| team members start to feel like it might be time to take a
| turn in the bilges.
|
| I can understand why the idea of hiring someone to handle
| that role would be appealing, but it really isn't a full-time
| job.
|
| Plus, the last thing that BigCo engineering teams need is
| more politics; they have more than enough of that between the
| overlapping layers of engineering, project, and product
| managers.
| raincom wrote:
| No, they are not. In some cases, if an individual contributor
| is not good at contributing, if one has political capital, that
| one can become a scrum master. And you see this in mega tech
| companies all the time.
| zdragnar wrote:
| I've heard that is the theory- that it should be a role on the
| team, not a title, and (optionally) that it should rotate.
| Everyone on the team at some point contributes to leading the
| team, so everyone gets accustomed to communicating well.
|
| That said, I've never actually seen it in practice.
|
| At best, it has been a role someone in product takes on so they
| can act as a shit shield from above and let us know if there is
| something urgent, but otherwise stays out of the way.
|
| At worst, it is a frivolous salary that takes the book-keeping
| notes from stand-ups and puts them in a report noone reads.
| belltaco wrote:
| I've never seen a scrum master code. Sometimes the daily scrum
| meeting is run by ICs when the scrum master is busy or not
| around.
| tetraca wrote:
| We have scrum master as a rotating hat with all the other
| senior developers on the team. 99% of my day is code or
| meetings on what I'm coding. The only burden is once a week I
| look at jira with some managers and help them click boxes.
| I'm not sure what a full time scrum master would really do.
| shamiln wrote:
| I have. Half of the time, I'm glad it's not their primary
| responsibility in this case.
| xwolfi wrote:
| We do it. Usually agile comes from above and the team only
| have to tick a box, say they re agile and show a shadow org
| around it. We even rotate the scrum master sometimes to
| spread the joy.
|
| End of the day, we fill the client's need, as efficiently as
| we can without letting them run wild in expectations and
| keeping cost in line with budget: it's common sense and I
| dont get what the agile religions bring really. Turn idiots
| into mediocre people, maybe ?
| jvanderbot wrote:
| It just seems to me that "agile as directed by management"
| is pretty much an oxymoron.
| bdavis__ wrote:
| i have seen a scrum master code.
| ScrumMaster = NULL;
|
| there you go !
| bastardoperator wrote:
| You can get a scrum master certification in about an hour and
| the test isn't even proctored.
| firstSpeaker wrote:
| well... https://www.scaledagileframework.com/ has gone so far
| into the koo koo land that teams are dysfunctional because of
| them.
| canadianfella wrote:
| Is this a parody website?
| __derek__ wrote:
| That one appears to be earnest, but Scaled Agile DevOps is
| definitely parody.[1]
|
| [1]: https://scaledagiledevops.com/
| 56friends wrote:
| "All teams should assemble in the Convoy Alignment room for
| this multi-day celebration of detailed planning. It is
| important that the alignment happens in person and that
| everyone travels to a remote location to eliminate
| distractions from less important things such as family or
| pets."
| firstSpeaker wrote:
| Wow, this is so fun to read!
| Throw10987 wrote:
| No, to the point that there is this website -
| https://safedelusion.com/
| winphone1974 wrote:
| I wish. It's the rational people back again, this time
| leaning heavily on agile to sell to the c-suite. Everything
| good here is common sense or stolen from elsewhere;
| everything else is at best absolutely terriblev and at it's
| worse permanently damaging
| winphone1974 wrote:
| We're in our second PI planning session and beyond SAFe it's
| gone so far off the rails we're into week 2 of planning. So bad
| that I'm likely to quit over the experience
| darth_avocado wrote:
| What is "agile" job role family?
| firstSpeaker wrote:
| Usually the family of jobs you do not see any big tech company.
| These are the roles that are defined in SAFe framework!
| l0gic4l wrote:
| Scrum masters
| trillic wrote:
| "Scrum masters" and their managers the "Agile delivery lead".
| Pretty sure there was somebody in charge of the AGLs under each
| director too.
|
| This was in addition to teams having product owners and an
| engineering manager as well at times. At times I had 3 people
| managing a team with 3-6 engineers.
|
| Very interesting tech culture.
| nhtsamera wrote:
| And to think, Office Space came out 24 years ago. Funny how
| things come full-circle.
|
| >And here's something else, Bob: I have eight different
| bosses right now.
|
| >I beg your pardon?
|
| >Eight bosses.
|
| >Eight?
|
| >Eight, Bob. So that means that when I make a mistake, I have
| eight different people coming by to tell me about it. That's
| my only real motivation, is not to be hassled. That, and the
| fear of losing my job. But you know, Bob, that will only make
| someone work just hard enough not to get fired.
|
| Cue some discussion about kids these days and "quiet
| quitting".
| Devasta wrote:
| These days, Office Space is downright aspirational.
|
| His cube is so big and private, and he can push to prod
| without going through change management! Heaven.
| matwood wrote:
| > It's not that I'm lazy, I just don't care.
|
| My SO at the time didn't understand what I did at work all
| day until we saw that movie in the theater.
| cjglo wrote:
| Also a former Cap1 employee here, the 3 people managing a
| team of 3 engineers is quite common.
|
| My last team before leaving had 3 engineers: tech lead, me,
| and a junior dev. It had 4 non-engineers managing us: a
| product owner, a head Agile Delivery Lead, a more junior
| agile Delivery Lead, and our manager.
| spritefs wrote:
| What did the agile people do?]
| AeroNotix wrote:
| Promote synergy, direct workflow, bring value to key
| stakeholders
| nkozyra wrote:
| See who could complain about this it sounds incredibly
| valuable.
| ushakov wrote:
| So, nothing?
| jpatt wrote:
| Eh, steel manning the role it kind of just sounds like a
| TPM. When roles are crisply defined, a good TPM has been
| a life changer for my job satisfaction. You basically get
| permission to farm out a lot of the most annoying parts
| of the job--status update forums, timeline management,
| and dependency wrangling--to another person who does it
| full time.
| spritefs wrote:
| Afaik all my tpm does is create outlook events and
| occasionally come to our standup to bitch about how we
| aren't doing enough jira
| belligeront wrote:
| I've seen both versions of these. A good TPM is extremely
| valuable though, especially for work that is highly
| reliant on coordinating other teams. The bad version was
| a net negative to team productivity.
| shamiln wrote:
| A reflection of your TPM, I guess
| krona wrote:
| > bring value to key stakeholders
|
| Or not, in this case.
| cinntaile wrote:
| They're getting axed while the engineers get to stay, so
| not much it seems.
| servercobra wrote:
| You need that many people to properly manage Jira /s
| __derek__ wrote:
| My first SDE job was in a company with a dedicated Scrum
| Master role, and they were basically the lubricant to
| make Agile/Scrum teams fit into what was essentially a
| waterfall environment. It's roughly a TPM in Big Tech,
| but without those companies as industry peers for setting
| comp.
| richiezc wrote:
| something something conjoined triangles of success
| feanaro wrote:
| It doesn't sound to me like the product owner should be
| considered the developers' manager. Though I guess that
| depends on what the word "manage" means and these days it's
| starting to sound like it's lost all meaning.
| SpicyLemonZest wrote:
| What makes it a hard call is that, in an organization
| that's trying to be engineering-focused, the product
| owner typically has as much say in what work you'll be
| doing as the person the org chart says you report to.
| (They have the most relevant expertise - a "people
| manager" has to spend a lot of their time managing
| people, while the product owner's sole and full-time
| responsibility is understanding what work the product
| needs.)
| oasisbob wrote:
| Strong product owners controlling the workflow and
| prioritization of the team certainly feel like management
| when you're working under one.
| MisterBastahrd wrote:
| They shouldn't. Otherwise, there's nobody to pushback
| against stupid client requests. Product owners should be
| managing the product, not the employees. Having an
| employee manager to butt heads leads to a better overall
| product because it leads to better discussion between the
| devs who know the system and the product owner who is
| helping to flesh out requirements.
| coffeebeqn wrote:
| Hilarious. First line of the Agile manifesto is lost irony on
| these people I guess. Scrum and safe and all that nonsense is
| basically just a cargocult but not even a cargocult or
| anything useful
|
| > Individuals and interactions over processes and tools
| bdavis__ wrote:
| "individuals and interactions" is how you make great things
| happen. "processes and tools" is how you make boring things
| happen at scale and with high quality.
|
| very few teams are willing to admit that they need to be
| making boring things happen.
|
| agile is not a universal tonic.
| marcosdumay wrote:
| The Agile manifesto is entirely about making boring
| things happen for loosed integrated teams. It was created
| by a forum of consultants that wrote CRUD for random
| companies.
|
| It is certainly not universal. As an example, if you want
| to make something great, it has absolutely no relation to
| your problem.
| saghm wrote:
| > "Scrum masters" and their managers the "Agile delivery
| lead". Pretty sure there was somebody in charge of the AGLs
| under each director too.
|
| Honestly, what bothers me the most about this is the idea
| that "agile delivery lead" is abbreviated "AGL". It doesn't
| even make it any more pronounceable compared to "ADL".
| dopylitty wrote:
| Another variation on this I've seen is an 'agile' 'team'
| composed of several groups of engineers each reporting to
| different managers in the organization with a scrum master
| and product owner who reported to yet different chains of
| command.
|
| All of these chains of command had different and conflicting
| priorities as well as political wars with each other. The
| product "owner" knew very little about the ill-defined
| product they owned yet they set the team's 'official'
| priorities based on wish lists from the business while the
| engineers also got different priorities from their chain of
| command and the scrum master was a glorified admin assistant.
|
| The result was that no strategy existed and nothing of value
| was done but the engineers were still ground to a paste
| against the mill stones of the Jira board every two weeks.
|
| It made me miss the simpler times of having a well defined
| waterfall project being done by a single team of engineers
| with a single engineering manager and a project manager to
| make the gantt chart and schedule the meetings.
| darth_avocado wrote:
| Ohh wow. I have worked in tech for over a decade now and none
| of this makes sense for me.
|
| Like we follow agile principles (often take the core
| understanding and apply it in a way that works for the team).
| Usually the positions you mentioned are just EMs or tech
| leads with added responsibilities.
| syspec wrote:
| > Many Reg readers will know Capital One best for the break-in in
| 2019, where an attacker raided Capital One's cloud storage
| buckets and stole personal information on 106 million credit card
| applicants in the US and Canada. Stolen data from people who
| applied for credit products included 140,000 US social security
| numbers and 80,000 bank account numbers, as well as one million
| Canadian social insurance numbers, plus names, addresses, phone
| numbers, dates of birth, and reported incomes.
|
| > Former Amazon engineer Paige A Thompson, who also went by the
| handle "erratic," was collared by the FBI the same week of the
| attack, and was convicted in June last year of pilfering millions
| of folks' data from the "misconfigured" storage buckets. In
| October, Thompson was sentenced to time served and five years of
| probation with location and computer monitoring.
|
| So wait, he stole millions of dollars worth of data, got rich off
| of it and was sentenced to time served?
| bobkazamakis wrote:
| where do you see that she got rich...?
| tanaros wrote:
| > So wait, he stole millions of dollars worth of data, got rich
| off of it and was sentenced to time served?
|
| She copied the data but there was no evidence she profited from
| it. Capital One paid $250+ million in fines and legal
| settlements as penalty for not securing the data properly.
| unity1001 wrote:
| Did the CEO take 'full responsibility' in this layoff too...
| [deleted]
| barbazoo wrote:
| I hope it's at least the ones that are responsible for
| aggressively pushing that stupid shopping browser extension every
| time I check my credit card account online. What a nonsensical
| thing to build, and what an annoying way to market it, without a
| way to opt out.
|
| Sorry for the people though that lost their jobs, I hope they all
| land on their feet.
| Eighth wrote:
| Ah. So, I expect my job interview to be cancelled next week...
| 29athrowaway wrote:
| I wonder how many trees are killed so that the shortsighted
| people at Capital One can keep blasting their spam every day.
| pdntspa wrote:
| Interesting, I remember hitting up their booth at AWS lovefest in
| Vegas in 2019, and being somewhat surprised/perplexed to see that
| they were getting into the cloud infra management business.
|
| They did give me a pretty cool t-shirt though.
| civilized wrote:
| > The consumer lending company told The Register that its plan
| was to eliminate its "Agile" job family and integrate staff there
| into "existing engineering and product manager roles."
|
| Do we dare dream?
| xwdv wrote:
| I can't wait to see these scrum master charlatans eliminated
| from most companies.
| winphone1974 wrote:
| This can actually be an unfair characterization: my company
| required some developers, who tended to be the stronger
| technical leaders, become certified scrum masters for their
| respective teams. Is hate to lose them all
| TulliusCicero wrote:
| People who are scrum masters as part of being a senior/lead
| engineer aren't really the problem.
|
| And it's possible some dedicated scrum masters could simply
| drop into the somewhat similar role of technical program
| manager.
| coffeebeqn wrote:
| A scrum master was one of the most useless people I've ever
| worked with. Not a product or project manager because they
| didn't know the domain. Didn't know all that much about
| building software because they didn't have any skills. Devs
| were still writing and moving tickets around so they
| basically did zero productive work.
| at_a_remove wrote:
| When this is done, probably after the next fad takes hold,
| I want a grim and thorough post-mortem of Agile, from its
| naive utopian vision to the various parasites the ecosystem
| attracted, down to the disillusionment and tears. I want
| names and I want shame. I want the nasty cultist tendencies
| exposed for everyone to see and hopefully (ha!) learn from.
| Perhaps not post-mortem, perhaps vivisection, so that a
| mirror could be held up to the abdominal cavity so that
| Agile could at last see the teratomas lurking inside of it
| since shortly after its conception, before the whole thing
| flickers out.
|
| The kindest interpretation one could offer is that it was a
| starry-eyed conception of how programming teams could
| constantly kick the blame-ball back to the stakeholders, as
| if the routine assignment of fault were somehow reasonable
| and rational in organizations, which it is not. At its
| worst, it looked like a solid grift, something that would
| last for several years as long as you kept smiling and
| promising.
| ethbr0 wrote:
| There's a pretty simple generic form of it:
|
| _{thing} is something we can pay money for, without
| making real changes or learning new information, to tell
| investors and competitors we 're part of {new fad}_
|
| Big-A Agile (as marketed, certified, and hired for) is
| that for little-a agile (the manifesto and cultural
| practice). It also describes most consultant trends.
|
| The root of it is the realization that nobody in
| positions of power wants to change or admit they don't
| know something. Highly structured Agile implementations
| promise to deliver agile without requiring either of
| those things of anyone in power, which is why they're
| CTO-down driven: hire for new roles, nod when report are
| presented, and pat each other on the back at how
| progressive your company is.
|
| It's management attempting to feign involvement at a
| lower level, without really putting in the effort to do
| so productively.
| 56friends wrote:
| My team was forced to invite a scrum master to several
| planning meetings. She sat quietly, observed the process,
| and then a few weeks later disappeared without a trace. We
| didn't get any feedback from her or the org. Still not sure
| what that was about.
| somehnguy wrote:
| Wow, I had almost the exact same experience with my team!
| The only reason I don't think we work together is that
| ours was a he.
|
| Still no idea what that was about, and it was never
| brought up again.
| abledon wrote:
| grug happy shaman ritual loosing power in org
| rado wrote:
| Nature is healing
| denton-scratch wrote:
| I learned something like "agile" from two guys that had worked
| with Ward Cunningham. That was useful; but it was also useful
| that they moved on after they'd trained the team.
|
| It sounds nuts to have an Agile job-family; I don't even know
| what that means. But hiring an Agile consultant for a few
| months can be transformative.
|
| [Edit] I think it's worth noting that neither of these two guys
| functioned as a "scrummaster" - they sometimes ran the scrum,
| sometimes it was other people. Even I did it once. They both
| coded, and paired with roughly eveyone. They were both rather
| heavy, for my taste, but I learned a huge amount from them.
| xwolfi wrote:
| Funnily enough my company started an agile reorg last year, and
| it's going as well as you can imagine. Cant wait for the de-
| agiling next phase where we can go back to having 4 matrix
| managers instead of 5...
| spamizbad wrote:
| This looks like they are cutting jobs like scrum masters and
| product managers.
| iLoveOncall wrote:
| Scrum master is a full time job?
|
| I thought I had heard it all with Happiness Managers but this
| takes the cake.
| denimnerd42 wrote:
| Our scrum masters are 100% useless at my company but they do
| work with 2 or 3 teams. They are basically
| secretaries/administrative assistants for JIRA and outlook
| which is fine.
| 56friends wrote:
| Finally, a silver lining of the economic downturn!
| janalsncm wrote:
| Used to work for C1. It was never really clear to me what scrum
| masters did, since our manager understood the technical and
| cross-team requirements of our product (I know this might not be
| universal) better than anyone else.
|
| The only time I saw scrum masters really do anything was
| "leading" standup and "leading" planning meetings every other
| month. I put leading in quotes because there's only so much
| leading one can do if everyone else knows more about the product
| due to the inherent transitory nature of the scrum master role.
| Are you really adding value by reminding people that story points
| (some vague relationship to days of work) can only be Fibonacci
| numbers?
|
| Inside the company, the CEO loved to tout the "technical journey"
| they made which included things like moving to the cloud. Agile
| was on that list but it never really felt like it belonged.
| Depending on one's tolerance of the kool-aid, some skepticism was
| always there.
| rogual wrote:
| Oh god, the Fibonacci numbers.
|
| Project planning does not get easier if you limit yourself to a
| number system that is not closed under addition. A strange
| thing to have to tell people, but here we are.
| charcircuit wrote:
| You can make it closed under addition by defining addition to
| round to the nearest Fibonacci number.
| rogual wrote:
| You can! But as a bit of an Agile cynic, I find it quite
| funny that you literally have to accept that 2+2=5 to use
| it.
| TulliusCicero wrote:
| > story points (some vague relationship to days of work)
|
| Watching people insist that story points are totally not
| representative of predicted time spent working on a thing is
| the funniest shit. The mental gymnastics are incredible.
| trentnix wrote:
| 1000x yes. I feel like I've had the same conversation about
| story points since 2006.
|
| Use story points. Succeed with story points. But don't try to
| convince yourself (or me) they aren't just an analogue for
| time.
| lawrence19 wrote:
| Story points in my experience almost always devolve into time
| estimates, but I don't agree they _have_ to be the same thing
| (which is how I interpret your use of "representative").
| They are related variables in the same way that temperature
| and pressure are related, but that doesn't mean they are
| identical.
|
| In a healthy environment, I think "story points" (horrendous
| name) should approximate "engineering complexity given the
| current state, skill set, and knowledge of the development
| team." Time estimates should then be _derived_ from that
| number based on historical performance of the team in its
| current state (if you fuck with the team structure, all bets
| are off and historical data becomes less useful).
|
| Ideally a team should use points to do thoughtful analysis of
| their backlog and think of ways to manipulate scope, invest
| in cleaning up technical debt, and learn new skills to
| cheapen the engineering complexity and in turn deliver
| faster. In practice, what you described is almost always what
| happens. Stakeholders keep pressing for time estimates, so
| shit just keeps getting added to the backlog and engineers
| estimate "how long?" because they are neither encouraged nor
| empowered to think of it any other way.
| dimal wrote:
| I've never understood story points either. Somehow, the
| argument goes that if you take a process that involves an
| high level of uncertainty, and you replace clearly defined
| units of work (time) with vaguely defined units of work
| (points), this will magically make estimation and planning
| _more_ accurate. Maybe, since you're using Fibonnaci numbers,
| that makes it scientific?! I've never seen it actually work
| in fifteen years of trying.
| adam_arthur wrote:
| Pointing in general is not very helpful in my experience.
|
| The engineering manager should know the product area and code
| well enough to gauge the LOE for tasks and plan, without the
| unnecessary step of estimation meetings (which likely aren't
| going to produce accurate numbers anyway).
|
| Could also be a tech lead that does this, but prefer that
| they're one in the same.
|
| Of course there are many aspects of "pure scrum" I don't
| agree with, such as a single sprint plan shared among the
| team
| bastardoperator wrote:
| Agile and scrum is not a solution to anything. Participating in
| agile voodoo has no measurable impact. In fact, I think in many
| cases agile makes you immediately slower. Developers than
| realize they have to pad everything with bullshit estimates
| they pulled out of thin air so they're not getting punished for
| missing work or bad guesses.
|
| I just assume if the company is doing agile they have lost
| faith in their developers when it comes to organizing or
| producing value.
| andor wrote:
| What you are describing makes sense within Scrum, because
| scrum asks for commitment.
|
| It has nothing to do with "agile" though. In fact, the agile
| manifesto clearly says "individuals and interactions over
| processes and tools". An organization that follows processes
| that don't make sense to its employees is not agile, despite
| what they claim.
| shsteimer_1 wrote:
| This is what I often describe as doing agile vs being
| agile. Most large companies are constitutionally incapable
| of being agile, for a while host if reasons I don't feel
| like iterating here, but I'm sure you can fill in the
| blanks.
|
| But they are more than capable of putting in rules and
| processes that allow them to do agile. The problem is that
| doing agile without being agile does far more harm than
| good.
| BoorishBears wrote:
| > Most large companies are constitutionally incapable of
| being agile, for a while host if reasons I don't feel
| like iterating here, but I'm sure you can fill in the
| blanks.
|
| There's a long list but only one really needs to be
| mentioned:
|
| _Payroll costs $XX,XXX,XXX and is due every 2 weeks._
|
| I've sat through "agile training" and it's the most plain
| grift I've ever seen.
|
| Selling developers on a deadline-less utopia, but walking
| it back just enough to not make management types paying
| for the whole thing balk. Switching which side of the
| scale their finger is on based on who seems the most
| engaged at a given moment.
|
| But at the end of the day, it's always predicated on the
| idea that developers can always provide backpressure
| against clients.
|
| Well you're free to do that, and clients are free to not
| pay, and unless your developers will work for client IOUs
| that's the end of the game.
|
| Agile mentality is great. The idea of rapidly iterating
| and rapidly producing feedback is great. But "Agile
| methodology" has evolved into a productivity ponzi scheme
| meant to add a place for consultants and trainers to
| insert themselves for $$$
| pydry wrote:
| If the execs and managers can't get out of the mentality
| of planning X deliverables for Q3, Y deliverables for Q4
| and Z feature by December 10th to satisfy a $10m customer
| then it becomes hollow and fake no matter how genuine and
| well meaning the consultants are.
|
| I dont really blame them. They've gotta eat, and
| occasionally they probably do get a client who is
| genuinely willing to enact a real transformation.
| Dysfunctional upper management is the real problem.
| timr wrote:
| > If the execs and managers can't get out of the
| mentality of planning X deliverables for Q3, Y
| deliverables for Q4 and Z feature by December 10th to
| satisfy a $10m customer then it becomes hollow and fake
| no matter how genuine and well meaning the consultants
| are.
|
| Dysfunctional upper management: maybe.
|
| Customers don't pay money today for products delivered on
| an indefinite, unspecified future timeline: _definitely_.
|
| More software engineers should have to be involved with
| customer conversations to internalize this...or just, I
| dunno...do a construction project or something. See how
| much _you_ like it when you 've paid money for something
| bespoke, and the people doing the work refuse to set
| schedules or tell you what you're getting. Suddenly
| you'll be a dysfunctional manager, too.
|
| Agile works best when you have a consultancy situation,
| and the customer can be directly involved in the
| construction of the product while it is being built. This
| rarely applies. But even then, customers tend to make
| ridiculous demands like _" advance notice before you
| change the software from under us so that we can re-train
| our large team of users"_, and as soon as you do that,
| you've got a calendar, a deliverable and a deadline.
| Probably some Gantt charts in there too, because only
| trivial projects have a single deliverable.
|
| Then you say "OK, let's _actually be agile_ , break down
| the project timeline using iterative deliverables and
| clear development cycles"...now you have sprints.
|
| I'm not defending "Scrum" -- just saying that
| deliverables and deadlines are part of life.
| YZF wrote:
| Agile (EDIT: The Agile Manifesto specifically) is meant to
| solve a very specific problem. It's meant to solve the
| problem of describing software via a contract, taking a long
| time to build the software described in that contract, and
| then the software not being useful despite an enormous amount
| of effort/resources poured into it.
|
| If you are working in an optimized team, that understands the
| business, understands the customer, and efficiently and
| incrementally delivers business value building the right kind
| of software then these practices won't help you and as you
| point out may actually hurt you.
|
| The above though is some minuscule fraction of software teams
| in the real world (and some may not know it).
|
| The problem with Agile practices and Scrum is that despite
| their theoretical ability to improve the way we build
| software, and the good intentions of the original ideas,
| inefficient teams and companies will always find a way to
| adopt the practices they think are good (and therefore keep
| them inefficient) while rejecting the practices that may help
| them. That's the conundrum of pretty much any process (and
| funny enough "people over process" in a twisted way means
| people that have no clue will subvert any process that tried
| to push for doing things better in most orgranizations).
| LAC-Tech wrote:
| _Agile (EDIT: The Agile Manifesto specifically) is meant to
| solve a very specific problem. It 's meant to solve the
| problem of describing software via a contract, taking a
| long time to build the software described in that contract,
| and then the software not being useful despite an enormous
| amount of effort/resources poured into it._
|
| Really? The impression I get it's that it's geared towards
| internal teams who can "iterate" until the cows come home.
| Contractors work on a fixed time-frame and/or cost, agile
| doesn't jive well with that unless you're just labour
| augmentation.
| i_like_apis wrote:
| Very much disagree. Well-run, minimal Agile is an amazing way
| to organize, see, plan, and go fast.
|
| There's a lot of gripers who don't like feeling managed and
| attack it with all sorts of false criticism though. And of
| course, poorly-run Agile can be pretty annoying.
|
| The key is to keep things minimal and fast: quick stand-ups,
| and as few meetings as needed. Who is leading it definitely
| matters too. Ideally it is a lead developer rather than a
| "product" or "project" person, IMO.
| lr4444lr wrote:
| This comment is totally opinion and no evidence. But also oh
| so cathartic to read. Rant on, sir!
| jrockway wrote:
| I'm not a big fan of agile, especially the more formal it
| gets. The problem that engineers have with it is that it does
| make things slower. Moving fast is absolutely not the goal of
| agile. The goal of agile is to make the development cycle
| predictable, so that all the moving parts of the bureaucracy
| can be at the right place at the right time. All of this
| stuff around estimation is really intended to make sure that
| unknowns are minimized, so that the list of work in JIRA or
| whatever is somewhat reflective of the actual work required.
| That lets the rest of the organization react to whatever the
| engineers are doing in a somewhat intelligent way. You can
| look at the progress bar on an epic, look at the date, and
| reasonably answer that question from a customer in the form
| "XXX bug is ruining my life, I hate you guys" "that will be
| in our Q2 release" "oh wow, I actually love you guys". That
| sort of interaction is what is paying your salary, so
| spending time to make it easy is what keeps the sales and
| support teams alive.
|
| I don't have any evidence, but I think it's an undeniable
| fact that coordination effort is very expensive. We are all
| familiar with how fast our 1 person weekend projects go; you
| spend 12 hours on Saturday evenings on something, and it
| feels like it progresses faster than what your team of 30
| people is doing at work 5 days a week. My opinion is that
| projects scale exponentially with complexity. A 1 person
| project takes 1 person. A 2 person project takes 2 people.
| But then, a 3 person project takes 4 people. A 4 person
| project takes 8 people. A 5 person project takes 16 people.
| By the time you are at big company sizes, you might have
| 30,000 people vaguely working on the same thing; by my rule
| above, that's a project that's 15x more complex than a 1
| person project. That's why it feels like "my friends and I
| could make Twitter over the weekend, why do they need 30,000
| employees!?" You're thinking that results scale linearly over
| the number of people, but it really scales logarithmically
| over the number of people. So now you're 1/30,000th of a 15
| person project, and you don't feel as productive. You are
| 0.003% of the equation. If you work 10x as hard, you're 0.03%
| of the equation. It just doesn't fit with your mental model
| of productivity that you extrapolate from personal projects
| (where it's 100%, or 110% if you had a really good cup of
| coffee). That's why it feels bad, but it's also why
| management is not super concerned that you are spending 20
| hours a week in meetings. Oh no, now you're only 0.0015% of
| the equation.
|
| The final question is, why does society put up with this? The
| answer is, there is money in these projects that are just a
| bit more complicated than a software engineer's personal
| project. You will be remembered more for the 0.003%
| contribution you had to the moon landing than you will for
| making the absolute best ever music file organizer. It sucks,
| but that's how the Universe works. You can embrace it, or you
| can fight it. But if you want to stave off the heat death of
| the Universe, you might need a team and a plan and maybe a
| few meetings to share the plan with your team ;)
| tikhonj wrote:
| > _The problem that engineers have with it is that it does
| make things slower._
|
| The problem I've seen is that formal agile processes
| _substantially reduce individual engineers ' autonomy_--
| slowing everything down seems more a symptom than the core
| problem. (Of course, it's ultimately the symptoms that kill
| the patient, right?)
|
| Coordination is both important and difficult, but a process
| oriented around tracking and directing individuals at a
| bite-sized-ticket level is not a necessary, sufficient _or
| even particularly effective_ solution. It 's an abstraction
| to make work legible in the worst way: it's restrictive to
| the people doing the work, encourages unhealthy patterns of
| top-down management, poorly reflects the ground truth while
| still giving managers the illusion of detailed
| understanding and control.
| jrockway wrote:
| I think the process is poor at accommodating generalists,
| since most people are not generalists. You might want to
| design a new feature one day, talk to customers the next,
| and then refactor your CI system on the third. The org
| really has no way to accommodate that; the cost to bring
| you up to speed on all the details is too high and your
| request is too weird. There is already a product team,
| support team, and testing team. Nobody has ever wanted to
| do all those things; all they want to do is show up, work
| on some technical mumbo jumbo, and disappear at 5pm.
| Moving the business forward what that at the bottom is
| what the process focuses on. (And, yes, this is why
| startups exist and do so well. If you can figure out
| Capital One or Twitter and pick the 10% that actually
| matters, you're back to a 2 person team. It ain't easy,
| though.)
|
| As for top-down, organizations try that approach because
| it seems like the problems could all be solved if people
| weren't coordinating with each other, but just did what
| they were told. It seems like it doesn't work like that;
| this presentation explains it pretty well (and was on HN
| last weekend): https://komoroske.com/slime-mold/
| sanedigital wrote:
| You have been blessed to work on self-organizing and self-
| managing teams. When we come into client orgs, they typically
| have no process in place and cannot understand why they're
| not shipping features.
|
| Scrum isn't perfect, but its an "industry-standard" practice
| that we can use to get quick buy-in from client stakeholders,
| and then use to apply even the most basic level of process to
| these teams.
|
| As an engineer at Google or a freelance developer it never
| made much sense to me.
|
| But as a manager of remote, distributed, international teams?
|
| It makes a lot of sense.
| trentnix wrote:
| > _When we come into client orgs, they typically have no
| process in place and cannot understand why they 're not
| shipping features._
|
| Sounds familiar.
|
| Back in my consultant days, we would encounter companies
| that wanted to be "agile". They'd insist they were
| waterfall and it wasn't working.
|
| Truth is, if they'd actually been doing waterfall they'd
| have been performing far better. Instead, they were just
| chaos, reacting to one fire after another with no plan to
| get out.
|
| Additionally, many teams were simply staffed with poor
| managers and poor engineers. There's no consulting-fu or
| process-fu that was going to overcome that. You can't win
| horse races with pack mules, my dad (a basketball coach)
| used to say.
| ethbr0 wrote:
| >> But as a manager of remote, distributed, international
| teams?
|
| > You can't win horse races with pack mules, my dad (a
| basketball coach) used to say.
|
| You can boil it down to saying that Scrum is either (a)
| micromanagement or (b) an admission that your developers
| and their managers suck.
|
| Fix the problem, instead of slapping a bureaucratic band-
| aid on that's going to attrit any remaining quality
| developers.
| trentnix wrote:
| > _Fix the problem, instead of slapping a bureaucratic
| band-aid on that 's going to attrit any remaining quality
| developers._
|
| I don't think this is right. It's like a sports team:
| your system, your philosophy, your approach matters. Like
| in basketball, you might utilize the flex motion offense
| or you might use the Tex Winters' triangle.
|
| Good teams can succeed with both, but depending on your
| personnel and what you're up against, you might find one
| strategy works better than the others.
| ethbr0 wrote:
| Good teams can succeed with both, but it's billed as a
| panacea for bad teams.
| eric-hu wrote:
| Do you realize you're attacking a straw man? Has anyone
| in this thread said that Agile is a panacea? I think we
| can agree it is not, nor is anything a panacea.
| hef19898 wrote:
| As my current, very pragmatic scrum master told me: we
| try to cover the failure to plan woth agile and wonder
| why nothing gets done (or something along that line).
| Well, now our chaos is agile...
| i_like_apis wrote:
| I also regularly question the value of "project" and "product"
| managers.
|
| However I have noticed that when that figurehead person is
| missing the meetings and goals quickly disassemble.
|
| In my experience the best leader of Agile or Scrum is always a
| lead developer, instead of a dedicated "project" or "product"
| person.
| crazygringo wrote:
| I can't speak to C1 specifically, but scrum masters ARE useful
| in some scenarios, while in others they are totally useless.
|
| Where I've seen them provide huge value is in an organzation
| transitioning to agile, where the product manager/owner is more
| on the side of waterfall/sales, making unreasonable demands.
| The scrum master is the one who pushes back against this and
| "protects" the devs, and basically ensures that sprints run
| smoothly. Especially if you have thousands of developers
| transitioning to agile, hiring scrum masters that can each
| associate with 5-10 teams can make a huge difference.
|
| On the other hand, if you have competent PM's (or even just eng
| team leads) who themselves serve as the buffer between the dev
| team and the rest of the org (sales, VP's, etc.) and who
| already know how to do agile, then yes, scrum master is
| entirely redundant.
|
| But to be clear, leading agile isn't about reminding about
| Fibonacci numbers. In an inexperienced team, if one dev picks a
| different number, there's often peer pressure to just "change
| their number" instead of discussing the sources of
| disagreement, which is the actual purpose of planning poker.
| And there are a ton of situations like these where both devs
| and a PM might want to "play pretend" at agile rather than
| actually rigorously questioning requirements, negotiating
| better requirements with owners, and relentlessly surfacing
| blockers. So leading agile requires both real knowledge of the
| process as well as the courage to stand up against owners,
| groupthink and peer pressure.
| clumsysmurf wrote:
| I worked at a company partially owned by C1. Our culture was
| somewhat derivative in the Agile aspect (Scrum, moving to
| SAFe).
|
| > The scrum master is the one who pushes back against this
| and "protects" the devs, and basically ensures that sprints
| run smoothly.
|
| That may be the ideal (of any leadership really) but our
| Scrum Masters reported to the PMO, which defined their agenda
| and financial rewards.
|
| In fact, our weekly retros were not what we could do better,
| but what the PMO wanted us to do differently (like report
| time estimated / worked on stories in Jira down to the
| minute).
| marcosdumay wrote:
| > The only time I saw scrum masters really do anything was
| "leading" standup and "leading" planning meetings every other
| month.
|
| AFAIK, scrum masters are supposed to be that one that goes from
| person to person, looking if everything is ok, if they need
| help, or if they should be doing something else.
|
| That certainly is not "leading". It is indeed some kind of
| "managing", mostly because this word is incredibly ambiguous.
| It is also the problem solved by dailys, so if your dailys are
| useful, it means your scrum master is useless. As far as I can
| see, there is no reason to have both. (And I'm still doubtful
| about any reason to have one of them.)
| trentnix wrote:
| > _The only time I saw scrum masters really do anything was
| "leading" standup and "leading" planning meetings every other
| month. I put leading in quotes because there's only so much
| leading one can do if everyone else knows more about the
| product due to the inherent transitory nature of the scrum
| master role._
|
| 100%
|
| I interviewed with a company (not C1) earlier this year that
| had one of those "every team has a manager, every team has a
| scrum master" bits going on. I asked multiple times what the
| difference between the roles were, and couldn't make sense of
| any of the answers I got (which were full of consultant-speak).
| I declined to move forward.
|
| Like anything, I'm sure there are teams out there with this
| situation that make it work. But it sounds to me like a recipe
| for confusion, conflict, and atrophy.
| abledon wrote:
| scrum master is one of the greatest grifts of 2010s-2020s tech.
| Esp when org chart pencils them in as 'mgmt' level so they are
| payed more than intermediate engineers, and on par with senior
| engineers
| newaccount2021 wrote:
| [dead]
| late2part wrote:
| Why is it a great gift?
| kensan73 wrote:
| Just in case you missed it, he said 'grift' (a petty or
| small-scale swindle)
| baxtr wrote:
| What's the overall feeling towards scrum masters? In my last
| company, everyone outside product tech never understood their
| actual value. My CTO was a big fan, he said they were the glue
| binding the teams together or something like that. I never had
| a strong opinion but I'm curious to see how much controversy
| there was around this role.
| ecshafer wrote:
| I don't see the point of scrum masters personally. They
| create more work if anything and mostly act as a cargo cult
| leader. A manager, a tech lead / staff developer, product
| manager... the other tech leadership positions on a team i
| see immediate value. Scrum Masters I do not and never have
| seen their use.
| LAC-Tech wrote:
| I thought Anton Oliver performed exceptionally well for the
| All Blacks in the 90s, and even his return in the early 2000s
| added a lot of much needed experience to the front row.
| tass wrote:
| At an old team of mine at Amazon we would assign an SDE to
| that role and switch it around every few months or so.
|
| They were in charge of getting the right people together for
| any meetings, asking for extra info to be added to any
| backlog items, and telling teams when we were planning to
| deprioritise or drop the backlog items they asked for. It
| worked pretty well for us, and took maybe a day of time per
| week
| morelisp wrote:
| > we would assign an SDE to that role and switch it around
| every few months or so... took maybe a day of time per week
|
| The problem is if you are having a struggling team, it
| takes a lot more of a day of time and requires a lot more
| maturity than just leaving jira comments and sending
| meeting invites. But if you put your devs who are good at
| structuring problems/time on it, now they're participating
| in the actual development less, so the team gets even less
| functional (at best temporarily, at worst you're now in a
| death spiral). Furthermore if the root problem is not
| really the organizing but more fundamental (poor skills /
| skill alignment, understaffing, chaos agent, etc) the
| singular dev will rarely have the ability to deal with it
| and can even start drawing animosity.
|
| Having a separate person responsible for this, in a
| different hierarchy with different ears, can be a lot more
| effective in these situations. (It can also make it worse,
| if the separate person is also shit at their job, has too
| much work, has very different attitudes towards work than
| the rest of the team, ...)
|
| tl;dr: If your team is functional pretty much anything will
| work, these structures also need to be judged by how well
| they can get it back on track from non-functional.
| i_like_apis wrote:
| It really depends on who they are and how good at their job
| they are. I've seen more bad ones than good ones.
|
| I prefer a lead or senior developer to have the role rather
| than a dedicated non- or even former- developer.
|
| When a good lead dev with good communication skills and
| experience has the role it can be awesome.
| ashconnor wrote:
| Also used to work for C1.
|
| You're right in the sense that the role was always awkwardly
| jammed into teams often when it didn't make sense.
|
| Some were pretty good but most were of the certificate-chasing
| type that had bought into the commercialization
| (bastardization) of Agile.
|
| Give C1 their due though. They dragged the entire company into
| AWS, mostly, which is something I don't think any other bank
| that's been around as long as they have has done.
| victor106 wrote:
| > They dragged the entire company into AWS,
|
| And why/how is that a good thing?
| noisenotsignal wrote:
| I interned there a couple years ago. It was nice to use
| tech that was more standardized than proprietary / internal
| so that the skills were easily transferable.
|
| From a business perspective it takes you out of the
| business of managing your own infrastructure. Even at big
| tech now we have to decide between managing our own
| infrastructure and "outsourcing" it to a managed service.
| Most advice I've gotten encourages the latter. It can cost
| more but if cost isn't prohibitive it frees you up to
| deliver features and value for customers because you no
| longer have to develop (as much) expertise in ops.
| ashconnor wrote:
| Get a job at any other bank that's been around since the
| 1980s and you'll know why that's a good thing.
| Throw10987 wrote:
| I think if you rephrase it that they "dragged the whole
| company out of the particular IT hell that is associated
| with banks owning, running and procuring infrastructure" it
| probably makes more sense.
| black_13 wrote:
| [dead]
| antihero wrote:
| I've heard that cap one were the first people to truly do data
| based lending, how's that holding up?
| denton-scratch wrote:
| > It says it uses "ML applications, APIs and cloud products" to
| prevent online credit fraud.
|
| I worked as a contractor for CapOne for 9 months, in Richmond VA,
| in 1996/7.
|
| I was a tech, but I worked mostly on applications to help the
| fraud team. In those days, I think CapOne was ahead of the curve
| in automating banking. The fraud team were working to a
| checklist, with lots of computer assistance. They were always
| frazzled, because they were customer-facing. They kept themselves
| to themselves, and they had a high turnover.
|
| In the canteen, I sometimes tried to eavesdrop on their
| conversations. They were always just grumbling. It must have been
| a shitty job.
| jabroni_salad wrote:
| When you are working fraud cases, you talk to zero people that
| are happy. Either you are talking to an actual scammer, a
| victim, or a victim who is very unhappy that the fraud system
| has flagged something. And then even when things are cut and
| dry it can take several days for a refund to go through, so if
| the customer is paycheck-to-paycheck they will need to make
| sacrifices until it all clears.
|
| One of my earlier gigs was insurance claims and then I also did
| a stint in fraud. I think the only worse job could be debt
| collection or those guys from the military that visit you if
| your spouse dies.
|
| I do technology in the FI space and pretty much all of my
| clients have a fraud process of "the customer notices their
| card is declined and has to call the number to find out why".
| C1 on the other hand will just send me a text asking for a
| yes/no and it works. Still ahead of the game as far as I am
| concerned.
| denton-scratch wrote:
| "FI"? "C1"? Sorry if I'm being dim.
|
| [Edit] Can't delete! Well, Duh. C1 is what I called CapOne. I
| knew that. <slaps head>
| jabroni_salad wrote:
| FI: financial institution
|
| c1: capital one
___________________________________________________________________
(page generated 2023-01-21 23:01 UTC)