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.
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.
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.
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?
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.
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).
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 ;)
> 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.
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 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.
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
> 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).
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.
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.
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
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.
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.
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
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.
> 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.)
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.
> 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.
> 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."
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.
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.
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
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...
Our scrum masters are pretty 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.
> 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?
> 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.
> 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.
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.
Your anecdote is from 1997, 26 years ago from today. Do you really think there is remotely any overlap from your experience in 1997 to how things are done today?
Well, I don't know. Corporate cultures are quite "sticky", in my experience. If a company is founded to exploit banking automation, I suppose it's likely to go on focusing on that expertise until it doesn't work any more.
So are you saying that CapOne is nowadays completely different from how it was in 1997? That would be an interesting comment. But you haven't actually said anything; you've only snarked.
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
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
IME the bot tier engineers who couldn’t code or think got into “scrum” and other BS to try and become engineering managers. Of course we know how that ends.
Honestly hope we see engineering manager title die off this decade as we go through these layoffs and reorgs.
Teams with a technical team lead should report to a director. It’s not that hard to slack someone if you’re blocked. We can even have an AI manager handle this kind of administrative crap.
I’ve had over a dozen engineering managers I’ve worked with and only two were any good. I mean, I keep in contact with them even years later. Rest were a joke at best or mostly terrible to work with.
Again I’m sure at some places this kind of arrangement works. But I’ve probably experienced more bot tier managers than bot tier engineers. And yea I’m mad about it so excuse my negative tone.
"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.
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".
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.
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.
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
> "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".
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.
Readit News
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.
I just assume if the company is doing agile they have lost faith in their developers when it comes to organizing or producing value.
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.
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.
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.
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).
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 ;)
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.
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.
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.
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
Use story points. Succeed with story points. But don’t try to convince yourself (or me) they aren’t just an analogue for time.
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.
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.
> 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).
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.
And why/how is that a good thing?
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.
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.
Dead Comment
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
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.
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.)
Deleted Comment
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.
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.
Do we dare dream?
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.
I thought I had heard it all with Happiness Managers but this takes the cake.
> 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?
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.
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.
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.
[Edit] Can't delete! Well, Duh. C1 is what I called CapOne. I knew that. <slaps head>
So are you saying that CapOne is nowadays completely different from how it was in 1997? That would be an interesting comment. But you haven't actually said anything; you've only snarked.
[1]: https://scaledagiledevops.com/
Honestly hope we see engineering manager title die off this decade as we go through these layoffs and reorgs.
Teams with a technical team lead should report to a director. It’s not that hard to slack someone if you’re blocked. We can even have an AI manager handle this kind of administrative crap.
I’ve had over a dozen engineering managers I’ve worked with and only two were any good. I mean, I keep in contact with them even years later. Rest were a joke at best or mostly terrible to work with.
Again I’m sure at some places this kind of arrangement works. But I’ve probably experienced more bot tier managers than bot tier engineers. And yea I’m mad about it so excuse my negative tone.
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.
>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".
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.
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.
> Individuals and interactions over processes and tools
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".
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.