15 ms·

How to distort Scrum until it no longer works

144 points by tapanjk 4y ago

enb 4y ago
What’s a good alternative to Scrum?
- nivertech 4y ago
  1. Shape Up method, for feature delivery at a small product-led company (e.g. SaaS startup) 2. mini-Waterfall: design -> plan -> build (iterate) -> ship - for platform/infra, or any other heavy engineering work 3. informal SDLC combining modern best practices in SW Engineering 4. Kanban for reactive work (bug-fixes, maintenance, QA, support, ops, etc.) 5. RUP (Rational Unified Process) for Mission/Safety critical systems 6. GROWS method - more like a collection of patterns / best practices 7. The GIST framework (Goals, Ideas, Steps, Tasks) - mostly about product management, but can be combined with Kanban There are many others, but they're either lacking communities (i.e. used by a single company only, no books/courses), and/or IMO not very good.
rightbyte 4y ago
I am so bitter about agile at this point it actually feels abit refreshing that someone still defends Scrum. > You’ll know you have successfully ruined your standups when they’re taking thirty or more minutes The author is an order of magnitude off here. The despair sets in way earlier.
- theshrike79 4y ago
  60 seconds per member of the team. 15 minutes hard limit. If there are issues, you handle them outside of the daily scrum, it's not a troubleshooting session, it's a status update.
  - lowercased 4y ago
    then you'll also have folks who would say "if your daily standup is a 'status update', you're doing it wrong". and they're probably right. scrum.org - "The Daily Scrum is a 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours." Most "daily standups" I've been at are performative song-and-dance with non-dev stakeholders running the meetings. They're definitionally just status meetings. There's no internal 'dev-only' talk, or identifying problems to work through, or sharing knowledge. Nope, it's just 'all non-devs need to know the status of every issue in a jira board, daily'. Why they can't just ... you know... look at the jira board they're forcing us to use, and see the status there... I dunno. Half the time when I'd update something there, I'd repeat in a meeting "all this is in jira". "Oh, I don't have time to comb through all that - it's too slow". OK... but if I DIDN'T update jira tickets... that was slowing down the team because "now people can't tell where you're at". So... there was no way to 'win' there...
    - deckard1 4y ago
      the whole Jira thing really pisses me off. I hate Jira almost more than this scrum/agile nonsense. If no one wants to look at the damn board, why are we doing this?? > with non-dev stakeholders running the meetings 9 out of 10 standups I'm in have zero of the stakeholders necessary to unblock the work. I'm announcing my blockers to other devs that zoned out 10 minutes ago and the scrum master that will say something hollow and silly such as "keep working on that" or "make sure to ping so-and-so." Thanks. Want to come to the restroom with me and hold my pee pee so I don't fuck that up too? We are all infants. Also. Allllllso. Scrum Master. Scrum. Master. Shouldn't you people be Scrum Main? Or Scrum Primary? Or did you not get that memo? They are literally keeping their developer minions in check. It's a bit... how do I say this? On the nose? Much more in a way than a branch name of git ever was.
  - rightbyte 4y ago
    > 60 seconds per member of the team. Ye, on average. Most people should ideally, in my mind, say "same old, same old" and let the next person speak. I don't like the concept of dailies, but if there has to be one, three per week is a good deal. I understand how managers would want one in somewhat messy places.
    - theshrike79 4y ago
      Yea, for a self-directing team three is perfectly fine. Monday, Wednesday and Friday.
- bryan0 4y ago
  Agile is very different than Scrum. Agile actually has very good SWE principles. Scrum is one heavy-handed approach to following them.
s1k3 4y ago
Using it at prescribed is all you need to do.
- convolvatron 4y ago
  you know what's even better? just talking to who you need to to get your job done. and if you're responsible for the group and someone looks like they are dropping off the map...just synch up with them
  - dragonsky 4y ago
    I think this point is missed in the implementation of these systems. Give the people doing the work the responsibility for the work and the authority to chase down and "demand" answers they need to get the work done. If that can't be achieved, then maybe you need a meeting where the manager is involved. No need for daily meetings with reports of "same as yesterday". No need to to wait for a meeting before getting advice on how to unblock something. Just get on with what needs to be done.
chrisseaton 4y ago
Does it ever occur to Scrum people that it’s not a good idea to spend your entire life in a mad state of sprinting? Marathon runners don’t sprint 100m, then sprint another 100m, repeatedly, to cover the distance of a race.
- somewhat_drunk 4y ago
  Would you rather call it a saunter?
- hbrn 4y ago
  As someone recently said it here, the difference between software development and marathon is that marathon runners know their destination.
  - chrisseaton 4y ago
    Orienteers then? They don’t know their destination until they have their next waypoint. It’s not healthy to live in an eternally manic state of having to sprint at work.
    - hbrn 4y ago
      Orienteering definitely fits better. And it's a competitive sport. It might not be healthy, but that's how you win.
  - hinkley 4y ago
    Not all who wander are lost. A hiker or a marathon runner or a club cyclist not currently at an event have a destination: where they started. But the good stuff happens in the middle, and that’s not necessarily planned out in advance. Pacing is even more important then because there may be nobody to come bail you out, or it might take hours for them to do so.
  - tomatotomato37 4y ago
    So do sprinting runners, unless something has gone horribly wrong in the track design. Maybe we should get rid of the running analogies altogether and adopt the term "voyage" instead
fortylove 4y ago
I came to dislike standup at Amazon. Everyday we had one to start the day, and people never talked about their blockers. Some folks would give a super brief overview of what they did and will do. This was fine, but not really interesting to have 5 days a week. But then other folks would give a play-by-play of what they did and how, and what they will do next and how they will do it. It's like sounding busy was more important than the rest of team's time and sanity. Personally, I think it's more helpful to just have a daily team 30 minutes scheduled to discuss any important topics, vs specifically to have a status updates. The actual standup function where people prefer updates can happen >= 1 day a week && < 5 days a week
- P5fRxh5kUvp2th 4y ago
  > But then other folks would give a play-by-play of what they did and how, and what they will do next and how they will do it. Saw a principal engineer do that. He would take what could be summarized in a sentence or two and spend 5+ minutes describing it. Same guy once rejected a PR and made me initialize a field to null instead of empty string, his rationalization is that he's been both a DBA and a developer over his 7 year career, so he knows better. than apparently the entire industry that's been moving away from code like that for the last 10+ years. yes, you read that right. 7 years, not all of it in software dev, working as a principal engineer. politics are a bitch sometimes.
  - commandlinefan 4y ago
    > take what could be summarized in a sentence or two and spend 5+ minutes describing it Don't hate the player, hate the game. I had a job that required weekly status updates by e-mail (cc-ed to the entire team for some reason). My updates went on for pages. If somebody asked me to look at something and it took more than 10 minutes, that went on my status report: "Worked with so-and-so to do such-and-such"). My boss confided in me that could tell what I was doing and he appreciated it. Why? Because he summarized those statuses into a big, long (the longer the better) update e-mail to his boss. If you incentivize stupidity, you're going to get stupidity, even from smart people. Especially from smart people.
