Hacker News Reader

Comment by janalsncm | Hacker News Reader

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.

View on HN

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.

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.

> 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.

>> 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.

> 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.

Good teams can succeed with both, but it's billed as a panacea for bad teams.

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.

The response was re: sanedigital's remark that it was a good way to minimally fix (implied) bad teams.

And I've seen it used exactly that way in practice at bad companies.

It's not a strawman if it's lived experience and professed corporate IT strategy at a lot of non-tech companies.

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...

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.

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.

> 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 $$$

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.

> 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.

>Customers don't pay money today for products delivered on an indefinite, unspecified future timeline

They frequently do for features though. I happily waited a year for my bank to implement virtual credit cards. As a corporate user of software I have waited similar lengths of time for features I really wanted.

This reality usually doesnt stop some layer(s) of management from waterfalling the shit out of everything simply because they can't conceive of an alternative.

>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.

Yeah, this is why I try to avoid that type of software development at all costs. I got burned on it when I was young, thinking that nothing was more natural than treating software like a construction project.

Practically speaking, when you do ask for something bespoke - whether it's a skyscraper, crossrail or a bathroom remodeling or software, you've gotta be prepared for delays and budget overruns. Software is much the same, and waterfalling the shit out of this type of thing may be unavoidable, but so is the inevitable shitty result. There are entire sub industries that can't seem to produce anything good (e.g. healthcare software) and I think this model of operation is largely why.

This is why it's better for execs to treat bespoke deliveries as something radioactive and try to minimize them as much as possible even if that means saying the scariest six words in an exec's vocab "sorry, we can't take your money".

> I happily waited a year for my bank to implement virtual credit cards.

Not the kind of feature I'm talking about -- your bank isn't contracting with you, personally, to make a credit card. Apple doesn't care at all about my opinions on when to release their next phone. Google doesn't ask me what they should name Chat this week.

Nonetheless, the stakeholders for such a project are going to be internal to the company, and there will be many: customer support, billing, compliance, marketing and legal, just to name a few. There will also be many deadlines, simply because huge numbers of people have to coordinate to turn out a complicated project.

> As a corporate user of software I have waited similar lengths of time for features I really wanted.

Again, unless you are signing the purchase order, you're not the customer, and you don't set the deadlines. Someone else is setting the deadlines for you. Also, just because you had to wait a long time doesn't mean that deadlines didn't exist for the project.

> This is why it's better for execs to treat bespoke deliveries as something radioactive

All software projects are bespoke. Some are smaller and more tightly scoped than others, but if you didn't need custom work done, you wouldn't pay an engineer to do it.

>Not the kind of feature I'm talking about

I know. I expressly declared the type of feature you were talking about radioactive.

The tragedy isnt that this type of feature exists it's that some managers cant conceive of there being any other kind and will turn every feature radioactive. Thats how we get shit software.

Dave Thomas, one of the co-creators and co-signer of the agile manifesto has a great talk on the topic.

Yes, the Agile Industrial Complex is a total grift and nothing to do with the manifesto.

Him warning about this may or may not have an effect though.

Highly recommended.

https://youtu.be/a-BOSpxYJ9M

> This is what I often describe as doing agile vs being agile.

I just started a new role leading a 30 person Engineering team at a company doing Scrum. My very first questions to everyone was why are we doing this? Answers ranged from some expectations like regular/predictable delivery of product to "because that's how software is done." From there, it's figure out a process that makes sense and actually achieves objectives. Scrum provides a nice framework, but everyone needs to be bought into the goals of it first. (My next actions were to get rid of most of the useless workflow rules in Jira and build that accountability at the team level...it works amazingly well that way)

I agree that it's much more doable at a small company. Once companies get big enough, the need to centrally plan and coordinate seem to create an irresistible urge to apply identical processes to all teams, compare velocities, and all sorts of other bad habits.

The fact that this confusing distinction even exists is testament to how unnecessarily complicated agile is.

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).

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.

The Agile Manifesto it’s a nice read but you cannot put it in practice. It’s like the Bible: everyone has its own interpretation.

Not sure why we still talk about it.

This comment is totally opinion and no evidence. But also oh so cathartic to read. Rant on, sir!

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 ;)

> 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.

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/

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.

> 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.

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.

But by "complexity" people pretty much always mean "how long it'll take", so it's still time. If something was complex in an abstract way but quick to implement, it would get a small number of story points, not a large number.

I don't disagree with you fundamentally, but maybe one way to reframe this is around the type of conversation we're looking to prompt when we point stories. The conversation you're describing (and to be fair that I mostly have experienced as well) is a one-way, "you owe us this, how long will it take?" conversation. The conversation I'm always hoping to have, and that I've seen happen before, is a bi-directional one in which tradeoffs are discussed, priorities are constantly shifting, thoughtful investments are planned, and engineering concerns are a first-class citizen. All of this can happen if you simply consider your estimates "time" as well, but I find that conceptualizing it as "engineering complexity" helps encourage an engineering mindset among the non-developers on a team.

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.

