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 just assume if the company is doing agile they have lost faith in their developers when it comes to organizing or producing value.
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.
Sounds familiar.
Back in my consultant days, we would encounter companies that wanted to be “agile”. They’d always insist they were waterfall and that 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.
> 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.
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.
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.
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.
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.
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 $$$
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.
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. 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 X-thousand person call center", 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.
They frequently do for features though. I waited a year for my bank to implement virtual credit cards.
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.
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.
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.
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.
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.
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.
Not sure why we still talk about it.
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 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.
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/
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.
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
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 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.
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.
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.
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).
Well, who's planning to do it?
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.
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.
It's weird how people whose half of work is coming up with clever abstractions, have so much problem with that one.
Maybe estimation is complex thing and therefore team needs to align opinions before doing it?
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.
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.
The engineering manager should know the product area 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)
Use story points. Succeed with story points. But don’t try to convince yourself (or me) they aren’t just an analogue for time.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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).
As a Product Manager, fucking yikes. I'm sorry for that horseshit.
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.
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.
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.