f1shy 4y ago
Where I suffer everyday, somebody had the idea of implementing SAFe: We have 10% more people to help with the "cermonies". That is, for every 30 people, there are 1 Scrum master, 1 Product manager, and 1 SAFe Programme Consultant (SPC) that help to implement the method (all external people costing 2x the normal employee cost) plus courses and certification for some internal employees. Dailys take 1 Hs, where people try to show off. Retros take 3Hs and is all about finding "who is guilty". PI plannings take 2 day, and consistently in the first week after planning we realise the whole planning cannot be realised for whatever reason. Backlog is always 100+ entries, that we leave there "just in case". PO does not work in the team, he is just the BOSS. We goes every day behind you pushing that you fill in the status of the task in our Track-n-release. The track and release tool is there to supervise the work being done, so there are very specific guidelines on how to fill the comments and when. The "velocity" is used to evaluate the people. Great place to work!!!
- bmj 4y ago
  Ugh, SAFe. My group has been trying to implement this methodology for well over a year. My observations: * Program increment planning is absolutely painful. Three full days of meetings, and rarely do the stakeholders come with fully refined features. And, typically, what plan emerges is changed within two weeks because of emergencies or an executive seeing a shiny bauble we absolutely need to have. * Two week sprints seem too short, at least for a group working in a highly regulated industry that requires a ton of manual testing and paperwork. I will also admit that we likely have trouble writing appropriately sized stories, but part of that circles back to the need for massive validation efforts. * We suffer from lots of turnover in product management (and perhaps too many product managers). If a PM leaves, their features tend to die on the vine, even if some executive has decided they are important. That leaves us with a massive backlog.
  - ethbr0 4y ago
    > highly regulated industry that requires a ton of manual testing and paperwork This describes every industry for a company I've seen SAFe at. Or, in other words, SAFe is: {how do we say we're doing Agile?} + {how do we avoid changing any of our regulatory compliance pipelines?} = {business as usual} + {a bunch of extra useless Agile theater}
0xbadcafebee 4y ago
If you have not yet read the Scrum Guide, please read it. It does not tell you in detail how to do Scrum, but the framework is there. https://scrumguides.org/scrum-guide.html https://scrumguides.org/scrum-guide.html My favorite method of story pointing is throwing some chicken bones at a grease stain on the wall. It's as accurate as anything else.
- jacobyoder 4y ago
  My overarching experience with 'agile story points' (paraphrased combination between multiple teams/projects). "If it's not a 3, then it might be a 5. But if it's not a 5, that would mean it's an 8, and we can't have 8s. 8s are too much. You have to break it down more". "What is 'too much'?" "That's too many days of work". "But I thought points weren't an estimate of time/hours/days, just a level of effort or complexity.". "8s are too big" "But... 8 is the best notion at this point. It's a complex problem. Maybe after working through the ticket, a natural break point will present itself and we can chunk it and make a second ticket with follow on work later. But right now, I can't see any split point". "Well... you have to break it down first. Make this in to multiple tickets. The sprint starts tomorrow and we can't have 8s".
  - commandlinefan 4y ago
    > "You have to break it down more" "How much time do I have to do the analysis to break it down?" "None"
  - deathanatos 4y ago
    And every ticket is complex, and the PM is annoyed that every ticket is being faithfully marked as such. But they balk at taking the time to try to plan out that high level goal to enough extend that we can break the ticket apart into smaller pieces that make sense, or just make it an epic because it is one and add tickets to it as we figure out how we're going to implement $todays_insanity_from_higher_up…
  - icedchai 4y ago
    I experienced similar at a previous company. Everything was a 1, 2, or 3. If it was a 5, the "scrum master" got a frowny-face. "Guys, can we break this down more??" Then a 15 minute discussion would ensue. That was literally the person's only contribution. (If you suggested an 8, they'd look at you crazy and it would get back logged.) The entire engineering org was measured on velocity. Every 2 weeks, at end of sprint, there would be a huge Slack posting with various stats for something like 6 or 7 teams. "85% completion! 5% are still in review. 10% of tasks were not even started!!" Some managers would game the system. If a task wasn't done, they'd just mark it complete and open a ticket to finish it up next sprint (typically "integration testing for feature X" or "QA feature X".) One guy must've dragged his original 3 point ticket out for 4 sprints doing this. The "velocity" was meaningless.
bryan0 4y ago
I read the title as: "How to distort Scrum until it actually works". At least that's been my experience over the past 15 years.
bgro 4y ago
I'm probably doing standups wrong, but I find it useful for devs to (briefly) talk about what they're working on. Bring up something you're struggling on and maybe I can jump in and help. Let people know you're working on a hotfix today, so try to not bother you. Get early feedback on priorities from the PM if you're going down the wrong path or a customer changed their mind on something you didn't hear about. I also like to have a casual dev text chat going throughout the day so you can post things like "Why isn't customer history appearing on this page?" "That page uses a one-off modified version of that query that doesn't grab history because we don't need to display it there. It used to increase load time by 30%." Sometimes the flow of this is just easier in person, and a dedicated short meeting where everyone speaks up about their own work doesn't feel as much like backseat accusations. It does require people actually feel comfortable asking for help, and it requires people to volunteer their guidance. As I see more and more devs and different work places, I can't believe how common it is to just sit in your corner and struggle while refusing to ask for help and refusing to speak up when someone on your team is actually asking for help. Is this communication failure the norm at your places of work? What's the deal?
- MartinCron 4y ago
  I'm probably doing standups wrong... And then you describe some of the healthiest standup culture I've seen...
  - deleted 4y ago
    [deleted]
- troupe 4y ago
  Are you getting value from those meetings? Are you willing to try new things if someone has a suggestion that might make it better? If so you are doing it right..regardless of what anyone else says.
- breakpete 4y ago
  You are not doing it wrong. Standups can be traced back to the Scrum practice Daily Scrum. The Daily Scrum is a short (max 15 minute) synchronisation meeting for developers. It is explicitly not a status meeting for PMs. It eventually became known as a standup because people figured out that it was easier to keep the meeting short when you were not sitting down. Scrum became popular, but it didn’t really make room for traditional project managers. So what to do with all the PMs? Teach them to be Scrum Masters. This is where things started to go downhill. Most PMs just kept doing what they had always done, just using different names. And so standups became hour long status meetings, inspect and adapt, sustainable pace and other good things were replaced with micromanagement and death marches. Dark Scrum was born. This is of course greatly simplified. Agile Consultants and certification peddlers are also to blame.
matai_kolila 4y ago
Agile and Scrum are not the same thing, and I think that's probably the most important idea to understand about Scrum. With Agile, if you can't draw a clear, bright line from some ritual you're doing to meaningful value, you need to drop that ritual immediately. With scrum, it tends to be "all-or-nothing", even if it's not quite meant to be. Even something as "fundamental" as stand-ups or sprints need to have clear value for your team[1], or you need to drop them, and I think a lot of leaders are afraid of doing so lest they lose the "magic" of Agile. [1] FWIW I do think stand-ups are usually valuable, but only if, "Nothing to report." is a 100% allowed thing to say. As a lead, I like to do this myself a bunch early on to show its acceptability.
andirk 4y ago
Tech-centric positions don't have enough sympathy for email job people. If there aren't meetings all day, then what do they do? They run out of email eventually. To correct poorly set meetings, including "scrum", have someone take notes and review those notes after. If there was constantly nothing to gain, then that meeting is 86'd and whoever set up that meeting gets their meeting setup privileges suspended.
de6u99er 4y ago
That's very funny! I've seen and participated in both unsuccessful and successful Scrum projects. A lot of time it's susscess comes down to company culture and the combination of filling the role of Scrum Master, Product Owner, and Solution Architect supporting the team.
- ryathal 4y ago
  So far I have learned that Scrum can work, but only if the CEO personally wants it to and they have someone spending time with them explaining what every level has to do differently and expect differently for it to work. Partial successes can be won from the bottom up approach, but they are far less impactful.
