The thing about Scrum is the observations and principles make sense, but then to sell it as a course they've turned it into very specific prescriptions.
I went on a scrum course and the takeaway was basically that feedback is a big deal, and you should try to get some repeatedly and quickly. It's also common sense that you should have tasks written down somewhere, and that some of them are more important than others.
You certainly need to think about how long tasks will take, but there's no reason why you need to do planning poker, that just seems to be one among many ways to think about how long something might take. Tracking velocity is another one of these things that seems replaceable.
If you have a team of people that more or less adheres to a few principles, there's no reason you can't get things done.
The problem with any system is that people try to enforce it, military style. In my previous job, we did scrum, but not too strict. We had two week cycles, not-too-strict deadlines (most of the time) etc. If I finished my task early, I was free to pick up tasks from the planned list, without having to get permission from my manager. We also didn't agonize over story points, retrospective etc. We did it light hearted and quick. The only thing we religiously followed was daily, quick 15 min stand-ups. Everything else was flexible.
My current job is the opposite. Some tasks take 15 minutes of discussion (no, they aren't complex tasks) with people debating whether it is worth 5 points or 8. It is just tiring and pointless. And retro - gawd, I hate those. There are all kinds of stupid shit (people using references from music, movies etc, trying to make it "fun" and "hip"). I can't bring other tasks into the sprint, even if I finished all my current tasks, without my manager's permission. And on and on.
I was thinking the other day why this is so painful and awkward. I realized that it all comes down to "metrics" - end of every sprint, my manager has to present it to his bosses, with pretty graphs describing "velocity" and other buzzwords. So he has to do all kinds of jugglery to appear competent to his bosses and not alienate the team at the same time.
All of this could be avoided by treating the team as adults, instead of trying to "processify" or quantify everything.
However hard we try, human beings can't be slotted neatly into buckets nor can they be precisely quantified. However hard we try, estimating software projects will never be an exact science.
A cause of this problem is when people are worried about what happens when they say "erm, I don't know how to do this cleanly" and so they want the "how" to be defined far far in advance. Solving this requires a mix of
A. Identifying those activities that will genuinely make people's lives easier if they have a process and designing those processes to be meaningful and low-burden. Those activities will vary based on team members individual peeves and affinities.
B. Creating clear lines of communication for how and whom to ask for help. This often means more clear naming of responsibilities.
C. Ensuring there is enough slack time for people to be able to help each other out.
D. Creating trust in the team that asking for help won't lead people to question if you are fit to do your job.
" I realized that it all comes down to "metrics" - end of every sprint, my manager has to present it to his bosses". I wonder how widespread this is.. Certainly that's exactly what I experienced at a previous workplace, and worse than that, people's performance was judged on whether they'd done exactly the "right" stories in a 2 week sprint. Rather than thinking about developing software, people were working out how to game the system to ensure their metrics were good. I cannot see how this can have done the employer any good. I've now moved jobs, to a place that's far more Kanban, and if mid-story we encounter bugs that need fixing, or opportunities to improve something, or something else useful that piques our fancy, then as long as the whole team agree and our overarching goals are being worked toward , we can work naturally, rather than rigidly.
> I realized that it all comes down to "metrics" - end of every sprint, my manager has to present it to his bosses, with pretty graphs describing "velocity" and other buzzwords.
You've discovered the secret of Agile in the corporate workplace: that the key takeaways, as far as the enterprise is concerned, are not finding better ways to develop software and better customer-developer relations. It's all about trackability, measurement, and metrics, because everything is. Trackability and measurement enable key decision makers to make accurate budgeting and execution plans and there is literally nothing else for key decision makers. Therefore, it makes less of a difference what you output than that it was properly planned for, tracked, and measured and that it hits organizational KPIs. That's why nobody cares that Scrum is a giant productivity suck. Code could be written faster, but that's not writing it properly.
Agile in the enterprise is a game of Mornington Crescent. The goal is not to foster the things advocated in the Agile Manifesto. It's to make it look like the company is fostering those things, while actually promoting the same Taylorist values corporations have always loved (and workers hated).
Funny, retros are the one thing I like. If you can get a team to honestly say what went well and what went bad, and the step that can be taken to improve, every two weeks, with some light follow up. In 6 - 12 months, you can turn a flaming wreck of a project into something that resembles best practice.
I have do it as a consultant. I have taken a project on life support that they were gonna cancel, regardless of our performance, and resurrected it so hard they actually decided to keep it. We changed their minds
The most effective tool was retros. I dislike agile in all other aspects, and do not use story points. Retros are the best bit! It's the core part of the learning loop.
I learnt retros from Google. Big tech does retros. Its honestly magic when done well.
I'm baffled by this behavior. If you know it is the next most important thing, why do you care? What would it change in your behavior if it is a 5 vs and 8? If you are looking at a task that you would choose not to do if it were an 8 but choose to do if it were a 5, then you probably look for something that is more important to work on.
I think you are right that much of that is driven by managers looking for metrics, but unless they understand what the metrics mean it is pointless.
Oh god, this perfectly describes the company I just quit. They went from using Trello, allowing us to choose what to work on, loosely setting story points and ... that was it.
Then they decided they needed the metrics on everything, so they switched to JIRA, started doing retros, setting strict points on tasks(reprimanded in retros if you messed up), using burndown charts to reprimand even more, and giving the product manager the power to dictate what I work on and in what order.
It went from being a great company to work at, to a company I ran away from. I have half a mind to send this thread over to them.
> My current job is the opposite. Some tasks take 15 minutes of discussion (no, they aren't complex tasks) with people debating whether it is worth 5 points or 8. It is just tiring and pointless.
That was my last gig. The whole organization eventually just collapsed under the increasing load of being "Agile".
At my work, when one of us gets too into the details of pointing, estimation, or process we usually realize, stop, and say "sorry--I was being a Scrumbag"
> I realized that it all comes down to "metrics" - end of every sprint, my manager has to present it to his bosses, with pretty graphs describing "velocity" and other buzzwords.
This is a thing that's pretty key to Scrum: velocity can't be used to compare teams. It is easy to misuse though. I would start every meeting I were in with "these points measures cannot be used to measure performance between teams."
We have sprint retros and generally find them valuable. I’m curious how one would even go about incorporating music and movies into a sprint retro? That does sound painful.
> The only thing we religiously followed was daily, quick 15 min stand-ups.
One of the worst parts of scrum in my opinion. Even if it's a "quick" 15 minutes (which in my experience it rarely ever is), the forced context switch ends up wasting more than 15 minutes of productive time every day.
> In my previous job, we did scrum, but not too strict. We had two week cycles, not-too-strict deadlines (most of the time) etc. If I finished my task early, I was free to pick up tasks from the planned list, without having to get permission from my manager. We also didn't agonize over story points, retrospective etc. We did it light hearted and quick. The only thing we religiously followed was daily, quick 15 min stand-ups. Everything else was flexible.
This is exactly how I've seen it run with success at several different companies (including how I run it).
In my mind, the most important value of Scrum is having a cadence to give people reasonable timeframes to think in AND ensure that a variety of different conversations happen frequently enough (discovery, planning, prioritization, execution).
----
> And retro - gawd, I hate those.
It sounds like you hate these because you aren't actually empowered to make meaningful change within your team.
We've found retros are one of our most important rituals. They help us identify risks, process, and team issues; often while they're still small. We quickly work those in.
>Some tasks take 15 minutes of discussion (no, they aren't complex tasks) with people debating whether it is worth 5 points or 8. It is just tiring and pointless.
If you're not personally responsible for deadlines on the project, it could seem pointless. But the difference might mean pushing the commitment for a feature out two weeks, which in a commercial project could be a big deal. Planning is hard: you've got to try to estimate something with incomplete information, and then reconcile differing opinions. But it's definitely not pointless.
Velocity is probably one of the most misunderstood aspects of scrum. It's a key metric for long-term planning, but it's not intended to be manageable. It's also unique to the team, and not intended to be compared between teams. Many managers are not used to a metric that they don't manage, and that causes a lot (maybe most) of the bad experiences people have with poorly practiced scrum.
A lot of places are looking for new people (even remotely), don't stay in a place that makes you miserable. You don't have to suffer for other peoples mismanagement.
The whole debating around agile, scrum, kanban etc etc, with seniors hating Scrum yet it being pushed ever and ever again made much more sense when I heard some guy talk about Shu-Ha-Ri (https://martinfowler.com/bliki/ShuHaRi.html).
Having a strict framework à la Scrum is very helpful for new developpers or new teams, where they don't yet have their marks and need to get a feel of what agility feels like. Being explained principles is not enough to know how to apply them: Scrum is not a bad starting point to be in the right-ish track without really knowing what you're doing. As you gain experience, it's natural to want to shake off constraints, that's Ha and Ri
Maybe if you don't fill a team with nine juniors that have no mentors, you don't get this problem?
It's not like FAANG isn't hiring boatloads of new grads every year. Why don't those people need scrum to get on the right track, but half the rest of the industry seems to?
I don't even know if it's a thing with new developers or old developers; I think sometimes you just get people who don't want to play along. Half-hearted participation is as good as no participation. You end up with user stories that are poorly written, poorly estimated, and you can't really reap a lot of the core benefits of Scrum like velocity forecasting. What you end up with is I Can't Believe It's Not Scrum; a shoddy clone of Scrum that never comes near the mark. You're forced to keep going along this way because not everyone agrees that you're failing.
Maybe people are tired of the nonsense that systems like Scrum bring with them? Even the name is a bit silly. And when you start naming roles and inundating people with rituals the eyerolls really get going. Why add abstraction to common sense?
Or maybe Scrum is really just an attempt to turn bad team members into good ones?
Good team members...
- Provide good estimates
- Cooperate to create clarity around requirements
- Work to divide big problems into small chunks
- Keep good track of their work in a shared format
Bad team members shun all of this and expect someone else to do it.
It also fits very well with feature factory shops: a story fits nicely into a single feature. God help you when you are trying to build a system from scratch with scrum overhead. Not everything is a story or a ticket. It's painful.
This one hurt, it's exactly what I spent the past 18 months doing - building a new system. Luckily my director was sympathetic but the Company loves Scrum and Metrics. Tried to change process unsuccessfully, so I quit to work somewhere saner.
Scrum is a specific implementation of some vague overarching concepts. Of course it's going to be prescriptive, that's the point. Else you're just doing "agile".
When you bring a prescriptive implementation, you can then leverage learnings from many orgs over many many years to handle all the edge cases instead of reinventing the wheel.
If you don't, or do "Scrum but not quite", then when things don't quite work out, you're on your own.
I'm no fan of Scrum, and rather use almost anything else, but that doesn't change that there's significant value in using systems that are mostly figured out and "work". Most of Scrum's bad rep comes from people who think they know better, tweak it to suit their needs, then realize they made a ton of holes in the system and their Frankenscrum doesn't really work. At that point you're better off just doing your own things. Which is what folks do, they abandon Scrum and do agile their way.
If you do "Scrum, exactly", then when things don't quite work out, being "on your own" is the best case scenario. Worst case is that someone yells at you and blames you because Scrum Objectively Works so it must be your fault.
I see no reason to believe that Scrum is a tightly tuned machine that must be precisely run to work at all, and any deviation from it makes it fall apart. In fact, if that is the case for Scrum I'd consider it a fatal objection. I don't believe the effectiveness landscape for project management techniques is shaped like that, I don't believe that the effectiveness landscape is a black pit everywhere just around Scrum only for a sudden spike of effectiveness to exist precisely where Scrum is located, and if it were shaped like that, I don't believe in the capability of anyone to have found and proved that spike. Since the only practical algorithm to explore this landscape is gradient descent, anyone carefully and thoughtfully exploring this landscape should never have found Scrum.
Or, to put it in less mathematical language, the idea that Scrum is super effective but if you deviate from it just a bit it all falls apart is complete garbage.
Do real agile, all the time. Scrum's only useful for raiding for ideas, and I'm not particularly impressed with it for that purpose, either. But it's not quite literally bereft of good ideas. I wouldn't give its ideas any particular credence for coming from "Scrum!", through. I don't see a lot of evidence that it is specially deserving of respect. It seems to work for some people, yes, I don't deny that, but the rate at which it works for people is sufficiently low that I don't think it has any sort of special claim.
The brilliant thing about Scrum marketing is it's pitched and talked about as infallible. If it didn't work, it's because you didn't do it right. If Scrum worked for you, you must've done it right.
> If you don't, or do "Scrum but not quite", then when things don't quite work out, you're on your own.
So, if you do exactly as Scrum prescribes and do not find success, in what way aren't you "on your own"?
OK, but scrum is supposed to be a way of doing agile. And "we're going to do agile by a rigidly defined process" is an oxymoron. If your process isn't one of the knobs you can turn, then you aren't actually agile.
>Most of Scrum's bad rep comes from people who think they know better, tweak it to suit their needs, then realize they made a ton of holes in the system and their Frankenscrum doesn't really work.
I remember when Scrum came out. It's a very specific method for a very specific company type that was sold to work with any company. Before scrum, each company kinda figured out their own processes based on their size, team composition, output requirements, and their risk tolerance. Ticket systems existed before scrum, feedback loops existed before scrum, bug tracking existed before scrum, prioritization existed before scrum. Scrum just took all the things that already existed and put them in a very specific and somewhat restrictive process. It was eye candy for the execs who had no idea how their department worked, it was a cash cow for the consultants selling it. It's ok if you don't have anything else or you're dealing with high turnover or something like that, but if you have a mature department already, it's probably more restrictive than not.
Scrum is like a global variable or a goto statement. If used carefully it could provide benefit but is often thought negatively. Used by untrained or junior team members and projects spiral. Senior members shy away because of experience.
People say that about communism too. I'm not open to debate any of the tankies I know are on HN, but if a paradigm brings utopia if implemented properly, and misery otherwise, and there have been no known utopia-yielding instances of the paradigm despite repeated attempts, it's time to consider that maybe misery is inherent to the paradigm.
I thought one of the interesting points in the article was that Scrum gives a team some breathing room when there are many "stakeholders" in the organization wanting feedback, updates on progress, and to frequently change requirements.
The Sprint gives a defined time period during which the team is allowed to work uninterrupted by these kinds of requests, with the updates, feedback, change requests etc. taking place at the Sprint boundaries.
A "scrum course" is to Scrum what a code boot camp is to programming. You're going to learn basics but you won't have the depth of knowledge to handle complexity in any form, nor how to answer questions about Scrum that inevitably are asked by leadership. There's a reason the Scrum leader (or master) role exists. It's supposed to be the person who has a depth of knowledge that goes beyond a simple "scrum course" and can guide an organization when complexity arises. Organizations rationalize why they don't need to hire someone into this role because a Scrum leader isn't a producing role. And they're right that Scrum leader isn't a producing role, it's a role that's supposed to make producing roles more efficient, a force multiplying role.
I suspect the prescriptivism and detail have one end goal and that is for someone that has no idea how software is done to follow the procedures. It also turns the process into an "almost predictable process" for the higher-ups to see turned into a graph in some ppt. You also have to deal with people who needs to be told which shoe to put in first before they think the process is "confusing".
Same reason for PMP, it's to turn the procedure into "paint by numbers". Of course it rarely works that easily.
But of course you can't justify the multiple middle-managers and why can't the people at the bottom just "turn the wheel faster" without it so there's a bit of purpose in that.
> It also turns the process into an "almost predictable process" for the higher-ups to see turned into a graph in some ppt.
This is not just a scrum problem. Any agile process eventually reports to a layer of management that doesn't think in agile terms, and wants their PERT charts or whatever. The impedance mismatch at that boundary is one of the biggest difficulties with implementing agile.
The issue with all of this addition process, ceremony and meetings is work still needs to get done. Sadly the only time to do work is often outside of working hours since then, finally, the meetings and ceremony have ended.
I see enterprises commonly mess up the planning stage.
They take the waterfall approach, what do we need to get done by X to achieve goal Y. Then apply tasks/actions to get it done to people who are at a meeting. Following this step they shift over to scrum sprints, routines and measures to give management comfort on whether its track or not.
The alternate might be, what is the highest value items that we can achieve with this group of people.
Generally speaking, if the thing that is meant to help you get to value becomes more of a focus then you're in a spot of bother
I fully agree, but I feel you vastly underestimate the difficulty of having a team that more or less adheres to these few principles. In your average Fortune 500 corp, it's next to impossible to have it without prescribing. If scrum is just writing down common sense in a onepager, then that's actually useful stuff.
In my experience, junior developers like the rigid structure and senior developers would prefer more flexibility.
Companies that implement agile to the letter typically treat their developers like consultants. You're treated as a mindless drone that is supposed to work on tasks that were predefined for you. You might as well be outsourced.
I found that kanban-style works better imo. A prioritized backlog where you pick the most important task to get done makes for a more relaxed and friendly environment, compared to an environment with a rigid deadline every two weeks that everyone sprints towards. As long as there's progressed made towards the most important items, everybody is typically happy.
Every company I've worked at that followed some sort of rigid scrum process has suffered from burnout and general failure in one form or another
It treats developers like consultants because it's really designed for agencies working on one-off short-burst projects ( this is the only setting I've seen it have a positive effect )
by nature it just chews people up if it becomes a day-to-day practice, the whole process revolves around the assumption that there's lack of trust and team cohesion
i've been a proponent of todo and task lists for years now. not one ounce of it feels like planning/prioritizing poker. i just throw a task on my list. i gauge it's priority by how pressing it is at that time. if it's super important, i'll probably make a calendar item for it as well.
do you know why i do this? cause i'm lazy. i can't be bothered to remember things or talk to people again so i do the one thing people often forget we can do: write it down. know how many times i've annoyed my lead by having to re-ask questions for a typical project? 0. cause i ask it once and write it down. it literally takes no time at all. it saves on having to do more meetings down the road because i have it all documented.
> For complex projects that span several teams across different offices and time zones, leading such a project is a full-time job for an engineer. Big Tech pulls in Technical Project Managers (TPMs) to manage these complex, and often strategic projects, taking the load off engineers.
> Dedicated Program Managers or Project Managers still exist within Big Tech. They are typically tied to external-facing commitments and customers – such as a Program Manager for the Apple partnership – or to long-running initiatives, like a compliance program. Similar to how TPMs are not allocated to a single engineering team, these Program Managers or Product Managers also don’t tend to have an engineering team, but they work across many teams instead.
> Engineers are encouraged to interact with the rest of the business and build relationships with non-engineers. In contrast, traditional companies often make it impossible for developers to interact with the rest of the business.
In my experience “traditional companies” will often have a bunch of people in cushy “gatekeeping“ jobs whose main function is basically forwarding emails back and forth between devs and the business. If you try to get direct access to the business usually the business is quite happy but the gatekeepers get very upset.
I work in a "traditional company" and the gatekeepers were installed to keep developers from going insane. When we have too much information back and forth between business and engineering, the loudest complaints from the business side (where the $$$ comes from today and tomorrow) drowns out the team's and department's internal goals, which are usually much longer term (meaning the $$$ is in months or years, not next week).
I believe this is why the author noticed that certain types of companies had engineers say the product owner was one of the reasons they're more satisfied. From when I started at my role, my team went about 2 years without one, and then within months of having one, we have been much more productive and have managed to create much more immediate and future value for the company.
The trick big tech uses to solve this is to not just pay extra for above average engineering talent, they pay extra for above average talent in all areas. So the people you talk to are almost always pretty reasonable and understanding, they want things done and complains but they don't ask for the impossible or unreasonable.
This is because businesses chronically underinvest in developer/engineering resources.
Developers tend to be viewed as something that is not "core" to the business, and generally only necessary on a project-by-project basis. So, projects are initiated, resource needs identified, and, since nobody wants to hire a bunch of full-time staff, most likely a consulting firm or off-the-shelf product is selected and configured.
The downside is now you have a thing that needs to be maintained, and probably it will be maintained by a limited pool of "in house experts", who are also responsible for just about everything else.
The net result is that you've got this centralized resource that is under provisioned and, well dear reader, what does your training as a systems engineer tells you will happen with a centralized resource that is under provisioned? Contention? Rising latencies and queue lengths? Disastrous to recover from failures?
The problem arises when the gatekeeper either no longer understands or no longer cares why their position exists. Then they just become an obstacle to the very communication they are supposed to be there to facilitate.
I've also seen some instance where gatekeeper were pretty effective at filtering users demands because some of those requests were too dumb and the "paying" users were used to have everything they wanted, and because they "paid" the dev department, "they had to do everything they wanted".
Like asking for a 6months dev work to help them save 1 hour annually on an annoying task they had to do.
My experience has been the exact opposite, if the developers understand what the business is trying to accomplish and what the incentives are then they are in a much better position to prioritize and build the right thing. Every single time I’ve seen 6 months of work on a useless or low value feature it has been the result of the dev team getting requests via some PM telephone game.
> Like asking for a 6months dev work to help them save 1 hour annually on an annoying task they had to do.
I see this as a complaint a lot, but... in a private company, they're the ones writing the checks. So if they want to spend hundreds of thousands of dollars to save an hour, that's their prerogative. It's certainly our obligation to point out the cost (including ongoing maintenance) but again in a private company you don't really have the option of saying "no" except with your feet.
I have seen it more often that gatekeepers filtered user demands based on their own knowledge and not on technical feasibility or effort. So you are told that a user needs a certain thing in a certain way but when you talk directly to the user you learn that the user actually had a different need which you can fulfill in an easier way than the gatekeeper thought possible.
In general I think there is a huge advantage if developers know first hand how their product is being used and not through gatekeepers.
Even when the possible goals are identified, someone has to prioritize them at some point, since there are always more goals you could achieve than goals you will achieve. To prioritize, you need to know both the benefit of a goal (which is really a probability distribution, not a number) and its cost (which is notoriously a wide probability distribution before you have done it). Sometimes this involves trading off the needs of different "goal donors"; in XP these all filter through a single "goal donor", confusingly called the "customer", who decides how to order the cards in the box once they're estimated. The goal donor (who may or may not be the gold owner, another confusing name) can reorder the cards at the beginning of each iteration, either because new information has appeared about the benefits, about the costs, or about the possible goals.
It sounds like what you're describing is the lack of such prioritization. It isn't necessary to keep the developers ignorant of new user "demands" in order to prioritize them; they just need to be empowered to follow the priorities the team has chosen instead of accommodating every demand.
Sometimes it's easier to accommodate a demand than to write up a card and estimate it, though. Sometimes a bug fix or layout tweak is obvious enough that doing it takes only a minute or two; then, it's just a question of process overhead whether the actual cost of doing it is five minutes or five hours: potentially multiple forwarded email round trips, a fresh checkout, pair programming or other code review, compilation time, test suites, commit comments, merge requests.
Usually, in my experience, if you have extreme overhead, most of those changes never get requested, because they don't get prioritized the way they would with the order-of-magnitude lower cost a lightweight process can provide. The result is that they never get done, so the product is full of easily observable minor problems, which is experienced as shoddiness.
What a utopia this movie portrays! Individual cubicles, administrative assistants for senior staff, and the protagonist has only been asked to work over a single weekend.
Yeah, I learned the hard way that one of the worst things you can say at a megacorporation is "this manager is just creating work to justify their existence in the company". In my case, it was directly applied to a specific manager (who heard me say it), and it led to me being lectured and yelled at and told that it was "unprofessional" talk (which to be fair it kind of was).
At the last large traditional place I was at it seemed a lot like the upper management types had put these gatekeepers in place so they had people that would pander to them. The amount of times one of them told me they couldn't tell their boss some bad news for risk of getting fired or chewed out, but wouldn't let me go and tell them the truth was mad.
From what I could tell no-one was firing engineers because it was too expensive and we didn't really care since we could get more work within a few hours, and the "bosses" didn't like the lack of power they had in that dynamic.
The best arrangement is to have business report to business and engineers report to IT, but have them communicate directly. This was they can't be pressured by business into short term tasks, because they are on the same level and not just mere subordinates of business folks.
In traditional (not engineer-first) companies, engineers are subordinates of PMs or business directly without their own agenda, so they just accept the fate and become a feature factory for the company.
> In my experience “traditional companies” will often have a bunch of people in cushy “gatekeeping“ jobs whose main function is basically forwarding emails back and forth between devs and the business. If you try to get direct access to the business usually the business is quite happy but the gatekeepers get very upset.
“But I’ve got people skills, dammit!”—Tom Smykowski
Constructive / progressive organizations can be built or transformed into, where collaborative knowledge-work happens at all levels.
Scrum is a parody and pretty much anti-agile.
Traditional organizations are driven by the cost-accounting mindset that creates gate-keepers and makes it impossible to share a common purpose, let alone collaborate across teams, units or vertically.
My current company is like this. I work directly with the business people anyway. When anyone says anything I just point them to my output, quality, and the feedback from the business people - shuts them up every time.
I’m one of these hypothetical gatekeepers and would be thrilled if a dev could successfully take this off my plate. Just prioritizing the incoming requests from stakeholders is a full-time job.
I really want to say this: SAFe is an awful process and a trend that will hopefully go the way of Unified Process/RUP. I won't go into it, but it's largely created and popularized by a vendor to sell their software. It is poison and exists to keep its practitioners employed. It attracts the highest-ego PMs like moths.
I find it interesting that they author references Skype circa 2012. It sounds like classic "uppercase A" agile: they reframe success as shipping and hitting other invented agile milestones, while masking shipping lousy and incomplete product that is not succeeding in the market. That was right around the time Skype started being bad. It may succeed on some metrics because MSFT started bundling it, but anyone that actively used it at that time should know what I mean.
The idea of an "agile enterprise" is intrinsically absurd. Teams are agile, not companies, and teams and products should be loosely coupled. That's why the big tech companies in this link have converged to similar answers to this problem (they are not "agile enterprises" but give teams some latitude to solve their own problems, and rather focus on results). Kanban is better in most ways for most teams.
Also, Tuckman is a silly model that is only popular because it rhymes.
PS: Strawberry-Jam-O-Meter and a Wrong-Order-O-Meter and their descriptions could hardly be more cringe inducing. Skype should be a part of the curriculum looking at less than ideal acquisitions and post-acquisition execution. https://www.wired.co.uk/article/skype-coronavirus-pandemic has is a reasonable overview if you're not familiar. They lost the consumer market and failed at enterprise (see Teams) and Teams in turn essentially failed in the general market- where most places that were free to do so went with Slack.
As a Dev, I loved SAFE. It changed everything about how our program operated to the point our delivery became extremely predictable and we still had every 9th and 10th week to tinker on new ideas or do refactoring and cleanup where we wanted. That program purred like nothing else I've ever been a part of. Senior leaders sat with devs, started talking to everyone about their priorities - people we had never seen before we started doing PI events. Antagonism dropped. We went from not being trusted to deploy during an annual heavy use period to being totally trusted to deploy and given additional contracts for maintenance. And this was with the exact same people who had been there. We just weren't working very well before we got into SAFe.
I think one of the keys to this was the buyin everyone had. It wasn't totally consistent at the beginning, but over time everyone got on board, we did trainings, actually incorporated feedback consistently.
I hear SAFe hate all the time, and when I ask how things went, inevitably it turns out they never actually did SAFe. Somebody made them email a 10 week plan and used the acronym and that was it. If you're gonna do SAFe, do SAFe.
“Senior leaders sat with devs, started talking to everyone about their priorities - people we had never seen before we started doing PI events”
Pretty much every process will work successfully if everybody participates in good faith. I don’t think SAFe has special properties that people honestly work together. For example in my company it would just create a new bureaucratic nightmare where we would hire even more managers, project managers and consultants while senior leadership still would never talk to the lower ranks.
As with all "Agile Frameworks", they are marketed as "If it worked it's because you did it right, and if it didn't work it's because you didn't do it right".
Is something actually valuable if it is A.) Inflexible and B.) Rarely goes well?
These things are tools to be used. If you use focus on the tool and not the end user, things will go badly. Typically you will see teams that are very hyper focused on some particular metric (time, points, stories churned, etc). Yet not focusing on 'how do I get my customer what they need'. These tools help devs break down the tasks and tell the end users 'hey we only have this amount of time so focus!' If they become about metrics or just randomly skip steps that depend on each other, you will fail.
You'd have to trust me, but I know SAFe well in theory and practice. I still don't like it, but I am glad you've had a good experience with it. It may be that it's the right fit for some companies. It is definitely better than organizational dysfunction. It sounds like your environment was dysfunctional and bringing SAFe in fixed that, at least.
> The idea an "agile enterprise" is intrinsically absurd. Teams are agile not companies
I’m really not sure what you are basing this on. Agile, as I’m familiar with it is framed in terms of lean management which is a well established approach to running business, exemplified by Toyota. Now you can debate the suitabilities of this and the effectiveness til the cows come home, just as you can with agile and scrum etc but it isn’t accurate to say that there aren’t a lot of businesses that aspire to the lean approach.
I don't think it's fair to say that http://agilemanifesto.org/ is "framed in terms of lean management", or indeed management at all. While there's nothing making it impossible to organize a company along those lines, you may be interested in https://news.ycombinator.com/item?id=28677886 where I explain why the Agile Manifesto values are deeply opposed to many established company value systems.
My sole experience in Big Tech consists of Facebook and the post more or less matches what I saw there. It seems to me, though, that the author views "no process" from a very positive lens, with no discussion of negatives. Like how at FB so many teams use spreadsheets to track their work (sometimes multiple spreadsheets per team, sometimes no tracking at all). There is some internal tooling, which is quite basic and at the time I was there it got deprecated without the replacement being finished yet. Whatever you say about JIRA, it can handle complex projects way better than a spreadsheet.
My biggest issue with the whole thing, however, boiled down to the set of incentives that centered around individual performance. You see, the teams weren't _teams_ per se, but a collection of individuals working on their own projects, sometimes related to those of other teammates, sometimes not. A team-oriented process like Scrum or Kanban cannot survive in an environment where every person is optimizing every decision for their advancement/bonus/whatever. There's some exaggeration here, but I definitely saw a lot of this at FB. Having come from a company with high-functioning Scrum and Kanban teams that worked together to achieve a common goal, I'd choose that any day, JIRA or not.
This is obviously a single example and many of the issues were Facebook-specific. But I bet there are other, not so positive, sides to the "no process" story at the rest of the companies.
Note I'm not claiming that the Agile processes are by definition good. I've seen plenty of bad implementations as well. At the end of the day, every group of humans is different and may require a different process (or no process at all) to maximize their success. What I'm suspicious of is the "every team picks their own process" claim, having seen company-set norms exerting enough force to make deviations from the common pattern rather painful and counter-cultural.
Funny that you mention spreadsheets. When I worked at Microsoft my entire business unit (multiple thousands of engineers, managers, PMs) exclusively used Excel for project management. Clean UI, filters, data rules, conditional formatting, validations, pivot tables..it was the absolute best. And with Excel data tools it was all hooked up to a central database (TFS) for live sync/updates.
Biggest difference between big tech companies and smaller companies is the sense of urgency to ship something to market and the time scale for that urgency. Bigger companies have lesser pressure to ship things too early and have slower (larger) time scales for product release cycles.
Both in enterprise space or in consumer space, smaller companies are on a much more rushed timeline, for varied reasons including but not limited to financial situation of the company.
Bigger companies can afford to build more slowly. This affects how the company plans and executes as well as rewards performance.
In a smaller company, when a complex thing has to be shipped on a shorter time scale, a lot of divide and conquer and quick coordination across large number of contributors is required. This is a necessity.
In a larger company, deep complex things are built by very small teams or just individuals over a relatively prolonged time. Individual engineers prefer to keep chiseling away at a particular problem until they can showcase a significant impact with high difficulty/complexity of the problem/solution. That's the consequence of individualistic performance measurement culture.
Both cultures have pros/cons and there are rotten extremes in both.
I had the same experience at AWS. A team of siloed engineers working on projects for the same product, with very little collaboration. Projects were tracked in spreadsheets. Time estimates were created out of thin air to meet the desired (impossible) deadline.
This kind of mass delusion has been pretty much de rigueur my entire career (decades):
Software is typically quite hard and mostly unknown at the beginning of a project. Most of the hard work is figuring out the things that weren't known. It's a learning/discovery experience. It's essentially impossible to predict how long that activity will take. The further out in time you consider, the less likely you'll have much of any clue about the subtasks to be done. And of course in the meantime the participants likely aren't even working close to 50% of their time on the new project -- instead they're fixing the bugs and technical debt in the last project.
And yet, the "stakeholders" simply wouldn't accept any narrative like the real one (we kind of have an idea how to do this but we're going to figure it out as we go and it'll be difficult and unpredictable). They'd go hire another bunch of folks who are willing to salute the flag. So instead we pretend that what we're doing is predicable and plannable, like building a bridge that's a bit longer or shorter than the last 10 bridges that we built.
The stakeholders probably have a pretty good idea that the developers are making it up as they go. But everyone behaves as if the reactor isn't on fire.
Very interesting, do you have any examples of how FB manages long term (2+ years out) project that involves 100+ Engineers? Are those 100+ engineers all "individuals working on their own project"?
I worked at FB for a while, and the problem with long term projects were that they were long term. In FB you need twice a year to make self review that shows what kind of impact you created during last 6 months (and based on this you are rated, raises, refreshers, etc). In long term projects impact might be only at the end of project, which leaves you "impactless" for a long-long time. Because of this people didn't really want to join any long term projects.
While I was there management was trying to resolve this situation and transmit message that long term projects are impactfull and important (and strategic to company), yet they couldn't answer question of how impact should be calculated every 6 months.
Maybe by now they came up with some formula or something
+1 to everything simplyaccont said. Long term projects were a tough beast to manage given the short-term incentives. Usually those got done by breaking them up into milestones and hitting those. That said, my general impression (as a first-level manager who sat in on calibrations) was that unless you move some serious metrics in those milestones, it would be difficult to exceed expectations and much of the upper management encouragement for long-term projects was mostly empty air due to the 6-month performance cycle.
That said, large cross-org projects certainly do exist. To answer your specific question, there would normally be some sort of a lead on the whole project, tech lead or PM lead or, often, a pair of those. They would meet regularly with leads of various sub-areas, organized similarly, and ensure things line up properly. Now repeat recursively until you get down to team level, where there might be a tech lead, or perhaps just a senior engineer working with a few non-seniors on their portion of the larger initiative. At this point this would get broken down into individual projects that each person owns and is accountable for. Tech lead may or may not contribute code to this project, they (and their team at large) might be involved in a bunch of parallel initiatives that often don't have much to do with each other, other than the product scope the team owns. Things like daily stand-ups don't work when everybody has their own work stream (and often multiple streams at that).
Hope this clarifies. The setup works for certain types of personalities, but I found it to be a very individualistic culture that I didn't particularly enjoy.
At Shopify, we tend to do whatever our engineers want in this regard. My team meets weekly and looks at a kanban project board. If we need to adjust, we have retros, etc and change the process. We have the autonomy.
In a past life you would be told Agile meant “self organizing teams”. But in practice that was only allowed in a narrow definition of change under the prescribed process being foisted on teams from above.
IMO while you need some consistency to get alignment on goals at a high level and coarse quarter-level goals, at the team level you can more or less let the team decide and then judge them on their effectiveness.
Odd how so many companies want to do “what [successful tech co] does”. Yet those companies innovate their own processes.
Nice to see big companies working like this. I wish more places would understand that different approaches work for different people, teams, products, technologies and contexts. There is no one true way, and most attempts to impose one tend to create something that is bigger and more complex than any single team needs. It's like the human equivalent of a code library that is trying to solve too many problems and so becomes an unweildy mess of config and options and meta-problems.
We (Bugsnag) are a relatively small engineering team, so have the advantage of low comms overhead, and we do have an overarching approach, but each of the teams works a bit differently. Even from project to project I'll adjust what makes sense based on complexity/risk/size.
I find this concept utterly baffling, but probably because I've never worked at this kind of org. I can see how letting engineers run their own process is great for engineering efficiency, but how do they know what to deliver and when?
My conjecture (please confirm or deny) is that these self-organizing teams are a result of and not a cause of big successful companies. You are probably iterating on a very well-understood and successful business model with a huge cushion for mistakes because you have some much revenue.
By contrast, I have mostly worked in consulting and non-tech orgs. If we don't show that we're spending their budget on high value features, we get layoffs. Hence we not only need very thorough clarity on what feature development will yield the greatest returns, but also deniability that we had good reason for doing what we were doing if it turns south.
I can't speak for Shopify, but in general you want teams that don't need anyone to tell them what to deliver and when because they can be trusted to figure that out for themselves and make a good call. That can't be done without having customer representation on the team (which you should anyway), and having engineers capable of taking a customer viewpoint. That is what "self-organising" should mean, but few organisations are mature enough to transition to it.
If you're in a situation where you need to show you're "spending their budget on high value features" that's a low-trust feature factory being treated as a cost centre by a remote client, not a value-producing unit setting its own terms.
One thing I learned a long time ago is that a "bad" process that is followed universally by everyone (dev, pjm, pm) will always out perform a "great" process with only token buy-in and constant exceptions.
I was there when Agile was invented. In my opinion, Scrum has always been the worst embodiment of a good idea.
In terms of content, teams of experienced developers have always worked in the spirit of Agile (of course there are exceptions). This informal understanding was and is superior to a formal horizontal Scrum implementation. For example, it preserves seniority and true accountability - two things that Scrum pretty systematically destroys in my experience.
Initially, I was hoping for additional solutions to problems in the vertical direction - management, customer relations, etc.... But that never materialized, at least in my environment. And since I've been in the industry for more than 20 years, that's not too little.
These days, mandatory Scrum is a contra-indicator for any project that crosses my path as a freelancer.
It seems to me that the industry's original sin with Agile was treating it as anything other than a model for managing a team of software consultants. There are certain types of internal product teams that can meaningfully emulate this paradigm, particularly in a B2B context where a tight feedback loop can be cultivated with customers. Chances are, though, that product teams, particularly in DTC businesses, don't have close enough relationships with their end users to be able to practice Agile as written.
I always viewed Scrum as training wheels. I've imposed it on teams who were dysfunctional as a way to get them on the rails. Hands and feet inside the car. Child safety locks engaged. It's a bit patronizing, but if you've ever worked with an unengaged team, it can be necessary. If you do it well, the team gets the feel for what agile delivery feels like and don't need the rituals to know what kind of touchpoints are actually required. Like the bottom of the Dreyfus model of skill acquisition. If you're "Big Tech" and have only hired the best and brightest and are working on enthralling problems, you tend to get people at the top of the pyramid who just run agile even when you don't tell them to.
I disagree with 2. Now, perhaps you disagree with 5. These were written in 2001 for problems in 2001. Now, some of these problems have been solved. Some of them are taken for granted today. However, we take them for granted in large part because a group of people got together and said, "we can do better."
I personally think it's time for another group (not the old agile luminaries but people with new ideas) to take a look at today's problems and take a fresh stab at it. Maybe it looks like "Plan-Build-Ship." But maybe it looks different.
But first, I think we need a clarifying question: What in the principles or manifesto do you disagree with?
Reading this, I'm struck by a thought: Are we the bad guys?
According to the article, what the big tech companies have in common is engineer-led products. It's not the besuited MBA's making product decisions, it's us, the engineers.
And the big tech companies are also united in having evil products. With the possible exception of Shopify and Datadog, every company on that list of "big tech" is doing things that actively harm society.
Cue the "are we the baddies?" meme [0]. If engineers are left to build products by ourselves, do we build things because we can and not because we should?
People who sign up to work on ad services for google or engagement for facebook have already self selected as willing to do morally dubious work in exchange for more money. There's no question that engineers do work that decreases society's utility.
I don't think following incentives makes someone bad though, it's only human nature, and of course there are plenty of people queued up to replace you. The system that creates those incentives might be bad, but it can be impossible to untangle where the incentives stem from.
Pay engineers to optimize a number and they will, that is all you need to do. In this case they told engineers to optimize the number of ads clicked and then the engineers self organized and did the rest.
Maybe evil is just more profitable than good because it externalizes its costs.
Creating a sports car, or paying someone else to do so, is a lot more expensive than just stealing one, if you can get away with it. Robbing a bank is cheaper than building a bank. If you can do this kind of thing at scale, well, to the extent that you only have to spend money on capturing value instead of both creating it and capturing it, you'll be vastly more profitable than the "suckers" you're capturing it from.
Same thing is true of Fecebutt: creating the mountains of data their users go to Fecebutt for (restaurant recommendations, family photos, thoughtful essays, sexy bikini shots, social-network data) took perhaps a trillion person-hours, but Fecebutt gained control over it at a cost of under a trillion dollars. Ballparking, they had to spend less than 5% of the cost of those assets to acquire control over them. Now it can leverage them to organize genocides, rig elections, and extort photos of government IDs and use them to out promiscuous women and closeted gay people—not to mention selling you tens of billions of dollars a year of stuff you don't need through advertising.
It's hard for positive-social-value companies like Shopify and Datadog to compete on salaries with that 20:1 value multiplier. The fact that they manage it at all is not only a testament to the enormous value they're producing but also the enormous destruction of value implicit in Facebook's business model.
From a management perspective, having everything reduced to a process and method is the ideal world, as no true knowledge about the actual work is needed. The weaker then understanding of the work, the stronger the desire to replace uncertainty with process.
However, no process can remove actual randomness (did anyone get the necessary ideas, for example) or uncertainty (is it even feasible, for instance).
That said, in larger - and I'd say mostly non-software companies - changing processes to things that are more inclusive, i.e. tech and the business talking directly to each other does help. And one way to sell that is under an agile/Scrum kind of construct. To me, seeing Scrum then more in non-tech/consultancy makes total sense.
Readit News
I went on a scrum course and the takeaway was basically that feedback is a big deal, and you should try to get some repeatedly and quickly. It's also common sense that you should have tasks written down somewhere, and that some of them are more important than others.
You certainly need to think about how long tasks will take, but there's no reason why you need to do planning poker, that just seems to be one among many ways to think about how long something might take. Tracking velocity is another one of these things that seems replaceable.
If you have a team of people that more or less adheres to a few principles, there's no reason you can't get things done.
My current job is the opposite. Some tasks take 15 minutes of discussion (no, they aren't complex tasks) with people debating whether it is worth 5 points or 8. It is just tiring and pointless. And retro - gawd, I hate those. There are all kinds of stupid shit (people using references from music, movies etc, trying to make it "fun" and "hip"). I can't bring other tasks into the sprint, even if I finished all my current tasks, without my manager's permission. And on and on.
I was thinking the other day why this is so painful and awkward. I realized that it all comes down to "metrics" - end of every sprint, my manager has to present it to his bosses, with pretty graphs describing "velocity" and other buzzwords. So he has to do all kinds of jugglery to appear competent to his bosses and not alienate the team at the same time.
All of this could be avoided by treating the team as adults, instead of trying to "processify" or quantify everything.
However hard we try, human beings can't be slotted neatly into buckets nor can they be precisely quantified. However hard we try, estimating software projects will never be an exact science.
A cause of this problem is when people are worried about what happens when they say "erm, I don't know how to do this cleanly" and so they want the "how" to be defined far far in advance. Solving this requires a mix of
A. Identifying those activities that will genuinely make people's lives easier if they have a process and designing those processes to be meaningful and low-burden. Those activities will vary based on team members individual peeves and affinities.
B. Creating clear lines of communication for how and whom to ask for help. This often means more clear naming of responsibilities.
C. Ensuring there is enough slack time for people to be able to help each other out.
D. Creating trust in the team that asking for help won't lead people to question if you are fit to do your job.
> quantify everything
Many times, this is the https://en.wikipedia.org/wiki/McNamara_fallacy
You've discovered the secret of Agile in the corporate workplace: that the key takeaways, as far as the enterprise is concerned, are not finding better ways to develop software and better customer-developer relations. It's all about trackability, measurement, and metrics, because everything is. Trackability and measurement enable key decision makers to make accurate budgeting and execution plans and there is literally nothing else for key decision makers. Therefore, it makes less of a difference what you output than that it was properly planned for, tracked, and measured and that it hits organizational KPIs. That's why nobody cares that Scrum is a giant productivity suck. Code could be written faster, but that's not writing it properly.
Agile in the enterprise is a game of Mornington Crescent. The goal is not to foster the things advocated in the Agile Manifesto. It's to make it look like the company is fostering those things, while actually promoting the same Taylorist values corporations have always loved (and workers hated).
I have do it as a consultant. I have taken a project on life support that they were gonna cancel, regardless of our performance, and resurrected it so hard they actually decided to keep it. We changed their minds
The most effective tool was retros. I dislike agile in all other aspects, and do not use story points. Retros are the best bit! It's the core part of the learning loop.
I learnt retros from Google. Big tech does retros. Its honestly magic when done well.
I'm baffled by this behavior. If you know it is the next most important thing, why do you care? What would it change in your behavior if it is a 5 vs and 8? If you are looking at a task that you would choose not to do if it were an 8 but choose to do if it were a 5, then you probably look for something that is more important to work on.
I think you are right that much of that is driven by managers looking for metrics, but unless they understand what the metrics mean it is pointless.
Then they decided they needed the metrics on everything, so they switched to JIRA, started doing retros, setting strict points on tasks(reprimanded in retros if you messed up), using burndown charts to reprimand even more, and giving the product manager the power to dictate what I work on and in what order.
It went from being a great company to work at, to a company I ran away from. I have half a mind to send this thread over to them.
That was my last gig. The whole organization eventually just collapsed under the increasing load of being "Agile".
This is a thing that's pretty key to Scrum: velocity can't be used to compare teams. It is easy to misuse though. I would start every meeting I were in with "these points measures cannot be used to measure performance between teams."
One of the worst parts of scrum in my opinion. Even if it's a "quick" 15 minutes (which in my experience it rarely ever is), the forced context switch ends up wasting more than 15 minutes of productive time every day.
This is exactly how I've seen it run with success at several different companies (including how I run it).
In my mind, the most important value of Scrum is having a cadence to give people reasonable timeframes to think in AND ensure that a variety of different conversations happen frequently enough (discovery, planning, prioritization, execution).
----
> And retro - gawd, I hate those.
It sounds like you hate these because you aren't actually empowered to make meaningful change within your team.
We've found retros are one of our most important rituals. They help us identify risks, process, and team issues; often while they're still small. We quickly work those in.
If you're not personally responsible for deadlines on the project, it could seem pointless. But the difference might mean pushing the commitment for a feature out two weeks, which in a commercial project could be a big deal. Planning is hard: you've got to try to estimate something with incomplete information, and then reconcile differing opinions. But it's definitely not pointless.
Velocity is probably one of the most misunderstood aspects of scrum. It's a key metric for long-term planning, but it's not intended to be manageable. It's also unique to the team, and not intended to be compared between teams. Many managers are not used to a metric that they don't manage, and that causes a lot (maybe most) of the bad experiences people have with poorly practiced scrum.
Having a strict framework à la Scrum is very helpful for new developpers or new teams, where they don't yet have their marks and need to get a feel of what agility feels like. Being explained principles is not enough to know how to apply them: Scrum is not a bad starting point to be in the right-ish track without really knowing what you're doing. As you gain experience, it's natural to want to shake off constraints, that's Ha and Ri
It's not like FAANG isn't hiring boatloads of new grads every year. Why don't those people need scrum to get on the right track, but half the rest of the industry seems to?
Maybe people are tired of the nonsense that systems like Scrum bring with them? Even the name is a bit silly. And when you start naming roles and inundating people with rituals the eyerolls really get going. Why add abstraction to common sense?
Or maybe Scrum is really just an attempt to turn bad team members into good ones?
Good team members...
- Provide good estimates
- Cooperate to create clarity around requirements
- Work to divide big problems into small chunks
- Keep good track of their work in a shared format
Bad team members shun all of this and expect someone else to do it.
When you bring a prescriptive implementation, you can then leverage learnings from many orgs over many many years to handle all the edge cases instead of reinventing the wheel.
If you don't, or do "Scrum but not quite", then when things don't quite work out, you're on your own.
I'm no fan of Scrum, and rather use almost anything else, but that doesn't change that there's significant value in using systems that are mostly figured out and "work". Most of Scrum's bad rep comes from people who think they know better, tweak it to suit their needs, then realize they made a ton of holes in the system and their Frankenscrum doesn't really work. At that point you're better off just doing your own things. Which is what folks do, they abandon Scrum and do agile their way.
I see no reason to believe that Scrum is a tightly tuned machine that must be precisely run to work at all, and any deviation from it makes it fall apart. In fact, if that is the case for Scrum I'd consider it a fatal objection. I don't believe the effectiveness landscape for project management techniques is shaped like that, I don't believe that the effectiveness landscape is a black pit everywhere just around Scrum only for a sudden spike of effectiveness to exist precisely where Scrum is located, and if it were shaped like that, I don't believe in the capability of anyone to have found and proved that spike. Since the only practical algorithm to explore this landscape is gradient descent, anyone carefully and thoughtfully exploring this landscape should never have found Scrum.
Or, to put it in less mathematical language, the idea that Scrum is super effective but if you deviate from it just a bit it all falls apart is complete garbage.
Do real agile, all the time. Scrum's only useful for raiding for ideas, and I'm not particularly impressed with it for that purpose, either. But it's not quite literally bereft of good ideas. I wouldn't give its ideas any particular credence for coming from "Scrum!", through. I don't see a lot of evidence that it is specially deserving of respect. It seems to work for some people, yes, I don't deny that, but the rate at which it works for people is sufficiently low that I don't think it has any sort of special claim.
> If you don't, or do "Scrum but not quite", then when things don't quite work out, you're on your own.
So, if you do exactly as Scrum prescribes and do not find success, in what way aren't you "on your own"?
I remember when Scrum came out. It's a very specific method for a very specific company type that was sold to work with any company. Before scrum, each company kinda figured out their own processes based on their size, team composition, output requirements, and their risk tolerance. Ticket systems existed before scrum, feedback loops existed before scrum, bug tracking existed before scrum, prioritization existed before scrum. Scrum just took all the things that already existed and put them in a very specific and somewhat restrictive process. It was eye candy for the execs who had no idea how their department worked, it was a cash cow for the consultants selling it. It's ok if you don't have anything else or you're dealing with high turnover or something like that, but if you have a mature department already, it's probably more restrictive than not.
The Sprint gives a defined time period during which the team is allowed to work uninterrupted by these kinds of requests, with the updates, feedback, change requests etc. taking place at the Sprint boundaries.
Same reason for PMP, it's to turn the procedure into "paint by numbers". Of course it rarely works that easily.
But of course you can't justify the multiple middle-managers and why can't the people at the bottom just "turn the wheel faster" without it so there's a bit of purpose in that.
This is not just a scrum problem. Any agile process eventually reports to a layer of management that doesn't think in agile terms, and wants their PERT charts or whatever. The impedance mismatch at that boundary is one of the biggest difficulties with implementing agile.
They take the waterfall approach, what do we need to get done by X to achieve goal Y. Then apply tasks/actions to get it done to people who are at a meeting. Following this step they shift over to scrum sprints, routines and measures to give management comfort on whether its track or not.
The alternate might be, what is the highest value items that we can achieve with this group of people.
Generally speaking, if the thing that is meant to help you get to value becomes more of a focus then you're in a spot of bother
Companies that implement agile to the letter typically treat their developers like consultants. You're treated as a mindless drone that is supposed to work on tasks that were predefined for you. You might as well be outsourced.
I found that kanban-style works better imo. A prioritized backlog where you pick the most important task to get done makes for a more relaxed and friendly environment, compared to an environment with a rigid deadline every two weeks that everyone sprints towards. As long as there's progressed made towards the most important items, everybody is typically happy.
It treats developers like consultants because it's really designed for agencies working on one-off short-burst projects ( this is the only setting I've seen it have a positive effect )
by nature it just chews people up if it becomes a day-to-day practice, the whole process revolves around the assumption that there's lack of trust and team cohesion
do you know why i do this? cause i'm lazy. i can't be bothered to remember things or talk to people again so i do the one thing people often forget we can do: write it down. know how many times i've annoyed my lead by having to re-ask questions for a typical project? 0. cause i ask it once and write it down. it literally takes no time at all. it saves on having to do more meetings down the road because i have it all documented.
Scrum is anti agile, it's basically processes over people.
Honestly I find it hilarious how agile people try to bring scrum into companies just so they can get a tiny bit of extra power.
> For complex projects that span several teams across different offices and time zones, leading such a project is a full-time job for an engineer. Big Tech pulls in Technical Project Managers (TPMs) to manage these complex, and often strategic projects, taking the load off engineers.
> Dedicated Program Managers or Project Managers still exist within Big Tech. They are typically tied to external-facing commitments and customers – such as a Program Manager for the Apple partnership – or to long-running initiatives, like a compliance program. Similar to how TPMs are not allocated to a single engineering team, these Program Managers or Product Managers also don’t tend to have an engineering team, but they work across many teams instead.
The author obtained first party data backing up what he wrote. You present nothing.
In my experience “traditional companies” will often have a bunch of people in cushy “gatekeeping“ jobs whose main function is basically forwarding emails back and forth between devs and the business. If you try to get direct access to the business usually the business is quite happy but the gatekeepers get very upset.
I believe this is why the author noticed that certain types of companies had engineers say the product owner was one of the reasons they're more satisfied. From when I started at my role, my team went about 2 years without one, and then within months of having one, we have been much more productive and have managed to create much more immediate and future value for the company.
Developers tend to be viewed as something that is not "core" to the business, and generally only necessary on a project-by-project basis. So, projects are initiated, resource needs identified, and, since nobody wants to hire a bunch of full-time staff, most likely a consulting firm or off-the-shelf product is selected and configured.
The downside is now you have a thing that needs to be maintained, and probably it will be maintained by a limited pool of "in house experts", who are also responsible for just about everything else.
The net result is that you've got this centralized resource that is under provisioned and, well dear reader, what does your training as a systems engineer tells you will happen with a centralized resource that is under provisioned? Contention? Rising latencies and queue lengths? Disastrous to recover from failures?
You betcha.
Like asking for a 6months dev work to help them save 1 hour annually on an annoying task they had to do.
I see this as a complaint a lot, but... in a private company, they're the ones writing the checks. So if they want to spend hundreds of thousands of dollars to save an hour, that's their prerogative. It's certainly our obligation to point out the cost (including ongoing maintenance) but again in a private company you don't really have the option of saying "no" except with your feet.
In general I think there is a huge advantage if developers know first hand how their product is being used and not through gatekeepers.
It sounds like what you're describing is the lack of such prioritization. It isn't necessary to keep the developers ignorant of new user "demands" in order to prioritize them; they just need to be empowered to follow the priorities the team has chosen instead of accommodating every demand.
Sometimes it's easier to accommodate a demand than to write up a card and estimate it, though. Sometimes a bug fix or layout tweak is obvious enough that doing it takes only a minute or two; then, it's just a question of process overhead whether the actual cost of doing it is five minutes or five hours: potentially multiple forwarded email round trips, a fresh checkout, pair programming or other code review, compilation time, test suites, commit comments, merge requests.
Usually, in my experience, if you have extreme overhead, most of those changes never get requested, because they don't get prioritized the way they would with the order-of-magnitude lower cost a lightweight process can provide. The result is that they never get done, so the product is full of easily observable minor problems, which is experienced as shoddiness.
https://www.youtube.com/watch?v=hNuu9CpdjIo
From what I could tell no-one was firing engineers because it was too expensive and we didn't really care since we could get more work within a few hours, and the "bosses" didn't like the lack of power they had in that dynamic.
In traditional (not engineer-first) companies, engineers are subordinates of PMs or business directly without their own agenda, so they just accept the fate and become a feature factory for the company.
“But I’ve got people skills, dammit!”—Tom Smykowski
Scrum is a parody and pretty much anti-agile.
Traditional organizations are driven by the cost-accounting mindset that creates gate-keepers and makes it impossible to share a common purpose, let alone collaborate across teams, units or vertically.
Deleted Comment
Deleted Comment
I find it interesting that they author references Skype circa 2012. It sounds like classic "uppercase A" agile: they reframe success as shipping and hitting other invented agile milestones, while masking shipping lousy and incomplete product that is not succeeding in the market. That was right around the time Skype started being bad. It may succeed on some metrics because MSFT started bundling it, but anyone that actively used it at that time should know what I mean.
The idea of an "agile enterprise" is intrinsically absurd. Teams are agile, not companies, and teams and products should be loosely coupled. That's why the big tech companies in this link have converged to similar answers to this problem (they are not "agile enterprises" but give teams some latitude to solve their own problems, and rather focus on results). Kanban is better in most ways for most teams.
Also, Tuckman is a silly model that is only popular because it rhymes.
PS: Strawberry-Jam-O-Meter and a Wrong-Order-O-Meter and their descriptions could hardly be more cringe inducing. Skype should be a part of the curriculum looking at less than ideal acquisitions and post-acquisition execution. https://www.wired.co.uk/article/skype-coronavirus-pandemic has is a reasonable overview if you're not familiar. They lost the consumer market and failed at enterprise (see Teams) and Teams in turn essentially failed in the general market- where most places that were free to do so went with Slack.
I think one of the keys to this was the buyin everyone had. It wasn't totally consistent at the beginning, but over time everyone got on board, we did trainings, actually incorporated feedback consistently.
I hear SAFe hate all the time, and when I ask how things went, inevitably it turns out they never actually did SAFe. Somebody made them email a 10 week plan and used the acronym and that was it. If you're gonna do SAFe, do SAFe.
Pretty much every process will work successfully if everybody participates in good faith. I don’t think SAFe has special properties that people honestly work together. For example in my company it would just create a new bureaucratic nightmare where we would hire even more managers, project managers and consultants while senior leadership still would never talk to the lower ranks.
We do PI planning from SAFe. We would get the last sprint of quarter for slack, improvements, they said.
Instead, we use it to clean up the mess created from waterfall scrum in the previous sprints.
Is something actually valuable if it is A.) Inflexible and B.) Rarely goes well?
I’m really not sure what you are basing this on. Agile, as I’m familiar with it is framed in terms of lean management which is a well established approach to running business, exemplified by Toyota. Now you can debate the suitabilities of this and the effectiveness til the cows come home, just as you can with agile and scrum etc but it isn’t accurate to say that there aren’t a lot of businesses that aspire to the lean approach.
My biggest issue with the whole thing, however, boiled down to the set of incentives that centered around individual performance. You see, the teams weren't _teams_ per se, but a collection of individuals working on their own projects, sometimes related to those of other teammates, sometimes not. A team-oriented process like Scrum or Kanban cannot survive in an environment where every person is optimizing every decision for their advancement/bonus/whatever. There's some exaggeration here, but I definitely saw a lot of this at FB. Having come from a company with high-functioning Scrum and Kanban teams that worked together to achieve a common goal, I'd choose that any day, JIRA or not.
This is obviously a single example and many of the issues were Facebook-specific. But I bet there are other, not so positive, sides to the "no process" story at the rest of the companies.
Note I'm not claiming that the Agile processes are by definition good. I've seen plenty of bad implementations as well. At the end of the day, every group of humans is different and may require a different process (or no process at all) to maximize their success. What I'm suspicious of is the "every team picks their own process" claim, having seen company-set norms exerting enough force to make deviations from the common pattern rather painful and counter-cultural.
Now I use Jira and hate every second of it.
Both in enterprise space or in consumer space, smaller companies are on a much more rushed timeline, for varied reasons including but not limited to financial situation of the company.
Bigger companies can afford to build more slowly. This affects how the company plans and executes as well as rewards performance.
In a smaller company, when a complex thing has to be shipped on a shorter time scale, a lot of divide and conquer and quick coordination across large number of contributors is required. This is a necessity.
In a larger company, deep complex things are built by very small teams or just individuals over a relatively prolonged time. Individual engineers prefer to keep chiseling away at a particular problem until they can showcase a significant impact with high difficulty/complexity of the problem/solution. That's the consequence of individualistic performance measurement culture.
Both cultures have pros/cons and there are rotten extremes in both.
Scrum/Agile tells you to split up a project into well defined tasks to be done simultaneously by multiple people.
That's counterproductive if, come perf, you need to show that you completed the project, and distinguish your contribution from others'.
Software is typically quite hard and mostly unknown at the beginning of a project. Most of the hard work is figuring out the things that weren't known. It's a learning/discovery experience. It's essentially impossible to predict how long that activity will take. The further out in time you consider, the less likely you'll have much of any clue about the subtasks to be done. And of course in the meantime the participants likely aren't even working close to 50% of their time on the new project -- instead they're fixing the bugs and technical debt in the last project.
And yet, the "stakeholders" simply wouldn't accept any narrative like the real one (we kind of have an idea how to do this but we're going to figure it out as we go and it'll be difficult and unpredictable). They'd go hire another bunch of folks who are willing to salute the flag. So instead we pretend that what we're doing is predicable and plannable, like building a bridge that's a bit longer or shorter than the last 10 bridges that we built.
The stakeholders probably have a pretty good idea that the developers are making it up as they go. But everyone behaves as if the reactor isn't on fire.
Frankly I have had a much better experience on teams that tracked work in spreadsheets than teams that tracked work in JIRA. Like it's not even close.
While I was there management was trying to resolve this situation and transmit message that long term projects are impactfull and important (and strategic to company), yet they couldn't answer question of how impact should be calculated every 6 months.
Maybe by now they came up with some formula or something
That said, large cross-org projects certainly do exist. To answer your specific question, there would normally be some sort of a lead on the whole project, tech lead or PM lead or, often, a pair of those. They would meet regularly with leads of various sub-areas, organized similarly, and ensure things line up properly. Now repeat recursively until you get down to team level, where there might be a tech lead, or perhaps just a senior engineer working with a few non-seniors on their portion of the larger initiative. At this point this would get broken down into individual projects that each person owns and is accountable for. Tech lead may or may not contribute code to this project, they (and their team at large) might be involved in a bunch of parallel initiatives that often don't have much to do with each other, other than the product scope the team owns. Things like daily stand-ups don't work when everybody has their own work stream (and often multiple streams at that).
Hope this clarifies. The setup works for certain types of personalities, but I found it to be a very individualistic culture that I didn't particularly enjoy.
In a past life you would be told Agile meant “self organizing teams”. But in practice that was only allowed in a narrow definition of change under the prescribed process being foisted on teams from above.
IMO while you need some consistency to get alignment on goals at a high level and coarse quarter-level goals, at the team level you can more or less let the team decide and then judge them on their effectiveness.
Odd how so many companies want to do “what [successful tech co] does”. Yet those companies innovate their own processes.
We (Bugsnag) are a relatively small engineering team, so have the advantage of low comms overhead, and we do have an overarching approach, but each of the teams works a bit differently. Even from project to project I'll adjust what makes sense based on complexity/risk/size.
My conjecture (please confirm or deny) is that these self-organizing teams are a result of and not a cause of big successful companies. You are probably iterating on a very well-understood and successful business model with a huge cushion for mistakes because you have some much revenue.
By contrast, I have mostly worked in consulting and non-tech orgs. If we don't show that we're spending their budget on high value features, we get layoffs. Hence we not only need very thorough clarity on what feature development will yield the greatest returns, but also deniability that we had good reason for doing what we were doing if it turns south.
If you're in a situation where you need to show you're "spending their budget on high value features" that's a low-trust feature factory being treated as a cost centre by a remote client, not a value-producing unit setting its own terms.
In terms of content, teams of experienced developers have always worked in the spirit of Agile (of course there are exceptions). This informal understanding was and is superior to a formal horizontal Scrum implementation. For example, it preserves seniority and true accountability - two things that Scrum pretty systematically destroys in my experience. Initially, I was hoping for additional solutions to problems in the vertical direction - management, customer relations, etc.... But that never materialized, at least in my environment. And since I've been in the industry for more than 20 years, that's not too little.
These days, mandatory Scrum is a contra-indicator for any project that crosses my path as a freelancer.
Yes! Although I don't agree that Agile is a good idea that scrum ruined.
Agile in 2021 means something different than Agile in 2002. Project Management was a different consideration 20 years ago.
Which of these do you disagree with? https://agilemanifesto.org/principles.html
I disagree with 2. Now, perhaps you disagree with 5. These were written in 2001 for problems in 2001. Now, some of these problems have been solved. Some of them are taken for granted today. However, we take them for granted in large part because a group of people got together and said, "we can do better."
I personally think it's time for another group (not the old agile luminaries but people with new ideas) to take a look at today's problems and take a fresh stab at it. Maybe it looks like "Plan-Build-Ship." But maybe it looks different.
But first, I think we need a clarifying question: What in the principles or manifesto do you disagree with?
Hmm. Scrum seems like a relatively good means of aligning two-parties with low-context.
I understand where you're coming from, a lot of freelance work these days is just code grinding for a short or maybe longer period of time.
My projects are not of this type. Most of the time they are a mixture of specialized mathematics, software design and implementation.
According to the article, what the big tech companies have in common is engineer-led products. It's not the besuited MBA's making product decisions, it's us, the engineers.
And the big tech companies are also united in having evil products. With the possible exception of Shopify and Datadog, every company on that list of "big tech" is doing things that actively harm society.
Cue the "are we the baddies?" meme [0]. If engineers are left to build products by ourselves, do we build things because we can and not because we should?
[0] from https://www.youtube.com/watch?v=uK-kWRAVmRU
I don't think following incentives makes someone bad though, it's only human nature, and of course there are plenty of people queued up to replace you. The system that creates those incentives might be bad, but it can be impossible to untangle where the incentives stem from.
Creating a sports car, or paying someone else to do so, is a lot more expensive than just stealing one, if you can get away with it. Robbing a bank is cheaper than building a bank. If you can do this kind of thing at scale, well, to the extent that you only have to spend money on capturing value instead of both creating it and capturing it, you'll be vastly more profitable than the "suckers" you're capturing it from.
Same thing is true of Fecebutt: creating the mountains of data their users go to Fecebutt for (restaurant recommendations, family photos, thoughtful essays, sexy bikini shots, social-network data) took perhaps a trillion person-hours, but Fecebutt gained control over it at a cost of under a trillion dollars. Ballparking, they had to spend less than 5% of the cost of those assets to acquire control over them. Now it can leverage them to organize genocides, rig elections, and extort photos of government IDs and use them to out promiscuous women and closeted gay people—not to mention selling you tens of billions of dollars a year of stuff you don't need through advertising.
It's hard for positive-social-value companies like Shopify and Datadog to compete on salaries with that 20:1 value multiplier. The fact that they manage it at all is not only a testament to the enormous value they're producing but also the enormous destruction of value implicit in Facebook's business model.
However, no process can remove actual randomness (did anyone get the necessary ideas, for example) or uncertainty (is it even feasible, for instance).
That said, in larger - and I'd say mostly non-software companies - changing processes to things that are more inclusive, i.e. tech and the business talking directly to each other does help. And one way to sell that is under an agile/Scrum kind of construct. To me, seeing Scrum then more in non-tech/consultancy makes total sense.