I added up all of the time we were spending in Scrum-related activities at a recent job. The company hired a lot of project and program managers who were pulling everyone into everyone meeting.
I presented the number of hours (meetings multiplied by engineering participants) to our VP and he insisted I must be wrong. He insisted there was no possible way we could be spending that much time doing Scrum things and that I must be exaggerating or lying. He then fell back to a lecture about how Scrum is an industry standard and how it's more efficient than alternatives.
Really opened my eyes to the disconnect between Scrum mythology and Scrum in practice. The amount of time lost to doing Scrum things was so out of control that some people had fewer than 3-4 hours per day to actually work.
Of course, the Scrum proponents will rush in and tell me that we were doing it wrong or that it's not truly Scrum if it's helping more than hurting, but these people were highly trained in the ways of Scrum and Agile and pointed to various Scrum and Agile books and certifications to defend their ways.
OTOH, I have been on very small teams where Scrum was implemented with low overhead, but those teams were filled with efficient people who would have been productive without formal methodologies either way.
This is one of the things I've added to me repertoire when I interview with teams: I always ask how often they meet and how they structure their meetings. Big red flag is there is a daily all hands (yes, I've seen this in a 16 person startup)
I think it's emblematic of a few things about the founder/cofounder/lead: 1) they are an egomaniac and just needs to see everyone reporting in, 2) they don't trust their teams because they need to have daily all-hands status updates, 3) they're not connected to their teams' work; there is no visibility into what's getting shipped, 4) there's a strong correlation with micromanagement.
Learned this through a few mistakes joining teams where the founder/lead insisted on frequent all-hands standups (sometimes lasting 45-60 minutes to get through all of the teams reporting in).
> Big red flag is there is a daily all hands (yes, I've seen this in a 16 person startup)
It was even worse than this: The Scrum operators wanted an engineer from every team they interacted with to also join their meetings.
So if a project made an API request to another project, they'd insist on pulling an engineer from that team into their weekly or daily meetings.
I had daily meetings with 10 people, half of whom might be engineers from other teams who didn't need to be there.
Meetings became so useless that everyone stopped listening until their name was called so they could work through meetings. Then every time someone's name was called, we had to spend 5 minutes recovering the last 5 minutes of the meeting to bring them up to speed.
The inefficiency was out of control, but the worst part was that some people thrived on this level of inefficiency: Lack of progress meant the empire builders could argue for more headcount, too many meetings meant the Program Management department could hire more program managers. It was like a case study in adverse incentives.
sounds like my (big co) meetings. also in the "scrums" everyone gets stuck on one topic and it turns into an hour long debate that could have been resolved by 30 mins of coding.
I work I infrastructure and the daily meeting in the morning is the most important part of our day. It last 15 minutes, first we review and dispatch the active alerts, then we check escalated demands, then we check if someone needs help. We not do to solve issues during that meeting, this is done in smaller groups after the daily. That meeting keeps us aligned.
Also no managers are allowed during our daily meetings. This is something important that enables more candid communication.
> Big red flag is there is a daily all hands standup
Something I've seen for the first time at my current project is instead of a daily standup, there's a daily thread to report what you've been doing in Slack instead. And then as long as there's nothing people want to go over, the actual standup meeting is skipped. We sometimes go a 2-3 weeks without an actual stand up call. It's pretty nice. Even if not, the calls are only scheduled twice a week anyway.
Much better than the 20 person in-person daily standups in the conference room, better get there early if you want to have a chair, at 8:15am every day, like a previous job.
We do that where I work and we did it at the last place.
I found it stressful to write the summary of what I did yesterday in the morning because I’d been thinking about other things in the interim. I discovered the “life hack” of filling out my report in the afternoon at quitting time which makes me, from the viewpoint of everyone else, the first to report. I find it really easy to do and when I get in the morning I have a plan in front of me which helps me carry forward my momentum from the previous day.
It should be a literal standing meeting. You dont get to sit and drone on. There is one in every bunch and when they make their peers stand for 10 mins. The team will self correct the person into not being that way.
That meeting is a check point. What is every one up to, and everyone else gets to hear. It's a way to get a team to gel (and many aren't)... If someone surfaces a problem in there (and they should be) then there should be some other team member offering to help out - there should be dialog if some dependency is going to get bumped by others being distracted.
These meetings are effective up to about 10 people. They work well with cross functional teams, or teams where the members have varying levels of experience.
Time spent with the team ebbs and flows depending on complexity of projects, where in the roadmap you are, seniority of the dev team, and more.
The agile manifesto was too abstract in it's original state, and folks who needed a rigid framework created capital A agile in order to adapt it to their cog in the machine role.
For my team of 6 in a ~20-25 person (remote) startup, we have a 30 minute dev meeting in the morning, and a 15 minute full team meeting where the agenda rotates daily around departments. I quite like it honestly, remote can be lonely and isolating otherwise.
Generally I think it's important to structure team responsibility around who ultimately needs to make the decision (although they need to consult others and get team buy-in). And hire people you trust to make the decisions. Then the meetings become about problem solving and getting through the work, rather than performance art and politics.
As a counterpoint: back in the day (around 2010) at JetBrains we had a daily all-hands stand-up for several teams, about 15 people in total.
It was literally a stand-up, that is, everyone stood in a circle. Everyone was expected to utter exactly two sentences: what has been done yesterday, and what are the plans for today. It usually took 10-30 seconds per person, so the entire meeting was under 10 minutes.
It was pretty efficient: you almost instantly knew who are you going to talk to later in the day, if need be, or what changes to look at.
Sounds good. 15 people seems too big, but if you're keeping it under 10 minutes then all power to you.
Very few people care about "what did you do yesterday?". It's already over, by that point. There's a lot of benefit to removing that one.
In my team we do it like this:
- how are the nightly tests? (we've actually dropped this in recent months)
- what's in the Test column, and does it still need manual testing? (we have automated unit and integration tests but also, sometimes, do manual testing just so a 2nd pair of eyes has seen a thing work. We're not strict about it)
- what's in the code review column? Are any of them stuck/unreviewed/etc? (to remind people to do reviews)
- what's in the progress column that needs help/pairing or some kind of management support?
- any other business
With these three rules:
- save the details for other, more focused meetings or Teams. Anyone call time on any discussion.
- strict max 15 minutes time-limit
- jokes are fine
Works well enough that the next time I work in a team that doesn't do it this way I'll do all I can to move them to this format.
> Very few people care about "what did you do yesterday?"
...except the people for whom what you have accomplished is a dependency in their work. It can be a direct code change you'd have to merge into your current branch, or something you might want to start using (or finally stop using). It may be even something you have to contemplate on, and it may affect your work much later.
Work of people in a team is inevitably interconnected, and so is work of people in sister teams.
This is a good point. I imagine in a more cross-functional team this would become more important.
My current team is essentially front-end only and it's rare that we divide work up such that one person is waiting on another in the same team. If that's a possibility, we tend to pair instead.
If you have deps, it’s better to have a direct meeting with both teams in order to resolve mishaps and have a channel of communication setup for that. Daily standup is a poor replacement for that.
The main point of stand-up/daily scrum is to set up collaborations and coordination. It's where you invite pairs, inform POs of blockers and discoveries that will lead to longer timelines etc.
If you're doing all that anyway, keep going and don't worry about stand-up.
We know scientifically that exercise is important. I highly doubt the same level of evidence exists for the importance of these short meetings.
Also, if your boss tells you to read the emails, and you don't, then you can get fired. You can't get fired from your job for not exercising. If you can ignore the emails and not get fired, that's proof in itself that the emails are not important, at least not to your boss.
> Also, if your boss tells you to read the emails, and you don't, then you can get fired.
The boss has no easy way to tell if you read the emails or not. The consequences of lack of information are often hidden / long term.
In many countries, it's pretty much impossible to fire employees for forgetting to read an email.
> If you can ignore the emails and not get fired, that's proof in itself that the emails are not important, at least not to your boss.
I'll try a proof in a similar style - if Scrum was so wildly inefficient, the companies practicing it would be a long time out of business since companies with no meetings would easily outcompete them by offering better products/services for lower costs. Yet Scrum (or similar methodologies) are used in many successful companies all over the world, that's a proof that Scrum works.
How do you like them now, these oversimplistic "proofs"?
This is one of the things I've added to me repertoire when I interview with teams: I always ask how often they meet and how they structure their meetings.
I once mysteriously turned into "not a culture fit" after several rounds of interviews with excellent feedback up to that point and I'm fairly sure asking a couple of similar routine questions about their dev process was what got me tagged with that label. I do consider that one a bullet dodged - if your process is so bad that you're worried about a candidate asking about it or you think they're being awkward for doing so then that says everything really - and I still ask similar questions of anyone I might work directly with/for today. But if there's a place you really want to work it's worth keeping in mind that some people apparently get rubbed the wrong way by this kind of question.
Every meeting only has 1-5 people talking, regardless of how many people are in it. Especially if they're remote. Sometimes a large meeting with many listeners is ok, but the same 16 people meeting every day is a waste of time.
It's not a "no true Scotsman" (scrumsman :)) if the counterexample is in fact not a Scotsman.
Whether it is or isn't depends on your feelings on scrum, but it's not a fallacy to try to defend the initial definition before it was co-opted by anyone with an Agile cert.
"Hammers suck at driving nails."
"You're holding a rubber mallet."
"No true Scotsman!"
This. People love dunking on Scrum because they have colleagues and managers that wield it as a weapon (often in conjunction with JIRA, which, although not an especially simple or well-running piece of software, is really only as bad as you choose to make it). It's actually a very simple process that was designed as the _antithesis_ to a lot of the atrocities committed in its name (based on a reading of this thread).
If you have managers/PMs/TMs/HMs/BDFLs that can't see the forest from the trees and a corporate mandate to use Scrum (or Agile generally) then of course they'll pervert it to suit their own ends. Slow-moving organizations with complex incentive structures like the government and Fortune 500s are especially good at this. If you want to be upset with somebody then blame them. I've worked on teams where stand-ups were less than ten minutes long, we delivered every two weeks, and we had properly-specified Scrum Master and Product Manager roles and it worked swimmingly because we _actually did Scrum_, not "Scrum, but...".
Scrum is a prescribed process. It is not the performative act of dragging work items into Sprints in JIRA then using various Scrum terms for 5-hour-long weekly meetings.
> It's not a "no true Scotsman" (scrumsman :)) if the counterexample is in fact not a Scotsman.
Every bad Scrum/Agile situation I've been in has orchestrated by people who were convinced they were doing it "the right way"
Every defense I've read has been from other people who weren't there who insist that it must be "the wrong way".
If you define the "right way" such that it can only be good, then you conveniently dismiss all of the negative criticisms at once. Yet in the real world, there appear to be a lot of us stuck in companies who think they're doing it by the book but it's still not working out.
I always wonder if they have retrospectives in those situations. And if so, what they actually do there.
In my opinion, retrospectives give the power to the team to improve their own process. Without self-organizing teams, you have no agile. So without retrospectives, you have no agile. So I always wonder if and what they do during these retrospectives.
Let's do a thought experiment. Imagine you have the same organization, same people, but a different methodology or perhaps no methodoligy at all. Would things get significantly better?
It became really difficult to push back on or change anything because the Program Managers would band together and brandish their Scrum certifications, Scrum books, Scrum podcasts, and other credentials to show that we couldn't argue with them. Unfortunately, it worked with management.
Wipe all of that away and let all of us work together toward a methodology that worked for everyone without Product Managers playing the Scrum card at every disagreement and I have no doubt it would have been better.
In fact, I have some proof: There were a few pockets of small teams that got to operate outside of the Scrum madness either because their tasks were thought to be too small or temporary, or because they existed in islands of the org chart that were free from the reaches of the Scrum people. These small teams ran circles around everyone else, but that would come grinding to a halt as soon as their projects got assimilated into the Scrum catastrophe.
And agile methodologies are not agile by the definition. Agile is a set of relative values, not a methodology. The first being to value people and interactions over processes and tools. No process is agile, no process can be.
I hear these aphorisms a lot, but none of it actually matters.
Agile has been plastered over certifications, podcasts, books, conferences, trainings, and everything else for years. The people I referred to above had been through it all and brandished it like a weapon. You can tell me all day that it's not true agile but it didn't make an iota of difference to how things play out.
Judging by the comments, my experience is not unique.
One of the most reliable indicators I know of a dysfunctional team is on average how many times whether what being proposed is sufficiently agile is put to question per meeting. If this is greater than some epsilon much smaller than 1, then you have trouble.
Overall "is that really agile though?" is such a fantastic thought stopper. It's can be thrown out to derail any sort of proceeding. It moves all focus from what's practical and applicable and relevant to the situation at hand, and moves it to an endless discussion about philsophical alignment.
The far biggest time sink is not what you logged though, but how you need to pad estimates and delay work to please the Scrum Lords.
Like, the burndown chart has to be nice and steadely go to zero. There is no way to do that without decoupling reported hours and estimated hours from actual hours. Or points. It doesn't matter which.
"POINTS AREN'T TIME! THEY'RE EFFORT AND/OR COMPLEXITY!" I've been routinely told. Yet... low complexity stuff was expected to take less time, even if it was high effort. All 'in my experience' of course.
Changing 95 files because someone didn't want to centralize some value in a method call last year (YAGNI!) is now high effort, even if low complexity.
Then... "that's too many files in a PR! break it up! no one can review that many files!" It's the same two line change in each file - this shouldn't take that long to 'review'.
I've often spent more time arguing about points/effort/estimates than doing the low effort work. But if we don't record it properly, you won't get 'credit' for the work!
Slow-paced insanity when taken anywhere near close to its logical conclusions.
> "POINTS AREN'T TIME! THEY'RE EFFORT AND/OR COMPLEXITY!" I've been routinely told. Yet... low complexity stuff was expected to take less time, even if it was high effort. All 'in my experience' of course.
This realy grinds my gears. I had a recent experience with a scrum master (technically a delivery lead but in practice a scrum master). Really nice guy, smart, easy going. We had many discussions about the value of estimates, and the whole "it's complexity, not time" trope would come up. So I asked what the estimates were used for. Turns out they're used to forecast cadence / velocity. Of course, knowing that we were going to be asked why a small story was taking two weeks to complete, we'd start sizing based on time. After all, we're humans, biased and flawed.
Now you tell me, how do you want a measure of complexity to be a predictor for cadence when these 2 things are at best orthogonal?
We don't create 1 point stories, you need to roll this up with another story!
Hey we don't do 13 point stories, you need to break that one up!
8 points? you sure that isn't a 5?
2 points, 3 points.. what's the difference just mark it as a 2.
OK so basically we just have 2s & 5s then? Amazing.
I had a colleague who told me his secret - "I just say 3 or 5 to anything". That was it. He would pause, then say 3 or 5. Anything I was asked to estimate, I'd give real effort estimates based on their scale. And was always pushed back on like you noted above. And it was a constant struggle. Yet... I always (like... over 95% of the time) hit all my targets, delivered early, and would sometimes pick up the other slack. The other guy with 3/5 - would almost always get pulled in to some other project (or aspect of the project) so almost never got his stuff 'done' (often I would finish it). But on paper... his estimates were always 'so easy' and his tickets always got done (often by me) but I was the 'difficult' one (for many other reasons beyond this).
If you try to right size tasks, you can just count tasks instead of estimating them. This approach even has a catchy brand name in agile circles: #noestimates.
In every team I’ve tracked, the task count burndown velocity was impressively linear, whether looking at weeks, months, or years of data. I think we can thank the Law of Large Numbers, with shorter than average and longer than average tasks balancing each other over time. (We never bothered with story points, so I can’t compare.)
The problem with Agile induced "right sizing" of tasks is that you artificially split atomic units of work into multiple tickets.
A single deliverable is now 3-5 different tickets that might get split across sprints. It now becomes harder to express when a piece of atomic functionality will be delivered because you need to track with dependencies across the tickets, etc.
So it feels like contortions to make reality fit into Agile which negatively effect reality.
Let's say we are using Agile in the kitchen and we have 3 tickets - 1) research recipe, 2) collect ingredients, 3) bake cake. These are logical and understandable to a stakeholder. You can assign them different story points / sizes / durations / whatever. It's relatively easy to express the dependency and also keep it in your mental model. Each has a deliverable - 1) recipe & ingredient list 2) the ingredients 3) the cake.
However Big Agile Coach argues that really it should be 1a) research recipe, 1b) collate ingredients required, 2a) research pricing on ingredients 2b) create per-vendor ingredient lists 2c1) buy ingredients at vendor 1, 2c2) buy ingredients at vendor 2, 3a) clean kitchen 3b) prepare cake batter 3c) bake cake 3d) cake frosting/finishing
OK which of these 9 tickets depend on which / which can be parallelized / which are best to keep with a single dev, which should be done within a single sprint vs split across? Etc.
Haha after 5 years our scrumlord finally relented that 1 point was 8 hours for our team because even he was apparently getting tired of the cognitive dissonance.
My response to estimating is that if you want anything accurate I’ll need time to estimate - roughly 1/4 of the estimated work should be spent estimating.
As a rule of thumb, if the work is estimated to be a day then is should take me 1/4 day to estimate. If two days then half a day to estimate. If 4 weeks then 1 week to estimate.
We normally continue with guesses that are meaningless.
I was already adding time to my work like an extra point or two here and there
But then in the grooming session the whole team would guesstimate even more story points! I was dumbfounded! This was beyond all of my levels of tolerance and rationality but it kept happening every sprint until something that was a 0.5 for me was a 5 point and I would have two 5 point tickets for the whole sprint that I would submit to QA one day before the sprint ended, 9-10 business days later
and actually doing that made me a star performer, what the hell!?
When I've used Story Points as the team manager, one of the things I made sure of was to completely avoid looking at any given team member's velocity, ever. I only cared about the team velocity, and only for the purpose of estimating risk to the timeline.
At the round-table people would report their retired points, and I'd add them to a running tally I kept on a piece of paper next to me. "2+1+0+5+2+2+8+0+1." Then I'd record the velocity for the week for the whole team, and we'd move on.
Scrum teams are self-managing, and point values are used for gauging your own team-workload.
When you point a "0.5" and your team points a "5", stop and discuss the discrepancy until an alignment can me found. Keep doing that, every task, until you a collective meaning of "a point" is found.
Personally:
* Less than 1 - These are a smell and should not exist. These misalign incentives and encourage "bike shedding".
* 1 point tasks - no task that requires 2 people (dev and qa) is a 1-pointer, so this is something that needn't be QA'd. 1 point tasks should be rare items that can't be a subtask of a "real" task.
* 3 point tasks - These can be done in a day (depending on the team's opinion, this might be multiple people and still be 3 points). Virtually every task should be a 3.
* 5 point tasks - These are tasks that cannot be broken down to be done in a reasonable amount of time. These are generally things that have minor external dependencies. ("not hard but I'll have to get a server spun up by the unix admins.")
* 8 point tasks - These are rough tasks that haven't been fully dissected by the team and are the scrum version of a "code smell". The team should break these down and dissect them.
* 13 point tasks - "There be dragons here" tasks. Large unknowns and these tasks should not be added to a sprint until they're broken down further.
It's a one-time conversation (per new team configuration) that makes every conversation thereafter fast.
My team's pointing sessions are lightning.
Even when you do have a new team member that wants to discuss a "0.5-vs-5" point disparity, you explain the above in less time it took to read it and get back to work.
If you measure velocity then the points are additive, how do you reconcile 3 point tasks doable in a day and 5 point tasks not doable in a reasonable amount of time?
Isn't 5 points less than 2 days then?
For the record, in my team we don't use story points or measure velocity. I just had a frustrating discussion with a peer team that didn't plan an important task because "its 5 points and does not fit into a sprint".
That kind of inflation corrects for itself. Because you're supposed to look at the previous sprints to judge how many points you'll get through this sprint.
I recently dealt with the same thing. We had an experienced CTO come in and implement a “big company” style of Agile. In all fairness, there was a lack of process that needed to be addressed, but the pendulum swung very much too far in the other direction. He left the company and I stepped up to fill the gap. First thing I did was quantify the amount of time the team was spending in meetings and it was over 25%. Those meetings weren’t even efficiently grouped, so with context switching it was even worse.
Luckily I was in a position to change things and consolidated a lot of the ceremonies. I kept more of the process in place for our offshore partner team because the communication burden was higher.
So I guess my two take aways are that time in meetings needs to be evaluated with how meetings are grouped to avoid too much context switching and allow for folks to get into a flow. The other is that how strictly you adhere to “textbook” scrum really depends on the composition of the team. More junior teams or teams that are insolated from the larger business context benefit more from more process imho.
Interesting, I have a very similar story from last year. Existing CTO and head of product acted as if they were writing complex, mission critical software (they weren’t) and instituted processes to match. It went from overly ad hoc to over-the-top scrum. As a result, features took months to develop and everyone was terrified of releases. Teams bloated to massive size.
CTO was fired, I came in and evaluated everything, slashed the consulting teams down to the ones clearly performing, and slashed the processes down to boot. Within a month the team velocity was way up and we were releasing to a nice cadence without fear.
And this was not because I’m a super man. I’m not. Any competent tech lead or manager could have done the same. The only difficult part was dragging the product folks along, they kicked and screamed the whole way, predicting doom, and were amazed when the sky didn’t fall.
The last org I was in realized how much time their engineers were spending in agile-caused meetings, much like what you describe, at least half of the working hours in a week - so they made a company-wide rule that no one could spend more than 4 hours a week in meetings.
What happened instead were impromptu "ghost" meetings and a ton of stuff done sloppily over chat instead, where I think the hope was that people would try to become "more efficient" with their meeting time.
To me, RACI charts are a missing component of meetings.
Required meeting attendees should consist of the Rs... and only the Rs. As and Cs can be optional, but meetings can conclude without them.
Everyone not in the meeting can be updated out of band.
"What action is this person taking in this meeting?" should be a brutally honest question. If the answer is only "listening", then it's a waste of their time.
And also, related point: what is the termination condition of this meeting? And has that been decided and communicated beforehand? I.e. What outcome are we seeking, that when done everyone agrees the meeting is over?
I can't stand agenda-less, "we're meeting to move something forward in some undefined way" meetings.
Agendas are critical and so is the purpose of the meeting.
Is the purpose of the meeting to inform, decide, workshop, or persuade?
If it's to inform, it should be an email, but some people do not read them, so you need to sometimes read the email to them in a meeting.
If it's to decide, do you have the people that will decide called out in the agenda? Do they have the necessary information or have they done the necessary work to make a decision in the meeting?
If it's a workshop, do you have the invitees pared-down to those that will be actively participating? Is there work they need to complete before the meeting, so they can be active participants?
If it's to persuade, these should be in smaller formats. Preferably 1-1 to start, so objections and resistance are raised in low(er) stakes meetings.
Meetings should end with a summary of decisions, next steps, or some other call to action. Preferably these are recorded somewhere and distributed to the rest of the attendees or a wider audience if needed.
"people had fewer than 3-4 hours per day to actually work" had the same experience. the unwritten expectation was to pull 8 hour coding days /plus/ all the Scrum overhead. if you don't like it, there's 1000 guys waiting to take your place, partly thanks to remote. a core reason we haven't fire you yet is that it is costly to ramp up new people, but don't try our patience.
> "people had fewer than 3-4 hours per day to actually work" had the same experience.
Same. Even worse, spread out in between meetings. Some days I'd have barely started understanding the work to be done and it was time for the next meeting. Rinse and repeat for each "non-meeting" slot throughout the day and the whole day is a write-off.
Never in my life have I encountered anyone from the engineering side who spoke positively about scrum. It's always the consultants and scrum masters and their ilk who push the agenda.
Never have I ever heard about any story about agile making things better.
I've worked at exactly one company where Scrum worked really well, but it was a somewhat... unique isn't the right word, but a specific set of circumstances:
- the team was made up of primarily junior engineers with a small handful of intermediate and seniors
- the company's work was split between a product and N consulting projects
- the company had standardized on a specific "default" architecture (Spring Boot + Angular) with a bunch of pre-existing components that teams could use to accelerate their projects
- the projects (product and consulting) were generally managed by the intermediate engineers with a handful of juniors on each project doing most of the day-to-day work
- the seniors were mostly on the product side but had latitude to go help on any of the consulting projects if anyone was stuck
Scrum with the daily standups and bi-weekly retros worked great here. The seniors went to all of them. If someone was getting ready to start on something and they weren't aware of existing components that were either available from the library or available to libraryize from a different project, we'd help facilitate that. If someone was getting stuck on either a tricky debugging problem (of which Spring Boot was good at making) or a complex design problem, one of us would stick around and just get it solved with whoever had the problem right away. And on the other side of it, we were sufficiently looped into the various projects that we could use that as input for larger-picture architecture decisions etc.
I'm old enough to have extensive experience from before agile methodologies were in vogue and things are generally better with Scrum / Agile than they were before, ceteris paribus.
Sometimes the process worked better, sometimes worse. It depends a lot on the company culture and people. The company I'm currently at has a very good process (SAFe).
I also think there is a certain comorbidity of an organization pushing scrum heavily and other dysfunctions.
From what I've heard before my time, a lot of traditional organizations had a non-flat hierarchy and a set of 'bosses' - people in charge of personnel, planning, requirements, and technical decisions.
In 'modern' orgs this has been replaced by a 'matrix' structure with each team having a dedicated product owner, scrum master, line manager, requirements engineer, architect etc.
While the traditional org structure had some shortcomings, mainly having to do with the fact that if said boss didn't perform, then the team had no chance, and that so much institutional knowledge was locked up in said boss, that they were nigh-impossible to replace.
Modern management techniques are about replacing potential excellence with guaranteed mediocrity.
> Of course, the Scrum proponents will rush in and tell me that we were doing it wrong
I don't think it's helpful in any discussion to try and pre-emptively dismiss people who might disagree. People have been doing that for the decade or so scrum has been mainstream and it just dumbs the discussion down to he-said she-said.
That being said, agile as it was originally described in the manifesto was not prescriptive, and scrum, while it was intended to follow in its footsteps, has been a victim of its own success. It's now firmly in the domain of other highly-prescriptive management frameworks thanks to the effort of consultants and managers who adhere strictly to the letter of scrum without paying thought to the essence of it.
Most people I know who were fans of scrum back in the day have distanced themselves from it because it's not agile any more. Certainly not with consultants selling SAFe as an agile methodology.
Just like "You are not your code", may be we should also have a "You are not your Process Certificate" mantra. It is not the people that are dismissed, but those who insist on The Process at all costs.
I personally strongly dislike a lot of aspects in SCRUM (individual commitments stick out especially, together with the entire role of Scrum Master), but am not sure I see an alternative for some form of agile (without the TM), that is adjusted to the individual team's needs, for the vast majority of teams. Whenever I read these criticisms, a lot of it rings true, but I fail to understand what the alternatives looks like besides Waterfall or chaos. Whoever does these write-ups always complains about some Agile™ thing, but takes the alternative for granted. What activities and meetings would be dropped or replaces and by what? It's not very meaningful to criticize something when comparing it to nothing.
> but I fail to understand what the alternatives looks like besides Waterfall or chaos.
What I've seen pretty much my entire career (early 80's) for projects is just a straightforward process of up some front planning, phased design+dev, management of tasks through a regular (weekly or twice weekly) low overhead process (what's ready for next step, where are challenges), etc.
The key is having an experienced technical leader to guide the process. Typically, PM's don't have enough detailed technical experience to really understand how to make this stuff work.
My biggest pet peeves are (a) when mature software or mature organizations pretend they are a three person startup and refuse to document anything and have meetings all day (b) when product owners say f the existing architecture or tech debt and literally tell you to rip out everything and install a new tech stack because it is agile.
These morons know nothing and bark out orders based on their agile bonafides which is nothing more than snake oil. A magical cure all irrespective of the problem you are trying to solve.
Which is another flavor of Agile which is what everyone is always complaining about. I'd take some form of Kanban any day over doing rigid Scrum by the book. Kanban needs a lot very similar meetings though. You still need to fill the backlog, discuss the tickets. If you were to do Kanban by the book as described by the Agile Alliance, you'd still do standups, retro under a different name etc.
In my experience people complain about strict processes that books or consultants say must be followed. I've rarely heard someone complain about the content of the agile manifesto. So start with what you've got, and iteratively keep what works and chuck what doesn't, until you have a process that works.
I'll add that kanban means much less time filling a backlog, to the point that an individual can own that, and you're eliminating that meeting.
> I'll add that kanban means much less time filling a backlog, to the point that an individual can own that, and you're eliminating that meeting.
I've only ever been on projects where the backlog was filled by a PM and or lead engineer and then reviewed collectively and maybe some amount of re-shuffling would take place. Are you saying you've been in meetings where the backlog started empty and it was populate with the entire team in the room?
I've never seen an empty backlog, but I've been in meetings the purpose of which is for an entire team to rubberstamp the order of the backlog. This is "grooming" or more recently "backlog refinement". You don't need to do this in kanban.
Don't you need to go over newly added tickets and ensure the tickets are clear, order makes sense, etc? Whenever we've skipped this some issues would emerge when tickets get picked up later. Depending on the project domain and if a PM or engineering lead wrote the tickets the issues would be either more about technical issues or misunderstanding of business requirements.
> I've never seen an empty backlog
How about a backlog with stuff near the top that's no longer relevant or has drastically dropped in importance?
Tickets are often written imperfectly but that doesn't necessitate a standing meeting for the whole team imo. Make your pm and em hash them out, make the most informed engineer write the ticket, but don't make everybody watch.
If the top of your backlog is uselessly stale, you're spending too much time writing tickets in the distant past and not enough recently (or maybe congrats on your velocity?). A ticket that's so old it needs to be overhauled to be worked on was written prematurely. This is one of the things kanban is good at.
Edit to add: a team that's heavily reliant on a PM might not be a great fit for kanban? It's not for all teams, and is a natural fit for some
What you are describing is entirely reasonable, but again still a lightweight Agile process. The thing that I don't understand is what the people want who keep complaining about all Agile, not just (rigid) Scrum in particular. I've worked with XP, Scrum, Kanban and versions of those adjusted to particular teams and companies. If someone doesn't want any Agile and doesn't want Waterfall, wtf do they want?
How do you refine features? How do you discuss team improvement measures? How does prioritization happen if you're working on a product?
The answer might be simple for small teams, but a lot more complex for larger teams, where the result might look eerily close to Scrum. One difference would be that meetings will take place infrequently and only "as needed", where I wouldn't trust most teams to recognize their needs.
I'm really curious about this question, are you thinking that not having Scrum makes it's harder to refine features?
I'm trying to understand what assumptions you are making, because I've never worked in a Scrum environment, but have always refined features as part of the natural flow.
> have always refined features as part of the natural flow.
"natural" as in "law of nature"? Or is it just a process which crystallized in the course of your career as something which makes sense to do?
Scrum, and other methodologies are mostly a collection of such processes which proved to be useful, are somewhat standardized for learning and communication.
One can reinvent many of the Scrum processes independently, but I kinda don't see the point. Just like I'd rather use a finished library / framework rather than try to hack together my own.
No, but I believe that whatever you're doing resembles what is done in scrum. Gather information, discuss with your colleagues, create a plan. Scrum enforces that colleagues talk to each other, which I learned is not always the case.
I have a similar experience to yours. My organization even hired a scrum expert who is probably just deadweight, he’s on mute in all our meetings for the past 6-8 months. It’s also true about having little actual work time, in my org we spend so much time in meetings that in the end 3-4 hours of actual work are left on a daily basis. I objected to this but was told everyone should learn everything, end of story. We’re supposed to be repleaceable cogs in a machinery and that goal was reached by now.
I've been in a couple places where I did know 'everything', or... near enough. The more I got to learn outside my own specific dept, the more cynical and frustrated I became (usually). You start to notice that entire groups of people are often just sitting around for days doing absolutely nothing because they're waiting for one person who's out for the week, etc. Or you learn that people just spent 4 months working on something that was rejected in a meeting 4 months earlier, but... the original team still wanted to do it anyway, and therefore couldn't help your group over the past 4 months.
On the opposite extreme, our teams use Jira, kind of structure it like Scrum, but don’t do any of the actual planning. It’s complete chaos and we have a similar level of meetings, maybe more, with everyone trying to figure out what’s going on and when things will be done. The go-to is a 30-60 minute daily meeting with each individual project manager for each project. Sometimes there are 3 project managers working on different aspects of the same project, so we have 3 hours of meetings (spread throughout the day) to give the same updates 3 times. Of course, there is no update, because all we do is attend meetings to provide updates.
Occasionally our Scrum Master will put an actual scrum meeting on the calendar, but then talks about whatever he wants, and it never moves the ball forward from an organizational point of view. A retrospective would go a long way; we’ve never had one of those. I bring that up often, as the 1 meeting we should have, if we only have 1 meeting.
I tracked my time meticulously for several years, and when I used it to point out how horrible the current environment is, I was told I was doing too much and should be much my lazy about the tracking, to the point where it becomes meaningless.
It sounds like you just have poor leadership or poor PMs. Daily meetings should be 15 min with an extended optional “parking lot” to dig into things and everything else should be adhoc meetings with as few engineers as possible, except a weekly and monthly meetings.
I’m a team lead (not manager) and I get over 50% if my time is builder time and I haven’t measured but I’d guess my teammates are around 80%.
The amount of time lost to doing Scrum things was so out of control that some people had fewer than 3-4 hours per day to actually work.
If the aggregate of the sprint planning, backlog refinement, retro and dailies is more than 10% of the total time (eg 1 full day out of a 10 day sprint) for most of the team then something bizarre is going on. If the everyone is losing 50% of their time to agile things then your process is impressively broken.
Interesting, I never experienced a team broken by Scrum. Just a retro, planning, demo, 15min daily and that's about it. Lots of other meetings, yes, but none of them due to Scrum, but rather complex company processes.
If a person is in 4 teams, and they're not a full-time 'product owner' where going to meetings is their whole job, I'd say something bizarre is going on.
My team has been an overlay team for years. We provide services to many teams. Since the glorious transition to agile and product focus, we had to sacrifice someone to be the product owner, so their 'whole job' is overhead management, which they hate. Now, every team wants someone from my team in every standup ("but we'll be blocked if a question for your team comes up and no one is standing in the corner patiently waiting to answer it") and definitely wants someone in every sprint planning. 8-ish person team, dozens of projects, and time disappears very, very fast. I've managed to push back on the 'every standup' nonsense so we don't spend 100% of our time in meetings, and in return the agile folks are using their 'metrics' to basically tut-tut and say we don't do any work.
I can see where if your whole job is on a single project where there workstream can be easily decomposed into 'sprint-size' chunks, agile and the rest are probably useful. But that's not every job, and maybe not most jobs, and it sure as hell isn't my job. But like so many other have concurred, and as I see on a routine basis, there will be someone with 'Agile' or 'Coach' or 'Product' in their job title will have an expansive explanation why I'm Doing It WRONG. Capital One seems to have figured it out...maybe there's hope[1].
every team wants someone from my team in every standup
In agile you're supposed to know what's going into your sprint, and each ticket should meet your "definition of ready". Teams shouldn't need someone on hand because they should already have refined and unblocked issues before the ticket was added to the sprint.
Well sure. That's the default response: "It's not us, it's you". But I can't help thinking "We have dozens of dedicated 'agile leaders', several dozens more 'agile coaches' who have various certifications, commitment from management and have hundreds if not thousands of people who have gone through multi-hour (at least) agile training. If we're still doing it so obviously wrong, maybe it's the methodology and not the people.".
How many teams before you consider it bizarre? As a mere individual contributor / senior dev, I've only ever officially been assigned to a single team at once, but there are times when I'm juggling tickets on 3 different teams' Jira boards and attending 3 different standup meetings. Thankfully, I typically don't have to worry about sitting in on more than 2 teams at once, and I'm definitely an outlier. For me, this arose from joining a growing team before it split several times and also from predating all the current product owners.
I had some coworkers who would spend 6hours in scrum related meeting every Tuesday....In addition to their daily 2h scrum meetings ( multiple teams and role meeting coordination).
I feel like SCRUM and anything like it is an attempt to formula and process-ify a thing that dies when you do exactly that. At my company we waste a ton of time on this stuff but we also have a ton of people with jobs that really only tie in to it so they will always defend it. Bureaucracy serves itself etc.
I was trained in Scrum, but the main thing I learned was that it is the opposite of what the "companies using Scrum" do. When I mentioned that in the company I worked at (the one that paid for my training), I was told that "we do Scrum differently here". They paid for my Scrum training just to tell me to shut up and do it the traditional way, only now I was supposed to call it Scrum, and the existing meetings had to be renamed using Scrum terminology. Oh, except for the retrospective (the part where developers provide feedback on everything, including Scrum itself), because retrospectives are a waste of time!
So it seems to me that the main reason why "true Scrum has never been tried" is that most companies never intended to actually try it. They just wanted the buzzword.
So it seems to me that the main reason why "true Scrum has never been tried" is that most companies never intended to actually try it. They just wanted the buzzword.
Scrum is actually a cultural change. The methodology is just the surface stuff, like the buzzword.
It also doesn't actually happen at the company level, unless the company is quite small. It happens at the group level. I just thought of this: The Scrum that can be named, is not the true Scrum.
"Practicing" Scrum by following dictums in a book is sort of like practicing marriage by following dictums in a book. Those are just guidelines, and the reality is at a deeper level.
EDIT: Come to think of it, that can also be interpreted as: Therefore Scrum is broken as a methodology. It cannot be "followed" at scale. (Much as communism is broken as an economic system.)
I've had good luck with small teams implementing "scrum" which really came down to: the team finding a minimal coordinating process that uses short units of work.
I will say that the part of scrum that I like (and I think most people like) are qualities that it's easy for like minded people to recognize. But if someone doesn't get...why it's good to summarize your progress for the team or break things up or understand what a task does for multiple stakeholders...scrum does not communicate that to them effectively. Imo it feels like a system you can use to teach people how to work effectively, but in general those who haven't seen most of it themselves often get buried under an avalanche of terminology and procedure.
We did a planning exercise every sprint at work to see how much time people had to work on features once you removed meetings and other ceremonies, RTO, holidays, oncall, etc.
We were tracking that per employee.
Everything was fine for a few months and then I added a "total" column next to each row and it became apparent that we were spending close to 60% of our sprint on non-development related tasks. On 45 work-days per sprint we had something like 19 days for features.
Needless to say it shocked my manager. He's not against change thankfully but we're still evaluating what could be better alternatives.
Do I understand correctly that you're doing nine week sprints? That sounds extremely long to me. I have to think you're spending lots of time planning work that won't be done. When you plan a sprint, how often does the work at the end of the sprint actually get completed by end of sprint?
Say you plan to start the "add Foo button to Bar page" in week 7, do you actually do that? That would require some really strong estimation skills and a remarkably stable product and business environment. What's the point in the sprint where you're doing more unplanned work than planned? Or how much carry over work do you have?
Because if I was trying to plan nine weeks of work, I'd get it drastically wrong, and waste tons of time planning stuff we weren't gonna do.
I would make the next few sprints 4 week ones and plan to get down to 2 week sprints after the shorter pace starts to show it's strengths.
Or maybe you have 9 people doing 1 week sprints and that's how you got 45 days. In which case, whoops! I have no suggestions!
Just by switching from Scrum to Kanban one can improve progress a lot. For being two very similar pull based systems the difference in effectiveness is just incredible.
Agreed. We use Kanban and are very happy.
We used to not do any estimates but have voices from others asking for them to do better planning of marketing and sales activities.
I understand where they are coming from but so far it's mostly guessing
So: Do you do estimation in Kanban and if so, how?
You don’t do estimation without prioritization. As a consultant, my default way of working is kanban, often setup on Trello. Once I deconstructed the project into features, the first thing I do with the client is arrange them by priority and arrange them into sets for releases.
If sales and marketing need to do planning, then they need to tell what they want to push back to the backlog so that the feature they want are on time.
We do that already, yeah. But they'd like estimates on a lot of issues so they can prioritize better. I believe it's a waste of time though. There is no good solution for this I believe.
I think generally you should be able to break some feature up into a series of very small tasks that can be estimated. So you may not be able to estimate an end to end feature accurately but you should be able to give rough ETAs for when different functionality will start to trickle in
This is what we've done of late. Massive improvement. Much lower time commitment and we get a good (enough...not perfect) view of the metrics we really need to focus on.
I really like Dave Thomas’ talk Agile is dead long live agile. Dave’s name is listed as one of the creators of the agile manifesto.
Basically, agile is an adjective. Anyone using it as a noun is selling snake oil. Yes, it is that bad - a whole industry built from the ground up to monetize a simple concept by enshittifying it into its very opposite.
Been using ShapeUp for nearly a year now in an org of ~50 engineers.
Let me start by saying, if you intend to adopt ShapeUp, spend a great deal of time reading and buying into their structure of teams. Aside from SIP/QA & KTLO work, they flatten the “Core Product team” and build ad-hoc teams for a pitch that has won at the betting table - for that cycle. Trying to maintain standing teams with domains of ownership is a very challenging way to adopt this process.
In my experience, unless the entire org is drinking the kool-aid - hard - you end up with 6w cycles of waterfall. Pitches morph quickly from “present your idea that we bet against” to “write up a detailed design doc, along with an Epic, backlog and all projected work” - then the org will just do the work they want (betting or no). Now your team is committed to delivering on your pitch - any other work just gets dumped on the wayside - unless you’re on-call of course.
As with any other incantation of an agile process, you can bastardize it to confusion, thinking you’re smarter, or “we’re adapting this to fit our org”.
Folks, this stuff is a discipline. You have to buy in, you have to learn the principles, you have to practice them - as described - until you attain some degree of mastery that you can adapt. This is not an individuals game, this is at the org level. The individuals must commit with the org to gaining mastery before customizing to your liking.
In spirit - there’s nothing fundamentally broken with Scrum or Kanban or ShapeUp or whatever. It’s really how you hold it - and yes you can shoot yourself and others in the face by holding it wrong.
Thank you for this. My sense is that shapeup requires more trust than what a large org is used to. Eliminates the micromanagement and limits the risk to n weeks.
There should be a saying, to the effect of: no enterprise idea can survive intact if it doesn't include a space for consultants.
Agile probably would have ended a lot better if it had been as designed... plus a requirement that you had to hire an agile specialist to sit in a closet.
The agile specialist doesn't do anything but sit in the closet.
... but on the plus side, the agile specialist doesn't do anything but sit in the closet.
Doubling down on my comments about ShapeUp (et al) as I reflect.
Engineering management, in my experience, has an allergy to agility. They can and do take any methodology, turn it into a process with a rigor (they love that) and strip agility from the mix. They are addicted to well defined requirements, some degree of estimation and being able to predict/project things like delivery, velocity, contributor performance, etc.
We engineers love the principles of agility, so engineering management tries over and over to find that happy medium where they have a well defined process that gives them what they want but imposes the least friction against the agility your engineers crave.
Custom solutions win the day. I have lived through all of the above. I remember when Agile was introduced, do you? Do you recall how violently reactive engineering managers were to this concept? It goes against everything they are supposed to do - manage. Agility inherently means they lose some degree of management ability. It means they lose their precious waterfall where things are meticulously (ridiculously, inaccurately, elegantly, uselessly) pre-planned on paper.
IMHO this is why we see every methodology that supports being Agile - bastardized to the point of confusion, academic arguments based on (not having actually learned, practiced, or gotten good at anything) gut feelings of “how we should do it here”.
Leading, managing work, organizing resources and getting shit done is a skillset that encompassing multiple disciplines. All are documented and practicable - we apparently don’t have the discipline to actually read and practice. We’re like a bunch of yokels on YouTube commenting on who’s a better MMA fighter, telling Joe Rogan he’s wrong - but only a select handful of us actually speak from authority. Only a small handful will actually take on the RISK of trying to understand the literature and practice a methodology like a beginner - without questioning the teacher or the teachings.
All that said. I have seen both Kanban and Scrum be wildly successful. The key ingredient in each of these was a shared humility and curiosity between engineers and managers and an environment that celebrated learnings and put no penalty on getting it wrong. The lack of hubris was absolutely the ticket to an agile environment where shit just got done, engineers had a GOOD TIME, we built meaningful product and we weren’t worried about blasting time in meetings because it never impeded our ability to get shit done. Once the engineering org can demonstrate its key metric (getting shit done) the battles with product cease!!! Product can trust that engineering will get shit done - without handwringing on “when” - and they can properly focus on “what” shit to get done.
When engineering is flailing around on their methodology, process or agility - they lose trust. That’s when product starts thrashing. That’s when you start to see initiatives/projects start and never finish, along with shifting priorities.
ShapeUp does an excellent job of giving product a tool to direct what work we’re doing - hopefully making sure we’re working on the right thing. However, if you’re trying to bastardize ShapeUp to fit your engineering org structure - it’s VERY difficult to demonstrate and project “well get this done”. Further, if you think you’re gonna keep your teams intact and do pitches per team - you’re already broken, committing to more than the org can deliver, creating conflict between teams on how to do the work, leading you right back to waterfall. Rather than building the right team of resources for the pitch/cycle - you now force all your teams to produce design docs, plans, backlogs - which have to go through review, get picked apart by other engineers, only to find your assumptions were wrong and the deliverable looks quite different than the design (shocker!!)
I’ll conclude to say we’re likely all doing some degree of waterfall++, branded as some form of “agile” methodology.
If you wish to see that change, encourage your peers and your managers to start with your team, pick a methodology, go exactly by the book, get “good” at it with practice over an extended period, collectively enjoy and DOCUMENT the many “aha!” moments along the way, the proliferate that out to the rest of the org. High performing teams are hard to ignore and at some point the org will ask why - simply be prepared with HOW you adopted and your learnings.
My hypothesis is that those people I worked with circa 2007-2015 that did Scrum really well (not everyone did), were happy about using Scrum, and delivered good results, ended up progressing/moving into management and lost contact with the day-to-day work.
1. They have an imaginary reality based on what it once was.
2. They don’t accept the evidence.
3. They have incentives to build systems of people to increase their salaries.
Can't speak to your company, but in my experience all Scrum (done well) is doing is making the overhead explicit and easy to quantify (as you yourself were able to do). Eliminating Scrum doesn't mean you'll save that time and overhead. It will simply be hidden.
Of course, that's with Scrum done well. If you're having 30 minute daily meetings, you have a point.
Scrum often has very subtle issues that snowball into chronic issues. I've never seen it done well outside of contract dev shops where they are literally negotiating and selling each sprint to a client.
I don't get your problem. What were you talking about on those meetings. Wasn't it about the project? Is discussion about the project, the features, planning lost time?
> some people had fewer than 3-4 hours per day to actually work.
3-4 hours per day? That seems like a lot to me! Looking at my calendar, I’m lucky if I get that many hours per week. (It’s not all scrum shit, but let’s just say between sync-ups, status reports, daily standups for multiple projects I’m involved in, architecture reviews, breakouts, etc etc etc, I’m lucky if I get a full work-day’s worth of coding done in a week.)
I've seen it suck even worse when trying to manage large X-Ops organizations. Something about the work, let's call it DevOps for the sake of simplicity, simply does not seem to lend itself well to the scrum methodology. Often priorities will shift rapidly even during the course of 1 working day, issues are vaguely defined and poorly scoped by nature (AZ1 cannot reach AZ2, plz fix ASAP), and the work is extraordinarily hard to measure complexity/effort (a one line config change can take weeks of investigation and touch tons of services).
I've seen plenty of people try though, to varying degrees of unsuccess. A kanban style system has always worked better for me personally.
See this all the time. There is a huge distinction between teams that are oriented to be proactively planned and teams that are oriented to be reactive. Neither is bad and both need to exist. Things will break people will have to fix them and therefore reactive work will exist.
Yes, exactly! In my career I am usually the first ops/DevOps person on the team. These are usually startups who have been run by developers. Nothing wrong with that, I've spent most of my career as a developer. But there is typically a huge blind spot with developers when it comes to ops. That could be a whole blog post and will someday, but relevant here is that they often do not understand when I try to explain how poorly scrum fits with ops. It can be remarkably frustrating for both parties to discuss how to plan ops work. Even breaking the work down can be a battle. Traditional software developers like to push for little chunks of work broken down into tiny pieces. However, when you are talking about a task that is completely and utterly unknown, and could take weeks to result in a one or two line config change, it cannot be broken down without visiting the future, finding out everything we don't know yet, and returning and planning it meticulously. Unfortunately, we don't have that time machine yet
I've seen this handled in various ways. Usually, the scrum master/PM will set aside extra "bandwidth" during a period that is expected to be heavy in interruptions. However, getting that right is almost impossible, and you can easily end up with way too much work in a sprint or way too little.
DevOps is definitely my favourite, since the history involved here is on the nose.
For those not in the know, "DevOps Days" was the conference that intended to deliver Agile to Systems Administration. The job title that was supposed to come from it was Agile Systems Administrator...
Alas, people got the conference conflated with the "10+ Deploys a day" talk from Flickr which merged ops and dev, and a mythology was born where everyone has their own interpretation of what devops means. :)
Operations is operations and fits well into the kanban system. Business operations should consider embracing kanban. Work comes in, work goes out, repeat.
Scrum (with sprints and things) should exclusively be used for New Product Development and Pre-Launch iterations. Using it for operations/ongoing work/enhancements is broken from the start.
"Waterfall" as defined by these articles is mostly a strawman.
Standups only work if someone is in-charge enough to keep them on track.
I agree that agile methodologies are a whole lot of bullshit, but the problem really is cargo cult.
Most people working in software are juniors, and that includes most managers. The fact that they have a title of "VP operations" 2 years after graduating does not magically make them experienced. What do they do then? They read books about "how to lead a team", and they blindly apply what they find there.
Because they have no clue. Many times they have not even had a team lead in there professional career themselves: they jumped right into management. And of course their team of junior developers (with high titles that don't make them experienced either) don't know better. So it ends up in a big cargo cult. Which sucks.
Wonder how 'Sprint', 'Scrum', 'Kanban' etc. all evolved out this? I really can't understand how it went from 'individuals and interactions over processes and tools' became formalized processes of daily standups, 2-week sprints, etc.
Scrum came from a world where product folks and developers never directly talked to each other. Everything was a formal written request with some requirements and there were SLAs for how long developers could look at it before providing questions and estimates back. After one (two if you're lucky) round(s) of questions a deadline is established, and work begins.
In that world, creating a single product owner that had the full complete say of this is what will happen that met with developers on a daily basis is a huge improvement of individuals and interactions. This is the single biggest win of Scrum, getting people to just talk to each other regularly, by having mandatory meetings all the time. If an organization has good communication or a product is too large for a single person to manage, Scrum ceases to be as useful option.
Kanban came from elsewhere. The word comes from post-war Japanese car factories, but the principle is older. Kanban boards were physical boards, with tokens representing various machines' or workers' availability, and the presence of things to work on. It's more a work-scheduling mechanism for known, understandable, repeatable work.
Interesting to know - thanks for the info. Strange to think that something designed for 'known, understandable, repeatable work' got adopted by software development.
Some software-related work, like regular changes to a website, or regular SRE work, is understandable and relatively repeatable.
Software development work usually isn't. Software development, by its nature, automates away everything repeatable and predictable, so unpredictable and never-before-seen stuff dominates.
Manifesto came out in 2001, you need to take into account the context of that time - the processes were often much more heavy-handed (esp. in big companies) than they are now. This manifesto item was never about not creating any processes.
I’ve said that many times over the years. The irrational mimicking of what others are doing created this Frankenstein model of working that proliferated over the industry.
And they self reinforce themselves in their biases. As long they say it's an epic and have a burndown chart they feel good. Nothing works, information is lost, quality and velocity is low, but we're very much agile.
One comment - the article mentions that Waterfall was basically the only approach used prior to agile. This is false. In some industries waterfall was used, but in others software was designed and driven incrementally just as with core agile. The work I did in fixed income brokerages in the early 90s was largely ad hoc agile.
Scrum is just one offshoot of Agile. It has become laden with jargon, Scrum-specific job titles, and rapidly trained Scrum Masters.
This obscures the fact that a competent team can start with traditional jobs and roles and use The Manifesto for Agile Software Development as their guide, with some modifications for a remote, Slack/Zoom world.
The XP folks crystallized what a lot of people were doing (in ad-hoc ways) and documented it so others could reuse the learnings more easily. [There's more to it than that, but that's the core of it]
I think that's in-line with what you described above. I also think it captured what a lot of folks were trying to do at the time: shorten feedback cycles with RAD, etc.
Scrum - or whatever it is that we see in the wild that's called Scrum - is exactly how you (and the article) describe. The way I see it, the corporate types were scared of the devs actually being self-managing/self-optimizing teams, and decided to turn to an Agile-Lite that they could sell as being new and shiney, but it's still the same command-and-control distrustful crap under the hood.
(Non-Scrum) Agile did a great job at the lower layers (devs, facilitators), but nothing can change that much if you don't affect the management and exec levels.
[Waterfall](https://leadinganswers.typepad.com/leading_answers/files/ori...) was an incremental design process directly in opposition to the hirearchial process that it's commonly conflated with. That's the paper that coined the term Waterfall, note the contrast between the final Waterfall process from the traditional process (figure 10). "Documentation Driven Development" is basically Royce's Waterfall under a different name.
Waterfall has the following 5 requirements/steps:
1. Design first. It'll get replaced (see step 3), but is needed for requirement 2.
2. Document the design. This defines what you're building (this time around) and the tests.
3. Do it twice (build a MVP, test, refactor & replace it as requirements become clear based on customer feedback, update the design & docs & tests, use those tests for the improved version).
4. Plan, control, and monitor testing.
5. Involve the customer.
Requirement 3 is what makes Waterfall inherently an incremental iterative process.
Most "Agile" proponents think of Waterfall as diagram 1 from the Waterfall paper, when in fact diagram 1 was the process Waterfall aimed to replace. It mostly gets used as a straw man process to oppose, few people seem to have ever read the Waterfall paper to begin with.
> but in others software was designed and driven incrementally just as with core agile
That's my experience also. Since the early 80's, every project I've been involved in was managed with a semi-flexible, pragmatic approach that involved breaking down the problem into smaller chunks, regular communication with the customer, etc.
The things I've taken from scrum and use at every team:
- plan in 2 week chunks
- estimate in points (relative size to something you've already done), emphasis on consistent estimates for each dev.
- make sure you define what 'done' means, and make sure it relates to what exactly you are trying to measure (Eg just coding effort, work till feature can ship?, etc). This is probably the most tricky bit.
- capture total velocity every 2 weeks and eventually use the avg for future planning
- review the entire process and modify things that take a lot of time for devs.
I have long abandoned scrum for Kanban. I don't care about sprints, and getting things done by the end. Just give me (or since I'm the team leader now often I'm the one giving) the next thing to work on and when it is done I'll start the next. Nobody cares about what you got done this sprint, they care about what what got into the next release. Next release includes a lot of manual testing as despite a very great automated test program we constantly discover a lot of serious bugs in manual test that are difficult to automate.
we gave up on points. All anyone cares about is days. Thus it is better to retro on the days estimate vs days to deliver and make adjustments on our end. Nobody cares about days for an individual story anyway - they want the days for the complete feature (or at least enough of the feature that we can ship it)
Yeah, you are doing it wrong if scrum is deadlines. I've worked with people who had to pull all nighters to get all sprint content done before the sprint closes. I'm using it more as a window to do some cheap analysis on our progress.
They are always deadlines as long as the cycle is official. An informal status update can be done with the project management tool, a 1:1 meeting or a quick team meeting (in this order)
> - capture total velocity every 2 weeks and eventually use the avg for future planning
I have never got to this stage. Someone is added to the team. Someone leaves the team. New team members get more knowledge. Old team members get sick or take a lot of leave. The focus of what you're working on moves from one part of the code base to another.
Every time you have to throw your velocity out the window because you're not the same team any more, and those metrics are for a different team that no longer exists.
You could argue points are useful as a discussion point to make sure there isn't some massive piece of complexity hiding in something (everyone says 3 points, the quiet person who knows the most about it says 13), but even tshirt sizing covers that imo, and regardless after that you should just throw them away.
Yeah, it won't work without a stable team. And that may be okay in a true agile environment but I've always had a manager who wants some type of estimate/high level schedule.
We do T-shirt sizes mapped to numbers, because recording effort in numbers lets you get an avg etc...
I’ve seen “scrum” work. The single most important thing we did was the retro always happened. In the retro we somehow managed to create a safe space where we could honestly discuss ways to improve. This may never be repeatable depending on the culture of the company, but the goal of a retro is to be a safe space where honesty is possible. Without honesty there can be no improvement to the process. Is some ceremony providing no value? That should come up in the retro. Proposed fixes should surface in the retro. Maybe you dump the ceremony, or do it less often. Ceremony is sort of stupid in general, but it’s often there because historically for some large percent of teams it was useful occassionally. It may not be useful for your team.
Retros are hard. Managers will try to run them. People can’t be honest with managers present. At least half an hour of the retro should be without the manager present. Retros should should also be long enough they feel slightly painful. There are people who have a hard time finding their voice in a group setting, especially with difficult topics. Giving them time and opportunity to speak is essential.
Retro's are at the core of agile, since they empower the team to finetune their own process.
I don't agree on the manager not being present. The manager must be present in my opinion, but I think you are facing a different problem: Your manager is the 'boss' and not at the service of their team.
Try to push your manager to be at the service of your team. If that doesn't work (which most probably is), go work for a manager that actually is at the service of their team.
None of the things the author complains about are specified in Scrum. The Scrum guide states that the developers choose the work: "Through discussion with the Product Owner, the Developers select items from the Product Backlog to include in the current Sprint." I've also heard people complain about the meetings, but honestly people hate meetings generally--my current team doesn't do Scrum or any other agile system, and we still have several time-wasting meetings every week. In my experience, scrum reduces the meetings you need to have to a minimum, and each one is there for a reason. If you use each meeting for its reason, they are valuable, if not, then sure, they probably are a waste of time.
I know that scrum has often been weaponized by managers and tools, but scrum doesn't prescribe this. Scrum doesn't prescribe story points or velocity or burndown charts. Those things may suck at your company, but they're not Scrum's fault.
Personally I like Scrum. I like the focus of the sprint goal and I like being able to show what I did at the end of the sprint. My team, as I say, has no process, and I started implementing scrum just for myself and my projects, that I work on solo. It's not perfect or ideal but it's better than any other system I've seen.
Having spent a year or so in a scrum and "scaled agile framework" shop, this resonates.
The disease is KPIs and metrics, and I'm betting it has gotten worse since COVID and WFH.
As the article states, teams have to focus on capturing every iota of work in tickets and stories and make sure they log the closures correct ly and tie every task to a greater story.
Scrum tools and pointing and tickets should support the goal of writing functional software. But when middle management demands 15 different KPIs determined by various calculations of time, estimates of effort and # tickets closed, the tickets/stories/epics become the goal, and development is the sideshow.
Before my devops role in 2019/2020, I was on a security operations team. We did our version of Kanban. It was simply organizing all our bigger goals/projects (initiatives with a definable end state) into backlog, doing, blocked, done. Operational tasks were worked on without documentation (daily software patches, on call tasks, etc) and small tasks from external teams were documented with a ticketing system and a 3 day SLO. A breach of SLO was not measured in any reporting! It was a good-faith goal that we met most of the time, and if it were breached and the external team got angry they could escalate to our manager.
The point is, the tools we used were made for the team's benefit of productivity and organization, without manager-observed KPIs. We just got shit done.
People who don’t use scrum or sprints or any of it, two questions: 1. Do you actually have very few meeting and all of them are meaningful and useful? 2. Is your work predictable and both devs and PMs have a reasonable idea of how much work is coming up and the nature of the work?
I’ve worked on “no sprint” teams and I end up having several “weekly checkin” meetings for different projects, plus intermittent “stand ups” that lack a clear focus, plus my manager discussing tactical matters in 1:1s and the work plan is still a clusterfuck where it’s hard to know what’s priority, what work is coming up, ensuring we have requirements clarified before starting work etc..
The biggest mistake I see people making with sprints is not understanding that you cluster your planning over 1-2 days then you have 2-3 weeks with basically zero meetings besides standup or working meetings like system design. The benefit of scrum is lots of heads down time, the cost is you’re not allowed to just book meetings Willy nilly whenever you want. Most places I’ve worked have wanted the benefit of sprints but not understood or been willing to pay the cost (no-meeting weeks). So it’s agile rituals plus whatever other meetings you already had, and of course that sucks.
I feel like agile processes are this boogeyman and people think “just get rid of them and we’ll be good!” but you need some process or else work is chaotic. So what’s the better process that works for you?
I do monthly sprints with just 3 stand ups a week and an extended mid month checkin. No other ceremonies. Planning is done ahead of time by leaders without every IC present. Design is done by ICs as part of tickets in a sprint like any other work ticket. Basically no retros or any other ceremonies and it works well. No points or ticket estimations or time tracking. All working great.
I sometimes wonder if some of the agile methods overly fetishize some kinda democracy which adds way too much bikeshedding and overhead. Whereas if you just provide sane leadership and planning. Everyone is happy to do their part without endless rituals.
The term scrum comes from rugby, and it has nothing to do with organization. It's literally when something goes wrong, pack everyone together and get the ball moving again. Symbolically, obviously, ball=project.
The problem, like everything these days, is corporatism. Things have been added to the old development model to create positions for knowledgeless managers to do nothing and make money. Agile means fast without preparation. That name no longer reflects the model.
These days, businesses have become so ritualistic to maintain power structure that they're inefficient, and morale is low. It gets to an unsustainable point and fails, meaning mass layoffs and restructuring, or the organization itself going down.
The real purpose of the scrum in rugby is to tie up half of the players (the forwards - the backs are not in the scrum) when restarting play.
Literally to remove the forwards from the play after a restart, by having them all bound together with their arms twisted around each other.
Then, when the ball pops out, the field of play is nice and empty for a few seconds and some running rugby can take place, while the forwards slowly untangle themselves from the scrum.
To translate to software engineering and agile, if scrum is taking half of the team's developers and tieing them up and preventing them from doing any work, then scrum is working exactly as intended.
To expand the analogy further the scrum, in modern rugby, is the worst part of the game and has gone through several iterations the last couple of decades to reform it as it often ends in a stalemate or arbitrary penalty to one side (as good as a coin flip), or worse: a head injury.
The approach has seen the game settle with "Crouch, Bind, Set", which seems to be a good compromise. And yet the hooker always, alwaysALWAYS, puts the ball in crooked and yet never gets called up on it.
In other words, it's all a big waste of time and energy.
(We're using agile at work, daily standups and retros, and it seems to be working)
Gah! Brain, I was thinking about which player usually strikes the ball first (hooker) rather than who feeds the scrum (scrum-half). Point still stands though I don't think I've seen a straight feed in years, at least in the Six Nations matches.
You are right, but in this case I have some sympathy for the argument. If all the technical terms in one methodology (scrum, sprint, velocity, commitment, ...) look like they were chosen not in good faith, well...
It's interesting to speculate on why, if Scrum is so bad, everyone uses it?
Is it because everyone is an idiot (e.g. management)? Or for some nefarious reason? Or maybe it isn't actually that bad?
On one project I was on, there was a contractor company billing millions per year to create a React admin tool frontend. Many developers involved, Scrum master full-time, and so on. Tickets were created for small parts of features, of course not considering anything more than 2 weeks ahead due to agility, then later other tickets would be created for the next phase of the feature so everything that had been done so far had to be thrown away as it was wrong (great for billable hours), etc.
The person on the customer's side managing this didn't really know what they wanted, so was happy to be told that, due to agility, they wouldn't have to specify anything more than two weeks ahead. A big decision can't be wrong if you aren't allowed to make big decisions! Can't get fired for decisions being wrong if you aren't allowed to make them.
So everyone won out of this situation really.
I don't know if there would have been a better way to manage this project. But I can see what everyone got out of it.
Because Developers are not the only stakeholders. Management and marketing needs to know when the next release will be. In a complex project it doesn't matter if you are ready to go with your part if someone else just merged in a new feature that is crash prone in situations they didn't think to test. In a complex project you may also depend on hardware being delivered at the same time. In a complex project there may be people planning when they can safely role this out to their system.
Agile works great for a small project where a few developers is all you need. However few in the agile manifesto seem to have thought about how to scale it to larger projects. That isn't to the manifesto is wrong - it very much fixes some real issues with previous project management. However some of those real issues were an intelligent response (not to be confused with good!) to even more complex issues that you cannot ignore just because they are causing issues.
Scrum is one of the few that thought about the large project problem, and so it appears at first you can scale it to larger projects. However now that we have tried it for a while I can safely conclude it isn't a great fix. I'm not even convinced Scrum is better than waterfall (waterfall has iterations - version 1.0, 2.0...), though scrum and waterfall get different things wrong with project management.
Of course the next question you should be asking is how do you manage a large project. I do not have an answer. I haven't even seen evidence that anyone has found a good answer despite many smart people facing the problem and thus thinking about it.
Management and marketing needs to know when the next release will be and what will be in it. Cutting things up into two week segments, and religiously opposing any attempt to plan together as group or come with rough schedules undermines engineerings ability to interact meaningfully with those people.
Sales people, investors, and customers really don't care about how good you are about meeting your scrum targets or how many fictional story points you're able to get through.
It's also possible that we have forgotten what anything else can look like.
For me, I'm a senior technical leader now and my entire professional career has been Agile and Scrum. I haven't been exposed to other techniques.
Better not upset the apple-cart, we all know how it works, and besides, it's the defacto for a reason... right? (this is tongue in cheek but to be fair, I make decisions like these subconsciously all the time; "why do CI/CD", "Why use GIT as SCM", "Why do peer review/MRs" --- because I always have and it seems good enough on the surface)
> It's interesting to speculate on why, if Scrum is so bad, everyone uses it?
Scrum is bad (as implemented by bigcorp), but waterfall is worse (as implemented by bigcorp).
A simple example from my past. My team was scrum based in a bigcorp that mostly did waterfall, so of course we did scrum badly too. That said, our scrum team shipped a major integration feature in two sprints (4 weeks) that the partner integrating team inserted into a 14 month long waterfall release train. It took ~16 months to ship a feature to customers that took 4 weeks to build and internally validate.
If there had been less bigcorp bullshit said feature might have taken 3 days, but at least 4 weeks is better than 14 months, although in this case customers got the worst of both.
It’s a combination of cargo culting (nobody ever got fired for using Scrum!) and consultants who use it as a form of leverage to extract billable hours from their clients.
Scrum is a decent framework for teaching business stakeholders how to work in an agile fashion, and to force some developers to always have releasable software.
But at a certain point people get so attached to the process (or teaching process) that they get scared to take the training wheels off. So yes, Scrum sucks.
From a more constructive "what is there besides scrum" I've been enjoying this persons blog and especially his book on software systems: https://softwarecrisis.baldurbjarnason.com/
"Way of work should be defined at a team level by its people, not by the company." - This is basically the origin of scrum.
Essentially every problem ascribed to scrum is its departure from this origin story.
Scrum is about making each team work better, but somehow it turned into the same weird top-down imposed structure that it was supposed to replace. 2 week sprints are mandatory for all teams? They all have to start and stop on the same day? And you can use any story point system you want as long as they neatly summarize into these t-shirt sizes?
There is little resemblance between the agile manifesto and what people are pretending to do today.
Ha! At my old employer they used "Scaled Agile Framework" (SAFe).
About a dozen teams of developers and operations people got together once a QUARTER to determine what big epics/objectives to complete, and then develop stories and estimates (points) for those stories and roughly which sprint they would fall into within the "iteration", as the quarter was called.
Every team on the same sprint schedule. Fibbonaci story rankings across the org. Product owner and scrum master would be shared between several teams, IIRC.
And of course, middle management observing the aggregate amount of work estimated vs. completed every "iteration".
Don't forget to tag and label every story appropriately, use the corporate standard for sprint names, and file those tps reports on time. That would be great.
I feel like that's unfair. It's normal in a company to answer to someone and its normal for that someone to want some way to answer the question "are we on track for X" when asked by their superior (whoever that may be). The larger the company the more that statement becomes true because the number of interconnect for N employees is O(N^2).
That does not excuse making the whole thing stupid and painful, but accountability is not an unreasonable request.
Of course! The problem is that this "accountability" is the grease on the slippery slope towards doom.
If I need every epic, story, task and subtask to be labelled in the correct way for your organization, then I no longer have an autonomous team that is able to self organize to maximize its own efficiency.
If I don't have that, I no longer have agile. There are better ways than turning agile into a caricature of its former self.
I have never, ever worked at a company where I e joyed any form of agile or scrum. All it did was kill my joy, add more meetings and complicate even the simplest things. I honestly wish it would just go away.
Scrum/Agile is awesome! I always used the daily calls to ask as much dumb shit as possible to make the meetings as long as i could so i could keep charging my hourly rate without actually working.
And I have gotten rid of people who were very clearly just being pedantic during every meeting and then would have a million questions (or just not build things to spec) when it came to time to actually work.
I wish there was an executive scrum that the rest of the company could see what their work load was for the week and how it was co-ordinated.
My feeling on scrum was it was always a way to daylight what people were doing for upper levels (and co-ordinating that work). It would be nice to see what higher echelons were actually working on.
Same could be said about logging in. Now that all my local shops manage a facebook page instead of a website, facebook nags me to hell and back to log in, and not even shows everything.
This article looks basically the same in FF reader view as the original, except for a banner that appears at the bottom in a private window that some cookie must've remembered I closed long ago. What am I missing?
You know when some tools have a section When to use X and When not to use X ? (e.g.
https://htmx.org/essays/when-to-use-hypermedia/). Management frameworks like Scrum should have the same, and should not be followed blindly. There are specific historical contexts and reasons why they were invented and those should not be ignored.
Scrum isn't the problem. It's your company's culture or whatever other dysfunction exists. Scrum is just how developers experience that. You could switch systems, but you'll just get beatings of a different flavor.
7-10 people gather in a circle every day, they all say “no blockers” or some talkative person diggs up some detail that sounds like it’s for another discussion, then they repeat “continuing to what I did yesterday” because we all already know, the scrum master tries to say something new but it sounds like BS, meeting over and we are all shaking our heads thinking “another waste of 10 minutes”
Take the retrospective seriously, as a moment to reflect with a clear mind, over what turned out to be a good strategy, how to iterate on that and praise the team for the job done.
I suspect you can probably predict how effective a scrum style team is based on how effective the retrospective is.
I retired two years ago, but finally made peace with SCRUM in my final years by eliminating standing team meetings for retrospective / review / backlog.
Backlog - groom during long/medium term planning. Not everyone needs to be in the room for this, just leads. Use 1:1s to triangulate on issues that we're ignoring or under-resourcing.
Retro - on an infrastructure team, retros are already built into the incident management process.
Sprint review - start sprint planning by asking how'd the last sprint go. Did anything gunk up the works? Are there any promises we didn't keep? The rotating on-call and triage (secondary on-call) would fill us in on any active fires, or less us know if we can/should hand ownership of an issue to another team.
I had an interview where communicated some critics of scrum, some that i agreed with experience and collected through posts about it etc, and was dismissed even without receiving no counterargument during the interview because they were looking some strict believers of scrum, it was an interview with a couple of non tech managers, i guess that’s the issue, scrum is a shallow version of XP who serves non tech middle managers, there is no criticism about it that can be useful to change anything, tech people already knows, but until companies keep useless middle managers around, the tech people just have to accept it
I get really tired of seeing this once a month. OP had a bad experience with Scrum. Lots of people have. I've seen it be incredibly effective. I generally prefer Kanban, the principles are mostly the same. In my experience, the effectiveness really boils down to team maturity. The crux of the process revolves around writing user stories that define an increment of user value and executing on each story past all defined quality gates in strict priority order. It does not and really cannot make a team actually operate faster, only deliver increments with observable velocity. In practice, most teams will end up going slower, but delivering more accurately and reducing rework or unmet expectations.
At best, Scrum or Kanban with a tool like JIRA are really there to establish a shared vernacular and facilitate clear communication and manage expectations. And if done properly, they are incredibly effective.
My biggest problem with Scrum in particular is really the word "Sprint". It implies we're all rushing to a goal and that's really never the cast. Literally just rename your 2-week iteration as a "Slog" and change nothing else and see how people react.
Where the process typically breaks down is being unclear about priorities, working on too many things at once, skipping quality gates, defining tasks instead of features or trying to estimate an entire product backlog at once and setting a deadline that is utterly doomed to fail.
I've never worked in a supremely functional scrum org, but as others have stated it may only really work if the whole org is on board.
In places that I've worked there has always been a fundamental tension between how developers/makers work best ("leave me alone! It'll be done when it's done!") and how the rest of the world expects things to happen ("I need to know if it's going to be next week or next year"). I imagine organizations that can take the "it'll be done when it's done" approach are very much the exception.
So in the usual case that means that developers have to "waste" a not insubstantial amount of time making plans (that may largely be thrown away) and estimates (that might be off by an order of magnitude), and then course-correct over time (trading off time, scope, and quality) as they learn things while doing the project.
The other thing I've found over the course of the last ~25 years is that any kind of system (waterfall, scrum, GTD) is an abstraction that inevitably leaks. It's not somehow provably correct that if you follow a system perfectly that nothing will fall through the cracks. You can either admit that any model of the world is necessarily simplified, or you can keep retroactively adjusting your definitions of things in the model and at some point end up like a game developer treating a subway train as a piece of clothing, or arguing about whether a particular body of water is a "pond" or a "lake".
Scrum was my first real experience where I saw marketing people and consultants take something beautiful and just smash it into the ground and turn it into a parasitic money and time suck, a twisted parody of what it was meant to be. It made me more cynical but perhaps better prepared when things like that happened later in my career, like DevOps.
Bad management will turn any methodology into a bad experience. I also think scrum, and especially its implementations that I have been subjected to, could use improvement.
I dislike the artificial time-constraints of the sprint, and the PI in SAFe. In my world, I wouldn't concern engineers with deadlines, but rather I'd have them work continuously, like in kanban. I think it eliminates overhead, and if velocity, and other such metrics are desired, management can conjure numbers out of thin air, just as they always did.
Without sprints, there would be no need for planning either, but I'd hold refinement meetings regularly. What I'd do is break down the work into tasks and create a dependency structure, like the Critical Path Method in project management.
I'd estimate in person-days, and that person would be a hypothetical normal teammate. Like, the best guy would do it in half that time, and a junior would take twice, even with hand-holding.
After working in teams using Scrum and fully unstructured “trust the engineer”, I agree there are certain parts of Scrum that feel like dead weight / overkill.
Daily standup can feel productive when you are doing it, but I think you have to be a very small and nimble team with high density of juniors for it to be appropriate to meet that frequency. With a mostly-senior team folks just reach out when needed to unblock each other, and proactively broadcast async updates. Tooling to encourage this “ambient information” is I think under-invested. Takes a lot of discipline in Slack to prevent channels from devolving into noisy discussions.
I think a lot of teams think they need more predictability than they actually do, and sizing/points are overrated. Again this is contextual; in some projects you really do need to forecast a Q/H roadmap for customers. But if you are shipping every week or two, sizing barely matters as you can just Kanban it and keep picking the most important item to work on each sprint.
I think retro is mostly time wasted. You can fill an hour per two weeks with it but I’m not convinced it’s the best use of that time when you are moving fast. Async tools that can measure a pulse survey & flag common themes that are bright red/green is probably a better place to be.
I think some sort of stakeholder review on a regular cadence is great, and sadly is the bit that is taken least seriously in Scrum IME. When stakeholders (in small companies this means CEO and the rest of leadership!) take this seriously you get a great feedback loop. Too often I see folks skipping as they have “real work” to do. I think this also points to lessons for the engineers; really need to keep things snappy and customer-focused. Have your tech-facing demos another time. Or, even better, record your product facing demos and post them, so you can get feedback async. If the CEO comments regularly on these it can still provide that feedback that the meeting / demo is valued and important.
It would be interesting to attempt an analogy between software development processes and parallel computations. Let's analyze which job tasks are atomic, parallelized, depend on read or write operations with common shared data, and the costs associated with setting up new job tasks.
It is likely that we would discover that the majority of programming tasks are not parallelized and are costly to set up, especially if frequently switched between job workers. This is because programmers need to delve into the problem domain, the existing code base, the API, and various other factors before commencing an actual task implementation.
Assuming that task workers are fully fault-tolerant ("no bus factor"), the optimal design would involve dividing the code base into loosely coupled modules, possibly organized into a hierarchy, with each module's management entrusted to a single worker (programmer). To mitigate the fault factor, we might have substitutional task workers dedicated to critical modules.
Regarding other task types, such as manual testing, these are usually less expensive to set up, do not require write access to the code base, and can be efficiently implemented by worker groups not bound to specific code modules.
This approach should be scalable and could effectively contribute to product quality. However, it necessitates the business being run and owned by programmers, and more crucially, earning revenue directly from end users who value product quality—a major success factor for the business.
There are successful examples of businesses following this model, including many indie game development studios and some software product businesses. The scarcity of such examples in the broader business community is attributed to the fact that the majority of funds today come from large corporations and ultimately from governments. This system undermines the free market, impacting everything in software development, from product quality to development methodologies.
Works great for us. Things that usually indicate that you're not working with agility: spending more than 10% of your time on process/meetings, have professional project managers 100% dedicated to processes, team unaware of mid and long term direction, team talks about scrum stuff instead of what they're working on, ...
I've learned to avoid any shop that has professional project managers doing what they term "the agile processes" instead of the team itself, as those shops are generally buzzword compliant cargo cult ghettos.
I get the "no true scrum master" thing. It's real. However, I was trained by Ken Schwaber, and I'd say most shops who say they're doing scrum are not doing anything that actually resembles that training, other than the lingo.
Scrum/Agile as it's practiced was invented in large part at consulting companies who were dealing with toxic clients. If you need a methodology to defensively manage a bad client then it's a pretty good cool.
As for the other parts there's a general problem of people applying a tool they don't understand. The benefit of a daily scrum meeting is not to remove blockers. If you think that's the point of the meeting then you've failed already. It's to build team camaraderie through repeated casual interactions. If you think it's there to remove blockers than you're tempted to try to eliminate those casual interactions instead of facilitate them and you end up doing the opposite - you erode team culture.
You forgot adding lengthy descriptions and constant updates to each ticket. The person who pushes the most tickets and with most words per ticket gets promoted. You're better off spending time optimizing JIRA than doing actual work.
That section describes various scenarios how scrum can be misapplied — starting from a team that doesn't find value in it ("Does your team still attend the stand-up meeting [without PO and SM in the office]? I doubt it."), and ending with various organizational dysfunctions (bosses, hierarchy, confusion, estimation, someone writing useless tickets, people not collaborating, and so on).
Why are those organizational dysfunctions Scrum's fault? Why is the title of the article "Scrum sucks"? Not clueless bosses suck, or orgs that are too firmly set in their ways suck?
I sometimes wonder if agile/scrum’s inefficiency stings so much because of its disconnect with the end product. Or, you end up being involved in a bunch of bureaucratic work as a programmer, even though you can see the codebase’s flaws in plain sight. You can view a peer’s backlog, but also see their concrete work on GitHub. The map truly isn’t the territory.
I haven’t really been wowed at all by LLMs over the past cycle, personally. That said, I wonder if it could truly shine as a tool that could conversationally explain a codebase to management to empower staff and cut down the red tape.
> "Way of work should be defined at a team level by its people, not by the company."
OP delivers that like a surprise, but isn't that the single core defining tenet of Agile? I thought it was.
> Sprint Planning — as simple as it seems, a long session (up to 4 hours)..
My big insight is, painful sprint planning is a result of painful deploys. Once you accomplish real CICD, you can just dispense with sprints and sprint planning entirely.
I'm not sure if that's something most people would agree with or not so I won't belabor it unless someone argues, but I can go on at length about that...
I think one of the biggest mistakes of Scrum is the Sprint concept. Artificially carving work into an X-week, immutable window makes no sense. Plan releases for when feature sets reach the level of maturity users and product folks want them.
The Sprint approach leads to half-assed features hiding behind a small army of feature flags.
At a minimum, if you can’t get rid of sprints, at least change the default 2 weeks into 3 or 4 weeks. Your meeting burden will go down add you’ll actually have time to deliver working features.
Sprints make/made sense in the world of slow deploy cycles, especially for lengthy manual regression testing. If it takes you three weeks to get from a story being done to a story being in production, deciding which sprint a thing goes in is the difference between customers getting it on day n or day n+21. Once that's not a problem you can kind of forget sprints exist.
I feel like I have to add insult to injury: the extra people who work full time to manage the scrum overhead earn more than the average dev - at least in the EU. Devs over here are criminally underpaid.
I'm a scientist that through a lateral career move has ended up doing something akin to software development. This means for the last few years I have attended daily scrum meetings for the project I'm working on.
Perhaps it's my inexperience with software development, or maybe it's specific to the company I work for, or the people on my team, but but I find the entire process a gigantic waste of time and mental energy. How does everyone else deal with this? Is there a better way that will help me not dread attending my standup?
Scrum is not the problem.
I worked with waterfall, Scrum, Extreme Go Horse, etc.
All the methodologies I was forced to work on basically didn't work, all the methodologies are just a play of “business theater”.
Someone with the power to decide decides to use anything fashionable, now it's Scrum, but it used to be something else. Whoever does well in this theater isn't a good employee, it's whoever does best in the current play.
My defense in the face of all this nonsense is to be professional, because the company will never be. I start work on time, do my work, leave on time. I help in emergencies, but if emergencies become the norm, I change sectors, hours or companies.
I try to avoid meetings. I say “I’m working on something important.” Always works.
I never allow anyone to disrespect me (I know a company with “physical punishments”). If that happens, I'll change companies.
Again, Scrum is not the problem. The next fantastic methodology will fail. It's just a Play, and you need to be an actor, or move to a theater whose play is in pre-production...and enjoy it until the play starts to be performed.
I wonder how Lockheed used to manage their successful projects like U2, which was delivered ahead of schedule and under budget. Joel Spolsky used to say that FogCreeks didn't need much project management because pretty much all the dependencies can be mocked out, so everyone would make progress in parallel. If someone needs to know where the project is, well, there will be plenty of offline channels for that. Daily meetup is silly.
Scrum is really useful for exploration and innovation work, things that may not even involve programming.
In general I think sticking to Scrum for Software Engineering is overkill, or maybe the 2 week sprints are too short.
I've had much happier engineers and product owners when working in Kanban, a steady stream of work with as few meetings as you can manage is much better for SE work, it is harder to get it up and running though, and can take some time to bed in.
Any eng project management practice that has its own name sucks. Same goes for programming paradigms. I like my team to be free of this pretentious stuff.
Developer-only "agile" never works, no point in ranting about the details. Either your company is able and willing to develop a product incrementally, or they’re not.
Agile is not going to help you better track a project that the rest of the company treats as waterfall, fixed date, fixed scope shit.
99% of the ranting about Scrum or whatever is about typical shit project management, that they've bolted agilish lingo to.
I believe that the most valuable aspect of Scrum is the retrospectives. These are recurring meetings where we assess what has been effective and what hasn’t. If the retrospectives consistently focus on the same issues, such as ongoing complaints about test environments, this also indicates a fundamental flaw in the overall architecture.
The best is when you, as a dev, get to have a struggle session with project planners because "your group's estimates are consistently half of the required points to complete the project." But, for some reason "then just double our consistent estimates for your purposes" is treated as a joke.
Correct me if I’m wrong, but Sprints only make sense for teams with more than, say, 4 engineers.
Because a Sprint is fundamentally about estimating bandwidth. You look at the old Sprints and are able to average out some kind of true estimate of capability, right?
But if you have a smaller team, everyone basically already knows what your bandwidth is.
I would say that a sprint is fundamentally about delivering a valuable Increment. Something useful, some kind of meaningful progress. You can start to use past performance as a way to estimate what you'll be able to do in the future, but only with a stable team that has been estimating its own work for a while.
most of the discussions on SCRUM come from people running scrum or commenting on scrum as employees.
scrum exists because companies are paying salaries for engineers and dont want them sort of milling about doing random sh*t all day in an aimless fashion.
my experience is most engineers are incredibly passive and just want a paycheck and are barely productive.
except management is often completely clueless / non-technical / not interested in technical topics / view technical stuff as being "beneath them" sort of like taking out the garbage or cleaning the windows.
solution is to create a pseudo-science pretend self-governed democracy.
let the engineers manage themselves! genius!
It is a zero-interest rate management cop-out for badly led highly mediocre companies with a lot of dead weight.
make the over-hired engineers engage in a lot of activity so they seem to be making progress.
scrum needs to be looked at in context of past economic conditions and the structure of the market. lots and lots and lots of engineers work in these environments of non-technical management who just want to see "activity that looks like progress" and dont have any intention of getting more engaged or involved than that.
compare to startups where the ceo is often an engineer and doing the work themselves
I think scrum is going to die a horribl death in a high interest rate environment with AI.
the mediocre overpaid middle in tech is going to get a very hard re-evaluation
so is mediocre middle management
all of that needs to go away
mediocre middle management and scrum and over-hired, bloated organizations are all phenomenon of low-interest rates.
in a tight environment, I hope that talent is what matters and all that gets the chop.
I think scrum will be categorized with "sitting in cubicles" as a productivity method in the near future.
The real culprit is coming up with a bunch of metrics that fail to model the actual performance of people. It instead incentivises going after the metrics. The type of orgs likely to metric-ify just happen to overlap a lot with the people that prefer scrum or agile or whatever.
If scrum sucks, suggest better. Waterfall is not better for software development. Author gives examples from bad management practices, work load, overloaded job queue and points all the problems to scrum but scrum has nothing to do with these problems.
I have my own (and many) criticisms of Scrum, but this article is so poorly written that I cannot say whether the author's views align with my own. I couldn't make it beyond the first few paragraphs.
SAFe is a cancer. In my experience scrum is done absolutely wrong, every time, and teams should be able to decide the most effective way to manage themselves, not top-down directives and one-size-fits-all garbage.
Holy shit people - scrum does not work without a fundamental understanding of the theory of constraints.
If you're burndown chart isn't burning down, something is blocking your team. A manager finds out what is blocking the team and works on it.
If your team has a bunch of tickets in process- then your WIP is high - that's bad. Someone taking on more tickets to just get to work should be pulling the equivalent of an Andon cord.
Tasks should not have estimates - tasks should roughly have the same time to complete - a task that takes 10 days is not a single task.
A sprint meeting should only assign new tickets based off the previous rate of completion. Adding more WIP only fucks things up more than they are.
Management sees the rate of completion of features - and then calculates the time to project completion in sprints.
IF YOU HAVE A DEADLINE and you're missing it...
- cut back on features
- or find out what's blocking your team.
Developers need to be told to emphasize and raise up items that are blocking them.
In any value stream - there is only one current constraint. The rest of the production process needs to be subordinated to the constraint.
Is it pull request reviews? Is it the QA process? Is it ambiguous tickets? Are questions not getting answered?
> I really believe there is one, but I have never seen a single engineer happy about their company Scrum implementation.
Yeah, I think that's an example of good idea but too easy to badly implement. With cargo cult and all that, people try to take it ready-made and don't event try to understand why things are done a certain way. Result is unavoidable garbage. I've never seen a good implementation as well
> One is on sick leave and the other has a well-deserved PTO or holiday.
Does your team still attend the stand-up meeting?
In my manager years, I've been using this as a metric. If I'm not there and meetings don't happen, it's probably a sign that the meeting isn't useful.
> Sidenote: I always disliked this religious term used to define these kind of meetings, but ok.
I've always read that as sarcasm though, precisely because ceremonies and masses happen religiously without questioning whether they should exist
I am using Scrum since 2006 and have worked with 30+ Teams so far. I don´t care for Scrum or any other framework, i only care about creating great organisations that empower teams to generate value.
In 2022 + 2023 i conducted about > 220 insight interviews with Scrum Masters, Agile Coaches and Product Owners for a product i am currently developing.
There was a VERY VERY clear pattern:
1. almost all teams where using Scrum or Kanban or some mixture of it
2. less then 1% of teams actually had a product vision, product goals or a sprint goals
3. nobody was actually doing "inspect&adapt"
My assumption #1: it is not the framework or the people, the failure is within the system.
My assumption #2: every company is different, a company is a complex system and many many factors contribute to the outcomes, nothing is clearly black or white. Any framework needs to be adopted with the core concepts in place; with Scrum the core concepts are usually not implemented and therefore Scrum fails.
() Site note: training standards of people seems to be very low; a lot of Sscrum Masters and even "Agile Coaches" cannot explain even the basic concepts of Scrum and Kanban.
Example: What is the purpose of Daily Standup? How can you assess the quality of Standup? How can you improve the Standup?
So what is wrong with the system?
- company does not have a product strategy, only tasks like "develop feature X"
- company does not have strategy management processes in place
- there is NO collection of meaningful data regarding process health and performance and specially Scrum Master work against creating transparency (out of fear)
What is the solution? Implementation of a framework without robust performance monitoring is pointless and failure is certain.
The issue? It seems that Scrum Masters push the most against performance monitoring out of fear to become transparent. Also, being transparent in an company with low (psychological) safety might be professional suicide.
People forget that Scrum was developed by observing successful (senior) teams, but if they don´t understand how value and waste it generated it is meaningless to follow any framework.
Example: Having a lot of meetings does not generate the waste, it is only the symptom. The root causes of many meetings are inefficient management and communication structures. In order to avoid the waste you don´t need to remove the meetings, but first resolve the underlaying issue(s) and then the need for the meetings disappear. Removing the wasteful meetings might actually create more waste/harm, as the company might perform even more badly afterwards.
So yes, individual developers might get more working hours but generate less value over time. The purpose is not to maximize the working hours of developers, but to maximize the value generated by the team. The assumption that "more development hours = more value generated" assumes that alignment with product goals, teamwork and cross-functional collaboration is in place.
Scrum sucks and much like HR it’s a made up field to get buddies employed for literally no ones benefit except their own department. Stand ups are never useful. Never. Not once in the history of the human race has an engineer ever though man I’m so glad I read out the state of a jira ticket to someone who doesn’t even know how to push a git commit.
Scrum doesn't inherently suck. Scrum can work if you do it right. It won't if you don't.
Just leaving it up to the individual team leads to the same result. If the team sucks at managing their work, the team will suck at managing their work. It doesn't matter what you follow if you suck at it.
This isn't as catchy and feel-good as the bullshit clickbait that reinforces what you want to believe (that the process is the problem, not you or your team). But it's accurate.
While some of the points in this post are valid most of this is just copy-paste non-sense stated in multiple articles. Of course "Scrum" cannot fix your problems if you have bad engineers who are happy to just "close" tickets or you have an organization where you do not know where to ask "who is knowledable about this business requirement". Scrum is a software delivery methodology which is ok in itself, it is not a silver bullet which will enable you to write great software which meets specification and runs for years without bugs, those things are completely tangential and require a specific set of skills.
I presented the number of hours (meetings multiplied by engineering participants) to our VP and he insisted I must be wrong. He insisted there was no possible way we could be spending that much time doing Scrum things and that I must be exaggerating or lying. He then fell back to a lecture about how Scrum is an industry standard and how it's more efficient than alternatives.
Really opened my eyes to the disconnect between Scrum mythology and Scrum in practice. The amount of time lost to doing Scrum things was so out of control that some people had fewer than 3-4 hours per day to actually work.
Of course, the Scrum proponents will rush in and tell me that we were doing it wrong or that it's not truly Scrum if it's helping more than hurting, but these people were highly trained in the ways of Scrum and Agile and pointed to various Scrum and Agile books and certifications to defend their ways.
OTOH, I have been on very small teams where Scrum was implemented with low overhead, but those teams were filled with efficient people who would have been productive without formal methodologies either way.