ghusto 4y ago
> The problem with Scrum is that it usually works Aaaand right off the bat you've lost me. Define "works". If you mean it is a process and can be followed, sure, I guess? I would rather define it as "bullshit that keeps non technical people happy and in control". Despite the derogatory tone, I think that can have it's place. For example, engineers are generally terrible at selling their product, and knowing what end users actually want -- with non technical applications. So having "business people" run the show there is probably a good idea. Where it becomes unbearably moronic however, is when that happens at a supposedly tech company.
- BarryMilo 4y ago
  Scrum is explicitly about giving control to the developers. This is why it's not used "correctly" (read: rigorously) in a lot of businesses, it's fundamentally incompatible with the micromanaging approach that control freak managers tend to use.
tbarbugli 4y ago
I actually cant understand the point the author is trying to make. For instance: what is his stance on retros?
BowBun 4y ago
I feel bad for all the folks in this thread who have to deal with the manager's version of optimizing scrum/agile to the point where everyone hates it. At my company, we enforce a 'little a agile' culture where we take the spirit of iteration and short-term planning, but we don't do certain ceremonies because we have to. Our standups take 15 minutes, we have a quick banter and then update on what we're working on and any blockers. Our retros/sprint planning are an hour each two weeks. We share responsibilities so that we take turns running retro and tie in themes and silly things to make it more bearable. My team is engaged and gives feedback on the process when it's annoying, which we take and apply as much as we can if the team agrees. Managers (like me) need to learn that agile isn't for them to get a status report every day on what their reports are doing. It's a set of tools for engineering to be effective. Hire good people and get out of the way. Let engineers tell you how to do their jobs effectively, your job is to clarify company goals and support them to reach those goals.
- ejb999 4y ago
  >>Hire good people and get out of the way. If you hire good people, it won't matter what framework they use, is my position. Give me a good team and I will deliver a good product agile/scrum/kanban/SAFe/waterfall - doesn't matter - thats all window dressing if you don't have a good team.
- greatgib 4y ago
  <<we enforce a 'little a agile'>> The word enforce here is a marker that shows that you failed to do Agile. You do something that is not the Agile as in "Agile Manifesto" and brand it like that. Because in the original agile concept, that is the team itself that can "self-organize" to what fits them the best. If management impose an organization, like mandatory meetings and co, it is not anymore Agile.
  - BowBun 4y ago
    Seems like you interpreted my use of 'enforce' quite heavily which isn't a good representation of our work culture. "We practice" would have been better phrasing. If you read the rest of my comment, I mention that we regularly solicit and apply feedback to our process which gives the team the opportunity to "self-organize", as you say.
TrevorJ 4y ago
I don't think you need to distort Scrum for it not to work.
yrgulation 4y ago
By pdf certified scrum masters who have nothing else to do but bastardise agile.
wonderwonder 4y ago
This was an excellent read. I worked at a company that did almost all of these. An absolute fanatical focus on velocity to the exclusion of everything else coupled with complete disconnect between story points and the time to actually implement the ticket. Total and complete failure to deliver almost every sprint. Every developer had to deliver a minimum of 10 points a week. Each sprint was 1 week. If you did not deliver 10 points you were written up. Jr. or Sr. and the points were estimated by the Sr. Devs. So the only way for a Jr. to hit their 10 points was to work 70 hours for months and years on end. I left a couple years ago but when I left the system was absolute garbage and every week leadership was astounded that progress was not being made while only focusing on the number of points closed. Company is publicly traded and will potentially go out of business in 6 months. I was written up at the start of covid for hitting 8 points 2 weeks in a row. Right when everything shut down, schools closed etc. When I quit, every Sr. engineer left within 6 months, ~50% of the engineering staff.
- wobbly_bush 4y ago
  Wow, that's crazy. Is it possible to find this out while interviewing? My worry is some company might be willing to pay high salaries to new hires to recover from situations like these, but it would suck for me to join such a place.
  - 0xbadcafebee 4y ago
    I always ask my potential peers how they feel. Are you stressed, relaxed, happy, sad, mad, excited, ambivalent. What works great, what needs improvement. Ask them directly: are you happy with your scrum/agile process? Be careful though as just the words might trigger some ;) If they won't let you talk to your peers and instead you only get to talk to the manager and team lead, be wary: they might be trying to escape & say anything to hire new people. And if they say they are very very excited to have you on board, I'd say that's worrying too, unless you are some kinda rockstar. Also check out Glassdoor and other review sites.
haolez 4y ago
I'm facing the opposite challenge right now. I've recently joined in as the CTO of a small company and the team is in love with Scrum. They love it and they love Jira as well. Sometimes it seems that they spend more time using Jira than using their IDEs. This wouldn't be so much of a problem, but the team is SLOW. Every little feature and adjustment drags for many 2-weeks sprints. Every task gets broken down to its atoms. And what's tiresome to me is that, whenever I try to reduce the overhead and get them more time to do useful work, they push back strongly and they start to pile up minor nitpicks and corner cases of what might go wrong in the future if we do change. I'd love to get some ideas on how to improve things without straining the relationship with top-down maneuvers.
- epicureanideal 4y ago
  > Every little feature and adjustment drags for many 2-weeks sprints. Every task gets broken down to its atoms. Can you provide some examples so readers can get a sense of whether we think your perception is accurate? It might be that you have very high expectations or it might be that they really are slow, maybe so slow they should be replaced. But without examples it’s not possible to get a sense of which is the case.
  - haolez 4y ago
    They are mostly developing an internal admin system meant for business operators. This system has the Lawsuit as its main entity. They spent two months to make a buggy screen that would aggregate several lawsuits into a single Deal (a new entity). This is an Angular + .NET project. They need more training and there is a lot of tech debt that's slowing them down, but how am I supposed to tackle tech debt without speeding up their processes first? Genuine doubt in my mind :)
    - epicureanideal 4y ago
      Sounds like you need a better tech team.
- tomohawk 4y ago
alexfromapex 4y ago
I talked to my supervisor because we're supposed to be doing Scrum but we're not doing the most important parts, namely sprint planning or retros. It's amazing to witness, coming from a team that did Scrum perfectly and functioned like clockwork.
lkrubner 4y ago
This part of the essay admits that everyone tends to have their own interpretation of what Scrum means, and success actually comes down to whether you have the correct interpretation: "Creating your own version of Scrum is a rite of passage for engineering managers. Both cases usually result in catastrophic failure, followed by tears and despair." I've seen a variety of Agile approaches work well for some project managers but fail miserably with other project managers, which leaves thinking that it comes down to the person in charge -- if something only works when a certain person does it, maybe the observed effect comes from that particular person, and not the formal methodology that was nominally adopted for the project? I've spent many years doing high level consulting, with multiple startups, which has been a great education for me because I've had a chance to observe a large number of different development methodologies. And while I've seen success with many of these methodologies, I've also seen failures, and the difference always seems to come down to who is charge, which makes me think the success or failure really depends on the leader and not the development methodology. To put that differently, I have not seen any methodology that reliably leads to success, but I have seen certain project managers who reliably deliver success, and I suspect they could switch to different development methodologies and still deliver success. Therefore the development methodology doesn't seem to matter much. I've only seen one rule that has consistently been true, and which grants a certain flexibility and agility to the development process: "Small meetings are more productive than large meetings, and one-on-one meetings are the most productive of all." I wrote about this here: "Truly Agile development revolves around one-on-one meetings, not daily standups" http://www.smashcompany.com/business/truly-agile-development-revolves-around-one-on-one-meetings-not-daily-standups http://www.smashcompany.com/business/truly-agile-development...
dgeiser13 4y ago
A: Use Scrum
jmull 4y ago
I can't believe anyone thinks a daily reportorial meeting by everyone to everyone is a good idea. (Please don't bother telling me that's not what scrum and agile is supposed to be. I know, I got the training. Maybe you can instead suggest a way a daily standup doesn't devolve into that pretty quickly no matter what anyone says at first.) One thing I've noticed is that so many people attempting to run software development projects are literally blind to information flow. They simply cannot conceive of the constraints of how information needs to flow... who would need to know what and when and where that information could come from. Any rational way of organizing this just moves straight to ball-of-mud, where everyone needs to know everything from everyone else. Any single gap impacts almost everything. I wonder why the velocity metric is so low!
- eschneider 4y ago
  I'm on a remote team and we do a video call standup once a week and the other days we just post our updates to slack at the same time every day. Folks do tend to read each other's updates and add comments when they have input. It works reasonably well for us.
