[HN Gopher] How to distort Scrum until it no longer works
___________________________________________________________________
How to distort Scrum until it no longer works
Author : tapanjk
Score : 73 points
Date : 2022-10-07 16:48 UTC (6 hours ago)
(HTM) web link (lucasfcosta.com)
(TXT) w3m dump (lucasfcosta.com)
| 0xbadcafebee wrote:
| 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
|
| 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.
| commandlinefan wrote:
| I remember reading the agile manifesto around '99 or so (back
| then it was called XP, "extreme progrmming") and then, after
| having worked in software for going on 10 years, it was a
| breath of fresh air. I couldn't believe that logical, rational,
| sane principles of software development were not just being
| proposed by influential voices but were actually _being
| considered_ by managers.
|
| It took about a year for disillusionment to settle in.
| Everybody seemed to come away from that document with a
| completely different interpretation and in most cases that
| interpretation was, "do exactly what we've always been doing
| that never worked, but add even more meetings on top of it."
|
| One thing that no big-A "Agile" document has ever spelled out
| clearly is that the sort of agility _can 't_ work with fixed
| delivery dates. (Nor can any other software design methodology,
| but that won't stop "stakeholders" from insisting that because
| fixed delivery dates are Very Important, they're not just
| achievable but easy and you're just stupid).
| [deleted]
| 0xbadcafebee wrote:
| I mean, Agile just can't work at all, because it conceives of
| only one part of a business without considering all the other
| parts.
|
| I would prefer we popularized Deming's 14 points. That at
| least is achievable, and considers the whole business.
| jacobyoder wrote:
| 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 wrote:
| > "You have to break it down more"
|
| "How much time do I have to do the analysis to break it
| down?"
|
| "None"
| deathanatos wrote:
| 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...
| andirk wrote:
| 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.
| s1k3 wrote:
| Using it at prescribed is all you need to do.
| convolvatron wrote:
| 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
| chrisseaton wrote:
| 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.
| de6u99er wrote:
| Estimates are done by developers. If devs think they must do
| things quickly it's up to them to communicate estimates that
| will make their life stressful. My approach was not to
| challenge estimates except if I thought they were too low,
| which led my teams to almost always meet their sprint goals.
| wahnfrieden wrote:
| employers are happy to let people "burn out" via exiting after
| a number of years of consistent sprinting because hiring
| occasional replacements can also be useful in other ways and
| the social cost of those burnout patterns isn't really the
| company's concern. so as often said at companies/by management,
| try to connect your view on what an individual's healthiest or
| most productive life would be to what is actually valuable to
| their employer as a business
| WorldMaker wrote:
| That's always bugged me as a broken analogy, too.
|
| In college it was an extremely common aphorism "It's a
| marathon, not a sprint" as reminder to sustainably pace
| yourself and it has always seemed like Scrum originators had
| heard that phrase and gotten it exactly backward and it stuck.
|
| In marathon pacing analogy terms, "Split" would be the more
| accurate term. Though I know a lot of people don't think that
| sounds as good as "Sprint" does. Personally, I've often
| preferred just calling them "Fortnights" as an accurate
| description for "two-week process" (and a useful callback to
| long watches in older times). (Though the game "Fortnite" has
| confused that term a bit recently among the youth. "What does
| this have to do with the shooter?" Sigh.)
| chrisseaton wrote:
| Maybe a 'lap'.
| WorldMaker wrote:
| The original legendary Marathon was a run between the
| cities of Marathon and Athens. No loops in that course to
| consider "a lap". 'Lap' doesn't fit the analogy quite right
| either. (Some modern street Marathons do use lapping
| courses today, but that is more for simplifying the
| logistics of getting people back to their cars and such
| from the finish line as anything proper to the "form" of a
| Marathon.)
| chrisseaton wrote:
| > The original legendary Marathon was a run between the
| cities of Marathon and Athens.
|
| Why's it have to be a marathon in your mind? Any race -
| doesn't have to be that literal.
| hbrn wrote:
| As someone recently said it here, the difference between
| software development and marathon is that marathon runners know
| their destination.
| tomatotomato37 wrote:
| 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
| rob74 wrote:
| Or "journey" - then you can explore philosophical concepts
| like "it's not about the destination, it's about the
| journey" to help cope with projects that never get
| finished...
| chrisseaton wrote:
| 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 wrote:
| Orienteering definitely fits better.
|
| And it's a competitive sport. It might not be healthy, but
| that's how you win.
| hinkley wrote:
| 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.
| commandlinefan wrote:
| > marathon runners know their destination
|
| Hell, in this analogy even the marathon _organizers_ don 't
| know the destination. Or much care.
| hbrn wrote:
| Ideally, during first few years organizers are runners.
| They don't know the destination, but they care more than
| anyone.
| mrguyorama wrote:
| I'm tired of pretending software developers don't know their
| destination.
|
| If you started making a task-tracking app, and after all the
| work for scrum end up building a video game instead,
| something has gone terribly wrong.
| chrisseaton wrote:
| Didn't Slack do that exact thing, but the other way around,
| and are now worth 20 billion?
| hbrn wrote:
| While I personally don't believe it, one could easily
| explain it with survivorship bias.
| rob74 wrote:
| Plus they ended up with the most elaborate Easter eggs I
| have seen in a web app: https://slack.com/404
| Macha wrote:
| The founder even did it twice. The last time he set out
| to make a video game, he came out the other end with
| Flickr
| bmj wrote:
| I think experiences vary greatly based on company and
| domain. I work on a team supporting features for an app
| that is used by tens of thousands of people every day. Yet,
| what we plan to produce at the beginning of the quarter
| rarely matches what we actually produce. Example: my team
| spent _months_ working to integrate our app with a new data
| gateway service. We were, I dunno, 75% of the way there
| when executives decided the data gateway should not be used
| (this months after they said this same gateway was the
| future of the company). So, I 'm not pretending when I say
| sometimes, I don't know my destination. Sometimes I _think_
| I know my destination, only to find that both my course and
| the destination have changed.
| theshrike79 wrote:
| Marathon has a clear route and a clear end point defined before
| the starter gun goes off.
|
| Now imagine a marathon run by a drunk monkey who changes the
| route on a whim every 30 minutes.
|
| Who wins, the sprinters who sprint for 30 minutes and check
| where the next target is or the marathon runners who are still
| going by the original plan?
| chrisseaton wrote:
| Well nobody can keep up a sprint pace for 30 mins let alone a
| marathon distance, so those people will burn out before they
| get that far.
| _gabe_ wrote:
| Well, one man can[0], but in general this is very true. My
| team was talking about this same thing a few days ago, as
| one of our team members got switched to a new team that
| sprints all the time. You can't sprint your whole life,
| it's much better to pace yourself and avoid burnout/injury.
|
| [0]: https://youtu.be/A73HQwEct-o
| yrgulation wrote:
| Doesnt matter, if you cant keep the pace they'll pip or
| underperform you and then throw you out.
| troupe wrote:
| The value of a sprint is to help keep everyone focused on how
| to deliver something of value and usually this means working
| with the customer to figure out how to make sure you deliver
| the valuable pieces while deferring the pieces that can wait
| until later. So basically making sure everyone is able to work
| efficiently. If they are being used to try to make people work
| more hours every week, then they are missing the point.
| clumsysmurf wrote:
| Why need a "push" sprint for that, a "pull" priority queue
| like XP is just fine. Then demo every few weeks plus or
| minus, when there is something tangible to show.
| rob74 wrote:
| Ah yes, the mythical customer that can tell you exactly what
| they need, and even prioritize it. This customer probably
| also can be bothered to give usable feedback on what you have
| built in a timely manner. But I've yet to see such a
| customer...
| TrevorJ wrote:
| I don't think you need to distort Scrum for it not to work.
| ghusto wrote:
| > 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.
| black_13 wrote:
| lkrubner wrote:
| 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...
| fortylove wrote:
| 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
| hbrn wrote:
| It's a slippery slope. If there's one guy that gives a 3 minute
| update, he'll look more productive than the guy that gives 30
| second update. So the next day 30s guy will fill his update
| with unnecessary details to look as productive.
|
| The cure is constantly being aware of that bias. And
| remembering that main audience for standups is not your
| manager, it's your peers. Talk about things you want them to
| know.
|
| There's a lot of subtle tricks that people don't even
| use/remember at this point. Like doing standups while actually
| physically standing. This creates a negative feedback loop
| instead of positive: if someone talks too much, the whole team
| will pushback.
| andirk wrote:
| No manager in the meeting. No one to impress. Everybody
| stands. Light banter at the beginning because we're a team.
| One person leads the standup, round robin each time. Standup
| leader takes notes to paste in chat after, hurries people the
| f up if they're going on and on. Lastly, if you are late to
| standup even by 1 minute, you have to sing a song of Standup
| Leader's choice.
| AnimalMuppet wrote:
| Yeah. "Let's take that offline/out of the meeting" when
| someone talks longer than 1 minute (longer than 30 seconds
| if it's a larger team).
|
| By the way, I was at a place that did XP, and one of the
| rules was that if there was a meeting, there had to be
| food. What that did is, if someone was talking too much,
| someone would ask them "Are you going to eat that?" That,
| um, gently if not subtly told them to stop talking so much.
| Also, it meant that we got to snack.
| personalidea wrote:
| we used to call 'parking lot' as in 'Let's take this
| outside'. Then when the standup ended, those that wanted
| to get in on the topics on the parking lot would stick
| around.
|
| And for every minute you ran late, you had to do a push
| up.
| no_wizard wrote:
| we combatted the bias factor by having managerless standups,
| and a designated (rotating) person just takes notes and
| forwards them to the manager.
|
| Its actually fine. Management has repeatedly admitted they
| get little out of standups when there isn't a managerial
| level blocker (IE, we need them to interface with a team) and
| the concise written note updates allow them to see patterns
| of issues and address them more holistically.
|
| For engineers, it got rid of the implicit bias talked about
| here.
|
| Our standups are like 5 minutes or less now, and blockers /
| collaboration on blockers is way more common.
|
| This also made the stakeholder check in every two weeks way
| more productive, people I think shifted their _look what I
| did and how I did it_ energies to that meeting, where its
| 100% more appropriate.
| Tarsul wrote:
| in the notes, is there information about _who_ did what or
| not?
| no_wizard wrote:
| I hesitate to broadly interpret this, but notes are not
| meant or used to "keep score", and if things can be
| explained without naming people they are, for sure, but
|
| "person A is going to help person B to unblock them
| because of x y z" is about as detailed as one needs to
| be, usually.
|
| Can you clarify what exactly you mean here?
| Tarsul wrote:
| You actually answered my question, thanks. I was/am just
| curious about which person has the decision power about
| who works on which part. But I guess it goes something
| like: person A tries to solve X. If he can't solve it, he
| asks the team and someone in the team will try helping.
| If the problem cannot be solved within a reasonable
| timeframe, then someday management will ask what's going
| on.
| hbrn wrote:
| I really like that.
|
| Having management present can subconsciously push people to
| turn standups into a productivity contest.
| ryathal wrote:
| It's not supposed to be a slippery slope. This is where a
| functioning "Scrum Master" is supposed to tell that person to
| stop talking and move on to the next person. That never
| actually happens though, so the next best scenario is light
| shaming of the guy who talks too long. If you have bad
| managers or too many people with management anxiety then it
| can be good to kick them out of the meeting.
| hbrn wrote:
| I understand that this is how it is supposed to work in
| theory. But realistically most startups don't (and dare I
| say shouldn't) have the luxury of a dedicated Scrum Master.
|
| Another thing I don't like is that it relies on humans to
| do a good job. How do you hire a good Scrum Master if
| you've never been one yourself? Hires like that are usually
| hit or miss. What if you need to hire ten of those?
| P5fRxh5kUvp2th wrote:
| > 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 wrote:
| > 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.
| theonething wrote:
| Has anyone here had experience with daily standups done
| exclusively over Slack (or similar service)?
|
| To me it seems like it would mitigate some of the downsides
| like people talking too much. And being asynchronous and in
| written form is a big plus to me. I can just skim through it
| quickly rather than sit through a monotonous daily meeting.
| em-bee wrote:
| at one company we did a project wide daily standup on irc.
| all teams, about 50 people would report all at once at a
| specific time of day. there was a bot that would track that
| everyone has reported, and that was it. as a developer i
| would look at the report log to see if anyone was touching
| issues that i was working on, and if so possibly talk to that
| person later to see if there was anything we needed to
| coordinate. likewise i'd look if anyone reported blockers
| where i could help.
| yrgulation wrote:
| By pdf certified scrum masters who have nothing else to do but
| bastardise agile.
| dgeiser13 wrote:
| A: Use Scrum
| tbarbugli wrote:
| I actually cant understand the point the author is trying to
| make. For instance: what is his stance on retros?
| nvader wrote:
| 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 wrote:
| Every time someone criticizes scrum/agile, "No true Scotsman" is
| the most common response.
| https://en.wikipedia.org/wiki/No_true_Scotsman
| haolez wrote:
| 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.
| tomohawk wrote:
| It gets back to what does the team value. If you can get the
| team to agree on what the core values are, it will help them
| take their eyes off the trees and focus on the forest. You'll
| need to meet with them apart from whatever scrum processes are
| going on.
|
| Once the team values are more aligned, the retrospectives can
| start to be fruitful. At the retrospective, pick one or two
| items that seem misaligned with the values. Try to have longer
| term (at least a quarter) view, with incremental progress.
|
| YMMV. I ended up leaving a team that functioned the way you
| describe. I'm sure your team is driving people away. At another
| team, I was able to take the approach above and the team became
| must better over 2 years.
| haolez wrote:
| Yes, it is driving people away. I lose one dev every two or
| tree weeks.
| epicureanideal wrote:
| > 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 wrote:
| 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 :)
| bryan0 wrote:
| 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 wrote:
| 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 wrote:
| _I 'm probably doing standups wrong..._
|
| And then you describe some of the healthiest standup culture
| I've seen...
| [deleted]
| breakpete wrote:
| 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.
| troupe wrote:
| 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.
| meesles wrote:
| 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 wrote:
| >>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.
| wonderwonder wrote:
| 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 wrote:
| 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.
| de6u99er wrote:
| 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 wrote:
| 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.
| alexfromapex wrote:
| 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.
| matai_kolila wrote:
| 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.
| rightbyte wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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.
| bryan0 wrote:
| Agile is very different than Scrum. Agile actually has very
| good SWE principles. Scrum is one heavy-handed approach to
| following them.
| f1shy wrote:
| 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!!!
| JonChesterfield wrote:
| What's a Hs?
| ryathal wrote:
| I swear someone created SAFe as a joke by just taking the
| strawman waterfall diagram and adding scrum words, and sprinkle
| in a few more useless people for good measure. It also ensures
| that anyone that needs to actually talk or work together is far
| to busy to achieve progress.
| bitwize wrote:
| You are exactly correct, except:
|
| 1) it was RUP, not waterfall (RUP is basically many
| waterfalls in parallel)
|
| 2) they were _dead fucking serious._
| sidewndr46 wrote:
| Is "RUP" Rational Unified Process here?
| bitwize wrote:
| Yes
| wpietri wrote:
| I think that's pretty close except for the joke part.
|
| The early-days problem with the Agile movement was that it
| promised actual change by empowering the line workers to
| actually get things done for users by shipping early and
| often. That was an intolerable threat to industrial-age
| managerial power structures, to which waterfall is an ideal
| that justifies lots of management control.
|
| But since then it's been gradually watered down and tamed.
| Scrum's certification scam was the start of that, and SAFe
| strikes me as the end result: lots of Agile jargon with the
| rigidity of waterfall, providing long-term safety to managers
| in large companies everywhere.
|
| I wrote about this dynamic before SAFe existed, but it seems
| to fit right in with what I described:
| https://williampietri.com/writing/2011/agiles-second-
| chasm-a...
| tharkun__ wrote:
| You hit the nail on the head and posted just before I
| would've. The only thing I can add to that directly here is
| this:
|
| Just look at the acronym itself!
|
| It tells those managers at Big Corp that it is finally
| _safe_ to implement Agile!
| pwinnski wrote:
| We do standups three times a week, and I will flat-out hang up
| Zoom once we hit 15 minutes. I find standups helpful, but not
| if they're longer than 15 minutes!
| jayofdoom wrote:
| Yep. I'd explicitly never work at a place that implemented
| SAFE. Reading this article felt like someone describing the
| process at a previous employer. Just nailed it with all
| planning right at the intersection of useless, time consuming,
| and painful.
| hkon wrote:
| Create very small tasks, that way you all will be super
| productive.
| bmj wrote:
| 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.
| jmull wrote:
| 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 wrote:
| 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 wrote:
| 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.
___________________________________________________________________
(page generated 2022-10-07 23:01 UTC)