[HN Gopher] Ask HN: Do you think Agile/Scrum is beneficial for s...
___________________________________________________________________
Ask HN: Do you think Agile/Scrum is beneficial for software
delivery?
what are the pros and cons of sprints and daily standups in your
experience Coming from old school 'non-agile' financial world
focused on bottom line I was in a bit of a shock learning about
this daily standup ritual. Besides being a dream for
micromanagers, it seems to be more about signalling progress vs.
actually making progress. Do these extra bureaucracy layers,
meetings, checkmarks and vague "man-points" estimates actually
bring any value.
Author : andyxor
Score : 63 points
Date : 2021-03-04 17:28 UTC (5 hours ago)
| domano wrote:
| In my org dailies are mostly helpful and not a reporting tool. We
| work in project teams for our customers and are about 300 people.
|
| Also our agile approaches mostly work out well, but our whole
| organization is structured in a way that facilitates this.
|
| We have only 2 levels of hierarchy and crossfunctional groups for
| arbitrary topics like "wage transparency", "consulting" or
| "technology". Anyone interested can take part in those and they
| get some budget too.
|
| Every few weeks there are townhalls where economic development is
| reported by the executives to the rest of the company and anyone
| can ask questions. Since covid we do this via google meet with
| great success.
|
| All in all agile approaches only truly work if acceptance from
| the higher ups is high. If agile is just used to get tighter
| deadlines out of devs it is actively harmful.
| corytheboyd wrote:
| I'm a little less zealous in my dislike of it. It's not that the
| process itself is "bad", the ideals behind it make sense. In
| practice (my own experience) it easily degrades into what I call
| "fake work"-- you feel like you're doing lots of productive
| measurement and estimation by drawing nice little boxes around
| projects, but projects rarely ever work this way. The one thing I
| see constantly is moving on to the next project because we
| checked off all the agile boxes, without giving much care to
| maintenance. There is always maintenance work, and it's very easy
| to turn a blind eye to.
|
| Something I consider maintenance work is refactoring of systems
| as new projects are planned/implemented. Everyone knows it's a
| bad idea to just bolt on more and more "feature" work without
| thinking systemically, then we all point at "systemic" issues in
| retrospective meetings.
|
| Again though, I'm not losing any sleep over this it's just an
| observation from 9 years of experience as a web developer working
| for mostly SV tech companies large and small. It won't be
| everyone's experience, and in general the best advice I can give
| is try to come up with solutions using your own experience and
| opinions over those people implicitly/explicitly tell you to
| follow because they are "good".
| imbnwa wrote:
| > Something I consider maintenance work is refactoring of
| systems as new projects are planned/implemented. Everyone knows
| it's a bad idea to just bolt on more and more "feature" work
| without thinking systemically, then we all point at "systemic"
| issues in retrospective meetings.
|
| When the great CPU architect Stephen Keller was on Lex
| Fridman's podcast, he made a comment that architectures should
| be refactored every 5 years and I thought to myself, "Good luck
| with that in Enterprise" as I looked over at the 10+ year old
| legacy infrastructure holding back org-level velocity at work
| corytheboyd wrote:
| oof every FIVE years is an eternity in software years. Maybe
| I have been working alone for too long while between jobs,
| but it just feels so much better to listen to all of your
| hunches about it being refactor time than to ignore them for
| the sake of functionality. It's just not possible to act on
| the hunch later when you have lost that important deep
| context and hastily added twelve other things too.
| imbnwa wrote:
| Tbf he was specifically thinking of CPU archs but at
| "Enterprise Scale" might as well be talking 10 years.
| Personally, from your comment, I'm learning to just stop
| giving a fuck and apply the (obvious, cause, you know,
| you've been looking at it for 5 years at least) re-factor
| regardless
| mytailorisrich wrote:
| The daily stand-up is about communication and fostering quick
| information sharing and quick problem resolution.
|
| That's also the reason they advocate that ideally the team should
| sit all together. In that ideal work the daily stand-up lasts
| only 5-10 minutes, it's not meant to be a dreaded status meeting
| where you talk for 5 minutes then try not to fall sleep for an
| hour...
| kevin_nisbet wrote:
| In my experience with old companies adopting agile, is I equate
| it to a company wants to evolve it's culture, but in doing so
| they start doing what they think the companies they want to
| emulate do to succeed. I'd equate it to doing a cargo cult.
|
| Doesn't mean there isn't value to companies that have succeeded
| with it, or created a value culture around this coordination. But
| my experience was a bunch of people sitting around talking about
| what color paper should be used for a particular work item on the
| sticky board, which I struggle to see the value of.
| g051051 wrote:
| There are no "pros". Agile was created by consultants to sell
| consulting, and the so-called "Agile Manifesto" is nothing but
| silly aphorisms unrelated to the task of developing and
| delivering software.
| buster wrote:
| Did you even care to check who wrote the agile manifesto? A
| good book about that might be clean agile by uncle Bob. It
| should will your view on the origin and history of agile.
| unethical_ban wrote:
| I like the idea of Kanban and 3x weekly standups/status.
|
| VS
|
| Sprints and daily standups.
|
| ---
|
| Daily standups are too often, not enough updates, and it feels
| more like pressure than utility for the engineers.
|
| Sprints, while helping keep multiple teams working on a single
| "epic" or "feature" in sync, also feel like an arbitrary slice of
| time vs. letting people work on things at the pace they are
| comfortable at. Finish early? Careful taking new work in, it will
| look bad to bring new things into the sprint and not finish.
|
| Take an extra day on a story due to some complications? That's
| fine if it's middle of sprint. But rollover into new sprint? Oh
| gosh, what will that do to our sprint report?
|
| Time estimations, maintaining backlogs of work and prioritizing,
| and documenting work done are all great. But some of it has too
| much ritual to it.
| natoliniak wrote:
| > Careful taking new work in, it will look bad to bring new
| things into the sprint and not finish
|
| yep. Furthermore, there are many other perverse incentives that
| I noticed, but one stands out: the incentive not to take on
| risky or difficult stories out of fear that if it is not
| finished by the "committed" date (end of sprint), you will be
| tarred and shamed during the sprint review.
| nihil75 wrote:
| Yes, it's working for us, but not without cost.
|
| It's a good way to set expectations for what will be/is to be
| delivered in a Sprint, and limits going off-piste in too many
| directions while not delivering functionality (which is a problem
| for creative/broad-skillset developers at times).
|
| It also limits the impact/waste in case the requirements change -
| you only worked two weeks in the wrong direction. (and they say
| changing requirements is the biggest problem in software projects
| since ever)
|
| However, I find that it often reduces developers to mindless
| drones, just trying to satisfy acceptance criteria without
| thinking about the big picture. (You know you're there when
| Refinement meetings are very quiet and the Architect does most of
| the talking).
|
| As for estimation/scoring - I find that estimating "complexity"
| is nonsense. Treating points as "days" is more realistic and
| leads to better time management from everyone.
| nihil75 wrote:
| Oh and standups are not that bad!
|
| We keep it small, team level (6 people), and they last 15
| minutes.
|
| No pressure to describe anything - you can say "I'm still
| working on that thing" and that's that..
|
| Honestly it's more of a social thing, especially while
| remoting, and a chance to share thoughts and offer assistane.
| danielovichdk wrote:
| Sounds like you are not doing scrum. And I only know of the term
| 'daily' being prt of the scrum process.
|
| So. If you're not doing scrum you are not leveraging it's
| potential and even more important, its rules.
|
| The rules of a daily is non-disputable. It has a formula. If
| you're not following the formula, it's not scrum.
|
| A daily is not about progress. It's about communication. You
| communicate what you did since the last daily, and what you
| expect to do before the next.
|
| But you're not being measured on what you communicated. You are
| merely sharing what you' re doing.
|
| If there is discussion in a daily, it's not a daily. If you're
| not using a board for the baseline for communicating, you're
| fucked.
|
| The role of a scrum master is to take note of what is going on
| and help out if she hears anything that sounds off. A good scrum
| master is a bit like a dictator. Focused, on top of things,
| helpful and listens to what is going on and does not bend to
| outsiders.
|
| Good scrum masters are hard to come by. That's most often imo,
| why scrum had a bad rep in some places.
|
| Also remember, agile is something that must happen on a top
| level, otherwise it will not work very well.
| logicslave wrote:
| "But you're not being measured on what you communicated. You
| are merely sharing what you' re doing."
|
| This is never true. Its a daily confession of what you did. Its
| micromanagement.
| rukuu001 wrote:
| A good team will produce good software, regardless of
| methodology.
|
| But a good agile team will be more responsive to changing
| customer needs.
| brailsafe wrote:
| Every company fails in some respect with at least rate limiting.
| The last thing you should do in software dev is introduce more
| meetings, but that's how managers interpret agile. If I didn't
| get anything done, or only a trivial part of a bigger picture,
| the last hing I want to talk about or hear from anyone else for
| 30 minutes first thing in the morning is that. Likewise with only
| being able to the fastest things done in two weeks, or small
| parts of them if the sprint schedule isn't adapted to the team
| very well.
|
| In most circumstances, one or two updates a week would be fine,
| preferably followed by the rest of update meetings so more
| contiguous hours of problem solving can happen.
| geocar wrote:
| Yes. They make it easier to co-manage larger teams with people
| with drastically different philosophical opinions and can (if
| well-trained and practiced) help avoid burning out your team.
|
| That is to say, in a lot of ways a small clever theologically-
| aligned team is going to be better. But if there's a good reason
| you can't have that, scrum can help you make the most of it.
| throwaway889900 wrote:
| The incentives have changed. Now I just work to say something at
| the standup, and standups are like 30 minutes long because people
| keep turning it into classical waterfall style discussion
| meetings between two people while everyone else listens. I hate
| it and the fossils that perpetuate this.
| comprev wrote:
| It's all about cutting the time in standups down to a bare
| minimum. I don't care what you did yesterday, I want to know in
| one sentence what you're doing _today_ and if you're blocking
| anyone.
| dec0dedab0de wrote:
| Sprints are nonsense unless they have gaps bewtween them, noone
| can sprint indefinitely
|
| Standups are good for small teams all working on the same thing,
| and only if no managers are present. Unless the manager is
| writing code too .
|
| Kanban seems ok but i havent used it for any period of time.
|
| The various tools are nice for remembering what needs to be done
| and making shared checklists.
| imbnwa wrote:
| > Sprints are nonsense unless they have gaps bewtween them,
| noone can sprint indefinitely
|
| This is the crux of the nonsense. A high-level engineer can
| work around this but for the mass of ticket punchers, it just
| encourages non-thinking, risk aversion, and a lack of trust
| between themselves do the pressure of velocity charts, which
| translates into buggy code, mounting legacy blockers.
|
| I know frontend engineers who didn't know what a finite state
| machine was, nevermind how it was implicit in their business
| code. For the mass of mediocre engineeers, sprints kill
| incentive to learn and become a better engineer; no is
| rewarding you.
|
| Product doesn't care cause they're incentive structure is
| advesarial to Engineering push-back on tech debt, refactoring,
| etc. Sprints allow them to make sure their bonus is on time.
| Then Product people quit when BS mounts, another round of
| Product management shows up, and rinse, repeat.
|
| I've seen this cycle happen three times in one org in just 5
| years, the org where I started as a Junior.
|
| And don't let DevOps also be working against sprints in a
| mediocre org
|
| Sprints have, for most of the industry, not the Top 10%
| employers and what not, frankly regressed the industry.
|
| Everyone stops working for the organization and starts trying
| to figure out how to make the organization work for them, from
| engineering to product to devops, etc. Good hiring is also a
| factor in what you'll get out of your employers, but sprints
| don't get you more at either rate.
| mytailorisrich wrote:
| 'Sprint' does not mean you have to push yourself to code as
| fast as you can, nor does it mean that you have to start coding
| straight away. In fact part of the work may not involve coding
| at all (e.g. studies and architecture work) and these
| activities can also be part of a sprint.
|
| Sprints are just time-bounded units to plan and execute the
| work with the stated aim of having working software at the end
| of each sprint. You can do that indefinitely in the same way
| you can follow another software development methodology
| indefinitely.
| booleandilemma wrote:
| In my experience sprints just represent artificial constructs
| that in the long run serve no real purpose. We end up saying
| strange things like "I won't be finished with X until next
| sprint", or "we took in 15 points this sprint". I've seen
| people become more interested in Jira ticket engineering than
| the actual work.
| Jtsummers wrote:
| > 'Sprint' does not mean you have to push yourself to code as
| fast as you can, nor does it mean that you have to start
| coding straight away. In fact part of the work may not
| involve coding at all (e.g. studies and architecture work)
| and these activities can also be part of a sprint.
|
| I agree with this statement. However, I believe the term is
| poorly chosen and, in my experience with managers, frequently
| misunderstood.
|
| There are two issues I have with the term. First, sprints, as
| a physical activity, are about short, very hard, bursts of
| work which are fundamentally unsustainable. Even an athlete
| competing in sprints takes a good break between each one.
| Second, "sprint" conveys a sense that the focus _is_ on speed
| because that 's how we judge sprinters.
|
| The first point suggests that Scrum needs a different kind of
| interval than just a sprint. It needs something like a rest
| period. Not a "sit down and do nothing" period, but analogous
| to the "active recovery" that athletes often take part in
| between exertions. Something productive, supportive, but
| secondary to the principle objective (a runner isn't at the
| race to stretch, but they stretch so they can continue to
| race).
|
| That second point is important, managers hear sprint and they
| think speed. Any kind of slow down or delay makes them think
| that the team is just dicking around. The idea that a sprint
| could be spent on anything bringing indirect value (rather
| than direct) like test and deployment automation, refactoring
| and cleanup, or training is antithetical to this perception.
| Consequently you cannot, easily, put those activities into
| sprints, or you have to disguise them or mete them out over a
| series of sprints so that enough "real" value is being
| created from the management perspective.
|
| Finally, "agile" is about responsiveness. The term was chosen
| for the manifesto deliberately. We don't look at Usain Bolt
| on race day and say, "Wow, that man is agile". But you
| _would_ talk about the agility of a football player who
| _loses speed_ dodging, avoiding, and leaping around a field
| to get a 100 yard touchdown. The agile player is _responsive
| to opposition and present conditions_. They do need to be
| fast, but their ultimate speed isn 't just from raw speed but
| from their ability to maintain progress despite adverse
| conditions. A faster but less agile player could get lucky,
| but more often will get blocked. The use of the term "sprint"
| in Scrum conveys no real sense that adaptation and
| responsiveness are important.
| st3fan wrote:
| Scrum is not agile. You really should not write scrum/agile. That
| is just as bad c/c++ :-)
| geocrasher wrote:
| In a perfect world? Yes. On paper it is very good. And making
| people accountable for their work is a good thing. So is
| organizing work to be sure it gets done. I'm not a developer, but
| my department is developing a product for internal consumption,
| and using the Agile method is good for this purpose. I'm a
| terribly disorganized person so I like the structure it brings.
|
| Beyond that, it's just a way of doing things, much like an OS. It
| doesn't matter if you're running W10, MacOS, or some flavor of
| Linux. If it's the right tool for the job, then it's the right
| tool for the job. But if it's not, then why is it in use?
| jayturley wrote:
| From my experience as a scrum master, if there is any micro-
| managing going on, it's being done wrong. The standup should
| literally be no more than a minute per person. Each person gets
| 2-3 sentences: "I did this yesterday. Today I'm working on this.
| I could use some help with X. (if applicable)"
|
| It's meant to help keep the team aligned on what everyone is
| doing at a higher level, not for any details at all. After the
| standup, the team can address any requests for help that came up
| as needed. But that falls outside of the standup.
|
| Agile is meant to help empower teams and improve their velocity,
| and that requires people to own their own stuff. So the standup
| should be a purely informative, high-level overview of where the
| team is so everyone is aligned. If it's anything more, it will
| become a cumbersome, painful exercise in micro-management and
| tangential discussions.
| UK-Al05 wrote:
| Compared to what? My experiance of traditional project managment
| is we used to have milestones, write daily progress reports,
| requirement anaysis meetings with BA's etc
|
| In my mind scrum has less bureaucracy than that.
|
| Scrum Meetings are best used as a way to come together as a team
| to work how to make progress today.
|
| For example:
|
| I want to deploy this change to prod today, but one of the tests
| is failing and I don't know why. Ok lets get a couple of people
| to mob on the test to figure out whats going on after scrum etc
|
| That's a good scrum meeting.
|
| Bad scrum meeting. Person 1: I did x yesterday. Person 2: I did x
| yesterday etc Person 3: I tried to get x done yesterday, but I
| got stuck i'll try again today.
|
| No value whatsoever.
|
| The emphasis should be on problem solving as a team, and focusing
| the team on pain points to get work across the finish line.
|
| To that end i find "walking the board" far more valuable, than
| status updates from each memeber.
| cashewchoo wrote:
| I've never felt like a stand-up with your manager-type-person
| present is ever net helpful. Stand-ups just implicitly become
| "what did you do yesterday that justified 10% of your biweekly
| paycheck" at some level, and people end up talking to the manager
| rather than to each other.
|
| I'm sure some super special orgs out there can counteract this
| with their incredible non-toxic culture and such. Most cannot.
| Ones that explicitly think they can almost certainly actually
| cannot.
|
| If it's solely the IC's, I think that's where it _can_ be good.
| People feel a lot more free to not say anything if they don 't
| have any blockers and don't need to put anything to the team.
| It's much easier to get in-and-out and have a high-bandwidth
| discussion.
|
| I've felt the most comfortable where we sat down once a week for
| an hour, went over the last week, and thought about the next. And
| we had an open-door policy (not literally/physically of course)
| if you ever needed to discuss blockers or put things to the team.
| "Standups" happened naturally, about once or twice as week, where
| people would accrete into a standup in the middle of our pod
| discussing something that was so interesting/relevant that it
| naturally drew us out of our offices.
|
| Maybe that was just the only time where we finally had the team
| and the process mesh on a natural level, and it doesn't prescribe
| this as "the way to do it" for anyone else. But damn did it work
| for us, for at least two years, before the org changed enough
| that our team didn't really exist as the same team anymore.
|
| One thing I have _never_ enjoyed was the "the big boss wants
| this project done ASAP, have standups every day to make sure it
| gets done as fast as possible". That and everything related to it
| was awful.
| 908B64B197 wrote:
| Agile/Scrum is great if done properly.
|
| Most of the industry is doing it wrong/cargo-culting the wrong
| think. Non-technical managers, or worse, CS grads whose goal
| was to stop coding 4 years into their careers, took the parts
| of Agile they liked and made it into a micro-management
| strategy to justify their work.
|
| Agile was written at a resort by 10x engineers for 10x
| engineers. Flat organization and high ownership (meaning these
| guys have a stake in the company). Trying to blindly copy it to
| highly hierarchical cost-center software shops is a recipe for
| disaster where the only ones making money are the agile
| consultants.
| myth2018 wrote:
| > Agile/Scrum is great if done properly.
|
| and, I'd like to point out, Agile/Scrum is great IF applied
| on suitable organizations/projects.
|
| Some projects are too big by nature and, regardless of how
| much resources are available, there are not enough 10x
| engineers to be hired and trained to deliver the project
| within a feasible time.
|
| Some organizations are too hierarchical and there's no way to
| change entire cultures based solely on software projects'
| needs. By extension, its employees are unlikely to show the
| level of ownership required by Agile.
|
| Don't get me wrong, I like Agile and favor it over other
| method families whenever I can, but I have a different point
| of view when it comes to organizations "not well-suited to
| Agile". I don't necessarily see them as limited solely based
| on how well software projects can be carried within their
| structures.
|
| It's indeed advantageous to possess a software project-
| friendly environment. That would provide them a good edge
| over competition.
|
| But there are so many other things beyond that, and so many
| organizations being successful on their main goals despite
| being Agile-hostile, that I'm more inclined to look for ways
| to cope with their shortcomings.
|
| I'm not implying you wanted to say that, but I see many Agile
| enthusiasts classifying those organizations as "not prepared
| to Agile" and I think this is so wrong. I see that simply as
| a natural incompatibility and, if I had to elect a culprit
| (which I don't think to be the case), then Agile would be the
| party which is in debt.
| 908B64B197 wrote:
| > Some organizations are too hierarchical and there's no
| way to change entire cultures based solely on software
| projects' needs. By extension, its employees are unlikely
| to show the level of ownership required by Agile.
|
| These two issues can be solved by isolating the software
| folks from the rest of the organization. Think of a company
| within a company. That and fixing the hiring pipeline can
| fix ownership: bringing a culture of stock based
| compensation typically attracts high achievers and make it
| important for the engineers to truly own the product.
| hrktb wrote:
| > Agile was written at a resort by 10x engineers for 10x
| engineers.
|
| Do these 10x engineers need Scrum ? I don't think flat/high
| ownership organization have a strong need to be told how to
| do things, or import some cookie cutter framework in their
| day to day operation.
|
| Getting inspired ? sure, but a lot of the ceremony parts of
| Scrum don't make sense if people already communicate fluently
| and organize seemlessly.
| 908B64B197 wrote:
| Nobody does the full Scrum.
|
| It's more of a set of ideas that can can be applied to a
| project (or not) and ways of thinking about the software
| engineering process itself. It's not a magic recipe, just
| like no programming language or framework will make
| RandomCo. a unicorn.
| Jtsummers wrote:
| One of the details of the manifesto is that it does _not_
| tell you how to do things, and in fact discourages the
| prioritization of "processes and tools" over "individuals
| and interactions" (doesn't remove processes and tools, but
| it deprioritizes them). The manifesto was as much for the
| developers as for their managers and customers. It
| established the priorities of their work and relationship
| with each other.
| path411 wrote:
| Honestly I feel like a team that communicates healthily in
| channels on slack kinda defeats the entire purpose of stand
| ups. At my current job, we even have the customers for my team
| in slack channels and they are highly communicative, so
| honestly it makes the whole scrum model seem just a waste of
| time when I can start a question/thread right in slack with the
| product owners/customers
| matwood wrote:
| A good team can make any process work, just like a bad
| manager/team can destroy the best process.
|
| I've done daily stand-ups/check-ins either end of day or first
| thing in the morning for nearly my entire career. I've also
| been fortunate enough to have good team members and technical
| management (prior to being management).
|
| I have always found them helpful, particularly when people get
| stuck. Of course someone can always shout I'm stuck and hope
| the right person hears, but I've lost count of the times
| someone in the standup that likely would not have seen this
| person's problem says 'oh, I've seen that - do this'. And that
| includes possible management. Also, many people don't want to
| say they are stuck or don't know something. While not
| automatic, this does provide a scheduled block of time to speak
| up.
|
| I've worked with many great engineer people who had tendencies
| to go down rabbit holes. A daily check-in made micromanagement
| unnecessary because it forced someone to think about what they
| accomplished and where was it headed.
|
| Finally, it's ok to say nothing was accomplished yesterday.
| Shit happens, we all know it.
| angarg12 wrote:
| What we think shouldn't matter, instead we should look at the
| evidence to judge if Agile is beneficial for software delivery.
|
| The problem is that research into software engineering sucks. The
| silver lining is that some people have done small scale studies
| on this subject.
|
| The studies I've read range from no impact to a significant
| improvement of using Agile methodologies over, say, waterfall
| processes. This large variability is a hint of how inconsistent
| these studies are, but I've seen more evidence piling up in the
| "good" side of the scale.
|
| However, from your loaded comment seems clear you aren't really
| interested in data anyway.
| tester756 wrote:
| I see value of daily standups and planning next sprint e.g 2
| weeks and I like them
|
| but we dropped that bullshit like "story points" - you know,
| abstraction over abstraction of time/effort whatever it is.
|
| we estimate stuff in man hours.
| l0b0 wrote:
| > Besides being a dream for micromanagers, it seems to be more
| about signalling progress vs. actually making progress.
|
| There are two massive red flags in that sentence. If the standup
| is being used as an excuse to micromanage something has gone
| horribly wrong. And if people don't use it to make progress (that
| is, asking for help and mentioning blockers) something else has
| gone terribly wrong.
|
| There are about a million discussions about how broken Agile is,
| most of which discuss some abomination of a process with very
| superficial similarities to Agile. It's not like _having a
| standup_ is some sort of magically good thing on its own if
| people just use it to do things the way they 've always done
| them.
|
| Cue the inevitable "If everybody is doing Agile wrong, maybe
| there's something wrong with Agile?" response, to which I would
| simply say that I've seen Agile work in at least two completely
| different workplaces, and I've seen how terrible non-Agile
| processes are in at least another two.
| buster wrote:
| Well, there is no mention of estimates in the manifesto. It's
| just people want to know if the thing they buy might cost them
| one million dollars or 100000 dollars. So giving estimates has
| nothing to do with agile per se. You probably needed to tell your
| customer or your boss how much time/money you think something
| will cost before, didn't you? If you didn't, I don't see why you
| should now.
|
| Daily meetings are not to micromanage and show off that you've
| done so much work yesterday, but to identify issues that need to
| be resolved and a good place to ask the team for help if you're
| stuck.
|
| Unfortunately, agile nowadays is mostly scrum, following some non
| sensical plan taught by some agile coach and too much management,
| whereas agile was invented solely by and for developers (not
| managers).
| bern4444 wrote:
| I hate the term sprints. The idea is good but the term is
| horribly inaccurate. Sprint makes it seem like its a quick dash
| to the finish line and then its over. But the work is never over.
| One sprint ends and the next one starts immediately after. Work
| is not a sprint, its a marathon.
|
| Sprints conceptually make sense. We have 3 features we want to
| develop. Lets aim to complete them in the next 2-3 weeks. I like
| them so long as the goals are extremly well defined and managed.
| Too many teams though forget the agile aspect of agile
| development. If there's a change to the priorities, its often
| poorly communicated or just added to the sprint without removing
| anything.
|
| Daily Standups, as practiced by most teams, are a waste of time.
| They become status updates for the Project Manager or Team
| Leader.
|
| What would be better is for engineers to use the time to review
| ideas, issues that have cropped up and ask questions about the
| codebase or specific issues. This is probably what a standup is
| supposed to be but when its mixed in with the context of status
| updates, it always takes a back seat.
|
| Pointing is a complete waste of time. I have no idea how long a
| ticket is going to take until I start working on it. Estimations
| are usually wrong anyway. If anything, tickets should be pointed
| once the work is complete to track a teams acutal performance and
| velocity (output).
|
| Having the team review tickets for the next sprint (sprint
| planning) is useful for inital discovery (so long as it doesn't
| involve pointing). One person on your team might know how to
| solve a bug ticket or know if a feature ticket is deceptively
| difficult. That discovery process can be extremely valuable.
|
| Overall agile ideas I think do help more than they hurt but not
| always and not by much.
| matt_s wrote:
| Following any process to the letter by some text book is
| problematic.
|
| If you consider things in the Agile Manifesto and the spirit of
| being agile, the pros are things like you don't waste time
| building stuff nobody uses. Why gather requirements, design,
| develop, test, deploy of features that have minimal or no usage.
| I've seen many cases that by the time a feature gets out there,
| its not needed/wanted any more. There are charts and stuff on
| this regarding Lean Software Development. Another pro is barriers
| are identified quickly and can be problem-solved quickly. Figure
| out your unknowns really early and you can adjust what you're
| building.
|
| Over the last year with everything going on there were days where
| at standup people said "got distracted" and that is perfectly
| fine. I took that to mean they didn't get anything done during
| the last day. There were some major life distractions this past
| year. Those meetings aren't for management to keep tallies on
| people for some fictitious scoreboard, they are there for the
| team to identify barriers, ask questions, etc. so the work can
| get done. Agile comes from lean principles from manufacturing,
| its about eliminating wasteful steps in a process.
|
| Some cons would be with the wrong culture you get micro-managers,
| people measuring stuff that doesn't matter (ticket size,
| velocity, whatever) and possibly people gaming whatever nonsense
| you are measuring. If there is bad culture the project management
| process being used doesn't matter really, its not going to be
| pleasant working in that.
|
| If there is high risk in what you are delivering, like if you're
| building software for controlling a nuclear power plant, ICU
| medical devices, etc. you may need a lot tighter controls around
| the project process because software bugs can result in really
| bad things. Maybe a waterfall process works better in those
| situations, otherwise use agile that fits the people and
| organization.
| meheleventyone wrote:
| Agile the stuff in the manifesto is pretty much spot on.
|
| Agile the stuff people make you do in work is often pretty anti-
| thetical.
|
| Scrum as a process is basically poison.
| jamesrr39 wrote:
| Upvoted (although I'm not sure I agree with the last point, but
| the top 2 are definitely spot-on)
|
| The agile manifesto is tiny and a scrum guide like this one:
| https://scrumguides.org/scrum-guide.html is readable in a
| couple of hours. But the version of "scrum" forced on many
| people is a far cry from that.
| meheleventyone wrote:
| For the last one, basically if a process is essentially never
| implemented in a way that respects the principles it's
| designed around something is very wrong.
| jamesrr39 wrote:
| Yes, I agree. But I'm not sure what you do about that
| though. Stronger "dictacts" from an international "scrum
| committee" putting out material telling you what is
| "correct" scrum and what is not?
| meheleventyone wrote:
| The problem as ever is people and expecting that process
| will fix them. Individuals and interactions over
| processes and tools.
|
| A dysfunctional team won't be fixed by a new process to
| follow. It'll just warp to the dysfunctions.
| Jtsummers wrote:
| Emphasize the principles more.
|
| The one thing I've consistently seen absent in many Scrum
| attempts is the sprint retrospective. When this is
| included and is permitted to include not just
| code/product issues but also _process_ issues, it has
| worked very well even when they skimped out on other
| elements of Scrum. But most often the retrospective is
| absent or the process is not permitted to be included in
| it. This makes you fundamentally anti-Agile as you
| literally have a rigid, static process.
|
| The one consistent element that I have found across
| nearly every reading of Agile I've done and my
| experiences over the past (now almost 20 professional)
| years has been that the critical element of agile is its
| responsiveness and introspectiveness. Lacking those two
| things you do not have anything that can be called Agile,
| at best it's an imitation, at worst it's SAFe and you
| should run fast.
|
| DevOps, Lean, Scrum, Theory of Constraints (realized in
| software, at least in part, as DevOps) to the extent that
| they have defined processes they are not the same. But
| the consistent element is introspection and
| responsiveness leading to adaptation to the team,
| organization, customers, and systems being
| developed/maintained.
|
| This is the critical element missing from many
| organizations and teams at the time of the manifesto. See
| Waterfall, any CMMI office. They become static, they
| delay their feedback loops to extraordinary time frames.
| Waterfall (may it die a fiery death), in some spectacular
| failures I've witnessed, had 5 years from start to
| delivery for customer _test_ , not deployment. CMMI has a
| strong association with Waterfall (unjust in my opinion),
| but it still promotes a _static_ process that is only
| reviewed when it 's time for your next appraisal
| (technically it promotes continuous monitoring and
| improvement, but like with Scrum everyone ignores it).
|
| It's still a crucial element missing from many
| organizations who have cargo culted their way into Agile
| or adopted "Agile" processes (like SAFe, may it suffer
| the same fate as Waterfall). If your processors ever
| become truly static, you either found The One True
| Process (for your team and situation) or you're failing
| to recognize and adapt to your circumstances.
| frugalmail wrote:
| Scrum, and "certified" (or not) Product Owners, Project Managers,
| Product Managers, Scrum Masters, Technical leads, architects,
| engineering managers, and QA that don't come with years of code
| slinging under their belt have no place in software development.
|
| Kanban makes so much more sense when that kind of garbage is in
| your work environment.
| j4yav wrote:
| I was a big believer 15 years ago, then became heavily
| disillusioned, and now have a pretty pragmatic view of it. It can
| help, if you don't know what you're doing at all it's a good
| framework to start. I feel like the Kanban approach where the
| team takes ownership of their process is a good one. There's a
| lot of great stuff in there about communicating as a team, and
| thinking about the customer.
|
| Too often though in practice it devolves into a kind of cargo
| cult and the apologists lean way too hard into the "if it isn't
| working, you must not have believed in it hard enough" defense
| which is a bit too easy in my opinion. It short circuits any
| actual reflection and learning.
|
| Basically, the agile manifesto is great.. the stuff agile coaches
| try to sell you is hot garbage. Everything else is somewhere in
| the middle, but Kanban is the closest because it preserves the
| "we are uncovering" part of the manifesto.
| smoldesu wrote:
| no
| nihil75 wrote:
| Now I want to be devils advocate and give you the "corporate"
| perspective -
|
| You say Agile disrupts your "flow", makes you deliver buggy code
| and just work to close tickets like a drone?
|
| Good! Who said code needs to be perfect and bug-free? remember
| Lean? Just get it out there! we can always fix things later.
|
| From a business perspective - we are spending money to develop
| functionality, not our peoples skills. Tickets and tasks should
| result in adding value _to the business_ , not to our codebase.
|
| This is a cruel and unsustainable way of thinking, which will
| have your best developers leaving the company very quickly. But
| if you're an enterprise corp - you see them as interchangable
| "resources" anyway, and Agile helps you accomodate to them
| leaving by splitting the work to small bits and having no single
| owner.
|
| This is also a way of looking at things...
| k__ wrote:
| Depends what you build.
|
| For experimental stuff, agile could be good.
|
| For product stuff, Scrum could be good.
|
| For commodity stuff, six sigma could be good.
|
| Using one of these for something it isn't meant to do will lead
| to failure.
| furstenheim wrote:
| I find value in part of it. Dailies I find very beneficial. You
| get to hear what other people are having problems with, and maybe
| you already faced something similar. Or the other way around,
| when you face it you remember that someone solved a similar
| issue.
| patmcc wrote:
| If "Agile" results in _extra_ layers of bureaucracy and more
| meetings, that 's a great sign that agile is being done terribly
| wrong. Which, to be fair, is very very common.
|
| Remember the manifesto:
|
| We are uncovering better ways of developing software by doing it
| and helping others do it. Through this work we have come to
| value:
|
| Individuals and interactions over processes and tools
|
| Working software over comprehensive documentation
|
| Customer collaboration over contract negotiation
|
| Responding to change over following a plan
| hinkley wrote:
| I think when Agile is finally replaced by something else it
| will be because of: Individuals and
| interactions over processes and tools Working software
| over comprehensive documentation
|
| Nothing in Agile has actually overcome the problems of
| horizontally scaling a team, and things like this stand in the
| way of scaling one vertically.
|
| Scaling developers vertically requires having support tools,
| processes, and people to get past the things that trip them up
| and back to forward progress. They don't have to be big tools,
| or big processes. In fact it's much more important that they be
| reliable than that they have huge feature sets.
|
| But Agile without tools and processes? Show me anyone who is
| pulling that off, and I'll show you someone who has mislabeled
| a bunch of things as 'not-tool' and 'not-process'.
| ipnon wrote:
| My thought to every line quoted is "why?" What are the actual
| principles involved, and why don't we just jump straight to
| those when making process decisions? Manifestos do more harm
| then good because their vagueness enables reinterpretation.
| patmcc wrote:
| https://agilemanifesto.org/principles.html
| [deleted]
| unethical_ban wrote:
| A manifesto _is_ a set of principles. Principles tend to be
| vague.
| myth2018 wrote:
| > Manifestos do more harm then good because their vagueness
| enables reinterpretation.
|
| That totally relates to my experience.
|
| I've seen this scene repeated over and over:
|
| - project begins
|
| - something happens and delays the project (arrival of new
| team members who need some time to learn about the code base,
| for instance; it's not even an issue, it's just a natural
| consequence which makes the project go different than planned
| and put certain kinds of managers in distress)
|
| - project start to get behind of the schedule or whatever
| tool in use to track progress
|
| - "you are not a true Agilist"
|
| I just can't understand why is it so easy to blame the old
| methods while it's so hard to identify weaknesses in the
| current ones.
|
| Besides, the room they left for interpretation leads to a
| good amount of bike-shedding and witch hunting as soon as
| something goes wrong in the project -- if one assumes the
| method is perfect, the only possible explanation for a
| failure is that the method has been misfollowed.
| closeparen wrote:
| Considering that "old-school non-agile" can mean many different
| things, it would be very surprising if Scrum were uniformly
| better or worse than _all_ of them.
| blablabla123 wrote:
| Pros: if done properly it makes software delivery actually
| predictable
|
| Cons: everything else :-)
|
| I enjoy the non-scrum world, but every time I try it, I realize
| how bad it actually is for everyone involved, especially if there
| are timelines. But also I think unless you're sufficiently
| experienced, Scrum is micromanagement hell indeed.
| kissgyorgy wrote:
| A lot of people misunderstand it, but what agile says is
| basically that "you should talk to each other more often" and
| "you should make smaller steps". So it's a YES from me.
|
| If you never seen this, you should read this ASAP:
| https://agilemanifesto.org/
|
| Because that's all there is to know about Agile. Obviously it
| takes a bit more time to really grasp how can you translate that
| to lines of code or building a deployment pipeline or shipping
| features, but if you understand these couple of lines, you
| already know enough about agile development.
| laurent92 wrote:
| I think Agile is best learnt by first failing a 1-million
| dollars Waterfall project.
|
| "Kids today don't know" what it feels like, explaining lawyers
| how you didn't feel the wind turning after spending 9 months
| delivering layer 1 and 2 and crossing your fingers that layer 3
| will be a wrap-up. Once you have seen that, the "less
| paperwork, more interactions", the "add value not layers"
| become a relief ;)
| djcjr wrote:
| The opponent is software complexity. The task is iterate design,
| to create a simple solution. Money will be made or lost depending
| on whether the solution is both simple and useful enough.
|
| Scrum, management, meetings distract at best, crush at worst,
| this critical creative process.
| mattzito wrote:
| I've always been a fan of a light agile process - every few weeks
| you sit down and come up with a target for the subsequent
| interval - 2 weeks is a good start, shouldn't be more than 6-8
| weeks. Within that, you define what you want to work on - could
| be a particular milestone within the project. Could also be user
| stories, doesn't really matter as long as everyone has a good
| sense of what the next milestone is.
|
| Then you check in as a group on a weekly, or maybe twice-weekly
| basis, with an explicit goal of identifying risks and
| uncertainties that have arisen during that timeframe.
|
| The goal here is not to micromanage, but to give a sense of
| progress towards a goal - whether a metric shift, a release, a
| roadmap commitment, etc. If you don't hit your interval
| milestones a few intervals in a row, your high-level thinking
| about timing is wrong, and you need to adapt the project or the
| timing.
| tanseydavid wrote:
| The definition is just too loose and what we seem to wind up with
| in many cases is a Cargo Cult version of Agile/Scrum.
|
| As an example, I have never had a PM/Team practice Agile/Scrum in
| a manner where the total amount of Work-in-Progress is something
| that gets paid attention to.
|
| In my opinion this is a very serious error.
| jimmyvalmer wrote:
| Speaking as someone from the financial world who was shocked to
| learn about daily standups, no, agile is complete * invented and
| promoted by non-technical armchair lieutenants.
|
| Mba-speak, translated:
|
| Value prop = You don't really need this
|
| Data Science = Not a Real Science
|
| I have it more or less working = It's not working
|
| I got it working = Please don't ask me about this anymore
|
| Does this make sense? = Are you even listening?
|
| Let's stop talking about talking about the issue = We're halfway
| through this meeting
|
| Please enter a jira estimate = I am or want to be your boss
|
| Quick stand-up = I'm interrupting your flow
|
| Daily stand-up = I'm interrupting your flow every day
|
| PM = Tom Smykowski
|
| Product = Paid Intern
|
| Feature complete = See "I have it more or less working"
|
| Deep dive = I have no intention of pursuing this
|
| In-flight = I enjoy dramatizing the trivial (See "How Can We Land
| the Plane")
|
| This is not intended to offend anyone = This probably offends
| everyone
| mathgladiator wrote:
| Let's take this offline = Well... It's complicated
| pan69 wrote:
| Time-box it = Same amount of work in less time
| iab wrote:
| More-or-less working, emphasis on "less"
| master_yoda_1 wrote:
| I am not even understand the purpose of manager in the team.
| steerpike wrote:
| Agile is the worst possible way to deliver software except for
| everything else we've tried.
| lawwantsin17 wrote:
| The surface area of a project is a fractal. Don't rathole.
| Writing tickets is the problem. Stand ups are so the mngr has
| something to say to his boss at his stand up.
| droobles wrote:
| no
|
| too much chin wagging, not enough building too much synchronous
| communication
|
| for being called agile you don't build software very quickly with
| it
| superbcarrot wrote:
| The topic is kind of broad but to focus on standups, I have a
| couple of firm beliefs:
|
| - Standups don't need to be daily - it's too much. Twice a week
| is okay (this can be adjusted depending on team/product
| dynamics).
|
| - They shouldn't consist of everyone telling everyone else what
| they're working on. This practice is boring and useless to anyone
| who is present. (If you want to check what I'm working on, log
| into the issue tracking system and look at the tickets against my
| name.) Instead, standups should focus on pieces of work that need
| to be delivered or that need to change status.
| rkv wrote:
| > They shouldn't consist of everyone telling everyone else what
| they're working on.
|
| It's a common habit people fall into when transitioning to
| scrum. An experienced scrum master should never let this happen
| though.
| res0nat0r wrote:
| I've been at jobs now for ~7 years and subjected to this.
| Everyone has to list what they're working on, everyone else
| ignores what is being listed/talked about until it is their
| turn and I feel like I'm repeating myself 10x a day. It sucks.
| tanseydavid wrote:
| This is the most common example of the Cargo Cult version of
| Agile/Scrum.
| giulianob wrote:
| Definitely my biggest gripe is story points + estimations. It's
| just completely flawed. We should be thinking more probabilistic
| (i.e. there's an 80% chance we'll get this done in 2 weeks). We
| should be doing that by running actual models on past work rather
| than gut feelings.
|
| If you want to listen to a couple of guys I used to work with who
| really know what they are talking about, check out this series:
| https://www.youtube.com/channel/UC758reHaPAeEixmCjWIbsOA/vid...
| frugalmail wrote:
| That's why Kanban with throughput/cycle-time makes so much more
| sense.
| jimbob45 wrote:
| https://owenmccall.com/high-performance-role-process-vs-
| outc...
|
| This article gave me clarity between the two philosophies.
| Kanban is about perfecting the process and trusting that
| results will naturally come as a result of that process.
| Agile is about attaining the outcomes and then focusing on
| what works for those outcomes.
|
| I agree that Kanban makes more sense but Agile allows
| managers to point the finger at devs instead of having to
| point the finger at themselves.
| matwood wrote:
| I see probabilistic accounting for unknowns. An 80% chance
| would have some a small amount of unknown, so if the task was 3
| points, I would bump it to a 5 to account for the known. And,
| since points are not linear, the larger task automatically
| grows proportionally, i.e. 8 -> 13.
| giulianob wrote:
| Points are flawed. Whether you have them grow linear,
| exponentially, or fibonacci doesn't make a difference. The
| fundamentals are flawed. They cover it in their videos and in
| more depth their talks/books.
| UK-Al05 wrote:
| Monte Carlo estimations and probabilistic estimates take
| longer to do.
|
| I don't know how they do it, but you used to have to group
| stories to stories of similar effort done in the past in
| order for the simulation to take into account story size.
| Otherwise your model will be effected by things like
| stories in different components taking more effort to do.
|
| Putting stories into rough size pots is essentially what
| pointing is.
| imbnwa wrote:
| I remember noticing this on my first frontend job 5 years ago.
| How are in hell are they accurately measuring any kind of
| performance? I'm sure it can actually be done but enterprise
| half-asses even that, likely because keeping it all slightly
| arbitrary allows for more ambiguity to leverage against workers
| (keeps them paranoid rather than certain, elites don't like
| safety amongst workers).
| hinkley wrote:
| > How are in hell are they accurately measuring any kind of
| performance?
|
| You aren't, and that's the grift.
|
| I force developers to do something they are bad at. They get
| better, but they're never 'great' at it. So I can withhold
| raises they deserve because I'm punishing them for what
| they're not good at instead of rewarding them for what they
| are great at.
| ipnon wrote:
| I wonder how much more accurate estimations would be if we had
| engineers actually draw probability curves that are then
| aggregated and analyzed. As it stands now, having had some
| experience getting burned, I always give my estimate that's
| really at the tail end, and I have become exceedingly efficient
| at explaining why that estimate is how long it will "really
| take."
| giulianob wrote:
| Estimating a single task is only really important to keep
| your cycle time in check and have the conversation about
| "should this task be broken down?"
|
| Estimations from engineers shouldn't be used to forecast when
| a feature will really be done. That's where the model comes
| in and probabilities comes in.
| alephu5 wrote:
| I understand your gripe but in a business setting you need some
| estimate of cost, even if it's on the order of hours, days,
| weeks etc. In my experience it's often cheaper to just get
| stuck in rather than trying to accurately predict the effort,
| since a single developer prototyping some solution for 10 hours
| goes further than 10 developers in a meeting for an hour. I'd
| say call a spade a spade, and put time estimates on these
| tasks, and admit that velocity is a measure of your bias (if
| you correctly estimate it will always be 1).
|
| What really gets me about story points are the Agile folks who
| say "story points are a measure of complexity not effort/time".
| As if adding more complexity in the same amount of time were a
| good thing...
| serial_dev wrote:
| One approach I want to try one day is described here in the Shape
| up book. It's free and takes around 2-3 hours to read cover to
| cover. The idea I liked the most is that it made me shift from
| "How much effort and time we need to solve the problem" to "How
| much effort we are willing to spend on solving the problem, then
| find a solution that matches that 'hunger', 'willingness'". It
| makes simplifications of solutions viable.
|
| But the books is full of gems, so my two sentence overview
| doesn't do it justice. Read it here https://basecamp.com/shapeup
|
| With that said, I don't expect any manager to allow us to try
| out. People love that they can hear people every day that they
| are all very busy.
|
| My current Scrum experience is from a large retail company. Our
| mobile app team of ~8 devs tries to keep up with the web team of
| ~50 devs (or even more, I just started and we work remote, I have
| no clue about the exact numbers).
|
| The schedule, roadmap is mapped out for at least the next year.
|
| Then, the Scrum doesn't make any sense. We can't decide what's
| important for the user. We can't work on bugs (that makes the
| lives of our users miserable) because we work on big feature
| launch X, and if we don't finish, it will jeopardize big
| migration Y in 2 months, and then it'll make big relaunch in
| Country Z impossible in 4 months.
|
| It's waterfall with two-week crunch times and daily standups. And
| our ratings in the app store are constantly declining. But hey,
| at least we are on time, no matter how terrible our app is, in
| Jira it says it's shipped so don't whine about software and
| product quality.
|
| During my whole career (about 5-ish years), I didn't find a place
| where a standup every day made sense. I think two or three sync-
| sessions per week would be perfect. Daily standups just made
| anxious, nobody listens to the others, you either say too little
| or too much, and the original promise of standups just didn't
| match my every day experience: we never found blockers we
| wouldn't have found otherwise, etc... In my opinion, pair/group
| programming (2-3 ppl) is thousand times better.
| mathgladiator wrote:
| Fundamentally, it's about discipline. The problem is that people
| don't know how to balance.
|
| Management needs tools to detect (1) slippage, (2) true cost, (3)
| emerging issues.
|
| Engineers need to not silo, work together, make progress, and
| share status.
|
| Amazon would do it at 11am, and it would last no more than 10
| minutes for a small team. Every two weeks, management and
| engineers get in a room to holistically determine where things
| are at, and then they go and report status up.
|
| What I would tell teams that I bootstrap is that the process
| itself doesn't matter, but the team needs a shared discipline to
| be effective. Their team has desired outcomes and everyone needs
| to be accountable for making progress.
| myth2018 wrote:
| The pros and cons are typically thought of as intrinsic
| properties of Agile in general. But they are not.
|
| Agile has a number of assumptions regarding organizational
| culture and the people involved on the project. Those assumptions
| are usually not discussed very often, which is bad, since I
| believe they are typically related to those many cases of failed
| Agile implementations that end up getting different explanations
| depending on how one likes/dislikes Agile.
|
| To summarize what I'd like to answer about your question:
|
| Pros:
|
| - They are great tools to break larger projects into smaller
| chunks and to keep track of their progresses. Experience shows
| that it's easier to reach success on smaller projects, and
| sprints and daily meetings are ways of emulate such sort of
| project even when working on larger ones.
|
| - There's an opportunity of catching and fixing schedule
| slippages, requirements misunderstandings and other sorts of
| deviations before they get too expensive to fix.
|
| Cons:
|
| - You need a bigger deal of maturity and commitment of people
| involved. As IT professionals, we usually complain about users
| being unprepared for working on Agile projects, but we have to
| admit that many professionals show a significant decrease in
| performance when they are not under a certain level of healthy
| pressure.
|
| - When you favor people over processes and communication over
| documentation, a higher level of mutual trust is required. You
| can't find that everywhere, for a number of reasons. Some say
| that such organizations are not prepared to work under Agile
| rules. Some are more pragmatic and adapt. I stick with the
| latter. Agile talks a great deal about embracing change on
| requirements, and I don't see what is the point of being a purist
| and refusing to adapt the method to deal with risks.
| jimbob45 wrote:
| What matters is critical thought in optimizing whichever
| methodology you use for your team.
|
| No methodology works right out of the box and it's insane to
| think that any could. You have to look at your specific
| requirements and mold Agile around your team. Agile literally
| says to do this but most just ignore it.
|
| The more thought you put into your methodology, the better it
| will work. I know most want Agile to replace critical thought
| because they don't want to have a target on their back if things
| go wrong but there is no substitute.
| mdlm wrote:
| The daily standup is not part of agile.
|
| Agile is defined here: http://agilemanifesto.org/
| mytailorisrich wrote:
| The manifesto lists principles. Principles must be implemented
| and turned into processes in order to actually produce
| software. Scrum's daily stand-up is a process, a tool, to
| implement the following principle:
|
| " _The most efficient and effective method of conveying
| information to and within a development team is face-to-face
| conversation._ "
|
| And it also contributes to this one:
|
| " _The best architectures, requirements, and designs emerge
| from self-organizing teams._ "
| g051051 wrote:
| _" The most efficient and effective method of conveying
| information to and within a development team is face-to-face
| conversation."_
|
| That statement indicates just how broken the whole idea of
| "Agile" is.
| gijoeyguerra wrote:
| I believe the daily standup is part of XP
| (http://www.extremeprogramming.org) which is an Agile Method.
| sli wrote:
| It's part of Scrum, which itself is also an agile method.
| [deleted]
| timwaagh wrote:
| Daily stand-up has the pro from a management perspective that
| people feel pressure to perform. It does make sure people focus
| on the things they should be focusing on. The associated con is
| that not everyone performs under pressure.
|
| The pro of having a sprint is that the team knows what they can
| do in advance. I don't need to ask my boss for a new task, I just
| pick the topmost of the board that's not been worked on. The con
| is sometimes added pressure to finish a sprint (beyond normal
| pressure and without real-world cause) and a lot of time wasted
| in team wide meetings to plan a new sprint.
|
| 'refinement' meetings as far as I understand are unfortunately
| usually a waste of time.
|
| Estimations in terms of 'effort' points are a recipe for failure
| because ultimately they will be converted into man-hour units yet
| were not supposed to think of them as time but 'complexity'. As a
| result velocity and burn down tools are just a cause for strife.
| I'd recommend using a normal time unit instead. Skip the
| conversion.
|
| The other way these things can possibly be made useful is if the
| most important metric is not velocity but reliability (which most
| teams don't use but is used in at least one team in my org).
|
| Personally I don't like agile/scrum but if I'd have to do it
| myself I would keep at least some elements, like the board you
| can take tasks from. Standups I would like to see alternatives
| for. Estimations I would try to do myself or maybe have a tech
| lead do. I wouldn't even bother communicating it with the rest.
| Ultimately I never learned anything besides agile scrum so I'd
| have to adopt at least parts of it no matter that I dislike it.
| dmead wrote:
| No.
|
| Agile/xp started at Chrysler as a way to push back on management
| on give engineers a chance to pace/structure/set expectations for
| their work
|
| Modern agile is just a management framework used as an excuse to
| micro manage the shit out of your work force.
| imbnwa wrote:
| Yeah, it's not complicated. What's crazy is the way lots of
| engineers rationalize all this instead of just being empirical.
| I think software selects for authoritarian personalities to a
| degree, who are quite comfortable pretending to be avatars of
| rule of law (they are merely messagers who can also disavow
| merely being a messenger) rather than looking at what's
| actually happening in front of their eyes, like the adversarial
| nature of most Product teams in most mediocre orgs.
| gijoeyguerra wrote:
| Yes. If by Agile you mean development practices like continuous
| integration (periodically integrating changes into a single
| environment so that the system can be tested) and creating short
| feedback loops like devs testing their code; and by Scrum you
| mean creating team routines for reviewing assumptions and the
| team talking directly to customers; and periodic reflection to
| improve processes, then yes, I do.
|
| Daily Standups are supposed to be Daily Planning Sessions for the
| Team. But the common implementation has devolved into status
| update meetings.
|
| So the con is that, more likely than not, it will be a status
| update meeting, in which case, a waste of most people's time.
|
| If it's a Daily Planning Session, there are no cons, only pros.
|
| The pro is team alignment, with each other and with project
| objectives and goals, with only a maximum of 24 hours for
| possible misalignment.
|
| Misalignment is ALWAYS the problem. Daily Planning Sessions help
| mitigate that ineveitability.
| [deleted]
___________________________________________________________________
(page generated 2021-03-04 23:01 UTC)