- BlargMcLarg 4y ago
  It's basically a shitty way to push people to communicate. When people mention "well just get rid of it and talk asynchronously", one of the counterarguments tends to be "but X may not communicate". Of course, no one bothers to answer the question "why does an adult need a daily reminder to speak?", and no one considers the repercussions of such a ritual (people will start hoarding questions until the daily, which makes the daily longer, which.. you get the point). That's the entire problem with Scrum anyway. It expects a very specific environment and immediately risks becoming redundant in such an environment (based on team preferences). Outside of that environment, it fails to do anything.
black_13 4y ago
nvader 4y ago
This is a weird article. There's a lot of rhetoric, and I especially take offense to the framing: > creating your own version of Scrum is a rite of passage for engineering managers [...] usually result[ing] in catastrophic failure The whole point of a framework is to adapt it to the specific context in which it is applied. This reads like a scrum apologetic, proclaiming that if your scrum is not working, you're not doing True Scrum. Then the second part of the article is "pointless" practices of Scrum. Which is it--should we create our own version of Scrum, or should we not? There's no hard data or evidence. Not even anecdotes. Overall, it looks like someone applied a light layer of css over ["part I like about scrum", "parts I don't like about scrum"]
zac23or 4y ago
Every time someone criticizes scrum/agile, "No true Scotsman" is the most common response. https://en.wikipedia.org/wiki/No_true_Scotsman https://en.wikipedia.org/wiki/No_true_Scotsman
redhale 4y ago
Agile requires trust to work. Without it, the process will quickly devolve. Low trust is the problem, not scrum. Trying to be agile without trust is like trying to bake bread without yeast. You go through all the same motions, but in the end all you have is a dense, sticky mess.
DangitBobby 4y ago
Can someone explain to me the point of a sprint? How about "there is some work available to do, and you do it as you become ready"? Am I supposed to be working longer than 40 hours this week to finish the work arbitrarily assinged to this sprint, because if so you are absolutely fucking off your rocker.
- mjfisher 4y ago
  The point of having sprints is to trade off some utilisation for predictable delivery. I.e. everything should be easily deliverable within a given sprint, to the point that almost everyone is idle (or working on non-sprint activities) by the end of it. In practice successful scrum teams might get 90% of their tasks done a sprint - if that's not happening you need to commit to less each sprint (fewer points or fewer estimated days) until it does.
js8 4y ago
I don't see any evidence that Scrum works. All the proclaimed good parts (standups, sprints, retros) can be done asynchronously on as required basis instead of synchronously/periodically and a decent manager is able to coach/remind people to do so. Making them synchronous is often very distracting.
- BarryMilo 4y ago
  The benefits of Scrum is not really Scrum itself, it's to have a standard by which to measure oneself. If you can say "this way is better than Scrum", great! But if you don't know any kind of methodology and are just winging it, you would be better off with Scrum 99% of the time, because it does, at the very least, enforce discipline through routine. Companies who don't have a measuring stick are likely to spend wayyy too much time on procedure tweaking. Speaking from experience. Having this standard also allows you to tell stakeholders "actually, this is normal for this industry and I can prove it", which is invaluable when they're not very technically minded.
  - js8 4y ago
    You're not really addressing the claim, which is whether or not Scrum actually works, i.e. is an improvement over any other method. I am not aware of any empirical, experimental or theoretical justification. Anything you currently practice can be used as a yardstick. However, I don't think that practitioners should be spending time on this research. That IMHO leads to exact problems that the article whines about. The idea that retrospectives are akin to scientific method is laughable. Maybe in 18th century that would fly, but there is lot more to scientific research than "continue doing what works and change what doesn't" (at the very least, following observations without theory leads to cargo-culting, which actually sums up the overall Scrum experiences pretty well).
    - BarryMilo 4y ago
      I'm not addressing your claim because I suspect it's not the main reason people use Scrum, in practice. I'm saying it's a political tool, and any debates around its "effectiveness" are pointless as the real benefit is keeping management away. The efficiency gains that you discuss would be pennies on the dollar in comparison.
ojciecczas 4y ago
:))))
bmitc 4y ago
I wonder how many articles, blogs, conferences, certifications, books, talks, soliloquies, consultants, etc. it will take to tell us we're all doing it wrong to make "Agile" and "Scrum" actually work.
- lloydatkinson 4y ago
  Honestly I’m not sure management will ever acknowledge or admit they’ve totally distorted agile from what it was meant to be in the manifesto into Big Agile™ with its optional add-ons Scrum® and SAFe© especially with “Agile Delivery Consultants” and other nonsense titles. They’ve started replacing scrum masters with those now too. At least until the next big thing comes along and they will declare agile to be just as bad as waterfall.
- antupis 4y ago
  Scrum works fine if you implement it by the book and then start tailoring slowly it based on team retros. Problem arises when PM or other manager goes rogue and starts implementing own ideas to scrum or just presures more stuff to sprint.
  - bmitc 4y ago
    That’s part of my point. How many companies do I need to work for such that that works, because every company that has used Agile or Scrum say that exact thing about tailoring it to the team from some base level. It seems to me that if everyone does it wrong, then it is not a good fit for how people actually work.
lloydatkinson 4y ago
I wrote an article on a specific part of scrum/agile: estimation and why most organisations are ruining team morale. https://www.lloydatkinson.net/posts/2022/one-teams-eight-points-is-another-teams-two-points/ https://www.lloydatkinson.net/posts/2022/one-teams-eight-poi...
jokethrowaway 4y ago
> The problem with Scrum is that it usually works. In tech, we hate that. What we like is to give talks, prepare slide decks, and, most importantly, to invent things ourselves. I've never seen Scrum works well in the last 10 years since I've heard of it. No amount of BS scrum consultants is enough to make it work.
seattle_spring 4y ago
> The problem with Scrum is that it usually works This was the first line of the article, and I immediately closed the tab because that is a dead-wrong claim. Is the rest of the article as ridiculous, or does it become worth reading?
brycewray 4y ago
> You’ll know you have successfully ruined your standups when they’re taking thirty or more minutes, and your whole team hates them to the point they won’t do it if you’re not present. (Involuntarily shudders due to flashbacks.)
Pentamerous 4y ago
I've been working in Scrum based frameworks for the past 8 years in different jobs. Learned from the teams practices and Scrum Masters. Only this year did I decide to actually read the Scrum Guide. I was never in a team that practiced it like that. All of them had stuff changed and reading the guide I was confused because the changes seemed for the worse. I feel like this is mostly the experience for people when they describe Scrum.
BoneZone 4y ago
> Just like creating your own front-end framework is a rite of passage for web developers, creating your own version of Scrum is a rite of passage for engineering managers. Excuse me, what? I've worked in web development for years and I personally know 0 people who have written a front end framework like React, View.js, etc.
addicted 4y ago
Something I don’t understand about standups. Why should anyone wait until the standup itself to reveal blockers? In my experience the team reveals blockers as they arise and someone usually finds a solution for them within 30-60 mins. There’s rarely an instance where there are pending blockers during the standup.
deleted 4y ago
[deleted]
Tycho 4y ago
There’s two good things about agile/scrum: breaking work up into manageable chunks; and having daily check-ins to make sure people aren’t doing the wrong thing for months on end. The rest can be ignored.

