[HN Gopher] The age of Scrum is over
___________________________________________________________________
The age of Scrum is over
Author : firstSpeaker
Score : 119 points
Date : 2022-05-27 18:56 UTC (4 hours ago)
(HTM) web link (chrisjameslennon.medium.com)
(TXT) w3m dump (chrisjameslennon.medium.com)
| adrianmsmith wrote:
| So what will come after Scrum? Is anyone here working in a "post-
| Scrum" world? What does it look like?
| c3534l wrote:
| Agile, but reinvented, until it becomes full of gurus, coaches,
| and certifications, at which point we will declare it dead and
| continue to reinvent the saming manfucturing system we've had
| since Deming in the early 1950s.
| lucisferre wrote:
| I've been working in a "post-Scrum" world I suppose in that I
| have not used it prescriptively for software development in a
| very long time.
|
| It isn't terribly exciting stuff. Simply remove the unnecessary
| ceremonies and "rituals" and instead focus on practical and
| effective solutions to the problems you actually have.
| Continuously try out new ways of building the software better,
| measure your results, continue to improve. The heart of the
| agile manifesto I suppose.
| adrianmsmith wrote:
| > measure your results ... The heart of the agile manifesto I
| suppose
|
| That's an interesting one. I don't know if Scrum teams I've
| been part of are doing this wrong, but I have seen a shocking
| lack of measurement going on. Much less than with even
| waterfall.
|
| Whereas with a waterfall approach from decades past one might
| have a deadline and know if one has hit it or not, or a
| budget and know if one has overrun or not, the product
| managers at most Scrum teams I've worked with recently
| wouldn't be able to tell you what % of time is spent in Scrum
| ritual meetings, whether the project is overrun or not (as we
| only plan one sprint ahead, and the project is going to take
| more than one sprint), what % of time was actually spent on
| what project in the last sprint (or over the last quarter),
| what % of time was split between requirements, dev, ops, or
| any other task, etc.
|
| Has your experience with agile been different? Or am I
| misunderstanding what you mean by measurement?
| jpswade wrote:
| The most important part of scrum and the only part that is
| important is retrospectives, because it allows the team
| opportunity to step back and make changes to their processes.
| Everything else is mostly arbitrary. Want to stop doing stand ups
| or change how you manage work? Go for it, nobody is stopping you.
| Do what works for you.
| krzyk wrote:
| In every new team, on first retrospective I test it with a
| simple: let's get rid of retrospectives (followed by: let's not
| make demos). If it passes the manager, this is a true retro -
| never happened.
| xcambar wrote:
| As a manager, I'd just think you're being provocative and
| short-sighted.
|
| As an IC, I'd think you're big-mouthed, in a bad way.
|
| In any case, even if you were right, I'd be the kind of
| colleague you'd have to work your way up to retrieve trust
| after such a stunt.
| iostream24 wrote:
| What is an IC?
| ldjkfkdsjnv wrote:
| Never seen anything useful actually come from a retrospective.
| There are open and interesting conversations about what went
| wrong/could be done better, but those discussions never
| materially change the team. Generally people are who they are,
| the work is what it is. How the team will be is relatively
| static given the same set of people and projects.
| latchkey wrote:
| This is why Pivotal Labs would rotate people on teams quite
| often. Nobody gets "stuck" doing the same thing endlessly.
| cableshaft wrote:
| I have the same experience with retros. Generally they've
| have been a waste of time. Any useful information that could
| have been gleaned from them were probably already had in an
| earlier discussion, tend not to be remembered to be brought
| up again in retros, and at least in the teams I've been on
| the minutes from the retro meetings don't get recorded
| anywhere anyway, so there's nothing to refer back to in the
| future.
| pas wrote:
| it seems these teams lack(ed) the drive to consciously
| change.
|
| meetings should have conclusions (action items based on
| consensus, which are commitments from all members) and it's
| a typical team dysfunction when members don't honor
| commitments (someone doesn't do something and then others
| don't bring this up to hold each other accountable)
|
| if the team is so dysfunctional that it just does the same
| thing over and over again while constantly promising to
| change then it should be broken up before the members
| themselves start to suffer the psychological toll of this
| cognitive dissonance.
| arnvald wrote:
| Interesting, I have a very different experience. My team does
| retrospective once a month (we don't do Scrum, so it's not
| tied to "sprints") and every month we actually do some
| improvements.
|
| Sometimes the problems are small, let's say our products have
| inconsistent CLI interfaces for developers, and that slows us
| down, so we decide to unify it. Sometimes it's big stuff, for
| example the team feels that we don't have enough clarity
| about long term of the product, or there are too many
| interruptions. Then it's my (EM) or PM's role to figure stuff
| out.
|
| Some of the good things we changed as a result of retro: we
| removed stand-ups, we agreed to meet in the office once a
| week, we introduced a daily support rotation for our users
| (we build internal tools). We can't fix everything, but every
| month we get something done, and that keeps the team
| motivated to bring new ideas to retros.
| latchkey wrote:
| You are right.
|
| I miss Friday's at Pivotal Labs where we went as a team to a
| conference room and wrote a happy face, meh face and sad face
| on the board.
|
| We wrote out things that happened during the week under each
| column. Everyone votes for what they want to talk about and the
| items with the most votes get discussed first.
|
| Doing this religiously helped with team cohesion and allowed us
| to develop better products together. Those 30 minutes were a
| great way to end each week and set us up for a productive new
| week on Monday.
| lostcolony wrote:
| That is also the only meeting (or doc; communal collaboration)
| prescribed by the Agile manifesto.
|
| People get so caught up in the process trappings of "agile"
| they miss the point.
| lcfcjs wrote:
| probotect0r wrote:
| In my experience, most retro meetings I have been in start with
| the scrum master asking things like "what did we do well this
| sprint?", followed by complete silence from the team until
| someone points out a non-point like "we collaborated well...".
|
| One team I worked on decided to not pre-schedule retro
| meetings. Instead we had a 'retro board', which was just a
| section of a white board where team members would write down
| specific things that they think would be worth discussing in a
| future retro meeting. The team would decide to hold a retro
| meeting once the board had accumulated a few things to talk
| about. We found this approach was super effective because we
| knew what we needed to discuss when we held the meeting,
| instead of waiting for team members to recall something to talk
| about.
| corrral wrote:
| That's how it works in well-functioning agile teams, but in
| "Agile" teams the team can't decide on their own to e.g.
| totally ditch standups. Management won't allow it, or they've
| set up the project manager to be God of Agile and they get last
| say on that kind of thing, and so on.
|
| "Agile" teams outnumber agile teams by a large margin.
| digisign wrote:
| I've tried to explain several times to a client that 20-25
| people is too many for a standup.
| corrral wrote:
| My "favorite" is when they mix teams working on unrelated
| things in the same standup. That sucks no matter how many
| people are in the meeting (thought obviously it's worse the
| larger the attendance)
| quickthrower2 wrote:
| The advantage if this is you have now 20 bored people
| waiting their turn to spit out a sentence. As they tune out
| their subconscious mind figures out an elegant solution to
| what they were suck on.
| henrikschroder wrote:
| If you have a good team with good people, it doesn't matter
| much which process you're following, because shit will get
| done anyway.
|
| Agile was a way of trying to document how some good teams got
| shit done, but most of the companies and people trying to
| implement it didn't understand that you actually need good
| people, they thought it was the process, and thus "Agile" was
| born.
|
| ...and to the _complete mystery_ of everyone involved,
| "Agile" teams don't get shit done.
| Silhouette wrote:
| This is painfully true and also deeply ironic given one of
| the lines in the Agile Manifesto itself.
| quickthrower2 wrote:
| Good people but not just that. Good culture, good
| management, good business model / funding, and a good
| sprinkle of luck.
|
| And what makes them high performing? What is the metric?
| Money?
| g051051 wrote:
| That's how it works in well-functioning teams, period. Being
| "Agile" or "agile" has nothing to do with it.
| flir wrote:
| You need measurement too. You need a way to measure the success
| of the change that was agreed on in the retrospective. Story
| points, LoC, tickets, whatever.
| ratww wrote:
| The most important part is making the changes to processes.
| Sure, retrospectives are part of it, but when retrospectives
| become just a place for the team to air their grievances but
| all suggestions are blocked by management, it is hell on earth.
|
| "Having no process at all" beats "Performative Scrum".
| _the_inflator wrote:
| I agree. I see retros as the only time, a team as a whole
| sits/works together for around 2 hours at a time.
|
| My advice: treat retros as a way to check in with your team or
| the team itself. Sometimes, if there are no pressing topics,
| just talking and chilling can be the best use of the time.
| WhiskeyTang wrote:
| I completely agree. I was a certified scrum master, scrum
| master of a team of 6 for 2 years, and was directly coached by
| an external (and expensive) scrum consultant. We got pretty
| deep into the scrum process, even going so far as to estimate
| and track the number of hours each task would take. After all
| of that, my takeaway is that thoughtful, engaging
| retrospectives are the only scrum "event" or process that a
| team should do. Want to do a stand up meeting only once a week?
| Go for it. You think pointing stories is a waste of time? Cool,
| spend that hour coding instead. But you have to regularly check
| in and make sure your process is actually working, and then put
| some effort into improving it.
|
| Also, don't forget to retro your retros. Maybe a 2 hour meeting
| twice a month is a waste of time because your team is already
| great at providing feedback and trying new things naturally.
| Getting rid of the meeting might be the best thing as long as
| there is a viable alternative way for everyone to provide
| feedback and suggestions.
| pas wrote:
| how did you estimate hours? do you mean that the team
| estimated "story points" and it was so precise _and_ the team
| was so good at meeting the per-sprint point load that it was
| basically a nice hour estimate? or did you estimate hours
| directly?
| adrianmsmith wrote:
| I find one problem with retros is they violate the principle of
| "praise in public, criticism in private". People instinctively
| understand that and thus there tends to be more praise.
| Everyone hears themselves praising the process and thus start
| to believe it actually is good. Therefore more Scrum gets done,
| no matter if it's actually good for the team or company or not.
|
| Recently I went to a retro where the positives were listed as a
| great team, great accomplishments in the last sprint, thanks to
| person X for going the extra mile, and so on. When it came to
| discuss the negatives, the main one was "the meeting room was
| hard to find".
| zerr wrote:
| In my several years of experience of participating in
| retrospectives at two different companies/teams - it's a total
| waste of time. Just one of the ceremonies for keeping "Agile
| Coaches" employed.
| spelunker wrote:
| IMO I think it depends on how the team handles it. The team
| I'm on tends to oscillate between "useless meeting" and
| "agent for change". I think if there's nothing to talk about
| why have yet another meeting? Perhaps we'll implement a straw
| poll about actually holding retrospective... I'll bring it up
| in the next retro of course.
| legulere wrote:
| Retrospectives don't help when your problems are external and
| you do not have influence on them. If you get how much needs to
| be done and what needs to be done set fixed from outside the
| team cannot do much about it. And that what scrum often ends up
| in a lot of companies: all the responsibility when things go
| bad but none of the autonomy that would be needed.
| muaddirac wrote:
| I've noticed a related effect, where every problem discussed
| in a retro has a "process" solution, because the team's own
| processes are the only thing the team can fully control.
|
| This can lead to both a constant churn in processes and a
| piling on of additional processes, which bog the team down
| with an explosion of on-call-like rolls that get rotated
| through team members.
| JTbane wrote:
| >The most important part of scrum and the only part that is
| important is retrospectives
|
| That's funny because my "scrum" team doesn't do retrospectives
| at all, we just focus on long planning sessions every sprint.
| We are fully scrumfall.
| SkyPuncher wrote:
| Everything needs to reflect to the team's needs. I'm a very big
| advocate of scrum, but I rarely have my teams run pure scrum.
| One thing I absolutely love is introducing the concepts of
| sprints and watching conversations switch from bickering about
| single day deadlines on a multi-week project to "sounds like
| it'll take X sprints".
|
| There are essentially two times you should try to follow scrum
| perfectly:
|
| * During a fire/emergency. This should be rare. It helps keep
| the response moving without unnecessary overhead. Yes, the
| meetings are overhead - but they often cut out other other
| head.
|
| * When gelling a new team. Scrum is really helpful in getting
| the team to mesh quickly. Routine contact, flexibility, small
| iteration, all good stuff.
|
| Outside of that, roll scrum back to match the team. For us,
| that's:
|
| * Bi-weekly retrospectives.
|
| * 1 to 3 standups per week (depending on the team's need)
|
| -----
|
| Basically, we ask for 4 hours of people's time over 2 weeks. We
| find this ends up saving well over 4-hours of 1-off and random
| meetings.
| Gunax wrote:
| I did retrospectives at a job for 2.5 years.
|
| I don't think in those ~60 retros, was there one thing we
| actually changed or accomplished.
|
| Certainly much griping happened. But ultimately very little
| couod be accomlished, because our problems were beyond the
| team.
|
| I would love to see retrospectives that worked, just to know
| what they are like. But so far I mostly see people forced to
| contribute to the retro, which results in:
|
| 1. Generic pats on the back for every minor thing we did.
| 'Really good job releasing feature X!' 2. Lot's of social
| compliments and jokes. 'X joined the team! Yay!' 3. Problems
| that we know about, but aren't tractable. 'The database schema
| we made 10 years ago really sucks!' but fixing it isn't
| practical.
| lostcolony wrote:
| So there probably were some things during that time the team
| could change, even if it was out of pure pragmatism (i.e.,
| "well, raising this issue led to a bunch of busy work. Let's
| not raise that kind of issue any more"). But even if not,
| there certainly was benefit just agreeing "yeah, this is a
| problem we can't address", since that builds a stronger team.
|
| That said, the situation you describe gets solved by the org
| adopting a retro itself. The team lead raises the broader
| issues up at a retro with other stakeholders/higher level
| management/etc, who -can- fix it.
| superfrank wrote:
| I disagree... kind of.
|
| Every team is different and will have different strengths and
| weaknesses. Scrum should act as a framework to get your team to
| do the things it's not doing, but it should be doing. The most
| important parts of scrum are the ones that align with your
| teams weaknesses. If your team is already good about giving
| feedback to each other and trying new things to improve retros
| may be completely unnecessary. If your team just carries on
| doing that same old things because "that's the way it's always
| been done", then retros could easily be the most important
| part.
|
| One of my favorite teams I ever worked on was great about
| giving each other feedback and trying new things. Retros were
| completely unnecessary because we were great about giving
| feedback in the moment. Stand ups were super important on that
| team though because we didn't have an EM and our PM was
| completely checked out, so everyone just kind of did what they
| wanted. If we didn't check in regularly it completely possible
| for stuff to fall through the cracks or get forgotten.
|
| The team I'm on now, retros are super important because
| everyone is super agreeable and will hold in complaints. Sprint
| planning on the other hand is almost completely unnecessary
| since we have a bunch of long running one person projects that
| will get done when they get done. Each sprint is basically just
| everyone going, "I'm continuing what I was working on last
| sprint".
|
| Figure out what the goal of each piece of scrum is. If your
| team already does that well, throw the process away. Scrum (for
| your team) should be what is left. Repeat occasionally since
| teams and people change.
| BlargMcLarg wrote:
| >If your team just carries on doing that same old things
| because "that's the way it's always been done", then retros
| could easily be the most important part.
|
| This tends to happen even with retros. Retros assume a lot of
| things about a team in order to work which just don't hold
| for a vast majority of teams.
|
| That's the problem with almost every methodology. They make
| assumptions on how a team _should_ work in order for the tool
| to do its job. If the team doesn 't work that way, it's the
| teams fault. You obviously can't blame a tool, but a tool
| isn't particularly useful when it doesn't solve the problem,
| either.
|
| Example for retros. They solve agreeableness and bottling
| things up, _in theory_. In practice, a lot of people stay
| agreeable and continue to bottle things up. They don 't want
| to share frustrations. Maybe they try a few times, only to
| notice what they say doesn't really affect the future,
| leading to more frustration than just not saying anything.
| Which then puts the time spent doing the retrospective in
| question, or worse, it causes frustration because it keeps
| individuals from burying their problems. There are so many
| ways retros can be a big nothing burger, none of which are
| inherently the problem with retros.
|
| Then someone comes along saying "have you tried this". No
| Captain Obvious, I haven't tried using a coconut to smash
| against the wall instead. I'm sure it will break now, and I
| won't risk getting coconut splinters in my face.
| superfrank wrote:
| First of all, I hear your frustration. I've been a part of
| way too many teams that just do things for the sake of
| doing them. It sucks when it seems like no one else cares
| or will even acknowledge that it's a waste of time.
|
| I'm not trying to push any particular part of scrum on
| anyone. My point was that I think teams should look to
| agile as a bunch of suggestions and should change or remove
| things as they see fit. If it's not working, scrap it. If
| retros assume your team works in one way, and your team
| doesn't work that way, change how your team does retros or
| don't do them.
|
| Hell, at one company I worked at that was going through a
| particularly rough transition, we moved our "retros" to 3pm
| on Friday, brought beers, and by the 15 minute mark it was
| usually just a bitch-fest about everything that was going
| wrong at the company. They weren't the most productive
| retros ever, but it was what the team needed at that time.
|
| > Example for retros. They solve agreeableness and bottling
| things up, in theory. In practice, a lot of people stay
| agreeable and continue to bottle things up.
|
| I disagree. From what I've seen, people are a lot more
| willing to speak up if they know they're not the only one
| feeling that way. It's easier to "yes and" someone else's
| complaint that speak up on your own. I just ran our retro
| today, where one of the more quiet members only had
| positive things to say until one of the other members of
| the team mentioned how they were having trouble getting
| reviews on PRs in a timely manner. Once that was out there
| the quiet team member was happy to hop in and share her
| issues around the same thing, but I doubt that would have
| happened if someone else hadn't "popped the cork".
|
| > Maybe they try a few times, only to notice what they say
| doesn't really affect the future, leading to more
| frustration than just not saying anything.
|
| This sounds like the real root of your problems. If nothing
| is coming from your retros, I can see why you would be
| frustrated (I would be too). Our retros end with us going
| over the list of action items and assigning owners. Our
| next retro then starts with us going over that same list
| and seeing who got what done. For my current team that
| works really well and we've actually had some pretty great
| things come out of our retros because of it. I'm not trying
| to push that on you, but just giving an example of what
| works for us.
|
| I hope I don't come off as offensive, but it really sounds
| to me like your team is pretty dysfunctional. I'm not sure
| there's really any process to get around that. Saying
| retros are useless when no one on your team cares is kind
| of like saying power steering is useless when your car is
| on fire.
| conradfr wrote:
| What's the point of even doing "sprints" then?
| superfrank wrote:
| Can you elaborate further? I don't understand what part of
| my response this is directed at.
|
| Edit: Nvm, I figured it out. I assume you're referring to
| this?
|
| > Sprint planning on the other hand is almost completely
| unnecessary since we have a bunch of long running one
| person projects that will get done when they get done. Each
| sprint is basically just everyone going, "I'm continuing
| what I was working on last sprint".
|
| Honestly, not a ton. If we worked in isolation, we could
| probably drop them and little would change for us. The
| value that I feel like they bring are:
|
| - It forces developers to agree on and commit to a certain
| amount of work for those two weeks. If a dev says, I'm
| going to do these three things and two weeks later they're
| not done with #1 it's a red flag. They may have a totally
| legitimate reason, but it at least forces us to ask the
| question.
|
| - Kind of in the same thought process it helps us break
| month long projects down into smaller deliverables and
| communicate the status outward. We could easily do this
| without sprints, but some sort of break down is needed, so
| why not sprints?
|
| - Other teams are doing more traditional sprint planning,
| so it gives us all a common language to communicate in. If
| we need something from another team, being on the same
| schedule as everyone else is nice.
|
| - Our release schedule is tied to sprints. Without sprints
| it'd be much harder to keep track of what is going out
| when.
|
| Just to give more detail, we do have a sprint planning
| meeting, but it's basically just all of us meeting and
| saying what we're working on in the next sprint. Like I
| said in my original comment, we took the parts that worked
| for our team and threw away the rest.
| usr1106 wrote:
| The whole terminology shows an attitude hostile to
| employees, just squeezing out the last drop of juiceout of
| them. Nobody can sprint all the time, sometimes you just
| need to walk slower.
|
| I think I have seen 3 types of people
|
| * some get cynical and just don't care about the sprint
| goals. What doesn't get done this sprint gets carried over
| to the next one
|
| * others really want to get ticked off everything. So they
| compromise on quality, pile up technical debt. Eventually
| they hope the project will be closed or they move one.
|
| * 3rd category burns out themselves. This can end badly, I
| have seen suicide attempts, people disappearing from their
| family and of course sick leaves and quitting their jobs.
|
| I don't think planning every 2 weeks is a bad thing. It
| just makes sure that plans get reviewed, updated, and
| refocussed frquently enough. Whether the goals have been
| reached or not I don't care that much. Retros are often a
| waste of time. Yeah, we underestimated something. We forgot
| a task. Unforeseen customer support suddenly had higher
| priority. There is always some reason why things went
| differently, despite all intentions to do it better every
| time.
|
| Edit: No I don't think all sprints go just completely
| wrong. But there is always something that didn't work out.
| Maybe 30% on average? With my current team we try to mostly
| look at the 70% that we got done reasonably well and then
| we move on carrying over what still needs to be done.
| villuv wrote:
| In my (20y+) experience, as soon as a methodology/process gets a
| name for itself, it has lost its original meaning and starts
| undermining the productivity. At that time all sorts of
| consultants crawl out of the woodwork and start converting
| companies to that process. Making good money of course. After
| that, following the process becomes more important than whatever
| the actual product is. Turning a large corporation into a new
| process takes years. Lots of documents created and new roles with
| funny names etc. And then someone invents a new cool process....
| In my opinion, the basics is just to plan ahead only as far as
| realistic, communicate freely and directly in all levels
| including customer, document what makes sense, learn from
| mistakes and don't be afraid to throw away and redo things that
| don't work. Which, in my opinion, is pretty much the core of most
| of the processes anyway. But please don't start calling it with
| some name....
| mumblemumble wrote:
| Just yesterday, my team officially agreed to discard the last
| vestiges of our ailing Scrum practice. (Corporate requires us to
| use JIRA, and JIRA forces us to organize things into sprints, so
| there's that, but, even there, we've agreed to just do what we're
| going to do and pencil whip things to make JIRA happy.) I'm
| optimistic. The new plan is a loose high-level structure and a
| lot more room to experiment with our process and find what feels
| good. And a renewed commitment to do so. And a fresh morale
| boost. The transition will be difficult, but we will learn much
| and be better for it.
|
| I personally tend to defend Scrum as being overly maligned and
| often blamed for the consequences of misapplications. But that
| last sentence is a double edged blade. The truth is, the model is
| brittle and internally unstable, and it's difficult to get good
| results without constant vigilance to ensure the rituals are
| being performed correctly.
|
| (There's even an entire role just for doing that. It's the one
| with Scrum in the name.)
|
| And that's getting tricky in an increasingly distributed world.
| Online ticketing systems, for example, practically beg you to
| overload the tickets with extraneous clutter and paperwork that
| bogs you down. But you can't use the preferred sticky notes on a
| wall if you're not co-located. Story points basically don't work
| without planning poker (or similar), but planning poker is
| exhausting, and videoconferencing is exhausting, and nobody has
| much appetite for the exercise in self flagellation that is Zoom
| planning poker, so we all mentally and emotionally check out,
| which completely defeats the purpose of planning poker.
|
| Also, Scrum is meeting-heavy. We're spread across six time zones.
| We have precious few hours in the day when we can all meet at the
| same time, and we simply can't afford to continue spending them
| all on so many synchronous rituals.
| adrianmsmith wrote:
| Looking at one software development agency I worked with for a
| large corporate client, everyone wanted to use Scrum, but there
| was massive inefficiency (maybe it was just the way they were
| doing it, although I've seen such things a few different
| companies now). The project managers at the customer were bright
| and competent, as were the team. Nobody was lazy. So why did they
| decide to work that way, and why did they put up with it?
|
| I came to the conclusion Scrum offers two key advantages to the
| stakeholders on each side of a client/agency relationship:
|
| - In a large company, mistakes are punished more harshly than
| successes are celebrated. (Mainly because your competition for
| the next promotion are going to promote your failures.) So it's
| important not to get things wrong. The most certain way to not
| get decisions wrong is to not decide anything at all. By using
| Scrum and planning only a sprint ahead, and not having any long-
| term vision, they achieve that.
|
| - The agency is billing by time. The longer things take the
| better. If all their team spend 30% of their time on Scrum
| meetings (the amount I currently spend at my current employer),
| the manager of the agency sees that and isn't unhappy about the
| situation. Soon progress slows down and the customer requests
| more people get put on the project, the manager of the agency
| isn't unhappy about that either.
|
| So both parties want to use Scrum, therefore of course an
| agreement is reached and Scrum is used.
|
| It's not about delivering great software, or delivering it
| quickly, etc. Neither the middle manager at the customer nor the
| boss of an agency directly benefit from those things.
| baal80spam wrote:
| > In a large company, mistakes are punished more harshly than
| successes are celebrated.
|
| But isn't it _always_ the case? The reason being: "we
| succeeded as we expected - move on, nothing to see here" vs
| "something failed, we need to discuss and find out who is to
| blame!"
| m12k wrote:
| To me, Scrum has always been something of a paradox. The whole
| point of agile is to adapt the process to the team's needs - if
| you're doing dogmatic agile, you're not actually doing agile. But
| what Scrum seems to add on top of the agile manifesto seems to be
| mainly dogma.
|
| I like the term "just-in-time process". A team should have only
| the processes in exactly the amounts that provide value to the
| team, and no more. If a daily standup is found to waste people's
| time, don't do it, or do it less often. If team members are found
| to need to do more coordination, maybe other avenues of
| communication could be encouraged?
| mxuribe wrote:
| I see it similarly! A team should leverage only what helps it,
| and no more. In fact, i have quoted to teams (that are thinking
| how to adopt agile, scrum, whatever) some lines from Bruce
| Lee's Jeet Kune Do: "...I hope to free my followers from
| clinging to styles, patterns, or molds. Remember that Jeet Kune
| Do is merely a name used, a mirror in which to see
| "ourselves"...Jeet Kune Do is not an organized institution that
| one can be a member of...Again let me remind you Jeet Kune Do
| is just a name used, a boat to get one across, and once across
| it is to be discarded and not to be carried on one's back..."
| Some teams get it, while others just follow what a paid
| consultant suggested (based on tech zeitgeist).
| myth2018 wrote:
| The biggest problem is not in Agile itself, but indeed in the
| dogmatism of its practitioners. I believe that stems from the
| fact that agile methods became too "productized": there's a
| whole market of books, lectures, certifications, courses etc
| and lots of people willing to profit from it.
|
| Eventually it became a sort of a religion. If you question it,
| it's because you don't understand it; if it yields bad results,
| it's because you did it wrong; if it doesn't fit the dynamics
| of the rest of the company, it's because the company is
| immature. All the methods have known limitations and
| prerequisites. All but Agile, which is perfect.
|
| It's a ridiculous lack of empiricism for a discipline like
| software engineering.
| marcosdumay wrote:
| I don't think "eventually" is the right word there. It
| immediately became dogma, and the one most used description
| about people's implementation of agile was always "you are
| doing it wrong".
|
| Somehow the things in the Agile Manifesto never popularized,
| only those religions did.
| pydry wrote:
| If agile were christianity, scrum would be the catholic
| church - the institutionalized, rigid, dogmatic and
| hierarchical instantiation of the original vaguely specified
| & lovey dovey cult.
| manuelabeledo wrote:
| > The biggest problem is not in Agile itself, but indeed in
| the dogmatism of its practitioners.
|
| I feel that most people don't understand that larger
| corporations don't adopt Agile to benefit product teams, but
| to add a layer of measurability to the process that is only
| useful for middle and upper management to establish and track
| OKRs.
|
| Thus Agile may not be a failed idea, but it arguably fails at
| the implementation.
|
| Agile apologists seem to be disconnected from this reality.
| capableweb wrote:
| Most of the consultants/junior developers/managers and others
| who try to shoehorn "agile" into every process and team
| doesn't seem to have actually read the original "agile
| manifesto", which 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
| DreamFlasher wrote:
| > consultants/junior developers/managers and others who try
| to shoehorn "agile" into every process and team
|
| This is in itself a major point. Managers trying to put
| scrum on everything. This is my main hope for scrum passing
| away. I have seen it now several times companies deciding
| to use scrum for research projects, and after a year they
| all realize how bad of an idea that is.
|
| On the other hand so far I haven't worked for a single
| company that actually did scrum (despite claiming it). They
| all started by "adjusting the process" and removing the
| scrum master. Sure. You totally understood how this works.
| myth2018 wrote:
| I agree with you.
|
| But even the Manifesto has some points that make it
| impractical in many circumstances.
|
| To stick with a single example: is it safe to favor
| customer collaboration over contract negotiation when
| dealing with high budget projects? Changes in requirements,
| delays, reprioritizing in client's side, those are all
| things we know that may happen. How are we going to deal
| with them after you favored customer collaboration, and
| that collaboration doesn't exist anymore?
|
| Agile requires Trust. But trust is a fluid thing, and we
| must cope with its fluctuations.
|
| The client is cooperating? Good, let's get a bit liberal
| about some rules, but let's keep monitoring the situation.
| The team is mature enough to self-manage? Good, let the
| team manage itself, but keep an eye to see if things are
| still running smoothly as the time goes by.
|
| The biggest problem of Agile is that it takes Trust for
| granted and assumes that every single stakeholder wants the
| project to succeed, and shares the exact same definition of
| success.
| dasil003 wrote:
| These are good points, but trust is not a prerequisite
| only for Agile. IMHO all large-scale software projects
| require trust to create space for the team to figure out
| the right path. If trust is lacking, it needs to be
| established, but the actions and steps that need to be
| taken are highly contextual and outside the scope of the
| Agile Manifesto.
| dragonwriter wrote:
| > To stick with a single example: is it safe to favor
| customer collaboration over contract negotiation when
| dealing with high budget projects?
|
| Yes, but note that the client is _inside the circle_ ,
| not an external force, in Agile.
|
| > Changes in requirements, delays, reprioritizing in
| client's side, those are all things we know that may
| happen.
|
| Yes, that is specifically what the point deals with, _on
| both sides_. Favoring contract negotiation over
| collaboration is a very poor way of dealing with those
| things.
|
| (The X over Y statements in the Manifesto are not X
| instead of Y, but Y must be centered on supporting X;
| contract negotiation is necessary, but the terms must be
| framed to support collaboration rather than impede it by
| being inflexible for the kinds of things that are known
| to be likely to change over the time of the project
| development.)
|
| > How are we going to deal with them after you favored
| customer collaboration, and that collaboration doesn't
| exist anymore?
|
| If the need for collaboration was centered in contract
| negotiation, then that will be addressed.
|
| > The biggest problem of Agile is that it takes Trust for
| granted
|
| The biggest problem (though far from only) problem of
| Agile is that the authors of the Manifesto underestimated
| the degree to which people would misread "over" as
| "instead of", even given an _explicit_ admonition that
| that reading was incorrect, making the Manifesto terse
| and catchy, but ineffective in communicating it 's core
| ideas.
| skrtskrt wrote:
| If you don't protect yourself with a contract, another
| party will screw you 11 times out of 10.
|
| By all means collaborate, but put it in a contract too.
| ignoramous wrote:
| > _...team should have only the processes in exactly the
| amounts that provide value to the team, and no more._
|
| It is interesting to go to the origins of _scrum_ and its
| emphasis on the team and team-work for high-quality, low-cost
| product development.
|
| > _...companies in Japan and the United States are using a
| holistic method -- as in rugby, the ball gets passed within the
| team as it moves as a unit up the field. This holistic approach
| has six characteristics: built-in instability, self-organizing
| project teams, overlapping development phases, 'multilearning,'
| subtle control, and organizational transfer of learning. The
| six pieces fit together like a jigsaw puzzle, forming a fast
| flexible process for new product development._
|
| A radical scruffy setup that challenges both the status quo and
| the leadership of an org rather than confirm to any set
| processes and workflows.
|
| https://hbr.org/2016/04/the-secret-history-of-agile-innovati...
|
| ---
|
| Some more snipped excerpts:
|
| > _...under the new approach (in its extreme form) nonexperts
| undertake product development. They are encouraged to acquire
| the necessary knowledge and skills on the job. Unlike the
| experts, who cannot tolerate mistakes even 1% of the time, the
| nonexperts are willing to challenge the status quo. But to do
| so, they must accumulate knowledge from across all areas of
| management, across different levels of the organization,
| functional specializations, and even organizational boundaries.
| Such learning in breadth serves as the necessary condition for
| shared division of labor to function effectively._
|
| > _A project team consisting of members with varying functional
| specializations, thought processes, and behavior patterns
| carries out new product development. While selecting a diverse
| team is crucial, it isn't until the members start to interact
| that cross-fertilization actually takes place._
|
| > _Selecting the right people for the project team while
| monitoring shifts in group dynamics and adding or dropping
| members when necessary. Creating an open work environment.
| Encouraging engineers to go out into the field and listen to
| what customers and dealers have to say. Establishing an
| evaluation and reward system based on group performance.
| Managing the differences in rhythm throughout the development
| process. Tolerating and anticipating mistakes. Encouraging
| suppliers to become self-organizing. Involving them early
| during design is a step in the right direction. But the project
| team should refrain from telling suppliers what to do._
|
| > _Headquarters ' involvement is limited to providing guidance,
| money, and moral support at the outset. On a day-to-day basis,
| top management seldom intervenes; the team is free to set its
| own direction. In a way, top management acts as a venture
| capitalist. Or as one executive said, 'We open up our purse but
| keep our mouth closed.'_
|
| > _Top management kicks off the development process by
| signaling a broad goal or a general strategic direction. It
| rarely hands out a clear-cut new product concept or a specific
| work plan._
|
| > _Starting with the guidelines set forth by top management,
| [the team begins] to establish their own goals and keep on
| elevating them throughout the development process. By pursuing
| what appear at first to be contradictory goals, they devise
| ways to override the status quo and make the big discovery._
| adrianmsmith wrote:
| > To me, Scrum has always been something of a paradox. The
| whole point of agile is to adapt the process to the team's
| needs - if you're doing dogmatic agile, you're not actually
| doing agile.
|
| It seems to me that Scrum has "no true Scotsman" built right in
| to the model. If you criticize it, a Scrum practitioner can
| just reply "well, just adapt it to your needs then". Or if you
| hear of something too crazy a team is doing with Scrum because
| they adapted "well, they're not doing Scrum right".
| synu wrote:
| They called it "scrum but"
| deanCommie wrote:
| In an age where tech workers have massive autonomy and respect,
| it might be difficult to remember WHY the original Agile
| manifesto was written.
|
| Sure it talks about delivery, working software, and the like.
|
| But a big motivator wasn't just "Craftsmen who want to do their
| craft more effectively", it was "Employees who are being abused
| by project managers, Gantt charts, and top-down waterfall death
| marches, who want to have sanity"
|
| The part of 2-week sprints that says "deliver working software
| at the end" is just as important as the part that says "PMs
| can't introduce new scope into the sprint".
|
| So the reality is It Depends on the company.
|
| If you're lucky enough to be in a place where you have full
| control over your process to deliver software, Bottoms Up,
| Just-In-Time Process is the perfect attitude. But if management
| is enforcing archaic practices for no seemingly clear reason,
| the "rigid" nature of Scrum actually helps enforce a good way
| of doing things in a way that "traditional" management can
| reason about.
| synu wrote:
| The Kanban book by David Anderson was all about this, but it
| never caught on like Scrum did. If I'm feeling cynical I think
| its because there were no certifications to charge for and no
| strange new roles for middle managers.
| Silhouette wrote:
| That is unfortunate indeed. The basic idea that you can run a
| software team by collecting a set of useful and moderately
| sized projects to do and then picking the most important ones
| to do first is reasonable enough. It's the extra process that
| goes way too far, full of formulaic time-wasting meetings and
| participants whose roles need silly names because no-one can
| explain or justify them on merit alone. But it's hard to sell
| tickets to a conference where the keynote speech is five
| minutes long and the same as last year.
| cupofpython wrote:
| i dont think that is cynicism. ideas need to be commodified
| for corporate use or else HR / recruiting does not know what
| to do with it.
| apocalyptic0n3 wrote:
| > The whole point of agile is to adapt the process to the
| team's needs - if you're doing dogmatic agile, you're not
| actually doing agile. But what Scrum seems to add on top of the
| agile manifesto seems to be mainly dogma.
|
| I oversee (i.e. just making sure they're running well and on
| schedule) a bunch of different project teams and this is a
| frequent debate I have with the leads on those projects. If x
| and y is working for you, but z isn't, why don't you meet with
| your team and adjust z to make it work with the project and,
| more specifically, your personnel better? The response is
| almost always "But then it's not Scrum." They get in this
| mindset that if they don't follow the Scrum workflow to a T,
| then they're failing as leaders. That the workflow should be a
| rock that you beat your team against until they conform to it.
| It's a struggle backing them down from that edge and convincing
| them that Scrum doesn't work in all (many) cases, but a few
| minor tweaks to it will make your team function more
| effectively pretty easily. A lot of them struggle to accept
| that the "few minor tweaks" is always different between
| projects and teams, too.
|
| Retros are essential for running an effective agile workflow,
| whether it be Scrum, Kanban, near-Scrum, or something else. You
| need to take a step back, view the process from the outside
| with your team, and figure out how to more effectively function
| going forward. Trying to appease the Scrum gods or your manager
| by adhering to every single character of Scrum as if it is
| scripture doesn't make any project better, in my opinion.
| Everything has to be flexible to some extent, including you,
| your team, and your processes.
| Jenk wrote:
| One near constant thing I notice is that hardly anyone
| (_especially_ scrum certified folk) recognises that scrum, by
| design, makes it self redundant. Most think scrum is a final-
| state. A goal line.
|
| It's not. Scrum is a training/introductory agile framework.
| There is an evolution to scrum built right into the framework
| that transforms it into not-scrum. The framework encourages
| moving from the initial (and what most orgs think is the final
| state of scrum) "Type A" where the team work in isolated
| timeboxes, with downtime between for planning etc. through
| "Type B" with preparation(s) for upcoming sprints, and feedback
| from previous sprints, overlapping the current sprint, to "Type
| C" with complete "just-in-time process" transformation where
| doing any given ceremony is done on-demand. And, crucially, it
| encourages evolving _beyond_ this.
|
| Type C will be familiar to anyone practicing Kanban. Or dare I
| say, anyone with experience with "doing agile right" will have
| an experience matching what Type C describes.
| rawoke083600 wrote:
| oh please let this be true !
| baal80spam wrote:
| But, but... where would all the Scrum Masters go?!
| mavelikara wrote:
| They will co-opt the next revolution, just as they did this
| one.
| lapetitejort wrote:
| Promoted to Vice President
| flir wrote:
| They just....... die?
| bbarnett wrote:
| Where the pocket calculators do?
| arthurcolle wrote:
| "I'll give you my HP Prime when you pry it from my cold, dead
| hands"
| cableshaft wrote:
| So Silicon Heaven, then?
|
| https://youtu.be/lm6YnAqPv4w
| AnimalMuppet wrote:
| Preferably, far away from me.
| pmoriarty wrote:
| This reminds me of Dave Thomas' _" Agile is Dead"_ talk:
|
| https://www.youtube.com/watch?v=a-BOSpxYJ9M
| loofatoofa wrote:
| lol the monoliths are going nowhere. scrum, rails, mainframes.
| whatevs.
| martythemaniak wrote:
| Apparently it came and went and I never understood what it was.
|
| My team meets regularly are we scrumming? We ship quickly and
| iteratively, are we agile?
| wccrawford wrote:
| Yes, but you're not "Scrumming" and "Agile" with capital
| letters. And that's a good thing, because then you wouldn't be
| "agile" anymore.
|
| I actually like Scrum, but holding onto it too tightly is a big
| mistake, IMO.
| peanut_worm wrote:
| Scrum and Agile are like Monads, no one really knows what they
| are.
| moron4hire wrote:
| What don't you get about a monad in X is just a monoid in the
| category of endofunctors of X, with product x replaced by
| composition of endofunctors and unit set by the identity
| endofunctor.
| mxuribe wrote:
| Monads are when you have more than a single nad... /s
| layer8 wrote:
| I'd argue that the Agile Principles are all you need, and that
| they are pretty much timeless. Really, please read through them:
| https://agilemanifesto.org/principles.html
|
| Everything else tends to devolve into ceremony/dogma.
| compiler-guy wrote:
| The age of Scrum never really started, because no one does any
| agile development properly ever.
|
| At least that's what the proponents say when anyone points out
| any issue at all with anything agile.
| krzyk wrote:
| And scrum is not agile ("people above processes").
| jtdev wrote:
| Most organizations that I've worked with as a consultant think
| Jira = Agile/Scrum and fail to do even the most basic actual
| Agile/Scrum things like proper story writing, filling a product
| owner role with someone who has even a remote idea of the
| product owner's responsibility, etc., etc.
| rawoke083600 wrote:
| Just glancing at some of the comments, can't help but notice many
| (not all) of the "positive or pro scrum" comments are from what
| looks like "team-leads/scrum-masters/managers" ?
| synu wrote:
| Scrum was always very strange, a little package of dogmatic
| practice as a way (supposedly) to implement a highly adaptive
| methodology.
| browningstreet wrote:
| Honest question: Is this worth discussing anymore in the
| abstract, versus in a place, doing a thing, with the people
| involved?
| outside1234 wrote:
| I think you should be careful about what you wish for. I've been
| in the alternative which is "nothing" and "waterfall" and scrum
| is a thousand years better than those two.
| zogomoox wrote:
| There's something even more hellish and that is Scaled Agile
| Framework.
| lgunsch wrote:
| What alternatives have people come across? I know there is
| waterfall: months of planning followed by months of
| implementation, followed by a single deployment at the very end.
| Then there is the gradient of in-betweens along the line of scrum
| to waterfall. I've not encountered any other methodologies yet.
| buescher wrote:
| There's more than one AGILE methodology. SCRUM is only one of
| several. Probably if you're doing SCRUM you're using techniques
| from some of the others, so you might not see the distinction.
| Look 'em up. KANBAN, for example.
|
| A whole lot of organizations, particularly gelled teams at
| them, do some variation of "plan, iterate, ship":
| https://blog.pragmaticengineer.com/project-management-at-big...
|
| AGILE consultants did not invent iterative development, by the
| way.
|
| I have never seen any process actually followed that looks like
| the AGILE consultants' caricature of "waterfall". The more
| serious you get, though, about defining requirements up front
| and making sure you meet them, the more your process will look
| like traditional systems engineering and stage gates. This does
| not preclude iterative work - the buzzword decades ago was the
| "spiral model".
| n42 wrote:
| Shape Up seems to have been gaining traction:
| https://basecamp.com/shapeup/webbook
|
| in my opinion, it feels more like agile than Agile(tm)
| mch82 wrote:
| XP - http://www.extremeprogramming.org/
|
| ShapeUp, as n42 commented -
| https://news.ycombinator.com/item?id=31534642
|
| Product Development Flow by Don Reinertsen -
| http://reinertsenassociates.com/books/
|
| Queueing Theory -
| https://en.m.wikipedia.org/wiki/Queueing_theory
| ARandomerDude wrote:
| > "It's easier to explain price once than to apologize for
| quality forever." - Zig Ziglar
|
| What a great quote.
| rob74 wrote:
| Disregarding the content (with which I mostly agree), this post
| could have used some more editing and tightening up. The
| introduction comes off a bit unfocused (it starts with the bold
| statement "the age of Scrum is over" and ends up with "is it?
| Time will tell"), the main text uses "its" where it should have
| used "it's" and vice versa. And "scupper" is "an opening cut
| through the bulwarks of a ship so that water falling on deck may
| flow overboard" - the word he was probably looking for is
| "scuttle"...
| yupper32 wrote:
| I never understood the need for these frameworks. Every time I
| try to read into it, it seems to make the assumption that your
| team are a bunch of children who can't manage their own tasks and
| escalate issues as they come up.
|
| Write up a plan, get it approved, build it, release it. Escalate
| blockers or issues along the way and adjust as needed. I guess
| it's closest to agile but I just see it as... being an adult and
| doing your job?
|
| All this process seems to just stress everyone out.
| lcfcjs wrote:
| mupuff1234 wrote:
| Can it please take agile with it?
| jtdev wrote:
| myth2018 wrote:
| Scrum and Agile have given us a lot.. of nasty problems.
|
| Don't get me wrong, I think Scrum and Agile may be great tools,
| but their values are not exclusively intrinsic. There are SEVERAL
| prerequisites for them to work well. And proponents of Agile
| methods, either by excess of enthusiasm or economic interests in
| selling courses, books, lectures etc, have always pushed this
| arrogant perspective of "if agile is not working for you, you are
| doing it wrong" and "some organizations are not mature enough for
| agile". The number of practitioners who bought that truckload of
| BS is terrifying.
|
| And then MBAs and PMPs finally "embraced" agile. The rest is
| consequence.
|
| So, yeah, farewell agile, and I fear for what comes next.
| jrochkind1 wrote:
| Many of the ideas and practices in "agile" in general seem to me
| still to be very relevant and useful. It can be used for good or
| evil (or just given lip-service without even really trying), but
| I think there is good advice and ideas there for those who are
| approaching it trying to do well.
|
| But "scrum" specifically has always seemed to me the worst of
| "agile", a system intentionally designed to turn the developer's
| experience into a fordist sweatshop cranking out as much
| productivity as possible, treating the developer like a
| commodified interchangeable part. It's like as if "economic
| efficiency over humanity" were part of the agile manifesto (it
| ain't).
| pleb_nz wrote:
| Been lucky enough to only be exposed to scrum in training course.
|
| Every team I've been apart of at multiple companies has been a
| team process around common sense, what works for the team,
| transparency and openness to suggestions and change.
| [deleted]
| [deleted]
| sharken wrote:
| I have more faith in empowered teams at least for companies where
| software is not the main focus.
|
| For software companies, it makes sense to do more DevOps, how
| much depends on the company.
|
| Scrum and all the events/meetings that go with it will certainly
| not be missed. That goes for SAFe as well.
| brightball wrote:
| Most of the meetings for the SAFe process aren't team oriented
| but collaboration oriented, to empower the team to work the way
| that's best for them.
|
| Teams within SAFe can use any methodology that they want,
| scrum, kanban, lean, etc.
|
| The world outside of your dev team is what the other meetings
| are for: keeping business side informed of progress, checking
| in on cross team dependencies, deciding whether a change in
| plan needs to happen based on some unexpected problem, etc.
| That's one of the reasons that SAFe insists on PI planning,
| it's to consolidate as many meetings as possible into 2 days
| per quarter so they don't invade every week as a back and
| forth.
|
| When the business side and dev side of the house are
| communicating and on the same page, there's a lot less friction
| in the work relationship.
| sumtechguy wrote:
| scrum works great when it is about the teams getting things
| done and not letting things fall through the cracks. It fails
| quick when it becomes about scrum process and making sure the
| 3000 fields in Jira are filled out correctly and making sure
| every processes is done correctly.
| Silhouette wrote:
| _It fails quick when it becomes about scrum process and
| making sure the 3000 fields in Jira are filled out correctly
| and making sure every processes is done correctly._
|
| If management types had to go through the same process to add
| each field to a task or each step to a process in their tools
| that they expect their teams to go through to get any real
| development done the world would probably be a much more
| efficient place. What specific, immediate, measurable benefit
| is that extra field going to provide? How important is it
| compared to the other ones you suggested last month? How much
| effort will it require for the team to fill it in (measured
| in arbitrary units that everyone on the team can dispute
| subjectively)? How will you monitor the performance of the
| team in using the new field? We can have a retrospective in a
| couple of weeks scheduled right in the middle of the
| afternoon when you need to take a call with a potential huge
| customer to discuss the new field and then if it's not
| working very well we can ignore that meeting and not change
| anything anyway.
| MisterBastahrd wrote:
| SAFe has been nothing but a giant timesink for our company, but
| I guess our managers got certifications out of it. For our org,
| it added a day and a half of planning each 10 week period plus
| devs are now in roadmap meetings, which we never were in
| before.
|
| We haven't increased in productivity. At all.
|
| For our small dev staff, they've added over 1000 man-hours
| worth of meetings per year.
| gjvc wrote:
| scrum encourages cult-like behaviours
| mkl95 wrote:
| > Within 5 years Scrum will be largely irrelevant as an influence
| in modern software companies
|
| I am a senior engineer and I still haven't experienced the
| mythical "scrum done well". Every single project that attempts
| scrum ends up burning people out eventually. The main cause is
| that it's a grossly leaky abstraction that forces people to
| micromanage themselves. If your company sucks, scrum is not going
| to save it.
| WesolyKubeczek wrote:
| I've seen it work, but only in very small teams (not teams that
| were a part of a big corporation, mind you, but small teams in
| a very small companies). Where there was a thick layer of
| middle management comprised mostly of social climbers and
| micromanagers, it all fell apart because all the rituals were
| in place for all the wrong reasons.
| FpUser wrote:
| Lucky me. I've ignored all this Agile/Scrum and had managed to
| live my coding life without all that religious looking
| "methodologies". In my life teams had always organized their work
| / communication organically. Whatever works for particular
| situation.
| Cwizard wrote:
| I actually like scrum but would say most people I have worked
| with have no clue what it is about. My scrum master for example
| mindlessly follows 'the rules' but does little to actually
| improve our teams productivity. They just make sure we do the
| meetings, fill in the right form in the retro, etc. Same with the
| sprints, we 'plan' our work in two weeks, when it won't fit, we
| just split it in part 1 & 2. We don't actually have working
| software at the end of the sprint, but we did it in two weeks
| right? It's a cargo cult.
|
| To me scrum is a bunch of guidelines that can give you some
| framework to start from, you try it out, and you see what works,
| what doesn't. You iterate on the process just as you iterate on
| the code, no fixed rules, but not too loose neither. But
| ambiguity, nuance, and context never work well in a corporate
| setting...
|
| I don't think we need a better process, we need better middle
| management.
| nmstoker wrote:
| Completely agree. It's the mindless nature that's the red flag
| here.
|
| I met a guy who came across as quite fluent in these meetings
| but quickly you would realise he didn't know what any of it
| meant - it was like the Chinese Room.
|
| With that little connection with anything it was impossible for
| people to pick up basic errors, it was just rote learning and
| soon it spread to others; no one was equipped to make sensible
| suggestions as they couldn't see the big picture and didn't
| really know what the things they did were actually for let
| alone the "why" ("Oh, so we're building a ship... to float on
| the water? Thanks!", turns back to keyboard, resumes vacant
| look)
| andrewstuart wrote:
| I hear this sort of thing often but I haven't heard a really good
| alternative.
|
| One thing I question about scrum is "why daily standups"? Why not
| 3 days a week? Or once a week. It seems like nothing more than a
| social event when the whole team gets together every seven
| working hours and says "here's what I did for the past 7 working
| hours, here's what I'm doing for the next seven working hours".
| lucisferre wrote:
| Can there ever be a prescriptive product development framework
| that works for all software development though? Is such a thing
| even possible.
| mrcus wrote:
| Good questions. The usual answer is "because it's a good
| staring point for teaching the team to talk and coordinate
| often". As with most scrum ceremonies, the standup should
| probably be adapted to match the needs of the team. It doesn't
| have to be a reporting circle where you tell your PM "what did
| you do, what will you do, what is blocking you".
|
| _edit_: Adapted or removed or reinvented.
| d4mi3n wrote:
| It is an arbitrary ritual. I never understood why everyone is
| so dogmatic about planning process. It's like any other
| development pattern--it should be adapted to the context it's
| in.
|
| The whole point of a standup is to keep the a team coordinated
| and it's manager/lead informed. Standup isn't the only way to
| do this. It can happen asynchronously. It can happen at end of
| day. It can happen as often or as infrequently makes sense
| given the size, maturity, and scope of your team.
|
| Agile and Scrum have a lot of great ideas, but there's so much
| dogma and cargo curling I feel like orgs take all of the ritual
| with none of the insight: iterate quickly and use the delta
| between plans and reality to gain a sense of predictability.
| That's all it really boils down to.
| arnvald wrote:
| From my experience the problem is that Scrum guides say (or
| used to say, it might have changed) that in order to do
| Scrum, you need to do it all. So all the certified Scrum
| Masters learn that they have to do daily stand-ups and all
| the other meetings, and because they believe their job is to
| implement Scrum (instead of making the team more productive),
| they enforce it all.
|
| Every time I worked with certified Scrum Masters I had
| exactly the same struggles.
| d4mi3n wrote:
| You raise a good point, and I've seen this in other
| contexts.
|
| Team wants to be better at X. Y is a tool or process that
| helps them get there.
|
| At some point, the goal of X is forgotten and Y subsumes
| everything, sometimes to the detriment of X.
|
| It's like a weird correlate or inversion of the XY problem
| and I've seen it in a lot of contexts.
| wccrawford wrote:
| That's about right. But what I see happening, when done right,
| is that people are forced to talk about what's holding them up.
| Without it, people tend to just keep spinning their wheels
| instead of asking for help. With Scrum, instead of asking for
| help, they're forced to just state their situation, and someone
| will jump in and help if they can... Or at least the team lead
| will know about the situation within a day, instead of finding
| out a week later when the thing is due.
|
| Done wrong, and it's a grueling 30-60 minute ordeal that wastes
| everyone's time.
|
| It's important to keep everyone to the 3 talking points. What
| did you do, what's blocking you, and what will you work on.
|
| It also keeps the team up to date with what's going on, and I
| know that I personally feel disconnected without that
| information.
|
| Do we scrum? Nope. But we do have a meeting every morning that
| also doubles as a time to chat about any random things we like,
| and it usually runs about an hour. We take care of business
| stuff some time during the hour, depending on how excited
| someone is to talk about non-work stuff, but the work stuff can
| take as little as a few minutes, or as long as the hour,
| depending on what's happening. Joining the meeting is mandatory
| for programmers and project manager, but staying in the meeting
| isn't. That said, I don't think any programmer has ever left
| early unless there's some emergency. It's optional for
| sysadmins, and each of them has treated it differently. I think
| it works best when they at least pop in and say "Hi", but we
| leave it up to them.
| Clubber wrote:
| >But what I see happening, when done right, is that people
| are forced to talk about what's holding them up.
|
| I bring that up right away to the appropriate person via
| email or call or walk-over (when all else fails). If I had to
| wait until the next morning's standup, it would be _less_
| efficient.
| wccrawford wrote:
| I wish everyone did. Everyone is certainly encouraged to do
| that. I've found it to be pretty rare that someone brings
| it up within a day unless they're prompted somehow.
| conradfr wrote:
| An hour each day?!
|
| It must be hell for anybody on your team having ADHD. If it's
| remote they probably drone the meeting out and play solitaire
| or something I guess.
|
| Also, the cost...
| itake wrote:
| I agree standups are a ritual, but for me, they help me pace my
| day. I typically start work for standup and they are great for
| ad-hoc discussions and team announcements.
|
| As an EM, Scrum notes log of what people have been working on
| which is helping for reviewing during performance management.
| spelunker wrote:
| We've been trying a more "Kanban" approach vs scrum, but who
| knows if we're actually implementing it correctly, which is
| perhaps the point of all this.
| Silhouette wrote:
| We can only hope. Little makes the good devs I know run faster
| from a job application than the phrase "Full participant in agile
| rituals/ceremonies". Everyone knows what the employer who says
| that is actually going to be like by now.
|
| If you have to tell everyone what you were doing yesterday and
| they actually need to know your project tracking tool is broken.
| If you have to wait until the next day to raise a blocking issue
| your project management process is broken and your team isn't
| communicating at all. So what is the benefit of a daily standup
| again? Anything useful that is said there would probably be
| better said through asynchronous channels in real time. Most of
| what is said there isn't useful to most of the people attending
| anyway.
|
| Then there's the planning poker thing. I think that's the one
| where a possibly large group of people often with conflicting
| incentives allocate imaginary points based on a mostly-arbitrary-
| in-practice scale to some tasks they might do in the next few
| weeks with the general goal of taking on just enough to look like
| they're doing something useful when management check without
| risking missing the entirely arbitrary deadline.
|
| We also have retrospectives to consider. Those are where you have
| yet another meeting to talk about what you could improve in the
| future based on what you've learned and then don't do any of it
| because the people leading the meeting aren't developers and miss
| the point and in any case management has prescribed the One True
| Process so you can't do things like dumping standups and planning
| poker even if none of you believe they are helping.
|
| As far as I can tell the Age of Scrum should never have started
| and the continued remarkably widespread practice of Scrum in the
| industry is much more due to management who read a book or went
| to a conference than developers who actually believe it makes
| them more effective.
| iostream24 wrote:
| Amen
| Overtonwindow wrote:
| Scrums sucked the life out of creative programing.
| nso95 wrote:
| Someone should tell my employer
| fnordpiglet wrote:
| I came to these conclusions about 6 years ago. But I think scrum
| has a place for inexperienced teams and managers to learn what
| processes work.
___________________________________________________________________
(page generated 2022-05-27 23:01 UTC)