Senior says task will take one day. Junior says it will take 3 days. What do you put into estimate?

Story points are simply a way to say "I think that looks roughly like twice the work of that one we estimated before".

Usefulness depends on specific environment and who and for what interprets the output (usually, at some organization level, there's excel/Gantt, that will convert them into an exact date. That will fail spectacularly in 99% of the cases).

> Senior says task will take one day. Junior says it will take 3 days. What do you put into estimate?

Well, who's planning to do it?

Depending on the team, number of tasks, size of task etc, answer to this ranges from: guy who does the estimate, to: whoever picks it first.

Which is almost always known at the time of estimation, in my experience. In the cases where it's not, then ok, points could make sense, but only as an interim step towards getting to a real time estimate once you know who is doing it. Having a vague point estimate could then be a useful indicator of "we don't really know yet".

> Which is almost always known at the time of estimation, in my experience.

In mine - not so much. Two dev team? Sure, you probably know. 6 dev team? Not so much. Estimation, then back to customer to decide if they'll eat the cost and decision 2 weeks later? Good luck knowing what will happen then.

Point is answering question "does it fit into the sprint", knowing that usually you can fit 3 big tasks and 3-5 small. Then real time estimate is end of sprint.

> "I think that looks roughly like twice the work of that one we estimated before".

And by "twice the work" they mean takes twice as long. It's still time.

Anyway you could just say "2 days of work" with the understanding that duh, a senior can do it quicker than a junior. It's just an estimate anyway.

So basically you say "two days", while knowing that won't be two days - it's "virtual day". At this point how is it different from story point? :-)

It's weird how people whose half of work is coming up with clever abstractions, have so much problem with that one.

because everyone could have a different opinion on what it actually means instead of just a simple time based measurement. The whole thing is just absolute bonkers

Well for a day I've already meet: ideal man/day, average man/day of the team, man/day of the guy doing estimate.

Maybe estimation is complex thing and therefore team needs to align opinions before doing it?

We never do that though, we have to estimate our own tickets. So we're always estimating time for ourselves, we just can't say it's time though. Drives me mad but scrum masters these days have fully drunk the kool aid, it's fixed adherence to meaningless fibonacci story points or you're not doing it right.

You don't know that it won't be two days. It's an estimate, it's possible that a junior will go quick or senior will go slow.

That's why points aren't really necessary. Using days is still an estimate.

That said, I don't really object to points, I object to the idea that they don't represent time, when they obviously do.

They do. It's just your subjective time not objective that entire team needs to agree on. Which - more we discuss seems more and more impossible because it's more or less random how long it will take specific person.

> Senior says task will take one day. Junior says it will take 3 days. What do you put into estimate?

Who is doing the work? The senior? One day. The junior? Three days. The estimate should always be done by the person doing the work. This also forces people to have skin in the game when making estimates. When you have a full team coming up with points, then no one has any consequences for being wrong. But if you say one day, then you have some incentive to think things through. You want to live up to your commitment. Of course, this assumes that there are some consequences for being wrong, which usually isn't the case. I think this is where many people go wrong with time estimates. If you're repeatedly wrong, that's not because time estimates don't work. That's because you're bad at them. And like most skills, if you do them repeatedly and try to learn from the cases where you failed, you'll get better at it.

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 goal shared among the team

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.

Agree. Especially because they are used mostly to gauge a team’s velocity.

You’re looking at it all wrong, story points are a defensive tool for you the developer. It gives your team a made up unit that no one else understands.

If you told someone on Monday that a ticket takes two days they’ll ask you on Thursday why it’s not done.

Instead story points combined with team velocity give your team a sense of how much work you can commit to.

Of course we all have in our mind that a 5 point story takes a like 3 days.

If some director or product leader comes in and looks at these tickets the won’t see any time estimates on them and thus can’t hold you accountable to them. Sue they can look at your team velocity. But that’s generally a higher level moving average of several sprints.

Of course this is all imprecise and often isn’t implemented well. I’ve seen it work very well for some teams, where it gave us a good sense of our accomplishments and led to more ownership. It often doesn’t work and just adds overhead.

I’ve ditched it for my current team.

I can see how that could be useful for some teams. I guess the teams I've been on just haven't needed that kind of obfuscation.

In any case, I was talking about the many devs who insist it's not time even though it is. Having it be a sort of abstracted or obfuscated time increment is fine imo.

> 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.

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.

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).

> 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).

As a Product Manager, fucking yikes. I'm sorry for that horseshit.

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.

> They dragged the entire company into AWS,

And why/how is that a good thing?

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.

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.

I get that and that is the selling point of the cloud and it makes total sense for some workloads like ML/Data Science.