144 points by tapanjk 4y ago

enb 4y ago

What’s a good alternative to Scrum?

nivertech 4y ago
1. Shape Up method, for feature delivery at a small product-led company (e.g. SaaS startup) 2. mini-Waterfall: design -> plan -> build (iterate) -> ship - for platform/infra, or any other heavy engineering work 3. informal SDLC combining modern best practices in SW Engineering 4. Kanban for reactive work (bug-fixes, maintenance, QA, support, ops, etc.) 5. RUP (Rational Unified Process) for Mission/Safety critical systems 6. GROWS method - more like a collection of patterns / best practices 7. The GIST framework (Goals, Ideas, Steps, Tasks) - mostly about product management, but can be combined with Kanban There are many others, but they're either lacking communities (i.e. used by a single company only, no books/courses), and/or IMO not very good.

rightbyte 4y ago

I am so bitter about agile at this point it actually feels abit refreshing that someone still defends Scrum. > You’ll know you have successfully ruined your standups when they’re taking thirty or more minutes The author is an order of magnitude off here. The despair sets in way earlier.

theshrike79 4y ago
60 seconds per member of the team. 15 minutes hard limit. If there are issues, you handle them outside of the daily scrum, it's not a troubleshooting session, it's a status update.
- lowercased 4y ago
  then you'll also have folks who would say "if your daily standup is a 'status update', you're doing it wrong". and they're probably right. scrum.org - "The Daily Scrum is a 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours." Most "daily standups" I've been at are performative song-and-dance with non-dev stakeholders running the meetings. They're definitionally just status meetings. There's no internal 'dev-only' talk, or identifying problems to work through, or sharing knowledge. Nope, it's just 'all non-devs need to know the status of every issue in a jira board, daily'. Why they can't just ... you know... look at the jira board they're forcing us to use, and see the status there... I dunno. Half the time when I'd update something there, I'd repeat in a meeting "all this is in jira". "Oh, I don't have time to comb through all that - it's too slow". OK... but if I DIDN'T update jira tickets... that was slowing down the team because "now people can't tell where you're at". So... there was no way to 'win' there...
  - deckard1 4y ago
    the whole Jira thing really pisses me off. I hate Jira almost more than this scrum/agile nonsense. If no one wants to look at the damn board, why are we doing this?? > with non-dev stakeholders running the meetings 9 out of 10 standups I'm in have zero of the stakeholders necessary to unblock the work. I'm announcing my blockers to other devs that zoned out 10 minutes ago and the scrum master that will say something hollow and silly such as "keep working on that" or "make sure to ping so-and-so." Thanks. Want to come to the restroom with me and hold my pee pee so I don't fuck that up too? We are all infants. Also. Allllllso. Scrum Master. Scrum. Master. Shouldn't you people be Scrum Main? Or Scrum Primary? Or did you not get that memo? They are literally keeping their developer minions in check. It's a bit... how do I say this? On the nose? Much more in a way than a branch name of git ever was.
- rightbyte 4y ago
  > 60 seconds per member of the team. Ye, on average. Most people should ideally, in my mind, say "same old, same old" and let the next person speak. I don't like the concept of dailies, but if there has to be one, three per week is a good deal. I understand how managers would want one in somewhat messy places.
  - theshrike79 4y ago
    Yea, for a self-directing team three is perfectly fine. Monday, Wednesday and Friday.
bryan0 4y ago
Agile is very different than Scrum. Agile actually has very good SWE principles. Scrum is one heavy-handed approach to following them.

s1k3 4y ago

Using it at prescribed is all you need to do.

convolvatron 4y ago
you know what's even better? just talking to who you need to to get your job done. and if you're responsible for the group and someone looks like they are dropping off the map...just synch up with them
- dragonsky 4y ago
  I think this point is missed in the implementation of these systems. Give the people doing the work the responsibility for the work and the authority to chase down and "demand" answers they need to get the work done. If that can't be achieved, then maybe you need a meeting where the manager is involved. No need for daily meetings with reports of "same as yesterday". No need to to wait for a meeting before getting advice on how to unblock something. Just get on with what needs to be done.

chrisseaton 4y ago

Does it ever occur to Scrum people that it’s not a good idea to spend your entire life in a mad state of sprinting? Marathon runners don’t sprint 100m, then sprint another 100m, repeatedly, to cover the distance of a race.

somewhat_drunk 4y ago
Would you rather call it a saunter?
hbrn 4y ago
As someone recently said it here, the difference between software development and marathon is that marathon runners know their destination.
- chrisseaton 4y ago
  Orienteers then? They don’t know their destination until they have their next waypoint. It’s not healthy to live in an eternally manic state of having to sprint at work.
  - hbrn 4y ago
    Orienteering definitely fits better. And it's a competitive sport. It might not be healthy, but that's how you win.
- hinkley 4y ago
  Not all who wander are lost. A hiker or a marathon runner or a club cyclist not currently at an event have a destination: where they started. But the good stuff happens in the middle, and that’s not necessarily planned out in advance. Pacing is even more important then because there may be nobody to come bail you out, or it might take hours for them to do so.
- tomatotomato37 4y ago
  So do sprinting runners, unless something has gone horribly wrong in the track design. Maybe we should get rid of the running analogies altogether and adopt the term "voyage" instead

fortylove 4y ago

I came to dislike standup at Amazon. Everyday we had one to start the day, and people never talked about their blockers. Some folks would give a super brief overview of what they did and will do. This was fine, but not really interesting to have 5 days a week. But then other folks would give a play-by-play of what they did and how, and what they will do next and how they will do it. It's like sounding busy was more important than the rest of team's time and sanity. Personally, I think it's more helpful to just have a daily team 30 minutes scheduled to discuss any important topics, vs specifically to have a status updates. The actual standup function where people prefer updates can happen >= 1 day a week && < 5 days a week

P5fRxh5kUvp2th 4y ago
> But then other folks would give a play-by-play of what they did and how, and what they will do next and how they will do it. Saw a principal engineer do that. He would take what could be summarized in a sentence or two and spend 5+ minutes describing it. Same guy once rejected a PR and made me initialize a field to null instead of empty string, his rationalization is that he's been both a DBA and a developer over his 7 year career, so he knows better. than apparently the entire industry that's been moving away from code like that for the last 10+ years. yes, you read that right. 7 years, not all of it in software dev, working as a principal engineer. politics are a bitch sometimes.
- commandlinefan 4y ago
  > take what could be summarized in a sentence or two and spend 5+ minutes describing it Don't hate the player, hate the game. I had a job that required weekly status updates by e-mail (cc-ed to the entire team for some reason). My updates went on for pages. If somebody asked me to look at something and it took more than 10 minutes, that went on my status report: "Worked with so-and-so to do such-and-such"). My boss confided in me that could tell what I was doing and he appreciated it. Why? Because he summarized those statuses into a big, long (the longer the better) update e-mail to his boss. If you incentivize stupidity, you're going to get stupidity, even from smart people. Especially from smart people.

f1shy 4y ago

Where I suffer everyday, somebody had the idea of implementing SAFe: We have 10% more people to help with the "cermonies". That is, for every 30 people, there are 1 Scrum master, 1 Product manager, and 1 SAFe Programme Consultant (SPC) that help to implement the method (all external people costing 2x the normal employee cost) plus courses and certification for some internal employees. Dailys take 1 Hs, where people try to show off. Retros take 3Hs and is all about finding "who is guilty". PI plannings take 2 day, and consistently in the first week after planning we realise the whole planning cannot be realised for whatever reason. Backlog is always 100+ entries, that we leave there "just in case". PO does not work in the team, he is just the BOSS. We goes every day behind you pushing that you fill in the status of the task in our Track-n-release. The track and release tool is there to supervise the work being done, so there are very specific guidelines on how to fill the comments and when. The "velocity" is used to evaluate the people. Great place to work!!!

