[HN Gopher] Why Scrum is stressing you out
___________________________________________________________________
Why Scrum is stressing you out
Author : aard
Score : 352 points
Date : 2024-09-14 23:11 UTC (1 days ago)
(HTM) web link (rethinkingsoftware.substack.com)
(TXT) w3m dump (rethinkingsoftware.substack.com)
| debacle wrote:
| We moved from sprints back to work queues for exactly this
| reason. Output is exactly the same but no one is cutting corners
| to "finish" the sprint. We still use a kanban and do estimation
| the same exact way, but rather than arbitrary deadlines, devs are
| trained and encouraged to communicate on their velocity in a way
| that is far more effective than a daily standup.
|
| Scrum was an idea that had its time, but after like...15 years
| the limitations are apparent.
| aetherson wrote:
| The main value of stressing about sprint goals and what's "in"
| a sprint and finishing it is the very specific situation of
| there being a bunch of people who want to feed in a large
| amount of work to a team (usually bugs/support
| requests/operational work) and it results in constant
| prioritization issues.
|
| If you don't have that situation, you probably don't need to be
| really careful about what's in a sprint.
| gregmac wrote:
| Kanban lets you prioritize exactly the same way, except it
| doesn't have to fit into a sprint schedule. You also have to
| make good stories, which are independent, have a meaningful
| thing that gets delivered and are of a reasonable size. Then
| important bugs can get moved to the top of the to-do column,
| and get done quickly as possible without interrupting any in-
| progress work.
| Viliam1234 wrote:
| Problems with Scrum: It's nice that you did your planning
| poker, but all these tasks need to be ready by the end of the
| month regardless.
|
| Problems with Kanban: It's nice that you set priorities to
| the tasks, but all of them need to be ready by the end of the
| month regardless.
|
| Conclusion: If there is more work than people can
| realistically do, and it all needs to be done no matter what,
| it doesn't matter what process you use; people will be
| stressed and burned out.
| lloeki wrote:
| > do estimation the same exact way, but rather than arbitrary
| deadlines,
|
| The core problem with that is that effort - consciously or not
| - gets immediately turned into (start day + estimate) =>
| deadline which only works when you consider spherical cows, not
| accounting for the hard true practical fact that reality is
| messy.
|
| And it is quite messy, by the very nature of the work which is
| to do something that has not been done before (otherwise by the
| very nature of software you'd just reuse it) and thus carries
| unknown unknowns. Everyone has experienced this "one-line fix,
| should be done tomorrow" that turns into a bind-mending multi-
| week hunt down the rabbit hole; replace "fix" with "feature" at
| your discretion; replace rabbit hole with "that very urgent
| task preempting anything else".
|
| The second-order problem is that deadlines are used to schedule
| higher level dependencies between teams, all the way up to
| product, and possibly customers, and then it becomes the
| coupling interface and everything falls apart when there's a
| delay that inevitably trickles up with rippling consequences,
| because the system is not designed to handle such a failure
| mode, having this deadline dependency as its core interface
| between all the parts.
|
| If you're not convinced of that, "follow the money": the
| consistent metric across the software industry to evaluate an
| employee's performance boils down to "deliver on time". Three
| months down the road, the rational explanation to delays of
| mandatory rabbit holes and very legit preempting tasks is
| forgotten, even when acknowledged by management. You're told to
| factor all that in, but estimating unknown unknowns is by
| definition impossible (best case you go statistical, with
| deadly outliers around the corner, which amounts to say it's a
| bet). Experience reduces these unknowns but they're still
| around, everywhere. Overall, you tried telling the hard truth
| with absolute candor were left helpless when it backfired.
|
| Ultimately, whatever the process, the stark reality is that to
| get shit done you have to take part in the make-believe dance
| and lie - white lies, because soon enough one realises that the
| other kind of lies also backfires very quickly - in a way that
| still communicates some form of deeper truth: "progress is
| being made, it'll be done (when it's done)". Inflate some
| numbers, tune wording when reporting, steal time by bleeding
| some for task X (reported or skunkworks) into task Y. All the
| reporting meetings and documents entirely become smoke and
| mirrors, but are somehow important as they're oil to the whole
| machinery. Two parallel universes emerge and graciously evolve
| in parallel.
|
| This sleigh of hand is the missing buffer catering for the lack
| of acknowledgment that producing software is entirely different
| in nature than producing hardware in a factory. It is in
| essence more of a creative act, albeit a strangely misleading
| one because of its technical component. Lots would be amazed as
| to how much closer it is to advanced drawing or musical
| composition than it is to more "material world" engineering
| (although the rigorous process of the latter certainly helps
| for technical aspects), and taking classes of the former would
| probably do a lot of good.
| AnarchismIsCool wrote:
| I've learned to hate software process. If you have team sizes set
| sanely and empower devs to do what they need to do in order to
| accomplish the goal, they'll be fine without the management
| overhead of arbitrarily imposed productivity flow. Agile et al,
| along with 99% of the features in ticketing systems, exist to
| make managers feel like they are justifying their paycheck.
|
| If you are a manager and this makes you angry, you're one of the
| bad ones.
| loloquwowndueo wrote:
| Just keep in mind that a lot of people equate Agile with Scrum,
| which is incorrect. Agile is about exactly what you said:
| empowering devs to get shit done. None of the extra "keep
| managers happy" crap that Scrum introduces is in any way
| covered by the Agile manifesto.
| LeFantome wrote:
| What in Scrum is about keeping managers happy?
| pan69 wrote:
| Story points, velocity, burn down charts, shit like that.
| wild_egg wrote:
| None of those things are part of scrum as described by
| the actual guide
| RussianCow wrote:
| But nobody follows the actual guide so it doesn't really
| matter.
| wsc981 wrote:
| Some things that come to mind:
|
| - burn-down / velocity charts
|
| - retrospectives
|
| - poker sessions
|
| - daily stand-ups
|
| - user stories and related tickets (eg in JIRA)
|
| There's probably more ...
|
| Perhaps these things are not necessarily _meant_ to make
| managers happy, though managers do seem to like this stuff.
|
| As a dev, I prefer a more fluid approach without all the
| rituals. In the start-up I joined a couple of months ago,
| we don't deal with any of the above shit. Which of course
| is sure to change as the company grows, as that seems to
| happen often.
|
| Our current way of working (remote company, 4 people):
|
| - 2 calls a week, which tend to last about an hour.
|
| - We discuss work for upcoming week or future stuff.
|
| - We try to deliver every week on whatever was agreed upon
| at start of week.
|
| Actually, previous company I worked at, was a bit bigger
| (35 people), but also very little rituals, at least for
| devs. There was a support department that did the JIRA
| related stuff. And we had like 2 day-long meetings every
| year to discuss personal goals/work for next half year. But
| afterwards just a short weekly meeting for team (sometimes
| lasting only 10 minutes), no stand-ups and such.
| jghn wrote:
| I've been a dev, and I've been an EM.
|
| The only thing on that list I've ever liked is the
| velocity charts. And the only reason I liked them is that
| it helped me give a slightly less made up date to my own
| bosses to explain when something might ship.
|
| Over the years I've found that devs have been the one who
| like retros. Or at least a certain subset of them. When
| I've been an EM I would try to get rid of them, only to
| have them requested by my teams. Who knew.
| rpcope1 wrote:
| As a developer, I find retros most useful when EMs (and
| probably PMs, depends on how things are configured
| organizationally) aren't present, as it should give a
| chance to talk freely about challenges you or the team
| face, which often are organizational in nature and may
| involve one's management chain. My current role doesn't
| adhere to this, and it makes retro often really painful.
| jghn wrote:
| I would agree with you. I never want my manager there. As
| an EM, I never want to be there. And yet, as the years go
| by, when I have an EM role I find my presence is
| requested. Again, who knew?
| Leherenn wrote:
| I don't know, at least for my current team a lot of the
| stuff we complain about in the retro is beyond the team
| level: coordination between teams, infrastructure issues,
| ... The intra team issues are usually talked about before
| (e.g. during standup, or just asynchronously).
|
| If the EM is not there, those are not actionable. What we
| try to do is: do the retro by ourselves, and invite the
| EM at the end of there is stuff for them. Usually they
| are not available though...
| meowfly wrote:
| Retros all too often focus on the last thing that
| happened and risk turning into a complaint session.
|
| I've told my team anyone is welcome to ask for a retro
| whenever for any reason, but we don't make them recurring
| meetings because there is too much of a temptation to
| find something wrong to fill the time.
| jghn wrote:
| This is exactly why I hate retros. It's just a venting
| session. We're going to whine about some things, of which
| we have absolutely no power to change, and somehow that
| changes the future.
|
| But people seem to love them.
|
| I'd prefer to spend that time putting my head down and
| grinding through whatever sucky thing people were
| otherwise whining about.
| shade wrote:
| Best retro I ever had, on a small team of seniors: we all
| sat down, looked at each other, agreed that a sprint
| happened and we couldn't think of anything that was good
| or bad about it. Then we called in our manager, who also
| acted as scrum master, so we could do planning for our
| next sprint. I thought this was reasonable enough -
| ostensibly we'd do retro and then planning back to back,
| and none of us minded the chance to take a few minutes
| and reflect if we had anything we should discuss.
|
| By contrast, I've worked with scrum masters who were
| strict about the process and insisted _every_ retro
| needed to have at least one improvmenet or action item
| out of it, preferably more. I found this pointless and
| I've rarely seen them actually followed up on.
| Stratoscope wrote:
| And sprints!
|
| When I started at my current job, I naively looked at the
| bugs and tasks assigned to me, and started picking and
| fixing the highest priority tickets.
|
| Then I was informed, "Oh no, that's not how we do things
| here. Don't look at the priority, just work on what is
| assigned to you in the current sprint."
|
| I had never heard of sprints before.
|
| More recently, I had a conversation with my manager and
| asked, "Do we really need sprints? I've been in this
| business a long time. 10, 20, 30 years ago we didn't have
| sprints and somehow still managed to produce great
| software."
|
| The reply was "But if we didn't have sprints, how could
| we possibly measure the team's productivity and
| individual productivity?"
|
| I knew I wouldn't win this debate, so I politely let it
| drop. I just wanted to sow some seeds of doubt.
|
| In all fairness, my manager is a very reasonable person.
| But when this devotion to sprints is ingrained in the
| entire company, it is hard to question it or get away
| from it.
|
| At least we don't do daily standups!
| ta_1138 wrote:
| That's normal nowadays, even in the most ridiculous of
| situations.
|
| I once found that a system was getting a little
| expensive. As, AWS was billing us a million a month
| expensive. I figured this out, and came up with a plan
| that would cut it down to 80 thousand by spending 4 days:
| You know, a mild, 11 million a year of savings.
| Management insisted that the work had to go through
| scheduling, and intake, a process that would involve zero
| developers looking at anything, but would delay doing the
| task a month and a half.
|
| And no, nothing the team was working on came even
| remotely close to that ROI. Following the process just
| cost an extra 1.5 million dollars.
| shostack wrote:
| What was the opportunity cost of potentially
| deprioritizing other work?
| nine_k wrote:
| ^ _nothing the team was working on came even remotely
| close to that ROI._
|
| I read it as that the opportunity cost would be lower.
| fwip wrote:
| The manager probably can't take the credit for saving 10
| million dollars if they don't put it through the system.
| userbinator wrote:
| _The reply was "But if we didn't have sprints, how could
| we possibly measure the team's productivity and
| individual productivity?"_
|
| "Do you really need to measure that, or perhaps something
| else is more important?"
| Silhouette wrote:
| _" But if we didn't have sprints, how could we possibly
| measure the team's productivity and individual
| productivity?"_
|
| A more enlightening question might be what actionable
| information about productivity they are gaining from the
| sprint-based metrics.
| jksmith wrote:
| Good points, and eye-rolling stuff for teams thaqt don't
| understand the intricacies. For instance:
|
| - burn-down / velocity charts: Teams use this at standups
| to make sure their sprint isn't drifting. That's why a
| burn-down should be tracked in hours and not points. With
| points, the data isn't actionable in a reasonable amount
| of time. The the team sees a problem, they might make use
| of a pre-determined emergency procedure to address it.
|
| - retrospectives: Yeah most retrospectives are horrible.
| Retros should be like post rocket test - examine your
| telemetry deltas to see what changed (edge cases,
| governance,compliance, desgn, etc.) These conversations
| are not forced, but good teams always repeat the same
| data analysis unless they intentionally change it.
|
| - poker sessions: Yeah this is totally misunderstood.
| Pointing stories is about snap reactions to comparing
| difficulties and complexity, and that's it, move on.
| Teams will tighten up estimates when they do an
| implementation plan in sprint planning. So they don't
| sweat estimates.
|
| - daily stand-ups: The whole team is responsible for the
| sprint backlog, nothing is assigned, everything is
| volunteered. So if you're working on something that is
| going south, or you have some extra capacity, let your
| team know about it. The team will work together to scale
| capacity to get things done, which is how they can
| disappear on Friday afternoons.
|
| - user stories and related tickets (eg in JIRA): Well
| yeah, Jira sucks. So do all the other major backlog
| tools. Jira gets addins, but the fundamental approach to
| backlog development hasn't changed in a decade. (I'm
| working on a soln from scratch, btw).
|
| Also, user stories are meant to be work-items with enough
| signal so they can be executed with certainty in a
| sprint. So that means a lot of refinement to the left of
| the story must occur to get rid of the noise (epics to
| features to stories to tasks). Once a team says a story
| meets their definition of ready, that story can be
| scheduled for a (timely) sprint. Team members may be
| doing hard-core story refinement because of some
| technical hurdles, so their time outside of development
| during sprint can be pinned down with the team's capacity
| plan. BTW, capacity plans and implementation plans belong
| solely to the team. They're nobody else's business,
| including managers to CEOs.
| relaxing wrote:
| > That's why a burn-down should be tracked in hours and
| not points. With points, the data isn't actionable in a
| reasonable amount of time.
|
| I don't follow this?
|
| The arguments against estimates in hours are well known
| as this point.
| jksmith wrote:
| Sure, comes from a prevailing view that estimating is
| bad. But it's only because estimating is treated like the
| answer, then we just go with that answer.
|
| The best scrum teams I've worked with maintain a very
| important survival notion: We don't know the full minimum
| survivable solution today, but that's ok because we do
| know enough to get to tomorrow at least. We survived
| another day. Point is, estimating was never meant to be
| an answer. It was just meant to kick off discovery. And
| that's a great way to start because humans tend to be
| exceptionally good at quickly comparing things for
| difficulty and complexity. It's an instinctive survival
| skill.
|
| Ultimately, well after estimating this scrum team will do
| an implementation (tasking) plan in hours if needed
| during sprint planning. They will compare that plan
| against their team capacity plan in hours. If the
| implementation plan blows out the cap plan by say, 30%
| then that's a warning sign and they'll tell the PO they
| need to drop a story for the upcoming sprint. If the cap
| plan compared against the imp plan shows a 30% surplus,
| then they will pull in a stretch story and bump their
| velocity, or won't tell the PO and maybe go play golf at
| the end of the sprint.
|
| So the story pointing exercise just gets the team some
| data that helps them get to the next day (survival
| speak). There's still a lot of story refinement to be
| done, before they will tell their PO a story is ready to
| be pulled into one of their sprints.
|
| When teams pull in stories to their sprint backlog, the
| team is committing to get that story done, so they need
| immediately actionable data on what's going on at every
| standup. If the burndown was done in points, the graph
| ends up looking like a straight line for days with sudden
| dropoffs toward the end of the sprint - that hides
| problems. So a sharp team will use task hours instead.
| Makes the plot a lot more actionable from day to day.
|
| Here's a popular presentation I do on estimating, and why
| we tend to misunderstand its usefulness. "How to do
| estimating while being chased by a rhinoceros:" https://g
| ithub.com/jamesksmithiii/Presentations/blob/main/Th...
|
| Also maybe useful: Drawings for what to cover in scrum
| ceremonies: https://github.com/jamesksmithiii/Presentatio
| ns/blob/main/Ce...
| relaxing wrote:
| No, the prevailing view is estimating in _hours_ is bad,
| hence the push for estimating in t-shirt sizes or other
| stand-ins for task complexity.
|
| The survival terminology is really off-putting. And
| what's the obsession with golf? This doesn't sound like
| any scrum team I've worked with or would want to be a
| part of.
| jksmith wrote:
| Well, a rather xor response, but that's ok. Let's go a
| different route: Someone is using a diet change (fixed),
| and the elliptical machine to lose weight. This person
| has no exercise background. The elliptical routine is
| basic - same program, one hour a day, 8 weeks. BF test is
| done at the end of each week. Graph the results. What do
| you think the plot will look like? Why did the subject's
| weight loss stall out?
|
| Estimations are meant to be exactly that, estimations.
| Don't try to make them anything else. They offer a grey
| answer, so use the best tools you have to deliver that
| grey answer. In this case, it's simply comparing
| challenges for size, complexity, etc. Don't try to do
| estimations in a different way just because you want an
| immediate answer. Estimations are meant to be a starting
| point to get to a minimum survivable solution. That's how
| humans use instinctive tools that use the least amount of
| energy to get to a point that they can survive a
| challenge. Think about the elliptical example.
|
| In scrum, estimations are the conscious way to get this
| discovery kicked off; they aren't meant to be an answer,
| because you don't have enough data yet for a solution.
| They are meant to be a starting point. Iterate to the
| solution. When you think you have enough signal for a
| solution (the sprint), do your final check and balance,
| which is a tasking plan in hours, during sprint planning.
|
| Another example: The year is 1929, and you're asked to
| guess the weight of the Empire State Bldg before
| construction has even begun (1931). What answer delivers
| more survival information? 180,000 tons, or this: "Well,
| we know each floor is going to have x concrete, y steel,
| but not sure about the other construction materials. So
| it will be something like (x+y+?)*#floors. If your life
| depended on it, which answer would you go with?
|
| You are looking for a number, and that's why people don't
| understand what estimating is about. The incorrect
| approach is like, "Well these estimations are crap, so
| let's change the estimation methodology." Yeah but it's
| still and estimation, and you already have a great
| instinctive tool to make those estimations via relative
| size comparison, which can be done so quickly, it could
| literally save your life. Instinctively, we accept that,
| conscoiusly we don't, so we turn into ill tempered Veruca
| Salt.
|
| Regarding the golf reference, I'm from Florida. Sorry if
| the attempt at levity was weak.
| rbetts wrote:
| > burn-down / velocity charts
|
| You need some coarse odometer to know where the finish
| line is. Burn-up charts are a reasonable input to that
| and can be very low effort. Just knowing where you hit
| the inflection point between new-issues added to a
| milestone vs. issues resolved is useful. If you can
| replace a burn up chart with tangible test results matrix
| or similar - even better.
|
| > retrospectives
|
| I have never found per-sprint retros useful, either. I
| guide teams to do a retro when the issues raised in the
| previous retro are resolved. WIP control FTW.
|
| > poker sessions
|
| In my experience, planning sessions are one of the most
| impactful parts of the stereotypical scrum process for
| three reasons: (a) Planning creates a consensus within
| the team about what the story actually means; (b)
| Planning often leads to someone proposing a good 80/20
| trade-off or raising an important point that avoids
| future re-work or unexpected tech debt. (c) Breaking big
| tasks into actionable, independently useful, small tasks
| is one of the hardest things for junior developers to
| learn. A lot of mentorship and teaching happens in good
| planning meetings. I encourage teams to try planning for
| the benefits of the process and not worry at all about
| fine grained points - "trivial", "medium", "unknown" is
| typically enough. Lots of mature teams will plan ad-hoc
| as they are ready for new work. This is my personal
| preference. But teaching teams how to plan effectively in
| a weekly planning meeting is often a good starting point.
|
| > daily stand-ups
|
| Standups that are control points for managers and
| expensive status gathering shortcuts are horrible.
| standups that are self-organizing, especially for teams
| that have ops + dev responsibilities, can be really
| useful. Nothing wrong with making a plan for the day - it
| should just take 10m.
|
| > user stories and related tickets (eg in JIRA)
|
| You should write down what you want to do somewhere and a
| few checklists go a long ways towards improving quality
| management.
|
| I have never found scrum to be a good process (like the
| article, I find it very grinding) and I strongly agree
| with the posted article. But a good dev process likely
| includes all of these elements in some shape.
| twunde wrote:
| Daily stand-ups, the main benefit of which is that managers
| (EMs/PMs) get daily updates on status. Sprints themselves
| which promise that a certain amount of work will always get
| done, without any free time being wasted.
|
| A lot of the ceremonies in general are mostly helpful to
| the EM/PM. How many things that you're doing are actually
| improving how you get work done? Especially when you
| consider how much time is spent on these ceremonies (sprint
| planning 1 hr, sprint retro 1 hour, daily standup 15-30
| minutes. Plus whatever prep is needed and the interruption
| time.) For many companies this is a 20% or more overhead
| that's mainly busywork because you still need the
| additional meetings to understand what you're working on.
| gedy wrote:
| This may sound like a no true Scotsman argument, when our
| company was trained by one of the scrum founders about 18
| years ago, they were very clear that the daily standup
| was only for the team members, and the scrum master. (The
| scrum master could be a team member, and rotate btw).
| Managers were not allowed or invited to these. The only
| thing product managers and engineering managers would
| participate in and give feedback was in Sprint demos, and
| the beginning of planning meetings to answer any
| questions on upcoming stories.
|
| At the time it was incredibly freeing and fixed a pretty
| awful and behind waterfall project. I was (briefly) at a
| startup a couple years ago that said they "did Scrum" and
| what a clusterfuck that was - all the managers meeting
| daily with devs to see if they were behind and scold them
| if they were. See ya.
| ta_1138 wrote:
| But Managers as the center of the scrum is how many, many
| tech companies the outside world wouldn't call crappy run
| things. They also use Jira, mostly because they want
| reports that let people two or three levels up think they
| have any control over anything.
|
| One of my least favorite standups was even worse than a
| ceremony for the manager: The manager and the Product
| representative were there in every single one, but they
| didn't actually pay any attention: Another 20+ minutes of
| "parking lot" would be added after the 5-10 minute
| process as they asked the team all the random questions
| they thought they needed, in which they also proved that
| they weren't actually paying attention to the actual
| updates, or the tickets, or anything. In practice, a
| sequence of 1:1 meetings where everyone was stuck
| watching, because after inquisition to one person, it'd
| come after another.
|
| In practice, I don't think I've seen scrum run without a
| manager in standup, ever.
| LaGrange wrote:
| Your scrum master is management. It's just a renamed PM.
|
| I can run a very near standup when allowed to. I also
| think it's a waste of time. Just send weekly updates to a
| group email, or something.
| wild_egg wrote:
| > Daily stand-ups, the main benefit of which is that
| managers (EMs/PMs) get daily updates on status.
|
| The scrum guide fairly explicitly states that managers
| should not attend or be part of stand-ups unless they're
| actively involved in the work as part of the development
| team.
| erik_seaberg wrote:
| That's hard to imagine. In big tech it's the team manager
| who decides that standups should happen and when (maybe
| this is an expectation from higher-ups). He always joins
| unless running late.
| bigstrat2003 wrote:
| Be that as it may, if the scrum guide explicitly says
| they shouldn't then it isn't really fair to blame scrum
| for that.
|
| Honestly, the recurring complaints with scrum, agile, etc
| basically boil down to this: shitty organizations can
| make any system miserable. People generally are blaming
| the intermediate cause (how we do scrum sucks) rather
| than the root cause (our company sucks and nothing would
| work).
| Aeolun wrote:
| We blame scrum because the framework provided makes it a
| lot easier for life to be miserable.
| bboygravity wrote:
| Oh, the good old "the user is doing it wrong, the product
| is fine" with scrum being the product.
|
| Can anybody (not PM/leader) give 1 example of a company
| where they saw scrum being done "correctly"?
|
| _crickets_
|
| I guess scrum is fine and people just don't know how to
| do it properly.
| albedoa wrote:
| Man, I agree with your specific criticism of the "No True
| Scotsman" refrain and with the larger criticisms of
| scrum, but this is an example of scrum prescribing _X_
| and companies doing _!X_ , the literal opposite.
|
| How could scrum, the product, possibly be to blame for
| that _even if_ it sucks? Or, at what point is it
| reasonable to blame the PM /leader for actively and
| knowingly practicing _!$scrum_ while pretending it 's
| _$scrum_?
| randomdata wrote:
| Companies try prescribing _X_ , but as developers have no
| reason to care _X_ doesn 't happen without strict
| oversight by management, thus leading to _!X_ to keep
| them in line.
|
| Is the gun with a 180o bend in the barrel, with a caution
| label that says "WARNING: Don't shoot yourself in the
| face", that sees everyone who tries using it shoot
| themselves in the face the user's fault, or could we say
| that the product is faulty?
|
| If a product relies on weasel words to try and pass its
| flaws off as being the user's fault, at what point is the
| product to blame? If one person uses it wrong, perhaps
| you can say that one person was doing something out of
| the ordinary, but when _every_ person uses it wrong...?
| oneshtein wrote:
| > In big tech it's the team manager who decides that
| standups should happen and when (maybe this is an
| expectation from higher-ups).
|
| Then it's not a SCRUM process at all. Case solved.
|
| https://scrumguides.org/scrum-guide.html#scrum-definition
|
| https://scrumguides.org/scrum-guide.html#daily-scrum
| nottorp wrote:
| > Then it's not a SCRUM process at all. Case solved.
|
| Yeah and communism also works in theory :)
| randomdata wrote:
| To be fair, it probably also works in practice, but by
| very definition post-scarcity is a necessary
| precondition. And that is still an ongoing effort that
| has never been realized. Granted, the UN has declared
| food to have achieved post-scarcity status so clear
| progress is being made, but we still have more work to
| do.
| nottorp wrote:
| > it probably also works in practice
|
| I've lived the first 14 years of my life under the
| Romanian communist dictatorship so no.
|
| Let's put it this way. If it's the property of the people
| it's not everyone's in practice, it's no one's. So you're
| free to slack, cheat and steal from your "property of the
| people", you're cheating "no one".
|
| > post-scarcity is a necessary precondition
|
| There is no post scarcity. The goalposts for scarcity
| just move up.
| randomdata wrote:
| _> I 've lived the first 14 years of my life under the
| Romanian communist dictatorship so no._
|
| That doesn't make any sense. Communism's defining feature
| is that there is no longer a state. How can you recognize
| Romania, and especially a Romanian dictatorship, without
| there being a state?
|
| Perhaps you're confusing communism with rule by the
| Communist Party?
|
| - Communism is a work of science fiction that imagines
| what life is like in a post-scarcity world - indeed,
| science fiction that some people would like to see become
| reality. Star Trek is a more modern adaptation on the
| same basic idea, which you may be more familiar with.
|
| - The Communist Party is a political group that, at least
| on paper, is focused on achieving post-scarcity through
| capturing the means of production. It was once theorized
| in a certain Manifesto about Communism that post-scarcity
| would not be achievable through capitalism as the
| capitalists would set up barriers to seeing it through,
| and that the way to protect against that was the bring
| the means of production into social hands. Hence why the
| Communist Party is so-named.
|
| But that would be like saying that democracy doesn't work
| because you don't like what the political party known as
| the Democrats are doing in the USA. Or that workers don't
| work because you don't like what the National Socialist
| German Workers' Party (Nazi) did.
|
| > There is no post scarcity. The goalposts for scarcity
| just move up.
|
| Perhaps. But it remains that communism cannot exist
| without having achieved post-scarcity. How could it?
| nottorp wrote:
| > Communism's defining feature is that there is no longer
| a state.
|
| Seriously? Who takes all the resources and allocates them
| "according to each person's need" then? :)
|
| > But it remains that communism cannot exist without
| having achieved post-scarcity. How could it?
|
| All the scarce resources are being stolen^H^H^Hshared in
| common.
|
| Communism predates the idea of post scarcity by a hundred
| years or more AFAIK.
| randomdata wrote:
| _> Seriously?_
|
| Yes. Communism's key attributes are that it is classless,
| stateless, and moneyless.
|
| _> Who takes all the resources and allocates them
| "according to each person's need" then?_
|
| We'd need to know more about how post-scarcity is
| achieved in order to answer that question. Star Trek says
| the replicator is responsible, although that seems
| unlikely outside of the imagined Star Trek universe.
| Based on what we can see today, I'd guess robots. But
| this is all speculative as we don't really know what
| post-scarcity truly looks like, or if it is achievable at
| all.
|
| _> Communism predates the idea of post scarcity by a
| hundred years or more AFAIK._
|
| Are you referring to what is oft referred to as primitive
| communism?
|
| Although I find it hard to believe that humans have ever
| not thought about post-scarcity. It seems like the first
| thought/dream anyone would have when first faced with
| scarcity constraints.
| nottorp wrote:
| > what is oft referred to as primitive communism?
|
| Did communist utopians realize it doesn't work so now
| they're adding "post scarcity" to it to make it work?
|
| Will they add "AI" next?
|
| Edit: "Based on what we can see today, I'd guess robots."
| Oh yea, "AI" is next.
| thayne wrote:
| In my experience, if the PM isn't part of it, the standup
| doesn't happen, because no one else cares that much. If
| someone gets stuck on something or needs help we just
| send a slack message, no need to wait for a fixed
| meeting.
| Aeolun wrote:
| It may be explicitly stated, but I've never had a scrum
| meeting without all managers and project managers.
|
| They also tend to make the stand-ups one hour long.
| shepherdjerred wrote:
| Surely you're exaggerating about a one hour standup?
| bboygravity wrote:
| The goal is always 15 minutes and the reality always
| (much) longer.
| mid-kid wrote:
| I've been at companies where this was indeed the case.
| dathinab wrote:
| I wich
|
| while it's not quite as bad for us 30min are the norm and
| it spilling to 40 min not rare and that is with us trying
| to cut it short
|
| but too many other things are conflicting with short
| dailies, mainly sure to company structure/size
| throw-the-towel wrote:
| Yeah, can't believe their standups are so short.
|
| (I wish I was joking.)
| oneshtein wrote:
| You never had a SCRUM meeting.
| repox wrote:
| > They also tend to make the stand-ups one hour long.
|
| I'm Head of Development in a midsized SaaS company.
| Another team's PM went for paternity leave and I stepped
| in to lean in on any needs.
|
| I discovered that the team of 10 people were using close
| to an hour a day on stand-up. A culture thing,
| apparently.
|
| I joined he stand-up a few times, slimmed the scope of
| the conversation to roughly 10-15 minutes.
|
| This worked for all three months of the PM's paternity
| leave.
|
| PM returns, is pissed over the change and in less than
| two days, the stand-up is back to almost an hour a day.
| jghn wrote:
| It Depends.
|
| I said in another post that I hated all the ceremonies,
| including standup. And it goes without saying that means
| long standups.
|
| But, one team I was one, we had long ass standup and it
| was perfect. It was very dev-driven, we were facing hard
| problems, and that was our time of the day to really nerd
| out. The PM would get bored after about 15-20 minutes and
| then we'd be working out how to deal with the issues that
| faced us. Sure, it could have happened at any point of
| the day, but that was our designated time where we were
| all in the office (this was pre-pandemic)
| relaxing wrote:
| Why is the PM still employed?
|
| Hasn't the team all quit?
| geodel wrote:
| Because in real world people play with the hand they are
| dealt with. Team hasn't quit because there are no better
| jobs with empowered developers are waiting.
| icedchai wrote:
| The real reason is why is the team putting up with this.
| They should be complaining about the PM and wasted time
| every chance they get, at the "retro", team meetings, and
| 1:1's... Complain, complain, complain.
| gloryjulio wrote:
| That's the issue where the PM has so much power. In our
| company the engineering team dictates their process. They
| can do however they like as long as they ship the
| products on time.
| osigurdson wrote:
| I don't like long daily meetings, but there is
| essentially no value in the YTNB meeting either
| ("yesterday, today, no blockers") meeting either.
| lpapez wrote:
| > It may be explicitly stated, but I've never had a scrum
| meeting without all managers and project managers.
|
| This, this, this and a thousand times this.
|
| It's always the same with Scrum. Every time you point out
| something clearly wrong, the response is always "well
| that's not really scrum, you're doing it wrong".
|
| It's like when discussing communism with some diehard
| fans - when you point out the flaws, the response is
| always "well that wasn't real communism that's why it
| failed".
|
| Well to both of those camps I say: if most attempts ended
| up implementing it "incorrectly" in the end, it's not a
| very useful framework to begin with then, is it?
| roenxi wrote:
| That similarity is superficial. It is observing that no
| ideology perfectly survives implementation - which is
| true, but there is no alternative option so it isn't a
| useful observation.
|
| We don't have any successful countries that use communist
| ideologies because central planning is destructive and
| the abolishment of private property is catastrophic.
| Calling for communism is tantamount to wishing for death
| and destruction. The path to success through communism is
| something like China where they eventually learned to do
| the opposite of communism and got great results.
|
| We do have lots of successful companies using Scrum. They
| hire Scrum masters. They see Scrum as adding value. The
| scrum ideal is generally a bit of a compass towards
| higher value add. So scrum as an ideology seems to be
| net-successful even if implemented wrong.
| carlmr wrote:
| >So scrum as an ideology seems to be net-successful even
| if implemented wrong.
|
| How do you get to this conclusion? I haven't seen any
| implementation of scrum that didn't slow down development
| speed, due to unnecessary meetings and micromanagement.
|
| This might be that I've only seen 8 or so
| "implementations". If there's any evidence that scrum is
| a key net positive I'd like to see it at this point.
|
| Kanban IME can work well if the manager understood the
| core principle: Limit amount of concurrent work, use
| daily standup to prioritize work and unblock people
| hitting the multitasking limit.
|
| Sadly this concept which is the core tenet of Kanban and
| can be explained in one sentence was still too much to
| grasp for some managers, but I've at least seen most
| Kanban implementations be either a net positive, or
| neutral.
|
| I might be biased by my own experience, but I still need
| to see a Scrum implementation that doesn't grind
| productivity to a halt.
| roenxi wrote:
| The company isn't optimising for fastest development
| speed. They typically optimise for low variance,
| consistent value in support of existing processes.
|
| Interestingly, if you want highest value then for
| software it is best to use a high-variance strategy. But
| that is never going to come out of a company large enough
| to need professional management because it is pointless
| to manage large numbers of people to a high variance
| strategy. Google is an interesting case study where they
| tried that and, by and large, flopped. It makes more
| sense to spin out separate companies VC-style. I assume
| programmers occasionally quit companies, build something
| and sell it back to the company at extortionate prices
| which would be the right way to do fast development.
|
| That isn't to say professional management is bad - large
| companies need it. It is just a fact that large companies
| aren't good at development and something like scrum
| elevates them from total failure to unproductive but
| fumbling in a good direction.
| carlmr wrote:
| >scrum elevates them from total failure to unproductive
| but fumbling in a good direction.
|
| Where's the evidence for this? I kind of agree on big
| corporate not being able to achieve great development
| speed. But they had a system before scrum, and I've yet
| to see scrum not completely destroying every metric of
| development achievement, whether it's throughput, latency
| or iteration speed.
| roenxi wrote:
| The evidence is in the company choosing scrum then
| sticking with it. They believe it helped.
|
| > I've yet to see scrum not completely destroying every
| metric of development achievement, whether it's
| throughput, latency or iteration speed.
|
| It is too hard to argue from vague anecdotes, so I am
| resisting the urge to try. However, I will say that if
| that is a demonstrable thing and there was no upside then
| it would be surprising that scrum sticks as well as it
| does.
| carlmr wrote:
| >scrum then sticking with it. They believe it helped.
|
| Not necessarily. It's well known that there are many
| psychological biases in favor of keeping the status quo.
| Whether it's the sunk cost fallacy, the escalation of
| commitment or the endowment effect.
|
| Humans tend to stick with bad decisions way longer than
| rational.
|
| https://en.wikipedia.org/wiki/Escalation_of_commitment#/s
| ear...
|
| I think the problem here is we've had a huge trend in
| switching to scrum, but then people stick with failed
| scrum because it's the new status quo. Switching back to
| waterfall can't be sold by consultants. Even if it would
| help.
| ath3nd wrote:
| > However, I will say that if that is a demonstrable
| thing
|
| It's demonstratable: https://www.theregister.com/2024/06/
| 05/agile_failure_rates/
|
| > and there was no upside
|
| I'd go on a sarcastic rant here, but it's hard to stop
| myself. Don't read further if exaggerations upset you.
|
| Sure, there are upsides, but they are hardly benefitting
| software engineering speed, quality, stability and
| developer happiness. The biggest upsides are for
| management:
|
| - keeping the engineers under tight control by one of
| their business types (PO)
|
| - making sure long-term thinking (like "what am I doing
| in this company") is suppressed by having a horizon of
| only 2 weeks in which you are supposed to give all you
| have to hit an arbitrary deadline. And then you start
| again! /s
|
| - scrum has the beautiful effect of making engineers
| feeling either like kindergartners:
|
| 1. what did you do yesterday, Timmy? (standup)
|
| 2. Let's play with some cards, kids (planning poker)
|
| 3. Let's review what we learned last two weeks, children,
| and let's see what progress you made on your bean
| drawings (retros and demos)
|
| How can you want a salary increase or question big man
| POs decisions, when you've just been acting like a kid
| for the last two weeks? Don't get me wrong, I do see the
| benefit of retros, demos, and some kind of planning and
| sync, but the way scrum just dumps it on you and
| prescribes you how to do it is just humiliating. Adults
| can sync, plan, retrospect and demonstrate what they did
| on their own volition and don't need some framework to
| tell them when and how, and two parental figures (the PO
| and Scrum master) to tell them what to do and when.
|
| > The evidence is in the company choosing scrum then
| sticking with it. They believe it helped.
|
| Many people also believe the Earth is flat and are
| sticking with that belief.
| ramblerman wrote:
| > How can you want a salary increase or question big man
| POs decisions, when you've just been acting like a kid
| for the last two weeks?
|
| I think you just provided me with a small epiphany...
| carlmr wrote:
| >two parental figures (the PO and Scrum master)
|
| Another great point. The overhead is insane. 2 people
| that don't directly contribute work output per team.
| marcosdumay wrote:
| About that article.
|
| We absolutely learned something since the 90s that was
| beneficial. Corporative software projects now have about
| a two times higher chance of success than they had back
| then.
|
| Also, we almost certainly learned that thing from Agile.
| There is no other credible source.
|
| But the article has a clear point that places where
| people _say_ they are practicing Agile has an even lower
| success rate than the overall one from the 90s. So it
| seems that the actual lesson from the Agile manifest was
| only learned by the people who don 't claim to practice
| it.
| ath3nd wrote:
| > We absolutely learned something since the 90s that was
| beneficial.
|
| Yes, software engineering has evolved, but to attribute
| its successes to the methodology used is like attributing
| higher cancer survival rates to better hospital
| management. In reality, it's due to the availability of
| better drugs, more understanding, and a lot of R&D, and
| it has 0 to do with management. Same with software
| engineering: we use better tooling, libraries, hardware
| is more commodified, and a lot of things we don't have to
| do ourselves. All things that have nothing to do with the
| methodology.
|
| > So it seems that the actual lesson from the Agile
| manifest was only learned by the people who don't claim
| to practice it.
|
| No methodology/manifest and no amount of management can
| compete with smart, qualified adult people being invested
| in their craft, and having autonomy and ownership on what
| they are building. The projects that succeeded are
| projects having those people, regardless of the
| methodology. In a way, people succeeded despite Agile,
| not because of it.
| marcosdumay wrote:
| The funny thing is that "communism" is a highly
| overloaded term, with several very precise definitions,
| one of what is so successful that about every country
| currently implements and people that dismiss it are
| ignored and considered radical. (But then, nobody calls
| that one "communism" nowadays, the the people pushing the
| others will really hate you if you talk about it.)
|
| While "scrum" is a proper name with a single definition
| that anybody can look that is absolutely not precise
| enough for anybody to follow. By definition you can't
| really do scrum right.
| vannevar wrote:
| >It's always the same with Scrum. Every time you point
| out something clearly wrong, the response is always "well
| that's not really scrum, you're doing it wrong".
|
| Yeah, that would be the correct response. If we were
| discussing communism, and you started complaining that
| under communism everyone has to stand on one leg and hop
| up and down, a communist would correctly point out that
| hopping on one leg is not communism.
|
| >Well to both of those camps I say: if most attempts
| ended up implementing it "incorrectly" in the end, it's
| not a very useful framework to begin with then, is it?
|
| This is like saying that exercise isn't useful because
| most people who attempt it don't stick with it. Doing
| actual scrum is hard (particularly for managers), so a
| lot of teams can't stick with it. That doesn't mean it
| isn't useful.
| wild_egg wrote:
| > It's always the same with Scrum. Every time you point
| out something clearly wrong, the response is always "well
| that's not really scrum, you're doing it wrong".
|
| Scrum is a victim of semantic drift. The vast majority of
| people "doing scrum" have never read the guide and are
| just doing things that other people have told them is
| Scrum.
|
| It's not Scrum's fault that people have hijacked its name
| for something completely different. It happens often.
|
| What people call Scrum isn't really Scrum. What people
| call REST isn't really REST. What people call DevOps
| isn't really DevOps.
|
| People using the wrong word for something doesn't mean
| the original definition of the word is invalid.
|
| It's fairly different from the Communism situation in
| that people discussing Communism are generally talking
| about the same concepts and the debate is whether or not
| they're feasible. With the other terms I used above,
| people are using the same words to talk about completely
| different concepts with different definitions.
| jjav wrote:
| > People using the wrong word for something doesn't mean
| the original definition of the word is invalid.
|
| It doesn't make the original definition invalid, but
| words mean what society uses them to mean, which changes
| over time.
|
| So agile & scrum do in fact today mean constant status
| meetings, treating professional developers as mindless
| cogs and keep everyone in line with a constant stream of
| tickets chosen by someone else.
|
| Perhaps it's not what it meant in some idealistic
| manifesto lost to history, but it is what it means to
| developers employed in the industry today.
| knallfrosch wrote:
| > It's not Scrum's fault that people have hijacked its
| name for something completely different. It happens
| often.
|
| Scrum contains so many pitfalls that it's inevitable to
| get it wrong. Oh, the Sprint Review is NOT a report to
| management? Please do tell me where this then happens
| instead. If a manager can attend a 1 hour meeting to
| summarize the 2-3 weeks that the sprint was about, it
| will be abused.
| Viliam1234 wrote:
| I have seen teams actually do the Scrum-according-to-the-
| textbook, but those are rare. Most companies are just
| doing whatever their managers think is a good idea, and
| they call it "Scrum".
|
| Ironically, the last time my team was doing Scrum-
| according-to-the-textbook, it was a decision of the
| developers... and then the higher management told us to
| stop, because the entire company decided to switch to
| "Scrum" (as in: endless meetings with managers present,
| no retrospective, but we call it "Scrum" because it
| sounds like we know what we are doing), so basically we
| had to abandon Scrum in the name of "Scrum".
|
| My conclusion from this experience is that Scrum-
| according-to-the-textbook never happens as a top-down
| decision. The managers have strong ideas about how things
| are supposed to work, and they are unwilling to change
| their ideas, although they may agree to rename them to
| "Scrum".
|
| I actually get the real-communism-has-never-been-tried
| vibe from people who say "scrum sucks, agile is the good
| idea". Scrum is simply what happens when Agile meets
| corporate reality. Make "agile" a popular buzzword among
| the managers... and soon you will see people complaining
| that agile in practice means endless meetings etc.
| northzen wrote:
| But ones you are in company which does it right you start
| appreciate all good things it brings.
|
| I haven't seen working communism though and never heard
| about it.
| the_other wrote:
| > It's always the same with Scrum. Every time you point
| out something clearly wrong, the response is always "well
| that's not really scrum, you're doing it wrong".
|
| Well, you are.
|
| Give this shitty process you're being forced to follow
| some other name and stop blaming Scrum.
|
| Do Scrum properly and you'll see why it's actually fairly
| good.
|
| > if most attempts ended up implementing it "incorrectly"
| in the end, it's not a very useful framework to begin
| with then, is it?
|
| You can't say that as you've not actually done the thing.
|
| The main problem is that most managers and senior company
| people feel like they want more control that scrum allows
| them to have, and their use their power to overrule it.
| That's their problem and not the fault of the Scrum
| system.
|
| You may be onto something with communism. It's definitely
| not resiliant to the kinds of paychopaths that end up
| dictators for life. I wish I knew why. Probably something
| to do with threats of violence.
| kgeist wrote:
| >It's like when discussing communism with some diehard
| fans - when you point out the flaws, the response is
| always "well that wasn't real communism that's why it
| failed".
|
| Nitpicking, but the Soviet Union, for example, never
| claimed they were already a communist state. They were
| the "Union of Soviet Socialist Republics", not "Communist
| Republics". Their idea was that, to have communism, you
| must have a transitional form of government first,
| "socialist government". The USSR even once had a motto,
| "we will build communism by 1980".
|
| It's like if someone said they were following some other
| development process which would eventually lead them to
| Scrum. But no one does that and just calls it Scrum :)
| quartesixte wrote:
| As someone who works in a hard-tech startup, where daily
| standups in production manufacturing teams are part of
| the daily culture.
|
| 1) Anything longer than 15 minutes is insane 2) What do
| you even talk about for an hour? 3) Why do you even do
| standups for design work? What "blockers" could you
| possibly have that require daily, 15 minute tagups with
| the entire crew?
| marcosdumay wrote:
| On #2, nothing. People stay an hour trying to look busy
| because somebody on the meeting expect them to be busy
| and the meeting to be important. So they spend an hour
| talking about nothing.
|
| On #3, blockers exist more on design than on operation.
| But the idea of a daily meeting to solve blockers is
| crazy-stupid. Imagine if operations did this, every time
| somebody's work get a wrong input, you'd stop their line
| until the next morning. That's why operations dailies
| aren't about blockers, and instead about information
| sharing. But design work doesn't have separate teams that
| need to share information, so they invent a bullshit
| reason to still have the meeting.
| kgeist wrote:
| >What do you even talk about for an hour?
|
| We once had 1 hour long standups. The reasons were:
|
| 1) large team
|
| 2) many devs loved to go into detail about their work,
| and no one stopped them
|
| 3) the expectation was that a standup must be about
| describing what you did yesterday, in detail
|
| What we did:
|
| 1) split the team into subteams where each team has their
| own standup (down to 5-15 min)
|
| 2) the standup's facilitator now stops devs from going
| into too much detail, "you guys can discuss it further
| after the standup"
|
| 3) now the expectation is that a standup should be about
| checking the project status and if there are any
| blockers, and that's it, you don't have to recount your
| whole yesterday in great detail
| kgeist wrote:
| Our PM quit a month ago and now we have stand-ups without
| any managers. I think it made the developers more
| responsible and involved: every stand-up a new dev gets
| the role of a facilitator. Previously, it was a one-man
| show. The stand-ups have become slightly shorter, too.
|
| 2 years ago we had 1 hour long dailies because the team
| was too large. We split into 3 subteams, each has their
| own stand-up. Now it's down to 15 minutes max.
| jboggan wrote:
| Real scrum has never been tried!
| rolisz wrote:
| Sprint planning 1h? Lucky you. At the former employer
| that was 6h (so basically the whole day was wasted)
| usea wrote:
| I interviewed at a place whose sprint planning took a
| full week and was reportedly incredibly stressful.
| Customers participated. Their product was a website that
| agile teams used to track their process.
| Lutger wrote:
| There are a lot of things better than scrum, but mostly
| these are all wrong ways to implement it.
|
| Daily: should average at 10 min, 15 min is really the
| maximum. Including prep. So 5-15 min. No status updates!
| The daily is about getting people unstuck with their
| current tasks and quickly aligning on what to do next. If
| it is not useful for the team, the implementation is
| wrong. Doesn't mean it always has to be useful and
| interesting to you, there's a difference. Management
| stays out of the daily.
|
| Sprint planning: the sprints are the compromise to
| management so we can have some sense of progress, so this
| is of course the one meeting that is useless to the team
| getting work done and can hamper productivity. Just make
| it quick.
|
| Retro: you should do a retro about if you think the retro
| is useful and why/why not. If the team doesn't think it
| is, either change it until it works or make this the very
| last one. Management stays out of the retro. ("But are
| you then not doing scrum anymore?" "So what, save the
| pedantry for writing out the functional and technical
| requirements please")
|
| Thing is, you _do_ need to understand what you are
| working on, and it needs to be more or less the same as
| what your team members think they are working on. If you
| are 100% efficient at building the wrong thing, your 0%
| overhead amounts to exactly nothing, and the 80%
| efficient scrum team is infinitely more efficient. Though
| these extreme cases are usually a problem from higher up,
| without any way to align your work you will usually not
| be efficient. And if you are, then good for you, don 't
| follow scrum like its some cult. But most teams need a
| little coordination.
|
| Basically if anybody feels a meeting (or anything,
| really) is a waste of time, there is a problem that needs
| addressing. And the problem is not the feeling, but what
| is causing that sense of waste. Take it seriously, it is
| almost always signaling a flaw in the process. Learn how
| to talk about this in the retro and get to the bottom of
| it.
|
| The retro is about debugging anything that isn't working
| optimal in the team. If you cannot find any bugs and fix
| them, then you are either perfect or just not good at
| debugging, and I know which one to bet one to be the most
| likely. One sure sign a team isn't very capable is when
| there is a lot of blaming involved. Usually external
| factors or tools get the blame, but in very dysfunctional
| teams people blame each other.
|
| If you work in a team that doesn't adequately address
| these problems and you have no power to change it, then
| it may be time to look for another job.
| marcosdumay wrote:
| The ages old "you are doing Agile wrong".
|
| When nobody manages to do the thing right, then the thing
| isn't good. It doesn't matter what platonic ideal you
| hold for it.
| lo_fye wrote:
| If I build a manual transmission car, and you insist on
| driving it like an automatic, it's not going to work for
| you, even though it's an amazing car. There are steps and
| processes that you must follow in order for the thing to
| work for you. If you don't, it won't. Simple as that.
|
| Put another way, if you enter the olympics for
| breakdancing, and then just move your body around in a
| floppy way, you will not win the gold medal.
| geodel wrote:
| > If you work in a team that doesn't adequately address
| these problems and you have no power to change it, then
| it may be time to look for another job.
|
| Huh, this is same for all employers I have known or
| worked at. Maybe on some distant planet it is done right.
| everdrive wrote:
| Without a lot of the project reports, the manager would
| honestly just have no idea what's going on. I recently
| moved into management, and one of the challenges I'm trying
| to balance is how to be aware of my team's progress without
| wasting their time or being a bottleneck for them. It's a
| legitimate problem which is often tackled poorly.
| skydhash wrote:
| You can just talk to them. No need to set a ritual around
| it. Most professionals know about expectations and the
| team's need to deliver.
| everdrive wrote:
| That's what I'm doing currently. We're a small team, and
| I'm a technical manager.
| laboratorymice wrote:
| regardless of "process", work items should be tracked (in
| the problem solving record for our future selves sense,
| not time keeping sense), so you can follow those. If
| you're a non-technical manager, then either a) the
| implementation goes super smoothly and the estimate the
| dev team initially gave you is all the progress update
| you need, or b) it doesn't go super-smoothly and you
| should be involved in any discussions that arise. If you
| find yourself asking "when is it ready?" you've likely
| gone astray.
| randomdata wrote:
| At least in the case of software development, which seems
| to be what Scrum is targeted at, you get the project
| reports for free by way of the commit log.
|
| That said, the 12 Principles of the Agile Manifesto
| offers another solution: Get rid of management entirely.
| It states that developers are best to work with the rest
| of the business collaboratively. Which is the irony of
| Scrum claiming to be Agile: Only management wants to use
| it, defying Agile to its fundamental core.
| dartos wrote:
| Burn down charts, team velocity, and story points.
|
| They all exist to give software development the illusion of
| predictability, but saying that a project should take "x
| sprints" is just setting a deadline with extra steps.
| PaulHoule wrote:
| There is nothing wrong with burndown charts but story
| points and team velocity are poison.
|
| The way you get good at estimating is looking at your
| database of experience. "I did a task similar to this in
| 8 days". Calendar time is real and punchclock time is
| real, either can be measured. Story points are not real
| and not measurable and they leave you lost at sea
| thinking that estimation is impossible, a scam, etc.
|
| See also
|
| https://en.wikipedia.org/wiki/Function_point
|
| Which is also a kind of development "funny money" but
| which have a somewhat rigorous method to arrive at
| estimates.
| _heimdall wrote:
| I don't know if this is properly part of scrum, but it is
| how I've seen it implemented on _every_ team I 've been on
| where scrum was implemented.
|
| Sprints end with some kind of demo, retrospective, and
| sprint planning designed almost entirely to keep PMs and
| managers in the loop and happy. Reports are generated,
| spreadsheets with a few quarters worth of tasks are
| updated, and PMs or managers get to run that further up the
| chain, presumably to make it clear that great progress is
| being made under their supervision and well run scrum
| methodology.
| lo_fye wrote:
| There are no PMs in actual Scrum. Scrum Teams are self-
| managing, so there's no need for a PM.
|
| There's a direct relationship between the Client and the
| Scrum Team. Where most companies screw up is in their
| business model. You can't charge a flat fee for fixed
| project description and call it Scrum. Scrum is
| iterative, by design. It's supposed to evolve with the
| CLient's needs and desires. They want to be able to
| change the scope, the price, and the timeline on a whim.
| If you aren't billing per-Sprint, then you're going to
| have a constant "charge the Client for a change request"
| mentality, which makes them feel like they're being
| Nickel and Dime. It's much better to say "We welcome your
| changes at any time for any reason. It may not fit in the
| next Sprint, but we can always put them in the one after
| that."
|
| In Sprint-based projects the Client has to be free to
| terminate the agreement at any time, if they feel they're
| not getting enough value in exchange for their money.
| This is why constantly delivering value to the Client is
| key.
|
| When they charge a flat fee, they feel they need a PM to
| make sure they don't lose money. And how can you know if
| you're losing money? You force people to track their
| hours back. It all gets toxic.
|
| When the Client pays per Sprint, as long as each Sprint
| is profitable and delivering value, it can be a huge
| profit center that has no end date. Often times, Clients
| will just keep adding features forever instead of
| stopping at the flat fee end date.
| _heimdall wrote:
| I could have been more clear there, "PM" has many
| different meanings these days.
|
| I've never been on a team using scrum that _didn 't_ have
| a project manager or product manager as part of scrum (or
| both). Most often they have been my scrum leader.
|
| Scrum is supposed to be self-guided, but I have never
| seen it implemented on a team of any scale.
|
| I also wouldn't expect a team without PMs, whether that's
| project managers or product managers, to be very
| effective. Someone needs to be focused on keeping the
| project moving, and often the skills needed for a scrum
| leader/master overlap greatly with project managers.
| Someone also needs to be focused on the product and how
| the team's efforts fit into the longer term product
| goals. If that isn't anyone with a PM title it will be
| someone else playing that role with everything but the
| title.
| 2-3-7-43-1807 wrote:
| 1) scrum is even more democratized than agile
|
| 2) no matter what "agile" was supposed to mean - managers
| anyway interpret it as devs having to be very agile for them
| all the time ...
| jrs235 wrote:
| And by "devs having to be agile" you mean "devs having to
| be interruptible during managers hours and flexible in
| doing their work after all the bs office hours are over".
| 2-3-7-43-1807 wrote:
| exactly ... i mean even without hindsight "agile" is a
| rather poor choice as the label. it just evokes the wrong
| ideas too easily.
| slim wrote:
| it's not poor, it's clever. that marketing is what made
| agile the dominant paradigm nowadays. remember agile was
| adopted in entreprise despite IBM pushing RUP
| whiteboardr wrote:
| From experience i haven't come across any "agile"
| organization that runs true to the manifesto.
|
| There's been plenty of discussions why the "what could have
| been" got buried in certain people jumping in, creating weird
| layers and interpretations of some process for their own
| profit and ego.
|
| Chinese whispers then lost in translation.
| _heimdall wrote:
| I worked at a small startup that actually handled that
| distinction well for a while.
|
| We did 2 week sprints, but that really was more to keep a
| remote team regularly in touch and updated. Sprint work was
| very much up to each dev, and at the end of the sprint
| anything that changed or slipped was just chalked up to
| lessons for future work.
|
| That did change eventually, both as the team grew a bit
| more and funding started to run low. Eventually we had the
| worst of both worlds mentioned in the article, sprints with
| more rigid goals leading to a quarterly goal driven more by
| marketing goals than anything else. Throw in the fact that
| the still rather small company ended up with one person
| making product, marketing, and even technical decisions and
| we devolved into glorified code monkeys pretty quickly.
| whstl wrote:
| My team works in an agile fashion. I simply stay out of
| their way and every week they finish what they promised to
| finish. The team is high-quality and hasn't missed targets
| or estimates. Most of our "ceremonies" are purely for
| socialization, as decided by the team.
|
| But this is extremely fragile, because it takes a lot of
| energy to fight external people (often product people) who
| want to remove the self-management aspect.
|
| Unless this is in the DNA of the company, you can't have
| agile or real Scrum, because it threatens those kinds of
| power-grabs. For this to work, you literally need someone
| threatening to fire people who attempt to micromanage
| others.
| replwoacause wrote:
| We use Agile at our company and let me tell you, it sucks.
| Maybe straight up scrum would be worse, but honestly agile is
| invasive and just feels like you're being babysat and forcing
| people to give BS updates at standups because they're afraid
| of sounding unproductive.
| prepend wrote:
| I find Agile is like democracy. It does suck, but it's
| better than everything else.
|
| What would you prefer besides agile?
|
| I had a conversation with a young devTM who was arguing
| that estimating is hard and always inaccurate so we
| shouldn't estimate. Everyone should just work on things
| until they are done. He argued this earnestly and didn't
| recognize that there are opportunity costs and conflicting
| priorities and the need to choose what to do. He earnestly
| argued that every single user story should be worked on in
| order of entry until it was completed. It would have been
| precious how clueless this suggestion was if he didn't
| spent 20-40 minutes a week arguing this as an explanation
| for why his items weren't done and why he was civil
| disobediencing to refuse to estimate or report time on
| tasks.
| rightbyte wrote:
| I'd have the straw man variant of waterfall every day in
| place of agile.
|
| Like, the constant micromanagement and process lawyers
| pushing you down makes me misarable.
|
| At least with classic project processes you'd have some
| oversight plan to follow.
| pyrale wrote:
| > I had a conversation with a young devTM who was arguing
| that estimating is hard and always inaccurate so we
| shouldn't estimate.
|
| Plenty of learned people have made defenses for having no
| estimates. If you want to make the opposite claim, you
| don't need to use a junior dev as a strawman.
| prepend wrote:
| I think estimates are wrong but useful and necessary. I
| don't think it's a strawman argument at all.
|
| For simple activities you can get by with no estimates
| but with dependencies estimates become more and more
| necessary.
| stetrain wrote:
| There isn't anything here about having to do daily
| standups:
|
| https://agilemanifesto.org
|
| https://agilemanifesto.org/principles.html
|
| It's common in corporate implementations of Agile (tm) but
| it isn't actually some commandment or prescribed feature of
| Agile itself. It's actually prescribed by Scrum:
|
| https://scrumguides.org/scrum-guide.html#daily-scrum
| vegetablepotpie wrote:
| There isn't anything in the agile manifesto on how to do
| _anything_. It's a statement of preferences and values.
|
| Business demands process for people in functions to
| follow. Scrum outlines meetings for programmers to
| attend, and specific process outputs like user stories to
| produce and close. Scrum is agile in business because
| business cannot do agile.
| stetrain wrote:
| Right, so when someone says they are doing Agile instead
| of Scrum but don't like it because of the invasive status
| meetings, they're probably actually doing some form of
| Scrum whether or not they realize it.
| bluGill wrote:
| There are agile processes other than Scrum. Scrum has
| gotten all the press for some reason, but there are other
| options.
|
| I personally prefer Kanban. The sprint is not a useful
| deadline for me so I want to ignore it.
| stetrain wrote:
| Agreed. But Kanban also often incorporates some of the
| processes from Scrum like daily standups that aren't
| prescribed anywhere in Agile.
|
| Personally I find it more useful to organize things
| around useful product milestones that are actually usable
| and demo-able. Those might take a week, or three weeks,
| but probably not two months because that's a long time to
| go without a demo and getting feedback. Sticking to a
| rigid 2-week sprint with an expectation of demo-able
| progress after each sprint doesn't feel particularly
| realistic or useful to me.
| bluGill wrote:
| The business has a need for a regular status update from
| everyone. You can call it a standup or not. You can call
| it not agile, but in the end the business has needs and
| you cannot ignore those needs.
|
| The business needs to know when something will be done as
| they need to make promises to customers. The business
| also needs to know when things will be done as that is a
| proxy for cost - they need to make sure they are not
| spending more creating a thing than it will deliver (this
| is a hard problem as some sales will not happen until it
| is done and there is typically a competitor customers
| could go with). That is nearly impossible to say how long
| engineering will take doesn't mean we don't need to know
| how long it will take!
| stetrain wrote:
| Sure. I'm not saying there shouldn't be status updates.
| I'm just saying that those status updates aren't because
| they are "doing Agile."
|
| There isn't really any such thing as "doing Agile", it
| isn't a prescribed process to follow.
|
| And saying that you use Agile instead of Scrum but
| dislike the invasive status meetings isn't actually
| congruent with the actual definitions of Agile or Scrum.
| happymellon wrote:
| Its also not for the business.
|
| > The Daily Scrum is a 15-minute event for the Developers
| of the Scrum Team
|
| The business doesn't actually need a daily update. They
| think they do because they dont want to give you the
| ability to deliver anything.
| Pet_Ant wrote:
| The stand-up is an opportunity to call out things that are
| blocking you, not for giving status updates. I got Scrum
| certified for resume padding, and thought it was gonna be
| easy, but I was blown away by the things I "knew had to be
| part of Scrum" that actually weren't.
|
| This is all there is to Scrum, if it's not here it's not
| part of it: https://scrumguides.org/scrum-guide.html
|
| It's like calling the electoral college part of democracy.
| Than just a choice one place made, it's not intrinsic.
| lo_fye wrote:
| "Keep managers happy" isn't part of Scrum, either. If you
| read any of the Scrum books by the creators of Scrum, you'll
| find that the way 95% of companies implement Scrum is nothing
| like what Scrum was intended to be. They mess it up,
| essentially in the name of marketing, and not wanting to
| truly change their ways.
| benfortuna wrote:
| But what does it mean to "empower devs". Do you give them
| requirements and say I'll check in on deadline day in 6 months?
|
| Presumably you would still use iterations to track progress,
| Epics/Features to break down requirements, some kind of
| estimation to track if you're ahead/behind schedule?
|
| I certainly wouldn't go back to Waterfall days, but I suspect
| many current devs never experienced that.
| shaunxcode wrote:
| as things are ready to be shown you will see them : this is
| how you will know
| Retric wrote:
| There's a world of difference between checking back in 6
| months and daily standup meetings + a host of weekly
| meetings.
|
| If you don't trust your team to be productive for 2 weeks
| without communication something is deeply wrong. Individuals
| should be in constant communication, but few things need to
| be said to everyone. Scrum style management may be useful for
| highly dysfunctional teams, but it frequently adds a great
| deal of unnecessary overhead.
| gridspy wrote:
| - One on Ones to discuss roadblocks and thoughts every week.
|
| - Issue tracking as a common place to describe what needs to
| be done and thoughts / details on how it is solved. Something
| lightweight like Trello is ideal
|
| - A Kanban board so people have an organised way to pick up
| new issues when low on work
|
| - A weekly showoff meeting where there are few 5 minute
| presentations and a 30 minute "I did something really cool or
| learned something really cool"
|
| - 6 month task split into 1 month ish deliverables, with a
| flexible deadline for each. Presentation of finished work
| each deliverable.
| cvoss wrote:
| This is basically how my team does it. I love it. My
| manager spends much of her time figuring out how to help
| remove our roadblocks and planning the 6 month to 1 year
| horizon (with our input). I lead the weekly meeting where
| we do the showing off, PSAs, or light brainstorming on
| issues with broad relevance.
|
| Two scheduled meetings per week = tons of dev time and
| freedom to explore / innovate! (Ok, three weekly meetings
| if you count the product-wide meeting, which is usually a
| waste of N-5 people's time, and I usually have it on the
| background while I continue working.)
|
| We are remote, so ideally there's also one in person
| gathering per year to do the big vision casting and major
| high level brainstorming.
|
| We still have room to improve, especially in the area of
| ad-hoc dev-dev communication. Always interested to hear how
| others do it!
| Aeolun wrote:
| You can have a two week cadence without connecting tasks to
| sprints.
| gklitz wrote:
| I'm confused. That is literally all sprints are a regular
| cadence that tasks and events are connected to?
| relaxing wrote:
| I think the key is you don't force/pressure tasks to be
| completed in sprints.
| justmarc wrote:
| Absolutely right. Well put.
| bdangubic wrote:
| After 26 years in the industry this is the only process that
| actually works - hire the right people and get the F out of the
| way
| tcgv wrote:
| > hire the right people
|
| That's no easy feat and often oversimplifies the challenge of
| building competent teams. I think it's achievable if you have
| a large budget to hire only senior/experienced devs and a
| mature hiring process/team. Plus, if your company has strong
| tech branding, it becomes easier to attract top talent too.
|
| But if you're at a startup with limited funding and possibly
| no branding at all, you'll likely face this situation:
|
| - Hire inexperienced but honest, motivated people with the
| potential to grow, and invest in mentoring them.
| bdangubic wrote:
| I do not disagree with anything you said at all! Though
| chances of success diminish here.
|
| If you have to introduce some "process" - whatever that
| "process" is - because you do not have competent people and
| you feel like "process" will fix it, your chance of
| succeeding are a lot smaller IMO...
| bfrog wrote:
| Pizza sized teams that can directly interact with customers
| don't need management. Management is playing telephone with
| someone in the middle with their own interpretation of
| everything which is 99% wrong.
| patrickmay wrote:
| It sounds like you've had bad management (like we all have).
| Good EMs will unblock you, deal with conflicting priorities
| from stakeholders, provide you with air cover to have focus
| time, and help manage your career growth (among other
| things). If your EM isn't doing that, find another one.
| randomdata wrote:
| _> Good EMs will unblock you, deal with conflicting
| priorities from stakeholders, provide you with air cover to
| have focus time, and help manage your career growth (among
| other things)._
|
| Those don't really seem like things you'd want to
| outsource, no matter how good the outsourcee is.
| mrits wrote:
| The reality is even good devs tend to work hard on the wrong
| thing. Accountability comes from your peers as much as your
| manager. If this makes you angry you are one of the bad ones.
| skydhash wrote:
| Everyone tends to work hard on the wrong thing if it what
| they like to do most currently. Everyone. A conversation is
| all that is needed to remind them of the team priority, non
| need to create a creativity carcan with processes.
| randomdata wrote:
| Give good devs a direct line to the customer and they're apt
| to always work on the right thing, but will spend a lot more
| time dealing with the customer and a lot less time in
| development in order to do so.
|
| Leave good devs to play telephone through a middle-man, what
| we call the manager, and they almost certainly will work on
| the wrong things, but will have a lot more time to do it.
|
| I wonder which is actually more productive? Agile (of the
| Manifesto kind) posits that the former is most productive,
| but Agile (of the fake kind) seems to always want to revolve
| around the latter. The general sentiment is that fake Agile
| is the one that gets it wrong, so presumably cutting out the
| manager is what is most productive, but more data is welcome.
| SoftTalker wrote:
| Disagree. The customer often has tunnel-vision on their
| needs, and doesn't know what's possible, and might have
| trouble even describing it except that _their_ manager told
| them that their foo task was a problem.
|
| The devs have the opposite problem, they can imagine all
| sorts of new technology that would be fun to use (for them)
| in helping the customer solve their problems with doing
| foo, and even if they understand foo from the customer's
| business perspective they they may not have a great
| understanding of how big a problem it is in the grand
| scheme of things and what commitment of resources and
| expenses are justifed in solving it.
|
| Managers talking to managers can (in theory) draw some
| boxes around scope and priorities and get the right
| development problems solved at the right time. They may
| talk and realize that doing foo isn't even really a great
| idea and they should be doing bar intstead. Line-level
| employees working directly with developers will not be as
| likely to realize that.
|
| Developers can fall into the trap of thinking that because
| they are smart (mostly) at building software they are
| automatically smart about all the business processes and
| problems and goals of the company. They should certainly be
| informed about those things, but they are not experts in
| everything.
| randomdata wrote:
| If we were talking about developers in general, perhaps,
| but we're specifically talking about _good_ developers.
| They exist at the intersection of understanding the
| business, what customers are _actually_ saying, and
| understanding the technology. Without that, what would
| make them good?
| SoftTalker wrote:
| Very very few of these people exist. They like to think
| that because they are very good at writing and
| understanding code and technology that they are
| automatically the smartest person in the room with every
| other aspect of the business. And I'm not talking
| exclusively about software developers, you'll find the
| same issues with anyone who is deeply smart and
| experienced at any one thing, thinking they must be smart
| about everything else too.
|
| There are a few polymaths out there, yes. But only a few.
| randomdata wrote:
| _> Very very few of these people exist._
|
| Well, yeah, that's why they're considered good. Why they
| get a special title not given to everyone else. It would
| be nonsensical for "good dev" to refer to everyone who
| touches software development. "dev" would already
| communicate everything you need to know. The addition of
| "good" implies being set apart from what is typical.
| mrits wrote:
| You generally don't want to act on customer feedback
| directly. Aggregating the feedback and making decisions at
| a broader level is a full time job.
|
| Of course, if you are an early stage startup and one of
| your customer is half your revenue, sure. Do whatever it
| takes to make them happy.
| randomdata wrote:
| _> You generally don 't want to act on customer feedback
| directly._
|
| Obviously not literally. What they want hasn't been
| invented yet, which means the words to accurately
| describe what they want also haven't been invented yet.
| But ultimately you do want to act on what they really,
| truly are trying to tell you. Indeed, figuring them out
| is a hard job all on its own.
|
| _> is a full time job._
|
| Sure. That's the tradeoff. You can spend most of your
| time figuring them out, and then the small few remaining
| units of time you have for development will be on point.
| Or you can play telephone and have all kinds of time for
| development, but will more often than not go down the
| wrong path.
|
| It's not really clear which is more productive at the end
| of the day. But we do know that Agile (of the Manifesto
| kind) pushes the former, while Agile (of the fake kind)
| pushes the latter. People seem to hate fake Agile more
| than they hate Manifesto Agile, so that does suggest that
| not playing telephone is more productive.
|
| But, still, data?
| Lutger wrote:
| I've heard a lot of push back against all kinds of process on
| this forum, and it always surprises me.
|
| But reading the article made something click: it is not about
| the specific process, the (lack of) autonomy is what really
| matters. I guess I got lucky to work a lot in teams where we
| largely controlled our own process, so even if we used bits and
| pieces of scrum, kanban or other methodologies, it was always
| of our collective choosing and when it didn't work, we changed
| it.
|
| I did like to have rules, principles and process. A simple
| playbook for a daily meeting that made us not forget important
| things and sped up the meeting. Making things in small
| increments meant that I didn't have to review thousands of
| lines of code. Having a visual overview of work neatly spelled
| out means I don't have to re-think every time I pick up a new
| item to work on. This also prevents useless work because one of
| your teammates decides to work on the same thing as you without
| telling it. All these things make me happier and more
| productive working together on some big thing.
|
| The key is that the team should be in control of the process,
| not some manager who isn't part of the team and affected by the
| process. You need to have a stake in it. The only other factor
| that undermines this is 'process for the sake of process'.
| Every part of the process needs to earn the inevitable cost its
| implementation is bringing. Some people seem to be happy paying
| the pricing without getting the value.
| mrmetanoia wrote:
| It seems we go astray when we start defining and evangelizing
| things that may have worked for some group of people to push
| them on others.
|
| Somewhere in all this process stuff, I see maybe what some
| teams were doing but I doubt it was as rigid and I doubt they
| indulged in it when it made no sense. Once these teams or
| people are asked what they're doing right - it eventually gets
| defined into rules and then evangelized to people made to feel
| they can't deviate or improvise when the framework makes no
| sense. "Trust the process."
|
| So people start wasting their time going through the process
| rather than using the process as a framework/tool for getting
| things done, they 'do' the process.
|
| Their job is standup, their job is scrum, tickets, and points,
| and as a result their job is only marginally to do the things
| that need doing.
|
| Company's might take more issue with this inefficiency if the
| workforce didn't double as something to manipulate pre and post
| head/tailwind to make the stock rise.
| SoftTalker wrote:
| All of these methodologies (and most formal software
| architectures as well) have as a their main sales pitch the
| idea that you _can_ hire average /entry-level developers and
| build good software with reduced defects and on a defined
| schedule if you only follow these magic guidelines.
|
| It refuses to learn from _The Mythical Man-Month_ and recognize
| that building software has an essential complexity that cannot
| be avoided. You need smart people to implement and manage it,
| and you 'll have to pay them what the market says they are
| worth.
|
| Building software that's more complicated than a standalone
| CRUD system is hard, it will always be hard, and unpredictable,
| and to some degree stressful. No methodology will ever make it
| anything else because the methodology used doesn't change the
| nature of the problem.
| bunderbunder wrote:
| My first and second experiences with Scrum couldn't be more
| different. And they were successive. Actually, they happened on
| the same team, same people, same project.
|
| Before: the team had internally decided to use Scrum. Other
| teams were not using it, and inter-team coordination used
| traditional project management methods. It was fantastic; the
| team worked like a well-oiled machine and I really did feel
| more productive. We never had crunch time. I did not feel the
| "end-of-sprint mini crunch" that this post describes; instead
| the norm was that, by the last couple days of the sprint,
| people were starting to finish up whatever tickets they had
| taken and pivoting to helping teammates get the rest of the
| work done. Oftentimes we'd close out all the user stories a day
| or so before the end of the sprint, and have all that time for
| tidying up the codebase, fixing small technical debt items,
| experimenting with new tools, or planning ahead for the next
| sprint. So, if anything, it was the opposite of what the
| article describes: the last few days of every sprint were
| downright relaxing.
|
| After: The executives got wind of Scrum, and decided to
| standardize the whole company on it. We stopped work for a week
| so that we could have a famous Agile coach do an all-hands
| Scrum workshop. Which was fun, but the middle and senior
| managers were conspicuously absent. And then, after that,
| things kind of went to heck. The way our team did Scrum rapidly
| started to change as our team manager started getting explicit
| instructions on how to do things. We also started experiencing
| pressure to keep or maintain velocity. We started getting
| questions about why our velocity was so much different from
| other teams'. We could explain that the story point scale is
| team-specific and you can't compare story points across teams,
| but that didn't go anywhere. As I said, the middle and upper
| managers skipped the Scrum training. They weren't interested in
| being lectured about what I'm sure they perceived as pedantic
| little bullshit details.
|
| I left that company and went to another where leadership didn't
| mandate any Agile methodology. My team did a homegrown Kanban-
| like thing. A team I collaborated closely with used Scrum. It
| also seemed to work pretty great. Again, possibly because we
| chose it for ourselves. I don't think the other team would have
| done as well on Kanban. Scrum wouldn't have worked so well for
| our team. I didn't see a problem with that. We each had
| different business domains that warranted very different "rules
| of engagement" with our stakeholders and ways of organizing the
| work.
|
| Since then it's been a couple more companies where "Agile" was
| mandated from the top, and, apologies to Tolstoy, but they were
| both miserable in the same way that the first one was after the
| Scrum mandate got handed down from above.
| cybrexalpha wrote:
| One of my soft requirements for engineering roles is "no agile".
| Usually if a hiring manager tells me that team is an agile one
| it's a very clear sign that I don't want to work there.
|
| Of course, this pickiness is only if I'm in a situation where I
| don't need to move. I can think of plenty of cases, for example
| being laid off, where I'd take a role in a scrum team.
| insane_dreamer wrote:
| We don't do agile, scrum, standups, etc. We meet 1x week to
| review where we're at and establish/re-establish priorities for
| the week if needed, use a ticket system for tasks to track
| progress, a high-level "weekly goals" shared doc, communicate on
| Slack as needed, and let the devs actually do the f'ing work the
| way they know best. If someone can't self-manage and produce
| without a manager over them, or reach out if they've hit a
| blocker (due to their own limitations or someone else's) they are
| not the right fit for us.
|
| IMO, if you're a SWE/dev and spending more time doing other stuff
| (meetings, TPS reports, etc.) than coding (coding includes the
| time needed to research, experiment and think of good solutions,
| not just actual coding), then something is wrong.
| iaaan wrote:
| How do you handle QA and automated testing?
| SamuelAdams wrote:
| Be like Microsoft. Fire all your QA. QA is now done by
| developers and end users.
|
| If a multibillion dollar corporation can do this, so can you!
| foobarchu wrote:
| Honestly that would be better than what I have now. Bad QA
| who you have to tell exactly what to do is infinitely worse
| than just doing it yourself.
| sanex wrote:
| Or Boeing. Works great there.
| sabbaticaldev wrote:
| and this is quite easy to automate with AI.
| fulafel wrote:
| You are doing agile. The agile manifesto is:
| Individuals and interactions over processes and tools
| Working software over comprehensive documentation
| Customer collaboration over contract negotiation
| Responding to change over following a plan
| insane_dreamer wrote:
| as a philosophy, yes; but as the way Agile is structured at
| most companies, no.
| skrebbel wrote:
| Just means you're doing it properly :-)
|
| It's kinda nuts how many capital-A Agile processes (and
| consultants!) produce situations that are diametrically
| opposed to the original ideas. Notably, Scrum is often
| processes and tools over individuals and interactions.
| freedomben wrote:
| How big is your team? and company?
| forgotacc240419 wrote:
| I feel like in a lot places the ultimate purpose of sprints is to
| let executives think they can see data that represents the amount
| of work getting done down to a fine level.
| Tempest1981 wrote:
| Indeed. Which is backwards. The goal shouldn't be giving execs
| a warm fuzzy feeling. It should be identifying issues and risks
| that execs can help fix. I.e. handle exceptions to the norm.
| freedomben wrote:
| Exactly right. I've seen it first-hand. It's all about the
| data. It's also neatly separated from the real operating
| context in a way that presents it as highly misleading.
|
| Incidentally, if you criticize the data (such as asking "Where
| does this data show the effort that people who spent time
| mentoring/pairing but didn't do the actual 'commit'? Where does
| the data show the effort spent code reviewing?), you should
| know that it won't be received well. The emperor really does
| not want to hear that he's not wearing clothes.
| maximumgeek wrote:
| I think back to the early 2000's, and there are other factors in
| play as well. Back then, I worked with a team of engineers that
| stayed together for over 4 years. In that time, we did not have
| Project Managers telling us to do daily standups. We met as an
| engineering team.
|
| We often would go days without having a formal meeting.
|
| But, software was different then as well. Everything is
| interconnected now. One team dropping the ball affects countless
| other teams. Deployments were whenever we felt a new one was due
| or at a multi month cadence. Did this introduce problems, yes,
| but at the same time, they came in controlled release cycles.
|
| Nothing against CI/CD and continuous delivery, but the hamster
| wheel has gotten to a point where we have to release all the
| time. Corners are cut on everything, and testing is given lip
| service.
|
| At this point, I am a manager, and SCRUM stresses me out. Either
| let us work from a queue, or give us a project with a deadline.
| Give me back a stupid gant or pert chart. At least then it was,
| is this done to allow XYZ, not we are going to accomplish this in
| the next 2 (arbitrary) weeks.
|
| So much more to say, but I am toast.
| saulpw wrote:
| Well you are a manager, can you at least change how things are
| done for your team?
| cdaringe wrote:
| ex manager here. managers are in an even worse wheel. biz
| demands managers show up to even _dumber_, less organized
| meetings than devs think they have to deal with. eng to eng
| meetings tend to be fine, but the rest of company culture at
| BigCorp weren't trained in structured problem solving. it's
| negotiating with goldfish half of the time (generally
| friendly goldfish), and no one actually practices any
| formalisms or larger cohesive pjm. "just give me a gantt"
| like the author says would be an absolutely monumental
| improvement from how i see things get done
| bruce511 wrote:
| With software you have a situation with two problems.
|
| First is the "gap" between those doing the work, and those
| writing the checks. (When it's the same person, this
| problem disappears.)
|
| The guy editing the checks likes to understand progress is
| being made, and that the project both has an end and will
| be successfully completed.
|
| The second problem is that by it's nature software "never
| ends" and many (dare I say most?) projects fail and are
| simply abandoned.
|
| The moment the check writer is not the direct manager of
| the development you have an intractable problem. The person
| in-between (quite literally middle management), is often
| not technical. But he has to convince the bean-counters
| that this project is "on time and on budget".
|
| He can't help but feel sometimes that he's herding cats.
| He's an irritant to those who are "doing the work" so they
| treat interactions with him as a waste of time. Inevitably
| he starts trying to measure things. (And we all know what
| that means.)
|
| His job is hard. He's stuck between developers who don't
| want anything to do with him and higher-ups who want
| reassurance, bit don't really trust what he's saying.
|
| The miracle is not that this process sometimes fails. The
| miracle is that it ever works at all.
|
| And sure, you may not like your meetings, but at least
| understanding the game might help you understand why his
| job is the crappiest of all of them.
| shepherdjerred wrote:
| This is really interesting. Do you know of any
| articles/blog post that goes into these ideas further?
| bruce511 wrote:
| No, alas no material to refer to, other than my own
| experiences at several places in the food chain.
|
| At the moment I'm having fun developing again, but I have
| had experience of management as well.
|
| Obviously my experience does not speak to all cases, and
| I'm fortunate that most middle managers I've dealt with
| are competant.
|
| I am in the fortunate position of being able to "speak
| truth to power" though, and generally been able to
| dispassionate translate technobabble into managerspeak,
| and help all the layers understand each other better.
|
| I've found that when both sides understand (as much as
| they able) the complex demands being encountered, more
| realistic expectations and demands are made (and usually
| achieved.)
|
| But I've been lucky. I've had good dev teams, good middle
| management, and good product owners. Who have all been
| pulling together to make projects successful. When one
| group is pulling the other way, things get tougher.
| intelVISA wrote:
| It's beyond software: any domain that requires oversight
| of non-trivial work should really have leadership from
| the ranks so they are able to ground their observations.
|
| Managers with no domain knowledge are just an extra layer
| of indirection and overhead without any of the benefits.
| Would any IC want their career gated by someone who has
| zero insight into the team's day to day duties, doubly so
| if it's at a supposed "tech" company?
| cdaringe wrote:
| Trust and rapport are gained in time, often in short
| order. Small artifacts of evidence should generally prove
| to the bean counter that they are cutting checks for
| something!
| randomdata wrote:
| _> at least understanding the game might help you
| understand why his job is the crappiest of all of them._
|
| Well, sure, but that's what the daily standup is for. So
| that the problem solvers on the team can understand the
| process, the problems it faces, and, importantly, find
| ways to optimize it.
|
| But it seems, for how crappy you claim it to be, those in
| that position don't want to talk about it in fear that it
| will get optimized away. Job protectionism trumps all, I
| suppose.
| moribvndvs wrote:
| In the nearly 30 years of doing this, I've had more success
| delivering good quality software that meets business
| requirements under waterfall than any of the SCRUM
| implementations I've worked with, and I am saying that without
| disagreeing that waterfall has its problems. In the agile
| space, kanban is the only one I've felt is productive, but it
| has trouble scaling to multiple teams.
| Clubber wrote:
| In my experience, waterfall forces business to think more
| about the project and plan accordingly. They have to think
| about how this feature interacts with this other feature.
| Business also usually has a better understanding of how the
| software will work because of the planning phase.
|
| In my experience, with 2 week sprints, the business doesn't
| really have to think about anything outside of bite sized
| chunks or even how those bite sized chunks affect later bite
| sized chunks. They can make a snap decision without thinking
| about it because it can be rectified in the next sprint.
| Almost no-one has a "big picture," view of the software.
|
| Before agile, we essentially did 4 releases a month (this was
| back on the burn a CD days), 2 major releases and 2 minor
| patch releases. It worked really well and we didn't get the
| burnout as much by sprinting a marathon. With sprints, I
| always feel burned out. No sense of accomplishment, no letup,
| working hard just gets you more work. It's like laying bricks
| one at a time on a wall with unlimited length.
| gtirloni wrote:
| _> No sense of accomplishment, no letup, working hard just
| gets you more work. It 's like laying bricks one at a time
| on a wall with unlimited length._
|
| Also feeling bad every 2 weeks because planning was really
| bad and now you need to say you're sorry the task has to
| roll over the next sprint and your manager has to explain
| to their manager, etc, etc.
| marcosdumay wrote:
| Yep. Somehow scrum leads to more rigid specifications
| than waterfall.
| ben7799 wrote:
| Waterfall forces management to get it's act together. These
| processes are all about giving management more power and
| less accountability.
|
| Product Management has fallen a tremendous distance from
| where it used to be. PMs who have come up completely under
| Scrum seem to think stories and epics barely require more
| than 1-2 sentences and the developers should have to figure
| everything out from there.
|
| Even senior people in their early 40s have completely
| forgotten how to specify or document anything well.
|
| It makes me wish I worked on something that involved
| physical products. The whole thing with agile/scrum is that
| management can change their mind at any time for any reason
| and the process gives them justification. It works in pure
| software, it doesn't work in anything physical because they
| had to sign the POs to buy materials and parts.
| gregmac wrote:
| > Nothing against CI/CD and continuous delivery, but the
| hamster wheel has gotten to a point where we have to release
| all the time. Corners are cut on everything, and testing is
| given lip service.
|
| Just to call it out: Having CI/CD doesn't mean you have to do
| all these things, or do scrum. It's imho just good engineering
| practice. I have it in my side projects, and I've had it at
| work on a Kanban-driven team (as well as on scrum).
|
| It removes disputes over build process (eg, nobody can ever say
| "well, it complies on my machine"). It is a form of
| build/deploy documentation. It removes bottlenecks ("only Tom
| knows how to deploy that service, but he's on vacation") and
| stupid mistakes ("whoever deployed this last did it wrong and
| left a bunch of old files around").
|
| I also have found deploying regularly is stress- _reducing_.
| For one, with CD the development environment is running the
| same steps, and we know it works because we do it dozens of
| times a week. The longer it 's been since last prod deploy, the
| less confident we can be it'll go smoothly, whereas when it
| gets deployed every few days it becomes a non-event.
|
| When something breaks, having only 1 or 3 changes makes it
| really easy to figure out why. Recovering after a big release
| with 40 PRs in it is absolutely painful.
|
| None of this means you have to release _everything_ on a
| regular schedule (like a sprint). You can still do long running
| branches or feature-flag things off, Just try not to go too
| long without deploying _something_.
| RussianCow wrote:
| > When something breaks, having only 1 or 3 changes makes it
| really easy to figure out why. Recovering after a big release
| with 40 PRs in it is absolutely painful.
|
| This is, by far, the most important reason to practice
| continuous deployment. I've been part of enough of these fire
| fighting sessions following big releases to see that it's not
| a sustainable way to deploy software. And yet, I've never
| been able to convince any boss I've ever had to adopt CD
| because they're worried it'll introduce more regressions into
| production.
| scott_w wrote:
| The way I've explained this before is "would you rather
| small issues that we can fix one by one until anyone really
| notices or would you rather we hit all those issues in one
| big go?" Your mileage may vary.
| RussianCow wrote:
| Intuitively, I think most managers think that tackling
| everything in one go is somehow easier or less risky.
| scott_w wrote:
| Speaking as a manager: any managers that think that are
| wrong.
| fireflash38 wrote:
| > and testing is given lip service.
|
| It's one reason I'm really thankful to work in a
| certified/regulated industry. It's mandated to effectively
| prove your work to get the sign off. And since you can't really
| sell too well in the area without that cert, it's a big part of
| development.
|
| But holy hell is it still hard to get specific people to test
| their work. They just don't even think about it.
| foolinaround wrote:
| are there places today that don't do some variation of scrum
| today? Waterfall is pretty much non-existent.
| Tagbert wrote:
| Some teams use Kanban which is a way to manage the number of
| tasks/tickets and doesn't generally use sprints. It's mostly a
| bug queue of work.
| 20240915 wrote:
| Work queues are themselves an issue. Instead you should have
| ways of documenting things that need doing that is adaptive.
| For example a groomed page about all the PDF bugs > 56 Jira
| tickers going back 10 years, some will take a day work to
| even fathom. It is a big time waste. For customer
| communication have case tickets. But a JIRA ticket is like
| body fat. You burn calories just to maintain it.
| userbinator wrote:
| From what I've heard, aerospace and automotive are still
| largely using waterfall.
| Jtsummers wrote:
| Yes. And it doesn't work very well. Lots of late deliveries
| or reduced project scopes (often still late and over budget,
| but mot as bad).
|
| Increasingly, iterative models are used and those are much
| better. For some reason since it isn't Scrum people still
| insist they do Waterfall even though they do nothing like it.
| 1over137 wrote:
| Planes fall from the sky far less than, say, some
| agile/scrum-based web app shitting itself constantly, which
| happens all the time. Maybe waterfall has its place.
| Jtsummers wrote:
| Eh. Waterfall adds risk to iterative approaches, not
| value. Wait 3 years to do integration testing because
| that's what the schedule says. The smart projects get
| better quality and use iterative models.
|
| Additionally, there are other iterative models than
| Scrum. That's pretty much the worst one out there and its
| only value is to inexperienced teams needing training
| wheels or overbearing management that doesn't trust the
| team.
| dezgeg wrote:
| Good example is SpaceX vs. all the others
| bigstrat2003 wrote:
| Even worse. When I worked in that sector, the government
| simultaneously mandated that we use agile methodologies, and
| also that we do waterfall things. Doing agilefall like that
| was the dumbest possible thing, because we got the benefits
| of neither and the weaknesses of both.
| smrtinsert wrote:
| some places are cheating and doing design sprints and
| eventually implementation sprints. better than doing mythical
| pure implementation.
| magicalhippo wrote:
| We don't do scrum. We release major versions once a month, and
| bugfixes daily. New features go into the next major version
| when done, bugfixes gets released as soon as they're done.
|
| We use Kanban boards to get an overview and prioritize work.
| Apart from that devs mostly manage their own work.
|
| We're a small shop though, perhaps that's why it works well.
| oneshtein wrote:
| Looks like SCRUM.
| magicalhippo wrote:
| But is it? Everything is the same if you squint hard
| enough.
|
| We do not have anything like a SCRUM master.
|
| We don't do stand-ups, we usually don't have a per-release
| target for features. For example, for the past three months
| I've had a target of October 1st for a feature, but no
| specific sub-deliverables for the realeases before that.
| This is typical.
|
| We don't have a separate sprint retrospective meeting. We
| discuss such things during our weekly meeting, even between
| releases (ie we don't wait).
|
| It doesn't feel like what I've been taught and have read
| about SCRUM. But sure I'll agree it's closer to SCRUM than
| to the waterfall method.
| oneshtein wrote:
| Yep, it's typical Agile.
|
| Scrum masters are needed to coach a new team with
| inexperienced project manager only. Established teams
| don't need them.
|
| Stand-ups can be easily replaced by a team chat, such as
| Slack, with even better results.
|
| I saw very few retrospective meetings too. If everything
| goes smoothly, then retrospective meetings are useless.
| 015a wrote:
| Many engineering orgs just give lip service to scrum, which is
| as good as not doing it, which is good and works better.
| Meaning, in my experience: You work in a priority queue, that
| priority queue is re-synced with stakeholders (at least) once
| every two weeks, retros may be there as an opportunity to get
| other business verticals into the room to see what engineering
| finished recently, and the concept of "a ticket going over to
| the next sprint" doesn't raise blood pressure, because the
| system is designed for this and sprints aren't deadlines.
| Features might have deadlines, absolutely, but that's
| independent of the sprint.
|
| I've worked at ~three places that operated similar to this;
| "minimum viable scrum" is a good name, or even better,
| "emergent scrum" because it isn't a process that's designed,
| its the process that emerges when someone toggles the
| "agile/scrum" button in Jira, but no one really cares one way
| or the other. Its a _good_ process.
|
| I've worked in one environment that was hard scrum, had scrum
| masters, extremely strict. To be honest: I felt almost no
| stress, but the company also delivered very little. There was a
| lot of "we can't get to swapping the color on that button until
| Sprint 18 in three months, but we'll schedule it for then".
| Missing a sprint was life or death, so every estimate got
| padded like crazy. When you took vacation, it was common
| knowledge that you needed to leave halfway through a sprint and
| come back halfway through another, sprint planning would
| basically forget about you. That (public tech) company doesn't
| exist anymore, and it radicalized me against agile/scrum: The
| entropic end-state of perfectly executed agile/scrum is an
| extremely well-lubricated machine that actually does very
| little.
| Arainach wrote:
| There are plenty. All you need is a competent team that trusts
| each others.
|
| I work for a huge corporation. My team plans and commits to
| quarterly OKRs and has a team meeting once a week to check in
| on how folks are doing. There are no sprints and no 2-week
| deadlines. Once a month or so we update the progress scoring on
| the OKRs.
| randomdata wrote:
| To be fair, waterfall was always non-existent. It was a
| hypothetical invented for illustration purposes.
| zombiwoof wrote:
| Love this. I've had anxiety about agile and how I've never seen
| it work well, and the "before days" was in some of the most
| enjoyable and productive projects until agile came along
| mempko wrote:
| The secret purpose of Scrum is to get rid of managers and empower
| the engineering team. Most "scrum" is simply taught wrong because
| it was sold to companies as a way to squeeze workers.
| jksmith wrote:
| Evolution of a manager and scrum team achieving high-
| performance together:
|
| Team: "We are having trouble with Bob." Manager: "Ok I'll talk
| to him."
|
| Team:"We are having trouble with Bob." Manager: "Don't come to
| me, you guys need to deal with that in your retro."
|
| Team: "We voted Bob off the island." Manager: 'Ok, I'll forward
| to HR."
|
| Autonomous teams get more done because they have eliminated
| management as a wait state and will proactively scale with
| other autonomous teams to maximize the amount of work _not_
| done. 21st century managers need to re-focus on flow
| efficiencies (as business engineers), and not people. 20th
| century managers won 't have a job in 5 years.
| 20240915 wrote:
| What if the board hires engineers, who then hire (and can
| fire) their manager.
|
| What if the entire company is inverted.
| jksmith wrote:
| Sure, maybe optimize further. Why have managers? The CD
| pipeline goes throughout the whole value stream, not just
| at delivery. Just like delivery automation (eliminate
| intervention of humans), there's also human automation
| (helping people get out of their own way). So I could see a
| use case where managers are just eliminated. You need
| people who can eliminate the noise and replace with enough
| signal that delivery teams can execute. POs and
| stakeholders can do that; managers not needed.
|
| I think what you bring up though is an interesting point:
| maybe managers needs to transition to business engineering
| roles.
|
| This all will play out in the 21st century. 20th century
| management is a legacy artifact at this point. Best example
| is F500s, which are generally mediocre in their execution.
| If a SpaceX type org (14k employees, private) gets into
| their space, they're screwed. Even with politicians in
| their pockets, I don't see how rock swallowing dinosaurs
| like Boeing (170k employees, public) will make it. Just the
| energy they have to expend to get anything done compared to
| SpaceX is massive, due in part to their giant management
| bureaucracy.
| ath3nd wrote:
| > The secret purpose of Scrum is to get rid of managers and
| empower the engineering team.
|
| Then Scrum spectacularly fails in its secret purpose, because
| it adds managerial type to the engineering team and removes
| power from the engineers.
| booleandilemma wrote:
| We have a woman at my company whose job is to update Jira ticket
| statuses.
|
| Instead of allowing the developers to update the statuses
| themselves, she will often prematurely update statuses from "In
| Development" to "Ready for QA" before any code is merged. Or
| she'll update a ticket that isn't yet being worked on to "In
| Development". It repeatedly causes a lot of confusion.
|
| I think she feels the need to be so hands on with updating the
| statuses in order to justify her job, which, in my opinion,
| shouldn't exist.
| semede wrote:
| That job definitely shouldn't exist. I'm not seeing where the
| gender of the person added much value to the story tho
| Biganon wrote:
| Would you have said anything if the comment said "there's a
| guy" ?...
|
| "There's a person" sounds weirdly mysterious
| randomdata wrote:
| "We have a non-binary, genderqueer, genderfluid, agender,
| bigender, demiboy, demigirl, two-spirit, androgynous,
| neutrois, third gender, polygender, maverique, hijra,
| kathoey, fa'afafine, man, or woman at my company whose job is
| to update Jira ticket statuses."
|
| Better? (apologies to anyone I may have missed)
| 20240915 wrote:
| I want her job. It would cost me 50c/day in tokens to automate,
| then grab 2 more jobs like that, and spend Tues onwards at the
| beach.
| Trasmatta wrote:
| I'm at a weird point in my career where every development process
| stresses me out, no matter what. Guess that's burnout.
| etiam wrote:
| Sorry to hear that, and please have it attended to sooner
| rather than later. The recovery times can be worlds apart
| depending on how far burnout is allowed to progress.
|
| I imagine it's still not that every development process
| stresses you out _equally_ though, so it 's still worthwhile
| considering _how much_ stress the environment adds and why.
| nyxtom wrote:
| I'm in the same boat. 15 years of work and I'm very burnt out
| now. Any development process stresses me out these days.
| paulcole wrote:
| > The business side just can't help itself. ("We have to market
| things!" "We need to inform customers about what's coming!" "We
| have to make promises at conventions!" "That's just the
| reality!")
|
| Then shortly after:
|
| > Treat [developers] as respected peers, not replaceable cogs in
| a machine.
|
| Yes, it's hard to know understand the (oft-maligned) "Business
| Side" doesn't bow and genuflect when they enter a room full of
| programmers.
| luckydata wrote:
| nobody has ever done "waterfall", it's a strawman created to
| explain why traditional project management doesn't work in
| software development. The fact that the article starts with "in
| the good old days of waterfall" takes away every expectation that
| I'll read anything intelligent in the article, I believe this
| post doesn't deserve your time and definitely doesn't deserve
| mine.
| wvenable wrote:
| I was trained to do waterfall in school (and also Agile). But I
| suppose if you are under a certain age you would have never
| done it.
| oneshtein wrote:
| Soviet planning was based on 5 year waterfalls.
| ern wrote:
| I'm not sure why the above comment is being downvoted:
|
| _I was reading The Practice of Cloud System Administration:
| Designing and Operating Large Distributed Systems, and I came
| across this quote:
|
| Royce's 1970 paper, which is credited with "inventing" the
| model, actually identifies it so Royce can criticize it and
| suggest improvements. He wrote it is "risky and invites
| failure" because "design iterations are never confined to the
| successive step." What Royce suggests as an alternative is
| similar to what we now call Agile. Sadly, multiple generations
| of software developers have had to suffer through waterfall
| projects thanks to people who, we can only assume, didn't read
| the entire paper (Pfeiffer 2012) [p. 175]._
|
| https://www.jjinux.com/2015/07/the-waterfall-model-was-straw...
| cassianoleal wrote:
| Probably because of exactly that.
|
| > Royce's 1970 paper, which is credited with "inventing" the
| model, actually identifies it so Royce can criticize it and
| suggest improvements.
|
| That means people were doing waterfall then, just maybe not
| calling it so.
|
| > Sadly, multiple generations of software developers have had
| to suffer through waterfall projects
|
| That means even after it being given the name "waterfall",
| "multiple generations" kept using it.
|
| This is making observations, coming up with a model that fits
| the observations, giving it a name, and arguing against it.
|
| This is definitely not a strawman as GP or the author of the
| post you linked seem to think, which is why it's being
| downvoted (I didn't btw).
| luckydata wrote:
| You should try actually reading the paper.
| dugmartin wrote:
| Early in my career (mid-90s) I worked for a defense contractor
| working on avionics for the F-22 and for GE working on a real-
| time automation OS. Both used waterfall exclusively. The
| defense contractor had a multi-year plan with monthly deadlines
| that could not be missed and the same was true for GE but the
| deadlines were more delivery based. At GE there were 400
| engineers working on the overall project and we had a 40 foot
| long wall where the GANTT chart for the project, generated by
| MS Project, was taped to the wall - it was about 4 feet high.
| ChicagoDave wrote:
| I've been building software applications for 40 years. No matter
| how you slice up the work, we all have to demonstrate progress
| and goal achievement.
|
| Agile, Scrum, Kanban, Method 1, or whatever are all meant to
| measure success.
|
| In a lot of cases there is a client or a customer that requires
| regular progress reports. Management uses reports to measure team
| performance.
|
| I'm not sure what planet the OP is from, but this will never
| change. If you have a small team with a simple codebase, kanban
| is probably sufficient. In larger teams or complex solutions, the
| reporting just needs to happen.
| 015a wrote:
| I don't feel anything you've said is logical. The deliverable
| _is_ , in the best case, what communicates progress and
| success. Short of that, tickets can do that, which is also not
| what the article is complaining about. The article also
| specifically attacks Agile/Scrum; Kanban is different and quite
| explicitly sidesteps a lot of the stress problems the article
| outlines.
| BurningFrog wrote:
| > _Agile, Scrum, Kanban, Method 1, or whatever are all meant to
| measure success._
|
| In the agile teams I've been on it's been to _produce_ success.
| Getting good and useful software fast.
|
| Of course, just like there are hundreds of wildly different
| Christian sub-religions, there are now any number of "agile"
| interpretations. In the end belief systems can be pushed to do
| most anything you want.
| gridspy wrote:
| The post is fundamentally about all the performance of making
| stories, assigning points, allocating work and doing standups
| all the time. None of that is required to actually create
| software.
|
| If people are judgemental around what stories are left
| uncompleted or points / week then the situation can become
| stressful for no benefit to anyone.
| bruce511 wrote:
| >> None of that is required to actually create software.
|
| Agreed. (Assuming you mean "create" as in write, as distinct
| from create as in get funded.)
|
| >> If people are judgemental around what stories are left
| uncompleted or points / week then the situation can become
| stressful for no benefit to anyone.
|
| Clearly no stress is better. But these things create stress
| in the other direction too. Slower than expected progress,
| the existence of "intractable problems", work going
| unfinished creates significant stress up the ladder.
|
| In a perfect world the dev team is given a perfect spec, and
| a reasonable time to do it in, and after being "left alone"
| they deliver the finished product on time.
|
| Given that that world doesn't exist, given that the "money
| we're spending" may turn out to be completely wasted (because
| the spec was wrong, or because the problem us much harder
| than anticipated), the ideal case seems unlikely to happen.
|
| I say this not as a defense of crappy management processes,
| or even less as a defense of crappy managers, but rather in
| the spirit that understanding the problem goes a long way to
| solving it.
|
| And yes, many places have bad processes and bad middle
| managers. I don't envy you that. But finding a way to better
| solve the manager's problem typically improves the
| relationship.
| Aeolun wrote:
| > Agreed. (Assuming you mean "create" as in write, as
| distinct from create as in get funded.)
|
| You are essentially saying "Shit is bad, give up on it ever
| improving."
| bruce511 wrote:
| Not at all. Quite the opposite. To improve the situation
| you first need to understand it.
|
| It seems to me that most devs don't understand the root
| problem, so they both don't understand, and don't
| constructively improve the current solution.
|
| Improvement is not "leave me alone". Improvement is
| finding efficient ways to remove stress from higher-ups.
| Because stress rolls downhill.
| ozim wrote:
| I would not say most devs.
|
| I think ones that are against scrum are loud about it on
| the internet.
|
| When it comes to have their salary paid out they will not
| speak up for themselves to push back against shitty
| management.
|
| Like accepting ever increasing velocity until they burn
| out or accepting bad requirements because business is
| sayin "it needs to be done now" and working blind only to
| be scolded they did bad but requirements were bad in the
| first place.
| relaxing wrote:
| > Improvement is finding efficient ways to remove stress
| from higher-ups.
|
| How about gym memberships and mindfulness exercises?
|
| Is the rise of Agile tied to the demise of the three-
| martini lunch?
| Viliam1234 wrote:
| > Improvement is finding efficient ways to remove stress
| from higher-ups. Because stress rolls downhill.
|
| The stress at the bottom is there by design. If you start
| meeting the deadlines too reliably, the higher-ups will
| probably conclude that there are needlessly many people
| in the team, and will try to remove one and see what
| happens. Repeat until things start cracking apart.
| bruce511 wrote:
| I guess that depends on your management. I've not
| experienced that myself, but I'm sure there are places
| where it happens.
| Viliam1234 wrote:
| In one of my previous jobs, I worked on a software
| project that frequently got the following two kinds of
| comments from the managers:
|
| "Wow, this is the only project in our company that works
| reliably. There are no major bugs ever; and all the small
| bugs are fixed within a day or two. I wish other projects
| worked like that."
|
| "You have _five_ developers working on one project? Isn
| 't that too much?"
|
| Seemingly none of them was able to connect the dots and
| conclude that maaaaaybe these two things are somehow
| related. That maybe the fact that we are _not_
| understaffed somehow allows us to write automated tests,
| refactor when necessary, etc., so we can keep adding new
| features as required and the project keeps working ok.
|
| So they started removing the developers one by one,
| moving them to other projects. The last guy left on the
| project felt overloaded and quit.
|
| The project still worked okay for a few years without new
| updates, and was gradually replaced by several new
| projects (because it had a lot of functionality). But the
| new projects only had two developers each on average, so
| at least the managers didn't feel like they were wasting
| money.
| kledru wrote:
| I must say you are the first one convincing me the other
| side of the coin does exist.
| noisy_boy wrote:
| > Improvement is finding efficient ways to remove stress
| from higher-ups. Because stress rolls downhill.
|
| Good luck with that because higher-ups have even-higher-
| ups until you reach the top. The bigger the pay packet,
| the more inflated the lifestyle and the associated stress
| of missing on the ever ballooning target. It is self-
| inflicted and never-ending; sacrifices of the lowly
| soldier will never quench that thirst.
| ako wrote:
| Scrum/Agile is basically an answer for things that went wrong
| in the past. Building software has a long history of delays,
| running over time, running out of budgets, etc. As a
| stakeholder/customer, you need certainties up front: how long
| is it going to take, what is it going to cost? And if you
| think this isn't reasonable, just consider, would you hire a
| contractor to work on your house that can't tell you up front
| cost and duration?
|
| Anybody doing work needs to be able to estimate duration,
| progress, risk of delays, etc. Other people's work depends on
| your deadlines. Go/no go of a project depends on cost and
| duration.
|
| Insight and tracking is required. None of this was done any
| better before agile.
| skydhash wrote:
| What is required is frank conversation with the
| stakeholder/customer, because there are so many trade offs
| decision to make. Devs don't like to estimate tasks because
| there's an exploration phase (which cost time an energy) to
| have the solution and the cost of time and energy for the
| implementation. And it's recursive. Agile was basically
| saying, let the devs do their thing, but have a
| conversation every once in a while to discuss new
| directions to the projects based on new evidence found. And
| unless the team have already built the same project (with
| the same people involved), it will always be a bet. No
| amount of tracking or insight will remedy that.
| ako wrote:
| Agile recognizes that software development is a design
| process with uncertainties and not a repeated tested
| manufacturing process (product development versus product
| manufacturing). With the uncertainty of a design process
| in mind, and the need for estimates, it suggests
| comparing similar tasks to get an empirical estimate. But
| since it's just an estimate, you regularly need to
| validate that the estimate is still considered correct.
| Double_a_92 wrote:
| Stories = Requirements Engineering
|
| Assigning Points = Roughly estimating how long it takes you
| to implement it
|
| Allocating Work = Well... allocating work
|
| Standups = Talking with your colleagues about the current
| work and clearing problems
|
| Reviews = Showing your results
|
| None of that seems unreasonable. The only thing that kinda
| sucks are the rigid sprints, because they just cause
| artificial stress by setting unnecessary deadlines.
| skydhash wrote:
| They're not unreasonable in themselves. What sucks is the
| process around them, because it impedes progress. Why
| because each tasks varies, and often it morphs while you're
| working on it. So whenever a metric is fixed or something
| interrupts you repeatedly, it just sucks.
| nine_zeros wrote:
| Progress is important. That's why you plan for large
| milestones. There is no need for micro-ticket-story level
| updates, tracking, and overhead.
| ChicagoDave wrote:
| Tell that to a large PM organization. They love tracking
| minutia.
| SoftTalker wrote:
| Method 1? Wow talk about a blast from the past. Did you work
| for or with Andersen Consulting at some point?
| mtrovo wrote:
| Yeah, I totally agree in theory, it doesn't really matter what
| methodology you use, at the end of the day dev management is
| just a means to an end.
|
| The real issue comes from middle management folks who conjure
| up buzzwords whenever they need to justify whatever they think
| the team should do. Don't know how to structure tasks but want
| to look like you're in control to the boss's boss? Just throw
| up a Kanban board with tiny tickets and a burndown chart
| trending down. Sprinkle in some Agile keywords in the
| management reports and call it a day. And let's not forget that
| by 'sprint' they often mean moving unfinished tickets from the
| last iteration to the current one, plus tacking on surprise
| urgent tasks that were not planned before because the product
| owner never shows up to share their vision and priorities.
| anothername12 wrote:
| I'm getting performance measured based on number of tickets
| completed and number of PRs merged per quarter.
| Viliam1234 wrote:
| I hope you make lots of small tickets, and a separate PR for
| every commit, and a separate commit for every line of code.
| jksmith wrote:
| Unfortunately, we aren't understanding the intricacies of high-
| performance. I've worked with maybe 150 scrum teams. 99% were
| mediocre. Remaining 1% understood energy usage, how to limit what
| they took into a sprint backlog, and how to manage their
| capacity.
|
| When I asked a manager about a particular team, he said "I don't
| care if they do fight club in the morning, just let them keep
| doing what they're doing." To reframe, high-performing scrum
| teams are actually anti-legacy management, they get more done,
| are happy (low energy state) and stakeholders were satisfied. So
| their rolling sprint goal was taking a half day each month and
| going to Top Golf . The key is, everybody on the team was a scrum
| sme, and understood how to work the process as a team to
| reinforce certainty and stability. They also didn't need a scrum
| master.
|
| I've got lots of anecdotes from this couple of teams, what kind
| of work their managers actually did, and the sneaky ways they
| made the process work for them. There's a lot more to scrum than
| a certification. Just the teams approach to sprint planning was
| in a whole different class from what mediocre teams normally did.
|
| As for the other 99% of teams, they were mostly management tools.
| Scrum had been co-opted, especially in orgs using the SAFe
| framework. This has been at F250's in my experience btw.
| TN1ck wrote:
| I wonder if this team could have choosen any framework and it
| would have worked, they just happened to use scrum. With the
| founder mode discussions recently there was this saying akin to
| "a successful process is a result of talented people" and not
| the other way around. It stuck in my head and I feel this is an
| instance of that. Although you definitely can force a process
| on a talented team and have their productivity diminish.
| jksmith wrote:
| Agree. It's just that well understood scrum is a great
| process for delivering certainty and stability, as proven by
| lots of teams (provided they did scrum correctly).Just saves
| energy to thoroughly vet the process before tossing it.
|
| But first principle, this is a physics issue: Whatever way a
| team comes up with to maximize the amount of work not done to
| deliver the same or better outcomes, I'm all for it.
| binary132 wrote:
| This article hit really hard. I'm super stressed with my team's
| cadence right now. I often think about what's pathological in
| modern-corporate-scaled-agile-abominations and this really hits
| the nail on the head, but I think for me the main complaint is
| that if you can only see two weeks into the future, planning can
| become very difficult.
|
| I also often think of how our scrum process makes me feel like
| I'm back in grade school doing little busywork projects like
| coloring a hand-outline turkey or whatever. I really kind of
| think that's the point. It's for people who never escaped the
| schoolchild mindset. No doubt it works wonderfully well for them.
| It doesn't work very well for me.
| swergi0 wrote:
| does your team not follow any sort of higher-level roadmap?
| binary132 wrote:
| people invested in scrum all think it's great
|
| people who have to do the actual work don't.
|
| you should pay attention to that
| lispisok wrote:
| One of my favorite moments was when my non-developer friend at a
| tech company asked me what scrum masters did because she could
| not figure out what the scrum masters did at her company. I told
| her the answer which is nothing.
| n_ary wrote:
| Schedule meetings, move tickets around, moderate meetings, call
| more meetings, scold misbehaviour during meetings, help
| management with their stuff(secretary/personal assistant?),
| scold other teams for not helping out in time, question about
| stale tasks(tickets), act as coordinator of
| news/requests/demands from other teams, attend all meetings
| which involve tickets, coerce/seduce other teams to deliver
| something early because our team has messed up, promote more
| scrum agile topics. At least that is what I observed at my
| work. They indeed do a lot of work but often not well defined.
| meheleventyone wrote:
| Scrum Master is a terrible name though, in games we call this
| role a Producer but I agree they do a lot of often unseen and
| very useful work.
| lispisok wrote:
| I cant tell if you're making fun of or trying to justify
| scrum masters
| 015a wrote:
| One hill I will utterly die on: Many people (including some in
| these comments) are fully able and happy to go their entire
| career mistaking high performing individuals with a high
| performing work framework.
| Aeolun wrote:
| Because for high performing individuals the framework doesn't
| really matter? Most people aren't high performing, so they're
| designed to get the best out of the mediocre ones.
| n_ary wrote:
| On the contrary, I'd say frameworks can't set its claws on
| high performing "politically influential" individuals because
| they are fairly powerful. In most cases, majority people are
| high performers but crippled by the frameworks due to power
| imbalance.
| fulafel wrote:
| Every post about "Scrum sucks" has comments about how you are
| doing agile wrong. I don't see any yet so as the devil's
| advocate:
|
| You're supposed to have autonomous teams who put up their own
| tasks they want to complete in the sprint, and the sprint length
| can be more than 2 weeks if the team wants. And if it's tight to
| get the scrum's tasks done, that's supposed to be feedback to you
| and the team. You have autonomy in setting sprint goals, you can
| put less stuff on a sprint so you have the slack you're supposed
| to between sprints. Or spend more effort refining so you don't
| get surprises so often. (Or otherwise change things up in how you
| work)
|
| If you don't have the autonomy and the continuous improvement in
| your work culture, it's not agile. Scrum is for agile and it
| doesn't work otherwise. If you do have autonomy you can switch to
| something else from scrum if you want.
|
| Same goes for the "scrumfall" part of course but that's admitted
| in the text already.
|
| (I do think scrum is overengineered for agile ideals, has failure
| modes like in the post, and in 95% of cases you should do
| something lighter than scrum)
| mortify wrote:
| There's truth to the ScrumFall design process which is inevitable
| for most development processes. It's not just that a tool needs
| to be marketed, but that it needs to be integrated with work from
| multiple teams and other processes. What ScrumFall does is
| provide some level of feedback prior to delivery. In the age of
| Waterfall, devs would develop until they said they were done,
| we'd get to delivery and UAT only to find that key features work
| differently than expected and continually extend the release date
| by months or years until it finally goes out the door more from
| frustration than actual completion. That stress level would be
| pegged at 10 for months until it was completed.
| bamboozled wrote:
| What I dislike about SCRUM specifically is that if you're having
| a rough week at home, recovering from illness or you just have
| things to do outside of work, you can't really just have an easy
| week and make up for it later on. It's a kind of constant grind
| and we always have a way of "filling up" our sprint. If we don't
| meet our target, it always feels like a fail. I know it shouldn't
| feel like that but it's human nature.
|
| Maybe having "easy" sprints would work?
|
| There are benefits too, just that constant grind aspect is why I
| believe it's mostly a temporary endeavor. After 6-12 months most
| teams seem to just do something else then come back to it once a
| new manager joins.
| Aeolun wrote:
| I just completely ignore sprints, or sprint/standup meetings.
| Somehow it works well enough that nobody has called me out on
| it yet.
|
| If they all want to waste 2 hours a day, more power to them.
| Pet_Ant wrote:
| If your stand-up meeting is more than 15 minutes long you are
| doing it wrong. It's called stand-up for a reason.
|
| https://scrumguides.org/scrum-guide.html#daily-scrum
|
| > The purpose of the Daily Scrum is to inspect progress
| toward the Sprint Goal and adapt the Sprint Backlog as
| necessary, adjusting the upcoming planned work. The Daily
| Scrum is a 15-minute event for the Developers of the Scrum
| Team. To reduce complexity, it is held at the same time and
| place every working day of the Sprint. If the Product Owner
| or Scrum Master are actively working on items in the Sprint
| Backlog, they participate as Developers.
|
| If what you are doing doesn't match that, then it's not a
| Scrum stand-up.
| randomdata wrote:
| _> If what you are doing doesn 't match that, then it's not
| a Scrum stand-up._
|
| You must have stopped reading too soon.
|
| _" The Daily Scrum is not the only time Developers are
| allowed to adjust their plan. They often meet throughout
| the day for more detailed discussions about adapting or re-
| planning the rest of the Sprint's work."_
| siva7 wrote:
| The sprint goal is a team target. If you're sick that shouldn't
| endanger the sprint goal because anyone in the team can pick up
| any work. Of course in mediocre or low-performing teams that's
| almost never the case but still not the fault of a product
| framework
| jacknews wrote:
| This seems like a disingenuous answer to me - the rest of the
| team will take up the slack? And if they can't they must be a
| low-performing team?
|
| The OP may have some things wrong, but the 'constant grind'
| aspect of scrum sprints is spot on, there is no slack.
|
| Add to that the 'radical transparency' aspect of scrum. That
| works great among a tight-knit team, but it can be insidious
| and actually self-defeating when certain types of manager get
| involved and weaponize it.
|
| I'm sure there are many people who love programming, but hate
| being a programmer as a job, and to some extent that has
| always been true, but scrum seems in many cases to make it
| much, much worse, IMHO. The attitude displayed here is
| exactly the problem.
| JansjoFromIkea wrote:
| This doesn't apply for pod-based systems though, does it?
| They were everywhere for years there and are still very
| common. Basically by definition there's only one or two
| people that can do each task.
| throwaway89988 wrote:
| What you say works 100% for trivial CRUD applications. Which
| is also, where SCRUM is still a bad framework, but at least
| SCRUM works on this trivial level of software development.
|
| When a project is about non trivial projects, people,
| especially developers can not be easily replaced, because no
| one can replace a specialist with several years of experience
| on the spot. What I can archive in one day and what somebody
| else can archive on a day highly depends on what it is. Write
| a field to the database? Works. Write a rule engine? I'll
| probably be a factor of 10x more productive than an average
| developer. Write some GUI/CSS? A frontend developer is 10x
| more productive than me.
| freedomben wrote:
| > _If we don 't meet our target, it always feels like a fail. I
| know it shouldn't feel like that but it's human nature._
|
| It definitely is human nature, and beyond that we're so trained
| to focus on goals and take them seriously that the "sprint
| goals" actually feel weaponized to me in order to get people to
| self-motivate/drive themselves. In the Scrum world engineers
| are fungible, so if one burns up or stops performing, you just
| replace them with a new one.
|
| Also that "rough week at home" is going to show up on metrics
| for a very long time. A good manager understands the ebb and
| flow, but many do not. It also doesn't help that the Certified
| ScrumMaster(r) people will put so much emphasis on smoothness
| and consistency, and when it doesn't happen there's always
| someone/something to blame. When you remove the context (like
| team lead who knows what happened) and put it in a quarterly
| chart for upper management, you get a lot of bad and counter-
| productive conclusions.
| phtevenf wrote:
| Out of the 8 companies I've worked at as a product engineer, the
| most successful framework to deliver tangible results has been
| Basecamp's Shape Up approach. Engineering managers always ask
| "how many days" of effort when the real question they should be
| asking is "how much appetite"/"how long do we want to spend" on
| the particular product/feature we want to build? The Shape Up
| framework was the only time I didn't feel constantly stressed and
| it actually provided time to cooldown between the six week
| cycles. And the fact is it actually led to very successful
| product deliveries consistently. For those interested here's a
| link to it https://basecamp.com/shapeup/0.3-chapter-01.
| szundi wrote:
| While I think the part about neglecting support became true at my
| org, I didn't forget how awesome E V E R Y O N E felt about Scrum
| when we started. It lasted for 1-2 years. All the devs and
| everyone loved it. So... then why?
|
| Because it brought a kind of order to the game. Story points
| worked. They became boring so the teams started to twist them.
|
| I think Scrum loses its advantage when people get bored - like
| with any other "process".
| freedomben wrote:
| I remember that as well, but I think scrum lost it's advantage
| once it was co-opted as a metrics and management tool, and by
| people looking to make a career out of "managing." That's the
| point at which it started shifting to being imposed on the team
| rather than offered as a tool to the team.
| irrational wrote:
| I refuse to stress about it. If I don't get the things done in
| the time allotted by the points, oh well. If I don't get them
| done by the end of the sprint, oh well. And, while my manager
| might bring it up in one-on-ones, I've never seen any
| consequences from not stressing about trying to meet artificial
| deadlines.
| 20240915 wrote:
| I have had consequences for not cranking out work fast enough.
| Usually PIP or PIP-larping processes are run. I then resign
| find another gig.
| morningsam wrote:
| Same here. I _have_ become stressed about deadlines that were
| actual deadlines imposed by external dependencies (e.g. API
| deprecation) or stakeholders (e.g. launch of feature needs to
| be coordinated with efforts in other departments), but never
| about "deadlines" I've just had a hand in making up out of
| thin air myself during sprint planning.
| justanotherjoe wrote:
| I think what people really want is not agile, not waterfall, just
| to do it in a way that feels natural. No framework. Pretty case-
| by-case. How I imagine Lao Tzu would have it. Roll your eyes but
| it's true though.
| oneshtein wrote:
| Individuals and interactions over processes and tools.
|
| Working software over comprehensive documentation.
|
| Customer collaboration over contract negotiation.
|
| Responding to change over following a plan.
|
| https://agilemanifesto.org/
| kkfx wrote:
| People like to forget a thing: Kanban, which is the scrum
| "ancestor", was designed for FACTORY MASS PRODUCTION of already
| designed parts, not for designing new ones, on other words it's a
| system that works only if what you do is pre-defined, does not
| demand much intellectual, creative activities and anything it's
| well known in advance.
|
| Applying it to creative activities is a classic application of a
| religion to a society blindly believing it's universal. It's not.
| That's the substantial stress.
| oneshtein wrote:
| Continuous delivery IS mass production.
| senko wrote:
| If a factory is producing N widgets, every widget is the
| same. If a software teams are producing deliverables, each is
| different.
|
| Kanban (originally) is an method of sending purchase orders
| (ie requests to make widgets of specific type in some
| quantity) from the team(s) who need them to the teams who
| make them.
|
| In software, quantity is always 1 and while the "widgets"
| have notionally been designed (specced out in the ticket),
| they have never been built before, unlike in the factory
| where every widget at least had a test run before.
|
| That is, Kanban in software development is a cargo cult from
| Toyota in which an essential difference (time to reconfigure
| the assembly line for another widget, vs time to design,
| prototype and test the widget) has been lost.
|
| And it STILL works better than Scrum.
| oneshtein wrote:
| Kanban was invented for Just-In-Time factories, where each
| product item is customized to meet demand, so fewer things
| can be predicted in advance, thus making Waterfall
| unsuitable. Kanban allows to achieve both the flexibility
| of customization and cost effectiveness of mass production.
|
| In software development, incoming requests are broken down
| into _small_ manageable tasks, which are familiar enough
| for developers to estimate reliably. Then this continuous
| stream of small tickets is executed continuously (Kanban)
| or in sprints (SCRUM).
|
| For example, request to add feature X can be broken down
| into <<Make UI for feature X>> and <<Make backend for
| feature X>>. If they are still large, they can be broken
| further, for example <<Make a CRUD for feature X.y>>,
| <<Make a SQL table for X.y with migration script>>, and so
| on.
| senko wrote:
| > each product item is customized to meet demand
|
| No, each product run is customized. Products are already
| known and fixed (they have been built before, with the
| same specs), the demand is unknown (in advance). There is
| a subtle difference between this and your "make CRUD for
| xyz", where XYZ is always something different (if it
| wasn't, we'd just reuse the thing we wrote the last
| time).
|
| I would encourage everyone to read a book about TPS (The
| Toyota Way is a good one), and compare/contrast that with
| Kanban as an agile software methodology.
| marcosdumay wrote:
| Well, it's worth pointing out that the only thing factory
| kanban has in common with software development kanban is the
| existence of some artifact called "kanban". What was probably a
| publicity stunt to use the hype of the other kind, kinda like
| Java and JavaScript.
| itronitron wrote:
| In my experience, Agile methods give power to non-developers
| which can be a good thing or bad thing depending on the workplace
| and the individual behavior or perspective of participants.
| nineteen999 wrote:
| Daily standups are horrendous. I don't know how people put up
| with that level of time wastage and micromanagement.
| Instantix wrote:
| It can be very useful at the start of a project to synchronize
| everyone but the over use of it can clearly be a problem.
| fernandotakai wrote:
| the "daily" part is what kills me, specially because saying "no
| updates" feels super bad, like you are slacking-off.
|
| i would be totally fine with twice a week (mondays so we can
| sync up and see what's being done throughout the week) and
| maybe fridays.
|
| as a tech lead that has to lead standups daily, it's
| frustrating.
| grumblehound wrote:
| I didn't mind our daily standups at the last place. They were
| usually short (10-15) mins. It was all the bullshit and
| developer grovelling at the end of the sprint, and the lack of
| allocated time to actually plan future work, that was the
| problem. I saw people time and time again cutting corners to
| meet their imaginary deadlines. I'd get sent PR's to review
| after hours by people in different teams the day before scrum
| deadlines. It was insane.
|
| The standups themselves were fine and actually I thought they
| were pretty helpful, especially during covid times.
| randomdata wrote:
| The problem with standups is that usually the wrong people are
| talking.
|
| I don't give a rat's ass about what other developers are doing.
| I either already know by virtue of having to work with them, or
| they are entirely disconnected from my work and so what they
| are doing doesn't really matter.
|
| What I really need to know what the managers and executive are
| doing. That has the most impact on my work. Yet, strangely,
| they almost never want to share.
| wg0 wrote:
| >With sprints, there are no breaks, little autonomy, and
| insufficient time to prepare.
|
| That's the TLDR and on the dot.
| ranjanprj wrote:
| Agile/Scrum and all forms of project management is a scam you
| should work in layers serving layer above, have wbs and tasks
| assigned out of it in your layer, justifying urgency by impact on
| business/users, reward people who accept and close most tasks by
| appreciation and break. And fire anyone who misbehaves.
| 20240915 wrote:
| Is this satire?
| n_ary wrote:
| I believe, they are describing real world consequences of
| scrum/agile and how real management uses it, which might be
| different from what the manifesto actually hoped.
| Too wrote:
| This guy has clearly never worked waterfall, the progress bar
| doesn't look at all like in the graph. Instead, there are even
| more milestones throughout the project. Granted, they are usually
| spread out further than every 2 weeks, there is no such thing as
| just one final deadline where you can slack the first half of the
| project.
|
| Month 1: Specifications need to be frozen, because month 2 all
| the test plans need to written, so that month 3 all the test
| cases can be implemented. Then month 4 all code should be written
| and month 5 we put everything together to test it. Hoping that
| what you wrote down half a year ago is still relevant and the
| most important thing to work at now. Add a complex web of
| dependencies to other teams on a gigantic gantt-chart with fixed
| dates and you will have deliveries regularly anyway.
|
| Usually, by month 2 you are already overdue on the first
| milestone. The time plan is not going to shift because of it.
| Meaning you now have even less time to meet the second deadline,
| obviously it will be missed, repeat throughout the remaining
| milestones, resulting in constant stress throughout the project.
|
| That's not to say that the graph doesn't exist, its just not
| called waterfall. It's longer deadlines with more autonomy
| between.
| freedomben wrote:
| > _This guy has clearly never worked waterfall, the progress
| bar doesn 't look at all like in the graph. Instead, there are
| even more milestones throughout the project. Granted, they are
| usually spread out further than every 2 weeks, there is no such
| thing as just one final deadline where you can slack the first
| half of the project._
|
| You are misreading the graph and then taking your own bad
| reading and projecting uncharitably on the author. Nowhere did
| he say that you can slack the first half of the project. Also,
| I know the author and I know that he _has_ worked waterfall, so
| your conclusion isn 't even accidentally correct.
|
| Look at the Y-axis. It's measuring _stress_ , not
| effort/work/slack/etc.
|
| Also, the graph itself refutes your conclusion that it is
| representing only one single "milestone." Notice the graph
| falls after achieving the milestone, and then begins again.
| It's a continuous cycle.
| drzzhan wrote:
| I learned scrum back in college and I hated it so much. I
| remember we had to meet 2-3 times a weak. And for each meeting we
| had to present something, with slides as well. We spend more time
| thinking about usercase than writing the code. I guess that's
| good in its own way but honestly I don't have such superpower to
| report something new every meeting. In fact most of my meeting
| back then were "I am still coding X" and that was it, then the
| scrum master or the leader would talk about big picture over
| again.
| mrsaint wrote:
| When challenged why we'd scrum since we were doing better as a
| whole before (better products, happier devs), mgt replies that
| they'd need scrum to detail the work we did so that they could
| write longer bills to the clients.
| freedomben wrote:
| Wow, that's remarkable honest of them! I actually respect and
| appreciate that a lot more than I would some BS about it being
| for your own good or whatever.
| VeejayRampay wrote:
| there has never been a conclusive study about the actual
| usefulness of those things, the agile, the scrum, etc.
|
| as such, it's more akin to something like litho therapy or
| astrology, that is what's stressing me out
| al_borland wrote:
| I was less stressed when doing scrum. When a new VP came in and
| tossed it out, he didn't replace it with anything. The void has
| been filled with chaos, where our priorities change based on who
| the last person to speak was. I'll take scrum over chaos any day.
| vannevar wrote:
| There are several flaws in this article's arguments, but the
| central one is easily revealed when you ask this question: why is
| there a big spike in stress for the "waterfall" project?
|
| The answer is that as the deadline nears, the team realizes that
| they have not made enough progress to meet the deadline. They
| must work longer hours, start cutting corners, and toss out
| features at the last minute. All of this is extremely stressful.
| It's also a cascading problem on bigger projects where this
| team's product is a subsystem that subsequently has to be
| integrated into a bigger platform, because they may have broken
| compatibility at the last minute to make their deadline.
|
| Contrast this with scrum, where the team collaboratively sets
| goals on a regular basis and regularly monitors the work
| remaining and the rate at which they are progressing, so that
| they know early whether they need to start making trade-offs or
| adding people to the team. As the author notes, this trades peaks
| of extreme stress for a predictable (and manageable) medium level
| of stress. But it also ensures a more consistent and panic-free
| delivery process.
|
| The problem of burnout is a separate issue. Neither scrum nor
| waterfall offers a solution to burnout---that is up to the team's
| management. Nothing in scrum prevents a team from taking breaks
| from sprints, either as a team or individually.
| uldos wrote:
| Why do you assume that its devs who are slacking in waterfall?
| Devs enjoy deving, usually there are either discoveries during
| execution or change of mind of client or pms figure out that
| their guestimation for year ahead was not exact. Surprise,
| surprise and who is going to have crunch time? Devs of course.
| vannevar wrote:
| I didn't say they were slacking, but they may be working on
| the wrong things, or prematurely optimizing things at the
| expense of other priorities. Ironically, it's the author who
| suggests implicitly that devs can slack more in waterfall
| ("Sprints never stop").
|
| Since the client is involved in every sprint, any change of
| mind they have during the development process (and keep in
| mind that changes of mind are a virtual certainty in either
| case)is at least better informed than if the touchpoints were
| much less frequent (or as is too often the case in waterfall)
| all back-loaded towards the end of the project.
|
| Does scrum eliminate crunch time? Of course not. But if it's
| done well, the impact is minimized because there has been so
| much more opportunity for course correction throughout the
| project.
| skydhash wrote:
| It's that culture of fear that I don't understand: devs
| working on the wrong thing. More often than not, it usually
| means: Is the dev spending more time than me (who is not
| doing the work) is willing to give him? Every professional
| understands priority and expectations. And communication is
| all that is required. But PM usually don't understand the
| nature of software development and fear of losing control
| (the bad ones). The good ones just let people work after
| they made it clear what should be worked on.
| jakub_g wrote:
| The forever-sprinting approach indeed is unmanageable long term.
|
| In my prev job we used to have a cycle of 2-3 sprints followed by
| 1-2 weeks of rest (to handle tech debt etc.)
|
| In other companies it could be named "innovation week" or
| something similar.
|
| I still didn't love this, precisely due to always wanting
| tangible deliverables within 1-2 weeks, while sometimes you just
| need more time to think clearly about some problem.
|
| We partially mitigated it though by explicitly stating whether a
| giving story is "delivery" or "discovery", the latter being used
| to better understand the scope of the problem, current status
| quo, validate assumptions etc.
| satisfice wrote:
| This was evident fron the beginning. The mystery to me is why was
| this adopted as the default way of working?
| Viliam1234 wrote:
| On a related topic: Why reading discussions about Scrum is
| stressing me out.
|
| Unlike most people here, I have read the Scrum Guide
| https://scrumguides.org/scrum-guide.html and I actually worked in
| a team that did Scrum almost by the textbook. And it was a great
| experience! But then higher management decided that the entire
| company needs to switch to "Scrum", so we were told to stop doing
| what we did, and switch to the corporate version of "Scrum"...
| which was exactly the kind of experience most of you are
| complaining about. (Then, gradually, the disappointed developers
| quit.)
|
| The sad truth is that managers do what managers want to do. They
| may be happy to adopt a new buzzword, but they will keep doing
| the same old thing. Anyone who says "agile is great but scrum
| sucks", please realize that it's merely because managers decided
| that "scrum" will be their favorite buzzword. If tomorrow they
| decide that "agile" is their favorite buzzword, soon HN will be
| full of people saying "agile sucks". You should be happy that
| "agile" is not a popular buzzword, because it means you still
| have something to dream about.
|
| In other words, it is not the fault of the Scrum process being
| somehow incorrectly designed. It is the fact that the design does
| not matter in practice, because almost no one is going to follow
| it anyway! It's the same thing as with ISO 9001 -- most companies
| have the certificate, but when you actually read the standard,
| you will find out that it does not resemble what actually happens
| in your company at all. You can't fight against people who decide
| to use the name of your idea, but ignore the content; which is
| the standard thing that happens in companies.
|
| If I was a manager, I would probably be happy when people say
| "Scrum sucks", because it means they are looking in a wrong
| direction. It's the way how companies are managed that sucks.
| Scrum or no scrum; agile or no agile; ISO or no ISO; the buzzword
| or a different buzzword... it's still the same thing, we are just
| pretending that it is something else than it was yesterday.
|
| Back to the article:
|
| > There is no time to breathe, no time to collect yourself.
|
| First, let me ask you: who decides how much work you should do in
| a sprint? Because if that person is you, they you only have
| yourself to blame if as a result you have no time to breathe, and
| you keep making the same mistake over and over again. Why don't
| you discuss this at the retrospective?
|
| Ah, let me guess. It's the management who decides how much you
| should do, and when are the deadlines. But they generously let
| you choose whether you do A in the first sprint and B in the
| second one, or the other way round. Or they let you do the cute
| game of poker planning or whatever, and then say: anyway, you
| must have all of this ready by the end of the month.
|
| Also, let me guess: you probably have no retrospective, because
| those are just a waste of time. No one is going to listen to your
| feedback anyway, so what's the point?
|
| > If a development team were to sit down and decide to deliver
| code every two weeks, based on a process of their own design
|
| Okay, let me stop you right in the middle of the sentence: it's
| not supposed to be two weeks! Two weeks are for beginners; for an
| experienced team, three weeks are generally recommended, but
| anyway that is a thing that the team should decide during the
| retrospective! Which you probably don't have, because no one is
| going to let you decide anything about the way you work.
|
| This may seem like an unimportant detail, but it's a red flag. If
| the management tells you it has to be two weeks no matter what,
| you don't really need more evidence that their "Scrum" has very
| little in common with the Scrum according to the textbook.
|
| > Every aspect of a sprint is prescribed: its duration, its
| meetings, its tasks, and even the roles of its participants.
|
| Yes. Specifically, the meetings are prescribed to be short. And
| the managers... wait, there are actually no managers in Scrum.
| And no, it's not because they were renamed to "Scrum masters" and
| "Product owners" and whatever. Those are completely different
| roles. The product owner should actually be someone from the
| customer's company. And the Scrum master is not supposed to be
| your boss.
|
| So, yeah. Every aspect is prescribed... and then ignored
| regardless.
|
| > This happens because no time is set aside for proper
| engineering prep work. There's far more to a task than simply
| typing out a solution.
|
| Exactly. So why don't you put the prep work as a task in your
| sprint?
|
| Ah, let me guess: your manager said no. So much for self-
| organizing.
|
| > The only remedy is to restore autonomy and professionalism to
| software development.
|
| Ah yes. If only there was some system that would say "no more
| managers; the developers decide for themselves how long the tasks
| are going to take; the meetings should be 5 minutes at most; and
| every few weeks the developers will reflect on whether they are
| happy with the rules, and will adjust them if needed". If only.
|
| I am sure your manager would allow you to do so. As opposed to
| e.g. using the name of your system as a buzzword, and saying
| "yes, we will do it... but we will do it my way: the managers
| will stay, you will be told what to do and how long should it
| take, the meetings will remain long, and the company is not
| really interested in your feedback. But we really like the name
| you invented for your system, so from now on our company will be
| using it officially. If someone later complains on Hacker News,
| we will tell them it was all your idea."
| yqtjnvou wrote:
| Scrum is useless.
|
| it's just another method of demanding results. Where there isn't
| anything to tell, you shouldn't be forced to do so. All this
| imbecility does is to create competition, and weed out the ones
| that don't comply.
|
| I've worked in teams where we were forced to have something to
| report even when nothing was to report. This made the team create
| "things" to match their daily scrums, because the truth might get
| you fired..
|
| Those that actually do work, have nothing to say in these scrums.
| It's a fact.
|
| Intellectual work is never measured.
| ath3nd wrote:
| > All this imbecility does is to create competition, and weed
| out the ones that don't comply.
|
| This ten million times. It's about control, and it's about
| showing you that the only way to be considered to be doing your
| job, is if you abandon all dignity, and allow yourself to be
| treated as a child.
|
| The adults (POs and managerial folk) are making your planning,
| your regime, you constantly report to them them what you are
| busy with, you summarize what you learned last week and what
| you'd be doing today, and you present to them your paintings
| for evaluation. It's so degrading and humiliating, but that's
| by design!
| Kalanos wrote:
| Normalize 3 week sprints. Enables the team to do what they need
| to do. Less planning overhead. Enables the product manager to be
| more forward-looking and spend more time focused on customers/
| market research.
| spacecadet wrote:
| Ive mainly work at startups and as a consultant/sub-contractor
| and have encountered many implementations of agile and waterfall.
| One place I consult for, and this is not a defense of agile just
| an observation of some good in what this shop is trying to do,
| well this place handles sprints as "multi-week" (defined by the
| team up front, weighing factors like; are we blocked by client,
| complexity, etc). The projects are still more or less waterfall
| with a client deadline at the end (They are mostly fixed
| scope/budget after all), and the only sprint deadlines are
| periodic client demos that have no expectations (progress check
| ins, see what we did, yay). The teams here only seem stressed in
| the old sense, right before the end. They often joke and call it
| agilefall, with the agile part intended to force teams to share
| progress and collect progressive feedback. As well as hold other
| internal meetings like sprint plannings (really just team
| checkins, are we blocked? should we start this vs that, have we
| learned something, etc) and retros (also just checkins, how we
| feeling? are people butting heads, etc). My biggest gripe with
| them is that no one takes responsibility for any form of ticket
| management and it can be chaotic knowing who is actually doing
| what day to day, requiring too many stand-ups and slack messages.
| They try to map tickets to scope up front but no one moves them
| along and they usually just follow the estimate document... since
| all the subs are global and remote it would be awesome to just
| check a board each day and dive into work instead of everyone
| needing and hour at the ass crack of dawn, during dinner, or at
| bed time, their local time...
|
| Again, not saying this is my recommendation, but its definitely
| not some feature-mill, even tho we are literally a feature-mill
| as a fixed scope/fixes budget consulting shop, lol... not the
| most interesting work, but pays well, low stress, and if I heads
| down and get it done, I get tons of free time to do my own thing.
| lasereyes136 wrote:
| Interesting article and I have observed all of the situation
| described in it.
|
| I would like to point out that when agile, and even Scrum to some
| degree, was introduced it was a way for people creating software
| to take back control of a runaway process that prevented team
| from doing their best work. It was a grassroots movement
| championed by people invested in finding better ways to create
| software that were less stressful and more successful.
|
| Most of the issues in the article were coopted in Scrum to take
| control of software creating back from the teams. Whatever
| replaces Scrum, and agile, will need to learn from the mistakes
| and compromises of Scrum or it will suffer the same fate as Scrum
| and become a tool to force teams into a delivery model that gives
| managers and executives more control while reducing their
| accountability.
| skrebbel wrote:
| Back when Scrum was new I already wondered how it could make
| sense to make developers be constantly sprinting. I mean it's
| right there in the word choice. You can't sprint all the time! A
| sprint is short and fast and then you rest. Making everything in
| work life be only sprints is madness.
| hawski wrote:
| You rest at all the meetings.
| skrebbel wrote:
| Hahahahah i LOL'ed
| gtirloni wrote:
| If HN had a way to pin a comment, this would be the one :)
| GoToRO wrote:
| I hope this comment is sarcastic. Nothing is more exhausting
| than having to hear people that have no clue about anything,
| i.e. managers, speak.
| randomdata wrote:
| You're not supposed to pay attention.
| datavirtue wrote:
| The meetings wear me out and make me disengage the rest of
| the day.
| tjr wrote:
| Especially the meetings which are held for the purpose of
| planning more meetings.
| freedomben wrote:
| Heh, I say the same thing nearly every time a meta-discussion
| on Scrum/sprints is had. As a former sprint-runner, it
| irritates me to no end that nobody sees a problem with
| sprinting all the time...
| dbingham wrote:
| It seems like HN has gotten one of these posts every month or two
| for as long as I've been reading it (about 15 years now). They
| always make me some combination of sad and angry, because they
| almost always misdiagnose the issue.
|
| Process isn't the enemy. The various named and defined processes
| are just tools. It's all in how the tool is applied. And while
| this post wrongly blames a process, it does get one thing right:
|
| > If a development team were to sit down and decide to deliver
| code every two weeks, based on a process of their own design--one
| that made sense to them and suited their circumstances--that
| would be one thing. [...] Autonomy--the ability to direct one's
| own work--plays a significant role in how work is experienced.
|
| The development team (which ideally includes design and product
| as equal members) should be deciding its own process collectively
| and with a high degree of autonomy. Scrum, Kanban, Scrumban,
| Waterfall, "no process", these are just the defined and tested
| tools we select from in deciding our processes. We can mix and
| match them, draw from them as needed, or throw them out and try
| something new.
|
| But we as a development team should be deciding, together, what
| process to adopt in order to achieve the businesses goals with
| the resources and time as best we can without burning ourselves
| out.
|
| ---
|
| I was a full stack IC for 10 years and an engineering manager for
| 5 years.
|
| I've done more or less all the processes. I'm currently back to
| being an IC in an org where Product dictates exactly the
| sprintless "no-process" this post is advocating and it is every
| bit as stressful and bad as he's claiming sprints are.
|
| The best team I've been on was one where we had full control of
| our process. We started with scrum-like month long sprints, of
| which the first week was planning week where we did deep dives on
| our stories, wrote them up and ended the week with the scrum
| planning ceremony and agile pointing. We used an "ideal day" as a
| point to give our estimates some level of concreteness, but
| largely stuck to our recorded velocity. And you know what? It
| worked! We got surprisingly good at estimating and, while we were
| never perfect, if we overran our sprints it often wasn't by much.
|
| Planning week was definitely rough, and we eventually chose to
| ditch it in favor of two week sprints with planning stories
| worked into the sprint as needed. That worked really well too
| (and I think that's my preferred process).
|
| But the point was, we choose these processes. We ran these
| processes. Our retros were vibrant and highly critical
| discussions where we asked ourselves every sprint what was and
| wasn't working and made changes.
|
| When I became a manager, I carried this forward on my teams. We
| iterated through the two week sprints with planning SPIKES, to
| continuous flow kanban, and back to two week sprints with
| planning SPIKES. When I became a manager of managers each of the
| teams in my org choose its own process. One stuck with the scrum-
| link, one adopted kanban, and one (the smallest) decided to throw
| it all out and go with "no process". Each made their respective
| process work. Each had different challenges, because no process
| is perfect. Each continued to iterate on their respective
| processes. And I worked with the leads - the manager and staff
| engineer of each team - to form the cross team processes and
| communication to ensure that each of these autonomous teams could
| still collaborate.
|
| Process is not the enemy. Process is just the structure of our
| collaboration.
|
| It becomes bureaucracy only when someone else is dictating that
| structure and preventing us from structuring our collaborations
| in the ways that best work for us.
| dartos wrote:
| Kind of off topic, but when articles have a "conclusion" section
| nowadays it just screams chatgpt to me, even if chatgpt wasn't
| involved at all.
|
| I wonder what the tech blog meta will shape up to be in a couple
| years.
| whaleofatw2022 wrote:
| It's getting bad. I'm even seeing what I'd almost certainly ai
| writeups for language releases and it's so ugly.
| freedomben wrote:
| Interesting, because I was trained in writing classes to always
| have a "conclusion" where you make sure to summarize and
| restate your thesis for emphasis and focus. That AI does this
| feels like a result of training/emulating what humans do. If
| people think my writing is AI driven because of that, that's
| quite unfortunate. If we have to start introducing errors or
| mistakes into our writing so people don't assume it's AI, that
| seems like a quick race to the bottom.
| dartos wrote:
| I don't think NOT having a conclusion is a mistake, but
| calling it "conclusion" is a stylistic choice that smells
| like AI to me.
|
| It's how style changes. Just like how websites influenced
| graphic design, AI influences writing.
| _heimdall wrote:
| > Scrumfall: The Real (and Worse) Picture
|
| This section is very, very accurate. I was at a startup that ran
| scrum really out of a need to jeep our remote team communicating
| regularly. Goals were loose and generally defined by each dev
| doing the work.
|
| That eventually broke down and we had quarterly goals driven by
| marketing and sprints with rigid, increasingly stressful goals.
| The difference in developer burnout was plain as day, once scrum
| ends up overlaid on a quarterly (or similar) waterfall the value
| of scrum is gone and people burn out fast.
| FpUser wrote:
| SCRUM is mostly self-serving abomination
| liampulles wrote:
| Ok, hot takes incoming:
|
| * Some of the article and commentary here read to me like Scrum
| is being equated with bad management, or a bad relationship with
| management. If the source of stress boils down to unrealistic
| deadlines and high workloads, then that problem will persist with
| a kanban process, or extreme programming, or "yolo free for all".
|
| * A relationship is a two-way street. Yes its certainly possible
| that your manager is a dickhead, or incompetent, or both - but it
| is also possible that they don't know how unrealistic their
| expectations are because you have failed to PUSH BACK properly. A
| healthy relationship includes saying no, and explaining problems
| - that is part of a developers job.
|
| * So many developers (my younger self included) WILDLY
| overestimate their ability to communicate effectively with non-
| tech people. The idea that you are going to go from having a bad
| management relationship, to talking to the business directly
| is... lets say "misguided". I'm still pretty bad at it, but at
| least I know that I'm lacking here - I'm very thankful for the
| people who are well versed in stakeholder management (which
| really is a skill).
| prepend wrote:
| What does "sprints are involuntary" mean?
|
| My team chooses the characteristics of the sprint. It's not like
| they are randomly assigned. It's a collaboration between
| leadership, team members and non-team stakeholders. It's not like
| there's anything mandatory, so we set our release schedule and
| what a release means based on what makes sense.
|
| What's the alternative proposed?
|
| I wonder how the author is working if they think that these
| things are involuntary. It seems like their environment sucks and
| it's expressed through saying scrum sucks. Scrum is so generic it
| can be adapted for many needs. I'd like to see the author explain
| why their scrum is so rigid. Does he suck at estimating? Suck at
| communicating? Lacks resources? Leadership is poor at estimating?
| Who knows, but it seems like blaming scrum is like blaming
| software development in general and more of a "this job would be
| great if it wasn't for the customers" type screaming into the
| void.
| nottorp wrote:
| > My team chooses the characteristics of the sprint. It's not
| like they are randomly assigned. It's a collaboration between
| leadership, team members and non-team stakeholders. It's not
| like there's anything mandatory, so we set our release schedule
| and what a release means based on what makes sense.
|
| But then it's not Scrum. Scrum is weekly.
| naavis wrote:
| I don't think anything in Scrum dictates iterations must be
| one week long.
|
| https://www.scrum.org/learning-series/what-is-scrum/
| freedomben wrote:
| No dictation on length, but the length is supposed to be
| _consistent_. If you want to take a three week sprint or
| something instead because the feature makes sense, you mess
| up a whole lot of things, especially the metrics. And, let
| 's be honest, the metrics are the biggest reason why
| management imposes Scrum. They want to be able to quantify
| everyones contribution down to hard numbers that they can
| then use to know how everyone is performing. If you screw
| up the metrics, it won't take long for someone to step in
| and "get your team back on track."
| ebiester wrote:
| Metrics and software process are orthogonal. Now, you can
| argue that consistent processes across teams is used to
| enable metrics, but Taylorism is going to creep up any
| place that has management that has been infected by it.
| ebiester wrote:
| "They are fixed length events of one month or less to create
| consistency. A new Sprint starts immediately after the
| conclusion of the previous Sprint." - scrumguides.org
|
| You also need to understand that "release" might mean behind
| a feature flag. Further, while continuous integration is not
| within the Scrum guide, it is a common practice in Scrum
| teams. Yes, there is a concept of a sprint goal, but the
| sprint goal may be a subset of the product goal. You may
| choose to group increments across sprint boundaries to
| present to customers independently of the end of the sprint.
| prepend wrote:
| Scrum is not necessarily weekly. You can pick any period for
| the sprint length. I think I've seen two week as the most
| typical.
| teeray wrote:
| > My team chooses the characteristics of the sprint. It's not
| like they are randomly assigned...It's not like there's
| anything mandatory, so we set our release schedule and what a
| release means based on what makes sense.
|
| Count your blessings. This is not the case everywhere.
| freedomben wrote:
| If you are working in a place that lets your team pick the
| sprint length each time based on how long you think it should
| be for the work you're doing, that is absolutely _not_ typical.
|
| You seem to be either taking your anecdotal experience with
| what was called "scrum" and projecting it back onto the spec.
| Or, redefining "scrum" to be what you think it _should_ be, not
| what it _is_. Incidentally, I find nearly everyone who defends
| scrum does the same thing. It 's a continual No True Scotsman
| that gets to the point where "scrum" becomes meaningless. I
| actually blame the Scrum people for that because there's a ton
| of things that are guidelines rather than rules, although the
| ultimate decision is with the ScrumMaster or PM, so the level
| of flexibility of the Scrum implementation is dependent on the
| benevolence of this ScrumMaster(r).
|
| I worked as a consultant for several years and have been at
| many different startups, so I've experienced a lot of different
| flavors of Scrum, and the effectiveness varies widely. There
| are Scrum implementations that are authoritarian hell-holes
| where devs are just mice on wheels, and there are some that are
| pretty good. The problem is, both are still "scrum." So it's a
| lot like saying "monarchy is good" or "monarchy is bad." Well,
| it depends a lot on the monarch, but the system itself gives an
| enormous amount of control to one (or a few) people, and then
| it's up to that person to divvy out autonomy as they see fit.
| You might get a benevolent ruler who gives autonomy, but you
| might not, and both fall under the system.
| prepend wrote:
| I've never had variable sprint lengths, but picking the
| internal is exactly how I've done agile for years.
|
| The whole point, I thought, is that you're just frequently
| releasing so you want some fixed interval rather than
| adjusting it based on workload. Pick work that fits into the
| time period, not the other way around.
| rickdeckard wrote:
| I don't know which process you follow, but while sprints are
| created in collaboration, in mid/large organizations everything
| is supposed to be in-sync across departments (so you can align
| interdisciplinary tasks).
|
| In most cases I've seen, Agile basically introduces an
| additional company-internal clock with tick-tocks for days and
| weeks.
|
| To me the article correctly describes how agile is assumed to
| be somewhat abstracted from "real-world" time, but in reality
| it's just two other hands on the same clock with pressure and
| tasks still increasing close to "real-world" clock-events
| (launch-dates, exhibitions, customer-events,...)
| nottorp wrote:
| Hmm I think 95% of the conversation in this thread can be
| summarized as:
|
| Person 1: Scrum sucks at my job because X, Y, Z.
|
| Person 2: That's not the ideal spherical cow! Sorry, it's not
| "real scrum".
| Pet_Ant wrote:
| Well I think that comes from top-down micro-managing
| organizations that just want to call themselves "scrum". They
| want to do what they want to do and will dress it up in
| whatever language is buzzword compliant.
|
| A director of engineering flat-out told me that being self-
| organising wasn't part of our scrum because we couldn't
| guarantee that each team made the same decisions and we needed
| developers to be interchangeable between teams.
| kristjank wrote:
| It's the "but it wasn't real communism" of the software world
| typeofhuman wrote:
| Person 3 (me): what's your proposed alternative - considering
| all stakeholders?
| filoeleven wrote:
| Rich Hickey put it best.
|
| "What kind of runner can run as fast as they possibly can from
| the very start of a race? Only someone who runs very short
| distances. But we're programmers, we're smarter than runners. We
| know how to fix that problem, we just fire the starting pistol
| every hundred yards, and call it a new sprint!"
|
| https://youtu.be/liUiRfN9NzQ?si=CRkbMokVLXLIdF42
| sevensor wrote:
| I would love to bring some scrum masters down to the local high
| school track and have them run back to back sprints until the
| message sinks in.
| lo_fye wrote:
| The Scrum Master is supposed to be part of the team,
| constantly helping with the Sprint, whether that's getting
| clarification for you, or pushing back on unrealistic
| expectations, or getting more resources, or whatever. Sprint
| was a bad choice of terms. It shouldn't have been related to
| races at all. If anything, it should be more like walking.
| It's about figuring out what pace is sustainable for your
| particular team, and sticking to that pace. Not driving
| anyone too hard, but delivering value (i.e. working software
| features and updates) at regular intervals. If a feature is
| too big to deliver in a single increment of time (Sprint),
| then it should be broken down into multiple features that
| build upon one another to eventually be the whole thing.
| sevensor wrote:
| Why should we give them a pass on the metaphor? If that's
| not what they mean, they can use different words. It's
| telling that they don't.
| bunderbunder wrote:
| Yes, sure, all of that. But also, my boss's boss and my
| boss's boss's boss are looking at velocity and continually
| asking for more. They've got dashboards for it. Managers
| have to answer for why their team's velocity is different
| from another manager's team. Et cetera.
|
| You can say "don't do that that's not how it works" until
| you're blue in the face, and it will still happen.
|
| That's the critical failure of Scrum: it's one giant
| managerial dark pattern that's full of enticements to abuse
| it. Those enticements are constant. The exhortations to not
| do it that way are buried in the fine print somewhere, and
| the only reminders about them are coming from disgruntled
| individual contributors, probably from lower-performing
| teams, whose opinion is therefore suspect. The managerial
| opinion is probably that they should stop whining and make
| the deadline already.
|
| I keep wishing we could instead have an agile framework
| that works with human nature instead of fighting against
| it.
| randomdata wrote:
| _> I keep wishing we could instead have an agile
| framework that works with human nature instead of
| fighting against it._
|
| What you describe is human nature. Any framework that
| tries to work with human nature will end up there.
|
| A framework that successfully fights human nature is the
| only hope. But, can you really fight human nature? My
| guess is no.
| mech422 wrote:
| LOL - that sounds uncomfortably accurate :-)
| rickdeckard wrote:
| Great description on what happens especially in scaled
| organizations, where sprints/iterations are supposed to be in-
| sync across departments (so you can align interdisciplinary tasks
| etc.).
|
| In most cases I've seen, it basically introduces an additional
| company-internal clock with tick-tocks for a custom frame of days
| and weeks.
|
| Everyone acts like this is more consistent and somewhat
| abstracted from "real-world" time, but in reality it's just two
| other hands on the same clock, with pressure and tasks still
| increasing close to "real-world" clock-events (launch-dates,
| exhibitions, customer-events,...)
| lo_fye wrote:
| This article has Scrum all wrong.
|
| What they're talking about is a process that someone is calling
| Scrum, but is nothing of the sort.
|
| A real Scrum process can be modified at any time to make it more
| workable/manageable/realistic. The Sprint Review is FOR modifying
| the process.
|
| If Sprints seem to be never ending-stress, then you're self-
| selecting too much work for a Sprint. Yes, self-selecting. In
| real Scrum, everyone chooses what tasks they agree to get done in
| the next Sprint. You set your own pace, and it's meant to be
| sustainable and constant, unlike the pace in Waterfall work.
|
| "Every aspect of a sprint is prescribed: its duration, its
| meetings, its tasks, and even the roles of its participants" --
| yes, and prescribed by who? THE SPRINT TEAM! The people doing the
| work. You.
|
| "Autonomy--the ability to direct one's own work--plays a
| significant role in how work is experienced." -- the article
| stated this as an argument for NOT using Scrum, but that's
| exactly what Scrum is meant to provide you with.
|
| "In Scrum, programmers are like those mice subjected to
| involuntary effort, forced to run on treadmills of our bosses'
| making" -- In Scrum, you don't have a boss. Your team has
| members, and everyone who's part of the team does real actual
| work in the Sprint. Yes, you have a Scrum Master, but their
| entire job isn't to track your hours, or force you to commit to
| something -- it's to run the Sprint meetings, solve your
| problems, and anything preventing you from getting the work you
| committed to for the Sprint, done by the end of the Sprint.
| That's it and that's all.
|
| "Sprints Neglect Key Supporting Activities" - Really? That's
| weird, because the team working in the Sprint can specify what
| needs to be part of every task in the Sprint.
|
| "There's no time is set aside for proper engineering prep work."
| -- Scrum is about constantly delivering value to the client. If
| you need to figure out the best way to do something, and can't
| manage to produce any working code while you do that (doubtful)
| then you can at least say you'll provide the client with a Report
| on your findings, and why you're going to proceed with Route A
| over Route B. And as I said before, if there's no provision for
| that, make one! or do it in Sprint Planning. If you're part of
| the Sprint Team, you're in control of your process, and if it's
| not working, it's your fault, and your responsibility to help fix
| it. Maybe if someone normally does 20 points of work per Sprint,
| but they need to plan a lot this Sprint, then if the Sprint Team
| is ok with them delivering only 10 points of client-facing
| working code, but also 10 points of valuable research, then
| that's ok! You can also do a lot of this planning (at least at a
| basic level) during Discovery with the Client, even if the Client
| is internal.
|
| "There's always a Waterfall-like, big-bang deadline quietly
| lurking in the background" -- You have been betrayed by all of
| the companies you've ever worked at who said they were doing
| Scrum, because they weren't. They were doing "sprint until you
| die", which isn't an actual process, but is how a lot of places
| work.
|
| "The business side just can't help itself" -- your Scrum Master
| needs to go to bat for you. The Business Side should only be told
| about features that have been completed, or are about to be
| completed, not about upcoming features except to say that "It's
| on our roadmap, but I can't tell you for when".
|
| "With sprints, there are no breaks, little autonomy, and
| insufficient time to prepare." -- True (but the pace is self-
| managed to be sustainable), False (Scrum is all about autonomy),
| & False, as stated above.
|
| "Let developers control both their craft and their process. Treat
| them as respected peers, not replaceable cogs in a machine." --
| Did your Scrum team miss the memo about the people that comprise
| the team is a crucial aspect of the team? A Scrum team should be
| 100% self-contained, and be comprised of all the people it needs
| to be able to get the job done. This means from architecture, to
| UX/UI, to coding, and design." -- If you don't think the unique
| individuals on the team matter, you're dead wrong.
|
| "Achieving these conditions will likely require grassroots
| efforts" -- yes, and that's how Scrum came about! It's literally
| solving what you're complaining about... except that companies
| have misused its name and implemented it so incorrectly that you
| now think it's the problem not the solution. How did this happen?
| Developers found out that Agile and Scrum were amazing. They were
| a much better way of working, that was sustainable, and
| fulfilling, and dare I say fun. They started quitting places that
| didn't do Agile or Scrum, and only applying to places that did.
| Shitty companies couldn't hire any good developers, so they
| started saying they "Do Agile". They started getting applications
| again. Only problem was, they already had a corporate
| infrastructure that didn't support Agile or Scrum, so you'd start
| noticing little things like "Hey, why is my Scrum Master asking
| me how many hours I've spent on a task instead of asking me what
| they can do to get barriers out of my way?" -- and this went on
| until the Agile and Scrum that companies professed to be
| practicing didn't resemble actual Scrum in the least. It was a
| bait and switch.
|
| Scrum is a process designed to help you continuously improve your
| own process, while always delivering value to the Customer along
| the way. That's it. Dead simple.
|
| Here's Scrum in a Nutshell:
|
| Sprint Planning: Make sure everything in the Product Backlog has
| estimations attached. If not, estimate them now. Make sure you
| know your own personal velocity. Then each person answers: What
| work can each of us realistically commit to have done, for sure,
| by the end of this Sprint?
|
| Daily Standup: (Each person answers) What did you finish since
| the last standup? What will you finish before the next one? Is
| there anything slowing you down?
|
| Sprint Retrospective: (Present to Client) We finished all of the
| work for the Sprint. We will now demo it for you. [demo it] How
| do you like it? Any feedback? Do you like the list of tasks we
| have scheduled for the next Sprint, or would you like to
| reprioritize it? Thanks, see you at the next Sprint Retrospective
| meeting.
|
| Sprint Review: (Team Meeting) What do you think went well? What
| do you think could have gone better? How do we want to change our
| process to reflect these?
| xbar wrote:
| Do Agile without Scrum.
| hydrogen7800 wrote:
| As a mechanical engineer I love lurking here because you software
| folk have a way of classifying and describing a technical
| workplace that I don't find anywhere else on the web.
|
| I was recently part of a program for ~2 years that was
| essentially in perpetual sprint mode. We never had time to stop
| and consider the impact of decisions, because requirements were
| constantly shifting beneath our feet. All the tasks and sub
| tasks, and their interrelated nature was haunting my dreams. I
| would have sudden panicked realizations in that brief window of
| clarity before bed that I forgot or missed something.
|
| There was always an acknowledgement among all in the (virtual)
| room during calls that the problem was outside the room, or that
| "yeah this sucks, but it's the least bad way to run the program"
| or something like that. The technical problems were interesting
| to me, but not enough to sustain my motivation through that.
|
| "Sprints, on the other hand, are fake deadlines". Amen. As a
| result of what I described above, it was hard to take these
| "deadlines" seriously.
| typeofhuman wrote:
| We all know these problems.
|
| What's the solution?
| borvo wrote:
| When agile first started it was developer centric and brought in
| the ideas of continuous improvement, inspect and adapt,
| eliminating waste (handoffs, extra communication etc). One of the
| core ideas was to look at what was working/not working - if it's
| not working you drop it. Then we got the scrum cult. Ironically
| it has led to a huge amount of wasted time and effort, as well as
| stressed devs. In a lot of cases these extra processes get added
| by well meaning people who don't look at the whole system of
| work. If you can't drop what is not working then it's not agile.
| randomdata wrote:
| If a team has reluctance to drop something where you see a need
| to drop it, it is _you_ who is not working. Will you drop
| yourself?
| pragma_x wrote:
| When managing a project scrum I stick to a few things that have
| worked well for me.
|
| - Make it clear that the name "sprint" is a bad one. This is
| marathon. Encourage maintaining a steady pace and do not become a
| party to burn-out.
|
| - Use Agile pointing methodology by the book.
|
| - Standups are for communicating wins and blockers; your overall
| general status is not useful to the rest of the team and makes
| the standup go long. Project chit-chat, problem-solving, and
| talking about wins, is for afterwords or completely different
| meetings.
|
| - Defend the team from management's attempt to deconstruct points
| into hours, days, or any other more conventional metric; Agile
| exists to neuter these anti-patterns, and the points exist only
| to figure out what gets done in a "sprint" interval. Offer
| velocity tracking and focus on results instead.
|
| - Defend the plan and the team from all stakeholder asks, and
| make it clear that adding to an existing plan also means taking
| other tasks away.
|
| - Carefully triage emergencies, bugs, into the plan with
| stakeholder consent and involvement.
|
| - In fact, everything for Scrum is just triage, including
| features. Mark everything with a relative priority, even the
| normal things.
|
| - Celebrate every single last win, no matter how small. There are
| no victory ceremonies in the standard Agile Scrum playbook; this
| is on project leadership to address and absolutely must be done
| without fail.
|
| If done well, the project says on a relatively even keel for the
| duration. Using Agile for evil, by instilling a false sense of
| urgency every two weeks, will burn your team out faster than any
| Waterfall crunch ever could.
|
| Here's where people get this all screwed up: Agile methodology
| requires constant communication between the team and
| stakeholders, leaving the PM/Lead to play goalie for the
| project's run. That leader must be comfortable saying "no" to
| anyone/everyone, manage stakeholder expectations at regular
| intervals, and must have a keen sense of how to break down a
| project's deliverables into achievable increments. In short: this
| person must be both technically and socially adept.
|
| If that doesn't sound like your lead or organization, Waterfall
| may be a better move. It pushes a lot of this communication and
| negotiation to the planning phase, before any engineering work is
| done. In the case of contracting, it also escalates project
| change to a legal process, which can blunt/halt the influence of
| meddlesome forces. It's also possible to avoid big crunches and
| burnout, if (and only if) your project management has a clue and
| is dogged about milestone due dates. Overall, it pushes the
| bigger social aspects to a preparatory phase which can be
| executed by different personnel than the team that implements the
| product.
| tcgv wrote:
| A lot of the criticism here comes from people who had bad
| experiences with poor managers, leading them to reject the idea
| of work processes altogether.
|
| The few defending Scrum are doing so based on positive
| experiences with great teams and strong leadership.
|
| In my view, high-performance teams don't just appear by "hiring
| good people and letting them do their thing." Good people
| naturally communicate, take initiative, prioritize, estimate,
| provide updates, and mentor less experienced team members. In
| other words, they often follow a pseudo-process or even suggest
| routines that resemble a formal process, if one is not already in
| place.
|
| Alignment, communication, transparency, and prioritization are
| key to achieving results. Processes should be designed to support
| these, providing space for creativity and autonomy, including
| review and constant improvement of the process itself.
| moominpapa wrote:
| Once upon a time, ivory tower "programmers" met in a cafe or
| something and grandiosely produced a manifesto called Agile and
| unleashed merry hell for poor souls who just want to produce
| something that works. Instead they must listen to managers who
| haven't written so much as "hello world", tell them how it should
| be done. I don't care of the intentions, it has been coopted into
| corporate micromanagement and busy work for deadwood corporate
| lifers. Enough, the original authors need to get back in that
| cafe and explain where it went wrong.
| nyxtom wrote:
| Every now and then I enjoy the opportunity to build things
| without planning around them. No ceremony, no tickets - just pure
| code and building things people are interested in or are looking
| to solve problems.
___________________________________________________________________
(page generated 2024-09-16 23:01 UTC)