However, once you move the companies infra to AWS (or any one cloud provider) and shutdown your infra, in due course AWS will keep increasing your price by x% every year. At the point you don't have a choice but to pay those price increases yoy. You have much less bargaining power.

I think hybrid cloud is the best way to go. You have lot of bargaining power and no one provider can hold you hostage.

Agree that strategically lock in is a concern, but getting on AWS at least removes the inertia of moving to cloud. It’s probably much easier to go from on prem to cloud to multicloud than on prem to multicloud directly - especially at the time C1 started the migration.

> However, once you move the companies infra to AWS (or any one cloud provider) and shutdown your infra, in due course AWS will keep increasing your price by x% every year. At the point you don't have a choice but to pay those price increases yoy. You have much less bargaining power.

I think you’re leaving out a key restraint: AWS is quite profitable now but has strong competitors and there’s still a much larger amount of IT spending which isn’t going to any cloud provider. If they abuse one customer, a ton of money is going to race to the exit. It’s also hard to see how they could raise prices enough to cancel out all of that lost future business without attracting regulatory attention, too — rearchitecting isn’t trivial but you’re still talking on the order of a year to profit before you’re not only losing the profits you had but also all of the future growth.

The other thing to consider is the substantially greater cost of a hybrid cloud: not just the obvious costs of extra resources, ops, security, training, application support, etc. but also the opportunity costs of restricting your usage to the lowest-common denominator cloud features. That’s a heavy cost to pay every month as a hedge against a low-probability event — I highly doubt that you’d lose money betting that you’d save so much money by using a single cloud that you’d still come out ahead if you had to migrate later.

There is a major cost of switching cloud providers, which means it’s less of an efficient market than it could be. Since all of the costs are transparent AWS knows how much more they can charge while still being cheaper than switching. Push the break even point far enough out and few companies will even consider switching.

And that doesn’t even get into the technical side of it, which is a logistical nightmare as you mentioned with multicloud. (I don’t even want to think about it for my personal projects!) If C1 has around 50k years of AWS experience among all its tech employees, it will take a long time to match that in Azure or GCP.

Switching costs are non-trivial but I would also keep in mind just how valuable “we don’t raise prices” is to AWS for getting businesses to adopt them. In practice that means they don’t lower prices as quickly when the underlying costs decrease but an awful lot of CIOs prefer that to volatility.

When the market is closer to saturation that could change but I think that’s going to hold for at least a decade or two: there is considerably more money being spent on traditional data centers than in the cloud and I’m sure they’re trying to give as few disincentives as possible to those potential customers.

Get a job at any other bank that's been around since the 1980s and you'll know why that's a good thing.

I was something like that in a previous role. I had no official title, but I was a sort of JIRA secretary. I chased people around to gather clear requirements, and cut them into understandable tickets. I babysat tickets to completion and did QA as needed. I made meetings redundant by doing the backlog grooming and requirements gathering in parallel. I chased information on behalf of developers, and made sure they didn't get stuck. I attended meetings and passed the relevant bits to devs.

Basically, I kept the backlog in sync with reality, and vice versa. I was the facilitator I wish scrum masters would be.

However I also met my fair share of post it fetishists who don't seem to get much done. They seem like the priests of a modern religion, bringing their tabernacle filled with coloured markers and helping us pray to the productivity gods.

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.

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

Why is it a great gift?

Just in case you missed it, he said 'grift' (a petty or small-scale swindle)

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.

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

> 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 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.

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.

It is rarely awesome for the lead or senior dev.

Anyone who doesn’t want to do it is the wrong person, and doesn’t sound like a good lead dev to me.

A lead dev isn't necessarily a team lead. They could be a technical lead, or an architect, or simply a senior dev with deep knowledge of one specific project. They may not have the interest, skill, or authority to deal with the situation. Even if they can do it you may be pushing them towards quitting or burnout; or creating a feedback loop where their technical contributions drop because they need to coordinate more people because quality is dropping because your top dev's technical contributions dropped.

Sounds weak. I wouldn’t call that person a team lead or a lead dev.

Agile doesn’t take much effort if you know what you’re doing. It’s just a card wall, standups and a planning meeting. This is not hard for a good lead dev. If you think it’s hard, you probably aren’t a good lead dev, or you don’t know how to do it right, which is the same thing.

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.

They are so 2010s. Hopefully the role will die soon in the 2020s.

> 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.)

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.

You can make it closed under addition by defining addition to round to the nearest Fibonacci number.

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.

> The only time I saw scrum masters really do anything was “leading” standup and “leading” planning meetings every other month

But, are they supposed to do something else? Been in many companies, and scrum masters are the most useless role out there. Somehow, they seem to be hired for who knows what reasons. Slowly, they are becoming less popular though. Now the trend seems to be Engineer Directors (middle management between Engineering Managers and C-level executives). Total waste once again.

Reply on news.ycombinator.com