bmj 4y ago
Ugh, SAFe. My group has been trying to implement this methodology for well over a year. My observations: * Program increment planning is absolutely painful. Three full days of meetings, and rarely do the stakeholders come with fully refined features. And, typically, what plan emerges is changed within two weeks because of emergencies or an executive seeing a shiny bauble we absolutely need to have. * Two week sprints seem too short, at least for a group working in a highly regulated industry that requires a ton of manual testing and paperwork. I will also admit that we likely have trouble writing appropriately sized stories, but part of that circles back to the need for massive validation efforts. * We suffer from lots of turnover in product management (and perhaps too many product managers). If a PM leaves, their features tend to die on the vine, even if some executive has decided they are important. That leaves us with a massive backlog.
- ethbr0 4y ago
  > highly regulated industry that requires a ton of manual testing and paperwork This describes every industry for a company I've seen SAFe at. Or, in other words, SAFe is: {how do we say we're doing Agile?} + {how do we avoid changing any of our regulatory compliance pipelines?} = {business as usual} + {a bunch of extra useless Agile theater}

0xbadcafebee 4y ago

If you have not yet read the Scrum Guide, please read it. It does not tell you in detail how to do Scrum, but the framework is there. https://scrumguides.org/scrum-guide.html https://scrumguides.org/scrum-guide.html My favorite method of story pointing is throwing some chicken bones at a grease stain on the wall. It's as accurate as anything else.

jacobyoder 4y ago
My overarching experience with 'agile story points' (paraphrased combination between multiple teams/projects). "If it's not a 3, then it might be a 5. But if it's not a 5, that would mean it's an 8, and we can't have 8s. 8s are too much. You have to break it down more". "What is 'too much'?" "That's too many days of work". "But I thought points weren't an estimate of time/hours/days, just a level of effort or complexity.". "8s are too big" "But... 8 is the best notion at this point. It's a complex problem. Maybe after working through the ticket, a natural break point will present itself and we can chunk it and make a second ticket with follow on work later. But right now, I can't see any split point". "Well... you have to break it down first. Make this in to multiple tickets. The sprint starts tomorrow and we can't have 8s".
- commandlinefan 4y ago
  > "You have to break it down more" "How much time do I have to do the analysis to break it down?" "None"
- deathanatos 4y ago
  And every ticket is complex, and the PM is annoyed that every ticket is being faithfully marked as such. But they balk at taking the time to try to plan out that high level goal to enough extend that we can break the ticket apart into smaller pieces that make sense, or just make it an epic because it is one and add tickets to it as we figure out how we're going to implement $todays_insanity_from_higher_up…
- icedchai 4y ago
  I experienced similar at a previous company. Everything was a 1, 2, or 3. If it was a 5, the "scrum master" got a frowny-face. "Guys, can we break this down more??" Then a 15 minute discussion would ensue. That was literally the person's only contribution. (If you suggested an 8, they'd look at you crazy and it would get back logged.) The entire engineering org was measured on velocity. Every 2 weeks, at end of sprint, there would be a huge Slack posting with various stats for something like 6 or 7 teams. "85% completion! 5% are still in review. 10% of tasks were not even started!!" Some managers would game the system. If a task wasn't done, they'd just mark it complete and open a ticket to finish it up next sprint (typically "integration testing for feature X" or "QA feature X".) One guy must've dragged his original 3 point ticket out for 4 sprints doing this. The "velocity" was meaningless.

bryan0 4y ago

I read the title as: "How to distort Scrum until it actually works". At least that's been my experience over the past 15 years.

bgro 4y ago

I'm probably doing standups wrong, but I find it useful for devs to (briefly) talk about what they're working on. Bring up something you're struggling on and maybe I can jump in and help. Let people know you're working on a hotfix today, so try to not bother you. Get early feedback on priorities from the PM if you're going down the wrong path or a customer changed their mind on something you didn't hear about. I also like to have a casual dev text chat going throughout the day so you can post things like "Why isn't customer history appearing on this page?" "That page uses a one-off modified version of that query that doesn't grab history because we don't need to display it there. It used to increase load time by 30%." Sometimes the flow of this is just easier in person, and a dedicated short meeting where everyone speaks up about their own work doesn't feel as much like backseat accusations. It does require people actually feel comfortable asking for help, and it requires people to volunteer their guidance. As I see more and more devs and different work places, I can't believe how common it is to just sit in your corner and struggle while refusing to ask for help and refusing to speak up when someone on your team is actually asking for help. Is this communication failure the norm at your places of work? What's the deal?

MartinCron 4y ago
I'm probably doing standups wrong... And then you describe some of the healthiest standup culture I've seen...
- deleted 4y ago
  [deleted]
troupe 4y ago
Are you getting value from those meetings? Are you willing to try new things if someone has a suggestion that might make it better? If so you are doing it right..regardless of what anyone else says.
breakpete 4y ago
You are not doing it wrong. Standups can be traced back to the Scrum practice Daily Scrum. The Daily Scrum is a short (max 15 minute) synchronisation meeting for developers. It is explicitly not a status meeting for PMs. It eventually became known as a standup because people figured out that it was easier to keep the meeting short when you were not sitting down. Scrum became popular, but it didn’t really make room for traditional project managers. So what to do with all the PMs? Teach them to be Scrum Masters. This is where things started to go downhill. Most PMs just kept doing what they had always done, just using different names. And so standups became hour long status meetings, inspect and adapt, sustainable pace and other good things were replaced with micromanagement and death marches. Dark Scrum was born. This is of course greatly simplified. Agile Consultants and certification peddlers are also to blame.

matai_kolila 4y ago

Agile and Scrum are not the same thing, and I think that's probably the most important idea to understand about Scrum. With Agile, if you can't draw a clear, bright line from some ritual you're doing to meaningful value, you need to drop that ritual immediately. With scrum, it tends to be "all-or-nothing", even if it's not quite meant to be. Even something as "fundamental" as stand-ups or sprints need to have clear value for your team[1], or you need to drop them, and I think a lot of leaders are afraid of doing so lest they lose the "magic" of Agile. [1] FWIW I do think stand-ups are usually valuable, but only if, "Nothing to report." is a 100% allowed thing to say. As a lead, I like to do this myself a bunch early on to show its acceptability.

andirk 4y ago

Tech-centric positions don't have enough sympathy for email job people. If there aren't meetings all day, then what do they do? They run out of email eventually. To correct poorly set meetings, including "scrum", have someone take notes and review those notes after. If there was constantly nothing to gain, then that meeting is 86'd and whoever set up that meeting gets their meeting setup privileges suspended.

de6u99er 4y ago

That's very funny! I've seen and participated in both unsuccessful and successful Scrum projects. A lot of time it's susscess comes down to company culture and the combination of filling the role of Scrum Master, Product Owner, and Solution Architect supporting the team.

ryathal 4y ago
So far I have learned that Scrum can work, but only if the CEO personally wants it to and they have someone spending time with them explaining what every level has to do differently and expect differently for it to work. Partial successes can be won from the bottom up approach, but they are far less impactful.

ghusto 4y ago

> The problem with Scrum is that it usually works Aaaand right off the bat you've lost me. Define "works". If you mean it is a process and can be followed, sure, I guess? I would rather define it as "bullshit that keeps non technical people happy and in control". Despite the derogatory tone, I think that can have it's place. For example, engineers are generally terrible at selling their product, and knowing what end users actually want -- with non technical applications. So having "business people" run the show there is probably a good idea. Where it becomes unbearably moronic however, is when that happens at a supposedly tech company.

BarryMilo 4y ago
Scrum is explicitly about giving control to the developers. This is why it's not used "correctly" (read: rigorously) in a lot of businesses, it's fundamentally incompatible with the micromanaging approach that control freak managers tend to use.

tbarbugli 4y ago

I actually cant understand the point the author is trying to make. For instance: what is his stance on retros?

BowBun 4y ago

I feel bad for all the folks in this thread who have to deal with the manager's version of optimizing scrum/agile to the point where everyone hates it. At my company, we enforce a 'little a agile' culture where we take the spirit of iteration and short-term planning, but we don't do certain ceremonies because we have to. Our standups take 15 minutes, we have a quick banter and then update on what we're working on and any blockers. Our retros/sprint planning are an hour each two weeks. We share responsibilities so that we take turns running retro and tie in themes and silly things to make it more bearable. My team is engaged and gives feedback on the process when it's annoying, which we take and apply as much as we can if the team agrees. Managers (like me) need to learn that agile isn't for them to get a status report every day on what their reports are doing. It's a set of tools for engineering to be effective. Hire good people and get out of the way. Let engineers tell you how to do their jobs effectively, your job is to clarify company goals and support them to reach those goals.

ejb999 4y ago
>>Hire good people and get out of the way. If you hire good people, it won't matter what framework they use, is my position. Give me a good team and I will deliver a good product agile/scrum/kanban/SAFe/waterfall - doesn't matter - thats all window dressing if you don't have a good team.
greatgib 4y ago
<<we enforce a 'little a agile'>> The word enforce here is a marker that shows that you failed to do Agile. You do something that is not the Agile as in "Agile Manifesto" and brand it like that. Because in the original agile concept, that is the team itself that can "self-organize" to what fits them the best. If management impose an organization, like mandatory meetings and co, it is not anymore Agile.
- BowBun 4y ago
  Seems like you interpreted my use of 'enforce' quite heavily which isn't a good representation of our work culture. "We practice" would have been better phrasing. If you read the rest of my comment, I mention that we regularly solicit and apply feedback to our process which gives the team the opportunity to "self-organize", as you say.

TrevorJ 4y ago

I don't think you need to distort Scrum for it not to work.

yrgulation 4y ago

By pdf certified scrum masters who have nothing else to do but bastardise agile.

wonderwonder 4y ago

This was an excellent read. I worked at a company that did almost all of these. An absolute fanatical focus on velocity to the exclusion of everything else coupled with complete disconnect between story points and the time to actually implement the ticket. Total and complete failure to deliver almost every sprint. Every developer had to deliver a minimum of 10 points a week. Each sprint was 1 week. If you did not deliver 10 points you were written up. Jr. or Sr. and the points were estimated by the Sr. Devs. So the only way for a Jr. to hit their 10 points was to work 70 hours for months and years on end. I left a couple years ago but when I left the system was absolute garbage and every week leadership was astounded that progress was not being made while only focusing on the number of points closed. Company is publicly traded and will potentially go out of business in 6 months. I was written up at the start of covid for hitting 8 points 2 weeks in a row. Right when everything shut down, schools closed etc. When I quit, every Sr. engineer left within 6 months, ~50% of the engineering staff.

wobbly_bush 4y ago
Wow, that's crazy. Is it possible to find this out while interviewing? My worry is some company might be willing to pay high salaries to new hires to recover from situations like these, but it would suck for me to join such a place.
- 0xbadcafebee 4y ago
  I always ask my potential peers how they feel. Are you stressed, relaxed, happy, sad, mad, excited, ambivalent. What works great, what needs improvement. Ask them directly: are you happy with your scrum/agile process? Be careful though as just the words might trigger some ;) If they won't let you talk to your peers and instead you only get to talk to the manager and team lead, be wary: they might be trying to escape & say anything to hire new people. And if they say they are very very excited to have you on board, I'd say that's worrying too, unless you are some kinda rockstar. Also check out Glassdoor and other review sites.

haolez 4y ago

I'm facing the opposite challenge right now. I've recently joined in as the CTO of a small company and the team is in love with Scrum. They love it and they love Jira as well. Sometimes it seems that they spend more time using Jira than using their IDEs. This wouldn't be so much of a problem, but the team is SLOW. Every little feature and adjustment drags for many 2-weeks sprints. Every task gets broken down to its atoms. And what's tiresome to me is that, whenever I try to reduce the overhead and get them more time to do useful work, they push back strongly and they start to pile up minor nitpicks and corner cases of what might go wrong in the future if we do change. I'd love to get some ideas on how to improve things without straining the relationship with top-down maneuvers.

epicureanideal 4y ago
> Every little feature and adjustment drags for many 2-weeks sprints. Every task gets broken down to its atoms. Can you provide some examples so readers can get a sense of whether we think your perception is accurate? It might be that you have very high expectations or it might be that they really are slow, maybe so slow they should be replaced. But without examples it’s not possible to get a sense of which is the case.
- haolez 4y ago
  They are mostly developing an internal admin system meant for business operators. This system has the Lawsuit as its main entity. They spent two months to make a buggy screen that would aggregate several lawsuits into a single Deal (a new entity). This is an Angular + .NET project. They need more training and there is a lot of tech debt that's slowing them down, but how am I supposed to tackle tech debt without speeding up their processes first? Genuine doubt in my mind :)
  - epicureanideal 4y ago
    Sounds like you need a better tech team.
tomohawk 4y ago

alexfromapex 4y ago

I talked to my supervisor because we're supposed to be doing Scrum but we're not doing the most important parts, namely sprint planning or retros. It's amazing to witness, coming from a team that did Scrum perfectly and functioned like clockwork.

lkrubner 4y ago

This part of the essay admits that everyone tends to have their own interpretation of what Scrum means, and success actually comes down to whether you have the correct interpretation: "Creating your own version of Scrum is a rite of passage for engineering managers. Both cases usually result in catastrophic failure, followed by tears and despair." I've seen a variety of Agile approaches work well for some project managers but fail miserably with other project managers, which leaves thinking that it comes down to the person in charge -- if something only works when a certain person does it, maybe the observed effect comes from that particular person, and not the formal methodology that was nominally adopted for the project? I've spent many years doing high level consulting, with multiple startups, which has been a great education for me because I've had a chance to observe a large number of different development methodologies. And while I've seen success with many of these methodologies, I've also seen failures, and the difference always seems to come down to who is charge, which makes me think the success or failure really depends on the leader and not the development methodology. To put that differently, I have not seen any methodology that reliably leads to success, but I have seen certain project managers who reliably deliver success, and I suspect they could switch to different development methodologies and still deliver success. Therefore the development methodology doesn't seem to matter much. I've only seen one rule that has consistently been true, and which grants a certain flexibility and agility to the development process: "Small meetings are more productive than large meetings, and one-on-one meetings are the most productive of all." I wrote about this here: "Truly Agile development revolves around one-on-one meetings, not daily standups" http://www.smashcompany.com/business/truly-agile-development-revolves-around-one-on-one-meetings-not-daily-standups http://www.smashcompany.com/business/truly-agile-development...

dgeiser13 4y ago

A: Use Scrum

jmull 4y ago

I can't believe anyone thinks a daily reportorial meeting by everyone to everyone is a good idea. (Please don't bother telling me that's not what scrum and agile is supposed to be. I know, I got the training. Maybe you can instead suggest a way a daily standup doesn't devolve into that pretty quickly no matter what anyone says at first.) One thing I've noticed is that so many people attempting to run software development projects are literally blind to information flow. They simply cannot conceive of the constraints of how information needs to flow... who would need to know what and when and where that information could come from. Any rational way of organizing this just moves straight to ball-of-mud, where everyone needs to know everything from everyone else. Any single gap impacts almost everything. I wonder why the velocity metric is so low!

eschneider 4y ago
I'm on a remote team and we do a video call standup once a week and the other days we just post our updates to slack at the same time every day. Folks do tend to read each other's updates and add comments when they have input. It works reasonably well for us.
BlargMcLarg 4y ago
It's basically a shitty way to push people to communicate. When people mention "well just get rid of it and talk asynchronously", one of the counterarguments tends to be "but X may not communicate". Of course, no one bothers to answer the question "why does an adult need a daily reminder to speak?", and no one considers the repercussions of such a ritual (people will start hoarding questions until the daily, which makes the daily longer, which.. you get the point). That's the entire problem with Scrum anyway. It expects a very specific environment and immediately risks becoming redundant in such an environment (based on team preferences). Outside of that environment, it fails to do anything.

black_13 4y ago

nvader 4y ago

This is a weird article. There's a lot of rhetoric, and I especially take offense to the framing: > creating your own version of Scrum is a rite of passage for engineering managers [...] usually result[ing] in catastrophic failure The whole point of a framework is to adapt it to the specific context in which it is applied. This reads like a scrum apologetic, proclaiming that if your scrum is not working, you're not doing True Scrum. Then the second part of the article is "pointless" practices of Scrum. Which is it--should we create our own version of Scrum, or should we not? There's no hard data or evidence. Not even anecdotes. Overall, it looks like someone applied a light layer of css over ["part I like about scrum", "parts I don't like about scrum"]

zac23or 4y ago

Every time someone criticizes scrum/agile, "No true Scotsman" is the most common response. https://en.wikipedia.org/wiki/No_true_Scotsman https://en.wikipedia.org/wiki/No_true_Scotsman

redhale 4y ago

Agile requires trust to work. Without it, the process will quickly devolve. Low trust is the problem, not scrum. Trying to be agile without trust is like trying to bake bread without yeast. You go through all the same motions, but in the end all you have is a dense, sticky mess.

DangitBobby 4y ago

Can someone explain to me the point of a sprint? How about "there is some work available to do, and you do it as you become ready"? Am I supposed to be working longer than 40 hours this week to finish the work arbitrarily assinged to this sprint, because if so you are absolutely fucking off your rocker.

mjfisher 4y ago
The point of having sprints is to trade off some utilisation for predictable delivery. I.e. everything should be easily deliverable within a given sprint, to the point that almost everyone is idle (or working on non-sprint activities) by the end of it. In practice successful scrum teams might get 90% of their tasks done a sprint - if that's not happening you need to commit to less each sprint (fewer points or fewer estimated days) until it does.

js8 4y ago

I don't see any evidence that Scrum works. All the proclaimed good parts (standups, sprints, retros) can be done asynchronously on as required basis instead of synchronously/periodically and a decent manager is able to coach/remind people to do so. Making them synchronous is often very distracting.

BarryMilo 4y ago
The benefits of Scrum is not really Scrum itself, it's to have a standard by which to measure oneself. If you can say "this way is better than Scrum", great! But if you don't know any kind of methodology and are just winging it, you would be better off with Scrum 99% of the time, because it does, at the very least, enforce discipline through routine. Companies who don't have a measuring stick are likely to spend wayyy too much time on procedure tweaking. Speaking from experience. Having this standard also allows you to tell stakeholders "actually, this is normal for this industry and I can prove it", which is invaluable when they're not very technically minded.
- js8 4y ago
  You're not really addressing the claim, which is whether or not Scrum actually works, i.e. is an improvement over any other method. I am not aware of any empirical, experimental or theoretical justification. Anything you currently practice can be used as a yardstick. However, I don't think that practitioners should be spending time on this research. That IMHO leads to exact problems that the article whines about. The idea that retrospectives are akin to scientific method is laughable. Maybe in 18th century that would fly, but there is lot more to scientific research than "continue doing what works and change what doesn't" (at the very least, following observations without theory leads to cargo-culting, which actually sums up the overall Scrum experiences pretty well).
  - BarryMilo 4y ago
    I'm not addressing your claim because I suspect it's not the main reason people use Scrum, in practice. I'm saying it's a political tool, and any debates around its "effectiveness" are pointless as the real benefit is keeping management away. The efficiency gains that you discuss would be pennies on the dollar in comparison.

ojciecczas 4y ago

:))))

bmitc 4y ago

I wonder how many articles, blogs, conferences, certifications, books, talks, soliloquies, consultants, etc. it will take to tell us we're all doing it wrong to make "Agile" and "Scrum" actually work.

lloydatkinson 4y ago
Honestly I’m not sure management will ever acknowledge or admit they’ve totally distorted agile from what it was meant to be in the manifesto into Big Agile™ with its optional add-ons Scrum® and SAFe© especially with “Agile Delivery Consultants” and other nonsense titles. They’ve started replacing scrum masters with those now too. At least until the next big thing comes along and they will declare agile to be just as bad as waterfall.
antupis 4y ago
Scrum works fine if you implement it by the book and then start tailoring slowly it based on team retros. Problem arises when PM or other manager goes rogue and starts implementing own ideas to scrum or just presures more stuff to sprint.
- bmitc 4y ago
  That’s part of my point. How many companies do I need to work for such that that works, because every company that has used Agile or Scrum say that exact thing about tailoring it to the team from some base level. It seems to me that if everyone does it wrong, then it is not a good fit for how people actually work.

lloydatkinson 4y ago

I wrote an article on a specific part of scrum/agile: estimation and why most organisations are ruining team morale. https://www.lloydatkinson.net/posts/2022/one-teams-eight-points-is-another-teams-two-points/ https://www.lloydatkinson.net/posts/2022/one-teams-eight-poi...

jokethrowaway 4y ago

> The problem with Scrum is that it usually works. In tech, we hate that. What we like is to give talks, prepare slide decks, and, most importantly, to invent things ourselves. I've never seen Scrum works well in the last 10 years since I've heard of it. No amount of BS scrum consultants is enough to make it work.

seattle_spring 4y ago

> The problem with Scrum is that it usually works This was the first line of the article, and I immediately closed the tab because that is a dead-wrong claim. Is the rest of the article as ridiculous, or does it become worth reading?

brycewray 4y ago

> You’ll know you have successfully ruined your standups when they’re taking thirty or more minutes, and your whole team hates them to the point they won’t do it if you’re not present. (Involuntarily shudders due to flashbacks.)

Pentamerous 4y ago

I've been working in Scrum based frameworks for the past 8 years in different jobs. Learned from the teams practices and Scrum Masters. Only this year did I decide to actually read the Scrum Guide. I was never in a team that practiced it like that. All of them had stuff changed and reading the guide I was confused because the changes seemed for the worse. I feel like this is mostly the experience for people when they describe Scrum.

BoneZone 4y ago

> Just like creating your own front-end framework is a rite of passage for web developers, creating your own version of Scrum is a rite of passage for engineering managers. Excuse me, what? I've worked in web development for years and I personally know 0 people who have written a front end framework like React, View.js, etc.

addicted 4y ago

Something I don’t understand about standups. Why should anyone wait until the standup itself to reveal blockers? In my experience the team reveals blockers as they arise and someone usually finds a solution for them within 30-60 mins. There’s rarely an instance where there are pending blockers during the standup.

deleted 4y ago

[deleted]

Tycho 4y ago

There’s two good things about agile/scrum: breaking work up into manageable chunks; and having daily check-ins to make sure people aren’t doing the wrong thing for months on end. The rest can be ignored.