[HN Gopher] Agile's early evangelists wouldn't mind watching Agi...
___________________________________________________________________
Agile's early evangelists wouldn't mind watching Agile die
Author : prepperpotts
Score : 361 points
Date : 2020-04-24 16:05 UTC (6 hours ago)
(HTM) web link (builtin.com)
(TXT) w3m dump (builtin.com)
| viburnum wrote:
| Corporate agile is a mixed bag but Extreme Programming is still
| good though.
| swagtricker wrote:
| I fully agree. In general, any flavor of agile for software
| development that doesn't include the engineering focus that
| Extreme Programming's technical practices bring in (fast
| feedback, refactoring, good testing & design, CI/CD deployment,
| team ownership of the solution - weather you pair program or
| not) is doomed to become intractable legacy after 12-18 months
| at the most optimistic.
| zabil wrote:
| > software developers need to become what they truly are:
| engineers.
|
| I couldn't agree more
| drapred7 wrote:
| What does that even mean? Its just some vague feel-good
| platitude like everything else in agile.
| zabil wrote:
| Fair point. I wish I could explain, but don't want to try.
| For the record, I've been knee deep in Agile.
| vbtemp wrote:
| For the past several years now, each time I join a new team or
| project, my first objective is to detach and destroy the "Agile"
| process workflow.
|
| When you finally liberate a team from Agile, it's just
| breathtaking how much you can focus on delivering working
| software that gets deployed with quick iterations that's closely
| aligned with the business and customer's needs. When free from
| the tyranny of Agile, teams can be effectively self-organize,
| remove micro-managers, and quickly adapt to changing needs and
| requirements. My experience is that staff are usually much
| happier, more productive, and less stressed once agile is gone.
|
| I mean contemporary Agile as pushed by corporations and those
| awful "coaches" (who never seem to be actual developers) --- if
| you were you design a system whose end goal was making great
| developers unhappy, unproductive and locked into a dysfunctional
| system, Agile would be it.
| trimbo wrote:
| > it's just breathtaking how much you can focus on delivering
| working software that gets deployed with quick iterations
| that's closely aligned with the business and customer's needs
|
| That's literally the agile manifesto.
|
| "Scrum" is one implementation of what agile was trying to
| achieve. Maybe that's what you're thinking of?
| vbtemp wrote:
| > That's literally the agile manifesto.
|
| I know, that's the irony. Agile as pushed today ends up with
| the compete anithesis of that. It's the difference between
| "Agile" (Capital A), and "agile"
| balfirevic wrote:
| Parent's post so closely resembles the agile manifesto that
| it's got to be on purpose.
| Jtsummers wrote:
| There's Big-A Agile and agile. The manifesto is really the
| latter, the former is a set (different depending on where you
| are) of very specific practices that neglect the principles
| in the manifesto (though, typically, they were derived from
| them originally).
|
| Read _SAFe Distilled_ or _SAFe 4.5 Reference Guide_ for what
| happens in large enterprises (god SAFe is a fuck up). It
| consists of some good ideas, but also some very explicit
| practices that don 't help in every effort (and sometimes
| hurt). It is literally the opposite of Agile, which is
| supposed to be about flexibility.
|
| If you want to hear about its "success", just remember it was
| used for F-35's software...
|
| Big-A Agile is based on the belief that adoption of practices
| is sufficient, and that deep understanding is unnecessary.
| This is the realm of cargo cults.
| vbtemp wrote:
| > If you want to hear about it's "success", just remember
| it was used for F-35's software...
|
| This is the example I use all the time!!
|
| Maybe agile is great when you're making an online shopping
| cart for a e-commerce website, but the idea of using Agile
| for complex, engineered systems is laugh-out-loud
| hysterically absurd. And this does not just mean
| spaceflight software, it basically means anything more
| sophisticated than a CRUD app.
| dankoss wrote:
| Totally agree. I believe Agile works well in environments
| with shallow tech stacks, but it has worked terribly in
| my experience in product companies that build hardware,
| FPGA dev, embedded software, and other disciplines that
| can't deliver on two week increments or increments that
| align well with other disciplines.
| Jtsummers wrote:
| Agile can work well in embedded, I've seen and done it.
|
| The thing people have to forget is the notion of "deliver
| on two week increments". It's not about delivering a
| product that can be fielded each increment, in the case
| of an embedded system, but about delivering something
| that has some improvement or new testable component. I
| can't make an embedded radio handle, in two weeks, a
| completely new message type (well, depends). But I can do
| things in each two week interval that is verifiable. I
| can show that I've actually received the new message,
| that I can send it back out, that I can pass it through
| the various internal processors (if multiple processors
| are used) or processes (if a single one). Then I can
| start transforming it, storing it, changing other things
| about the radio state based on the message contents. Each
| of those is independently verifiable and completable
| within a short period of time. But taken as a whole, it's
| a 6-month project. The agile way has you make those small
| things, verify them, and then move on to the next thing.
| I can deliver (to the test team, to others using the
| system) the partially-completed system, it just can't be
| fielded (and that's fine).
|
| And that's not unique to embedded. If you only focus on
| things that can be fielded in each increment, you'll
| never develop the more complex tasks, or address the tech
| debt.
| andarleen wrote:
| "and it's pushing women engineers into non-technical roles" - wtf
| drapred7 wrote:
| Feminists are always promoting numerous and spurious
| explanations for why women seek out non-technical roles The
| qualities of women themselves being a sexist and therefor a
| priori false explanation.
| adwn wrote:
| > _Women dominated computing professions from their inception in
| the 1940s all the way through the 1960s. As the scope of
| computers' usefulness became clearer, however, those jobs started
| going to men._
|
| Bullshit. Back then, the term "programmer" didn't mean what it
| means today. A "programmer" was someone who entered a program
| into a computer, or even earlier, plugged in wires according to a
| schematic. The actual development of the program was almost
| exclusively done by men, even more so than today (this is not
| supposed to be a value judgement, nor do I want to justify the
| situation back then or today).
|
| It's really disappointing to see this tired myth of a supposed
| "Golden Age of women in computer science" repeated in the
| article.
| raarts wrote:
| Related: the article is misguided on the women thing.
|
| I teach CS in college. I see it every day. Women on average are
| more interested to work with people than men. This hasn't
| changed despite trying to boost girls' interest in typical STEM
| fields for 25 years. HR departments have been pouring money
| into this like mad. Hasn't moved the needle. Research has shown
| that girls don't fare worse in math tests if they are told
| beforehand that girls are worse at math. In countries where the
| sexes are treated more equally men more often choose thing-jobs
| and women more often choose people jobs.
|
| Who thinks that if society would treat everybody completely
| equal, all occupations would end up exactly even distributed
| across the sexes? There are real differences between the sexes.
|
| The push towards exact equal distribution in everything is
| futile, hasn't worked and will not work.
|
| I think it's more important that people can choose to do what
| they want to do.
|
| Sounds like a rant, sorry.
| Yhippa wrote:
| Nearly everywhere I've worked the quarterly earnings report is
| the problem. Due dates mean that time has to be managed so any
| attempt to use a methodology seems to regress to some not fun way
| of developing software.
|
| In places I've worked without the pressure of the quarterly
| earnings report I've seen that developers tended to use whatever
| methodology worked best. It could be Agile, pair programming, or
| just walking over to each other's desks and talking on IM.
| jahaja wrote:
| I guess it's hard to keep methodologies from being co-opted by
| management for their own ends, since they do after all have the
| "power".
| corpMaverick wrote:
| Managers trying to control engineers. I don't know how we are
| OK when people in charge don't understand what they are
| managing. Agile was an attempt to take control back to
| engineers but it was co-opted.
| kradroy wrote:
| I implemented Agile scrum on my team at the behest of my
| organization. I did it enthusiastically at first, because I
| thought it might make a difference. My opinion changed within
| the first 6 months. I think it's a waste of time.
|
| Our stand-ups are pointless because they're just status
| updates. Not much of consequence can happen in 10 minutes
| anyway. I ignore our metrics at the end of each sprint. They're
| meaningless. Our retrospectives are largely useless other than
| giving shoutouts to team members. I feel the sprint structure
| leads to Parkinson's law.
|
| This situation, however, is perfectly normal because Agile
| advocates "people over processes." My team doesn't give a shit
| about the Agile process, so it's mostly like forced physical
| training but without the fitness benefits.
| swagtricker wrote:
| Scrum should at best be viewed as training wheels for agile
| teams. Not the end state. Good teams abandon scrum for Kanban
| / Lean concepts once they start building good collaboration
| structures, better communication with business, earn trust by
| delivering and recognize (as you point out nicely) that the
| sprint timebox is artificial B.S. in practice. I think the
| Parkinson's law can be a common trap for teams to fall into
| with the Sprint timebox malarkey.
| vpeters25 wrote:
| This 100%. One of the reasons people hate Agile is because
| they miss this point and keep micro-managing.
| legitster wrote:
| There are many fingers to point here, but I point mine at bigger
| consulting firms like Accenture. I have first hand experience
| with their miserable "agile" process at Microsoft.
|
| If you want a stapler, you have to schedule a meeting 3 weeks in
| advance with 2 team leads and 3 contractors who decide what
| sprint "getting a stapler" will be assigned to. Then "getting a
| stapler" gets pushed back two sprints because some priority came
| along (a vice president somewhere just learned that his binder
| was on hold for four months). An Accenture contractor from India
| informs you that a hole punch is on the way. Apparently you
| checked the wrong box on the stapler requisition form, so you
| have to start the process over again.
|
| Then the Accenture quarterly deck shows they met 97% of all
| stapler demands for the quarter! Isn't life so much more easier
| and more measurable now? But they will need to hire more
| contractors to keep up with capacity.
| MattGaiser wrote:
| That is Agile as a religion.
| aeturnum wrote:
| If you should meet Agile along the road, destroy it!
| winrid wrote:
| When I was a manager I'd get the team together every quarter and
| we'd agree on "this is what we're going to do" - and then we'd do
| it, usually. At the end of the quarter we'd have to explain why
| certain pressures pushed things out, but usually the business
| cared more that we kept churn down.
|
| For over a year I pushed back on story pointing and things that
| felt micro manage-y to me.
|
| It was very hard on me, but it was worth seeing the productivity.
|
| Eventually I was forced to give in to Agile with the big A and
| left soon after.
|
| I can't get another management job because everyone wants to do
| Agile in a way I hate to manage - so now I'm a developer again...
| :)
| raiyu wrote:
| Can we just replace agile, and every modern management practice
| with some mix of common sense, talking to the customer, talking
| to the team, and being able to voice concerns to upper management
| where people actually listen instead of running their own agenda?
| =]
| robjan wrote:
| What you just said can't be packaged up and sold as training
| courses or countless books, which is why it hasn't prevailed.
| danieldisu wrote:
| The main problem for me is the misalignment of goals between
| upper management, middle management and the rest, the higher
| you climb the less interested they are in they user/client,
| they only care about some bullshit metric that will end up
| paying their bonuses. This is specially visible in public
| companies where they only chase the metrics that the market
| looks in that decade, ignoring the rest or the actual user
| satisfaction (they do try to put a metric on that, with
| bullshit forms and all :))
| projektfu wrote:
| XP, and several other processes, identify the problem as a
| mismatch between the goals of the developer and the actual
| customer (not necessarily the end user). Management doesn't
| figure prominently in the solution which is probably one
| reason why a different form of Agile is usually chosen. I
| also don't know why businesses are so reluctant to have their
| customers involved in software development. But you're
| definitely right, when all the incentives align on the axis
| of management and their needs, you get garbage.
|
| This is not to say that management isn't useful or necessary,
| but they are a facilitator of work, not the patron.
| Leherenn wrote:
| Because the goals and needs of the upper management and of
| the customers do not align.
|
| There's a lot of companies where delivering what the
| consumers want/need is not the end goal of the company, at
| best it's needed to help fulfill the end goal.
| hn_acc_2 wrote:
| But this is the root of all these issues... Because everyone
| has a different perspective that underlies their "common
| sense," so this system of unspoken agreement just falls apart.
|
| When you throw in the incentives of compensation and career
| advancement, politics and human nature are bound to corrupt the
| process further.
|
| This is why codified process will always be better in the long
| run for most companies, because it's the only tool possible for
| combatting this
| asplake wrote:
| ...until codified process becomes the problem. It never ends!
| brazzledazzle wrote:
| People that corrupt a process are often the ones it's
| designed to stop. It's not even done with ill intent more
| often than not.
|
| How do you create a paradigm or process that can be amended
| adapt to a persistent threat without that amendment process
| itself being used as a tool to corrupt it?
| asplake wrote:
| I completely agree that you don't need to assume ill
| intent. But by that same token, the fact that a paradigm
| or process isn't invulnerable does not mean that it
| shouldn't be used.
|
| Bureaucracy, heavyweight process, and all rest are ways
| that systems protect themselves. Wasteful though, which
| is why new paradigms such as Agile come along.
|
| Now the Agile ecosystem has become corrupted by a process
| not comparable to all the above. Not solvable by those
| means either. It's a toughie.
| Ididntdothis wrote:
| "being able to voice concerns to upper management where people
| actually listen"
|
| I think that's what's missing in most companies. We have 360
| reviews, retrospectives and all kinds of stuff but there is no
| feedback channel up the chain. At my company whenever there are
| obvious problems management secludes itself and then a solution
| will be revealed to the underlings who never got heard.
| Especially in tech it's pretty safe to assume that engineers at
| the bottom of the pyramid are as intelligent and educated as
| people further up the chain so I think their input is valuable.
| btilly wrote:
| This problem is endemic.
|
| It is human nature that when talking to your boss you put
| things in the most optimistic way that fits your
| understanding, and your boss hears it even more
| optimistically. After a few steps up the chain this results
| in a complete disconnect from reality.
|
| http://www.stamey.info/Humor/shithappens.htm is a humorous
| but basically accurate take on the dynamic.
|
| Now, you say, reality eventually intrudes. Yes, but it is
| normal for upper management to not realize that deadlines
| will slip until about 2 weeks before they do. And will
| continue to think it is about 2 weeks off indefinitely.
| Jtsummers wrote:
| > It is human nature that when talking to your boss you put
| things in the most optimistic way that fits your
| understanding, and your boss hears it even more
| optimistically. After a few steps up the chain this results
| in a complete disconnect from reality.
|
| I learned this the hard way, maybe 3 months into my first
| real job. I was testing safety critical systems, but it was
| still being developed so the tests procedures were also
| being developed and executed. I was asked for my status, I
| said: I've tested about 60% of the system (this one was
| small enough that that sort of statement was actually
| valid), everything has passed so far. My boss heard:
| Everything passed. He released the build to the customer,
| who found a failure almost immediately (about the same time
| I did, but I had no idea it had been released). I was taken
| into a conference room and chewed out for making us look
| like amateurs (we were, when it came to software). I
| learned several things: 1) I needed a new job; 2) Never use
| the words "done", "everything", "all" until everything is
| actually all done, managers only hear those words and
| nothing else.
|
| > Now, you say, reality eventually intrudes. Yes, but it is
| normal for upper management to not realize that deadlines
| will slip until about 2 weeks before they do. And will
| continue to think it is about 2 weeks off indefinitely.
|
| A manager, fortunately not mine I was his peer though he
| got promoted for his "successes", would always say that his
| products never shipped late. "How can you say that? I know
| your last release was 3 months late." "We updated the
| schedule and we hit the new schedule." "But you didn't
| update it until the last month. It was 2 months late by
| then already." "But we hit the final scheduled release
| date." He just got lucky that the customers weren't loud
| enough for his boss to realize the spectacular, repeated
| failure until after he got promoted. The new manager got
| hit with it instead.
| karatestomp wrote:
| I too have seen that hears-half-of-what-you-said-and-
| only-the-good-parts, then gets mad at you because _they_
| are shitty listeners, in action. Hell, I 've seen it with
| a guy who appeared to constantly be taking diligent
| notes, they were just very often _incorrect_! It 's
| infuriating and there's no arguing with them because they
| just think you're lying or misremembering (even if you
| _also_ took notes, or even prepared them in advance then
| read from them, and, unlike theirs, yours don 't suck).
| The only way to deal with it is to communicate in
| writing.
| commandlinefan wrote:
| None of that is ever going to happen until management accepts
| that developers can't give an accurate timeline on the spot,
| immediately, after a 10-minute overview of the project. Which
| means never.
| darepublic wrote:
| Product Manager > Everyone vote on the story points for this
| task. Hold up fingers two or three. You there.. why did you
| put up three?
|
| Me > Well um.. because I just thought ticket B is a three and
| this is comparable complexity.
|
| Lead Dev > Yea... this is a two. I mean ticket B.. that can
| be a two too.
|
| Me > Ok
|
| Product Manager > Next ticket. Let's say a five? Or a four.
| Everyone hold up your fingers, is this a five or four
|
| Me > (Looks around to see the popular choice. Holds up the
| same number of fingers)
| dane-pgp wrote:
| I experienced a similar situation. The team leader looked
| back at the past few sprints and worked out how many story
| points we had completed, and calculated how much our
| salaries had cost the company in that time, to work out a
| "cost per story point".
|
| He then went off on his own to talk to upper management and
| committed, without our input, to large new pieces of work,
| and was told what the budgets for those deliverables were.
|
| At the next sprint planning, he was basically telling
| developers their estimates were wrong because the number of
| story points we were deciding equated to more money than
| the budget for those features.
|
| Rather than play along, I simply said "Well why don't you
| come up with the estimates for us, then?".
|
| To his credit, he did then stop trying to influence the
| votes after that, but it wasn't long before the product was
| put into maintenance mode and he was assigned to a
| different team.
| projektfu wrote:
| Most process pathologies are the result of common sense.
| Waterfall is a description of the usual reaction to undesirable
| results on the first project--add more planning steps and make
| people sign off on phases before moving to the next, more
| expensive phase.
| adamsea wrote:
| I think the words we're looking for here are "accountability,
| responsibility, leadership" ;) :/ :| :(
| Hermel wrote:
| That sounds almost like the original agile manifesto.
| balfirevic wrote:
| Are you saying we should emphasize individuals and their
| interactions, customer collaboration and responding to change?
| Perhaps also working software?
|
| Well, who would have thought :)
| Ididntdothis wrote:
| Publish it and you will be rich. Just don't call it "Agile"
| and nobody will notice.
| cs02rm0 wrote:
| No, because management.
|
| A key success of agile was to provide a buzzword that let
| engineers say no when they were asked for a fixed estimate for
| a fixed-until-it-changes scope to fit in a Gantt chart.
|
| Take agile away and they'll be straight back to demanding to
| know how long it's going to take to build something when no
| one's really sure what the something is.
| plughs wrote:
| My first team, some 14 years ago, had the best experience with
| Agile. What made this work
|
| > During planning, everyone understood that the estimates were
| _estimates_. Tasks could take longer or shorter, that was OK and
| even expected. The goal was to improve velocity, not to
| accomplish every story, every time.
|
| > Engineers felt comfortable taking stories in areas they knew
| nothing about. A stated goal was that every engineer understand
| every piece of the project.
|
| > Standups were team only. Engineers felt comfortable saying they
| got stuck or needed help or got lost in a rathole and didn't make
| the progress they hoped.
|
| > Demos were important so that the team and the clients could
| understand what had changed and what new features were available.
|
| But it quickly got lost - managers and PMs and Directors got
| involved and Jira boards became published for all to see. (In the
| beginning it was whiteboards and sticky note). Standups and Demos
| were all about self-promotion. No one ever wanted to take on a
| task they weren't 100% certain they could do. If a task was 3
| point it needed to be done in 3 days or there would be questions.
|
| When I left the last company it had gotten outrageous. Every task
| should be completed in three days and in production in five days
| - and if not that team was Doing Something Wrong.
|
| ( We were told that this was standard FAANG practice, I have no
| idea how true that was )
|
| What happened was what you'd expect - shortcuts, tech debt, unit
| tests cynically design to pass and meet code coverage
| expectations instead of actually usefully testing.
|
| The reality is that any process is going to fail one senior
| leadership decides it's a way to evaluate engineers, not create a
| good product.
| analyst74 wrote:
| I agree with what you say in principle, but just to play
| devil's advocate.
|
| One difference between those highly paid software companies and
| others, is the expectation of performance. Netflix famously
| considers their team a sports team rather than a typical
| corporation. It's totally common for a great engineer to bomb
| out of those companies, just like how great athletes get kicked
| off top tier sports teams when they failed to perform due to
| reasons out of their control.
|
| While most other companies, lacking the ability or willingness
| to pay top dollars, are probably better off creating a safe
| environment for engineers who can be on-par or even better than
| FAANG engineers, but lack the political maturity to survive
| those high pressure environment.
| lonelappde wrote:
| N's philosophy is famous because it's NOT how FAAG operate.
| BurningFrog wrote:
| This reminds me why the agile "customer" concept is so
| important.
|
| As a customer, you get to decide what you want to buy, and you
| get to be happy or unhappy with the delivered product.
|
| But you don't get to control or even monitor the work in the
| factory/kitchen/etc.
|
| That's instead the job of a boss! Of course, an agile team also
| has a boss. But it's not the customer.
| einpoklum wrote:
| Isn't it the case the most places "doing agile" don't
| actually involve the eventual customer in the process, just
| junior and higher management?
| hinkley wrote:
| > Engineers felt comfortable taking stories in areas they knew
| nothing about.
|
| _and it was understood and expected that this meant the
| estimate would go up_
|
| Today we have 'bidding', which if that sounds like something a
| three year old does to their parents, you'd be right, and it's
| the same thing. You just ask someone else until you get the
| answer you want to hear (instead of the one you need to hear).
| Supermancho wrote:
| > you'd be right, and it's the same thing.
|
| It's not the same thing. It's not "bidding", even if it's
| called that because the lowest or highest or middling bid
| doesn't necessarily get the work. I know, I know, it sounds
| like another "you're doing Agile wrong", but Agile already
| fucked it up by saying "bidding", so we get these wild
| stories of how companies have their laziest incompetents in
| charge of trying to make improvements to process.
|
| > You just ask someone else until you get the answer you want
| to hear (instead of the one you need to hear).
|
| Otherwise you will only have the most jr or senior people
| working on everything. The system of bidding just doesn't
| work, which is why it's not bidding in a practical sense.
|
| You ask why people put down their estimates by describing
| what they know about the work. This is an opportunity to
| transfer some cursory knowledge and reinforce pain points. At
| a very progressive "Agile" company (we would invite speakers
| and A/B tested various practices across teams), I notoriously
| inflated/deflated all estimates by bringing up edge cases
| and/or constraining objectives. Story grooming aside, there
| are always people trying to over-engineer and estimation is
| another gate to prevent that.
|
| Agile was a good try to create software process, but it's
| incomplete at best. The idea that it would evolve is
| laughably naiive (https://app.spectator.co.uk/2020/04/22/the-
| illusion-of-certa...). Companies want S&Ps, not sauce that
| they have to mix themselves.
| hinkley wrote:
| I'm not talking about Planning Poker, per se.
|
| I'm talking about the dickering about whether something is
| N points or N-2 points. Or whether the points even mean the
| same between two teams. Or whether it's appropriate to
| assign it to another team or individual who says a smaller
| number because they have a different definition of Done or
| are more or less invested in the long-term health of the
| project.
|
| I'm going to ask this person or the question in this way
| because I'll get the answer I like, even if that answer is
| unhealthy or even pure fiction.
| Zelphyr wrote:
| > We were told that this was standard FAANG practice
|
| I'm getting really tired of companies trotting out the "because
| [Facebook|Apple|Google] does it" excuse. Those are massive
| companies. Are we so delusional to believe that what works for
| a $70B/year company will automatically work for our $20MM/year
| company?
| plughs wrote:
| The craziest part of this was that it was banking software.
| Every so often someone would inadvisedly suggest that banking
| customers weren't waiting on the edge of their seats for new
| features and really really really dislike bugs. Perhaps - the
| hapless engineer would suggest - companies like facebook
| weren't the greatest model for how our company should
| operate.
|
| It was a good way to get your head bitten off.
| lonelappde wrote:
| Spoiler alert: it's not how FAANG operate.
|
| The idea that FAANG are _faster_ then your startup is absurd
| on its face. The revenue and legal risk is absolutely huge.
| joejerryronnie wrote:
| The idea that all dev teams within a single FAANG operate
| in the same manner is also absurd (much less that all dev
| teams across all FAANGs operate in some identical, optimal
| fashion).
| wpietri wrote:
| Totally. "When a measure becomes a target, it ceases to be a
| good measure. https://en.wikipedia.org/wiki/Goodhart%27s_law
|
| And as you say, managerial involvement is the problem. Managers
| and execs mostly get paid to appear to be in control, so having
| the appearance of control is vital to them, even if that makes
| the results wildly worse.
| brightball wrote:
| That is one of the all time best quotes that nobody is
| willing to hear.
| wpietri wrote:
| Which reminds me of one of the other great quotes: "It is
| difficult to get a man to understand something when his
| salary depends upon his not understanding it."
| Roboprog wrote:
| Like measuring nitrogen content as a proxy for protein?
| dkbrk wrote:
| Exactly, then unscrupulous people adulterate it with
| melamine to artificially boost measured protein.
| mavelikara wrote:
| "We are not doing it like the FAANG companies" is a refrain
| you get from engineers themselves too.
| goostavos wrote:
| Surely uttered by people who haven't been at FAANG
| companies. It's not magical over here, people.
|
| I've legit sat through 1.5 hour long calls with 6 other
| devs so we could watch our manager type notes into a
| presentation that he'll give to a collection of other
| managers who will only be half-listening until it's their
| turn to be visible, and all because some other, more
| powerful manager, decided this was important for the org to
| do.
|
| It was layers of bureaucracy so deep I wasn't sure where I
| was anymore.
| timwis wrote:
| Really insightful. Thanks for sharing.
| marktangotango wrote:
| A looong time ago I went through Army basic training. As a BS
| degree holder I was given the job of "book man". This meant I
| carried around the platoon training book and carried placards
| to put in signs at various training locations that told what
| battalion, company, and platoon we were so if anyone driving by
| a gun range, motor pool, or classroom could look and see oh
| that's 1st platoon, C company, 1st training battalion.
|
| I've come to believe that that main driver for Agile adoption
| has come to be something similar. Making visible to outsiders
| what software development teams are doing, and making progress
| (or it's lack) visible to management. I thinks that's a
| completely reasonable expectation. Businesses are paying
| exorbitant salaries and providing ping pong tables, why
| shouldn't they have visibility into what's being done?
|
| Where it becomes toxic is in areas this posts parent indicates;
| posturing, one upsmanship, pressure to perform. Effective teams
| need "safe spaces" to learn, discover, try and fail. Agile
| isn't that anymore. Hasn't been for a long time.
| jjjensen90 wrote:
| Software engineering salaries are not exorbitant. In fact,
| engineers may be consistently underpaid for the value
| delivered. A small team can create millions for executives
| and shareholders. Ping pong tables etc are a sad tool for
| management to placate the people who drive the company value
| up, to keep them from unionizing and realizing the power they
| hold.
| Jasper_ wrote:
| > Software engineering salaries are not exorbitant. In
| fact, engineers may be consistently underpaid for the value
| delivered.
|
| What about the value of those who cooked your lunch?
| Without them, software engineers would starve and die, so
| that makes them have far more value, no? Do you think that
| food service workers are also underpaid?
| loopz wrote:
| whataboutism
| sanderjd wrote:
| It is _reasonable_ but it is not necessarily the smartest way
| of going about things.
|
| The question of whom things are visible to is an important
| one. Your comment says "management", and yeah that's one
| common way of thinking about it. But managers are just
| individuals with their own motivations. It is really "the
| business" that wants visibility in order to best accomplish
| its goals. There is an assumption that "management" is better
| aligned with "the business" than the employees they are
| paying "exorbitant" salaries to. But that may or may not be
| true, managers are also just individuals with their own
| motivations. So to the extent that it is true that managers
| are better aligned with the business, why is that the case? I
| see a few things that trend in that direction: compensation
| that is more tied to the performance of the business (through
| bonuses or what have you), more visibility into the goals and
| reasoning for decisions being made by leadership, and a
| better grounding in the dynamics of the business (what is the
| strategy, how does its market work, how does it make money).
| The theory is that because of those things (and probably
| others I'm not thinking of), the managers are better suited
| to be representing the interests of the business, whereas the
| engineers are just tools those managers can use to further
| those interests.
|
| That is one way of doing it, probably the most common way,
| and it definitely seems like management visibility into work
| is extremely important in such a setup. But another way might
| be to align the engineers with the business in the same way
| managers are: pay bonuses based on the performance of the
| business, give them visibility into goals and decisions,
| teach them about the strategy of the business and the
| dynamics of how it makes money. That is, give the engineers
| ownership in the same way management has ownership, and trust
| them to make decisions that are in the interest of the
| business.
|
| To put this another way: if you trust managers to make
| decisions about trade-offs that are in the best interest of
| the business, why can't you trust engineers as well? Are the
| engineers dumber or shiftier than the managers such that they
| can't be trusted with this?
| codesuki wrote:
| The articles on this blog argue exactly the same thing.
| https://svpg.com/the-most-important-thing/ I really enjoy
| his articles, they taught me a lot.
| musicale wrote:
| > give the engineers ownership in the same way management
| has ownership, and trust them to make decisions that are in
| the interest of the business.
|
| that's crazy talk ;-)
| Tyrek wrote:
| The general line of argument here is that the managers have
| spent time and effort as part of their professional
| development in order to understand the business, whereas
| the engineers have dedicated their time towards a more
| technical focus. This is reflected in how they spend their
| days - the manager spends time in meetings, whereas the
| engineer is spending time coding (very broad
| generalization)
|
| Assuming that neither side is doing significant amounts of
| extracurricular work to bridge the gap, it therefore
| follows that management understands the business better,
| because that is explicitly the purpose of their job.
|
| In a best case scenario, it makes sense to provide
| engineers etc. with the context to understand the
| decisions. On the flip side, business decisions are often
| made upon a huge heap of context that is generally
| invisible to the engineer (unless they spend an equal
| amount of time in building up their business knowledge,
| spending time in meetings, etc. - but at that point,
| they're basically a manager?)
|
| It's not to say that engineers _can 't_ develop the
| background, etc. to make the decisions, but that it's not
| exactly part of the expected job functions, and not
| something that's explicitly looked for as part of the
| recruitment process. In a sense, this is a bit of a
| tautological issue.
| plughs wrote:
| There are certainly good reasons to make a team's progress
| visible. PMs/POs ( I'm never sure of the difference ) will
| want to know if a project can meet the release date. They
| will want to know that the need-to-have features are being
| worked on before the nice-to-have. I don't want to sat a team
| should work in total isolation.
|
| I can only say that IME a team is going to be a lot more
| productive if they are able to own their development process.
| Good infrastructure, knowledgeable engineers, healthy
| relationships instead of competitive ones - that's what
| creates a highly productive team and highly productive
| engineers.
| lonelappde wrote:
| > will want to know if a project can meet the release date
|
| The number one main headline takeway axiom of Agile is that
| this question is completely banned.
|
| Agile is about delivering working software continuously,
| delivering whatever increment you get working at each
| timepoint, adapting to observed reality as it comes, and
| _not_ having deadlines for specific features that might
| turn out to be impossible or harder than estimated.
| satyrnein wrote:
| That question is not banned; story points and velocity
| measurements are mainstream agile, right?
| davidwf wrote:
| "Banned" may not be the right word, but I do agree it's
| the wrong question. Story points and velocity
| measurements are about giving a reasonable guess about
| what's "likely" to be completed at any given point in
| time in the future, with bigger error bars the further
| out you look. Agile projects don't "complete" so much as
| a decision is made to release at a given point, and
| everyone is happier with agile in an environment where
| there's an expectation of multiple, continuous releases.
| dsfdsfsdfasd wrote:
| That's a really interesting idea that I never thought about.
| Seems to make a lot of sense.
|
| As far as business deserves to know what they are paying for,
| that is absolutely correct as well.
|
| The problem is that business is not paying for story points.
| They are paying for actual product and delivery. So when they
| measure output by story points, you end up with a situation
| where teams are trying to maximize story points delivery,
| etc. as opposed to actual product delivery.
| LoSboccacc wrote:
| > business is not paying for story points. They are paying
| for actual product and delivery.
|
| but that's the whole problem, if you constrain time, cost
| and result there's no any space left for agility.
|
| the point of agile is to maximize the value of what can be
| produced with a given team within a given project, you
| picked time and cost and you apply agile to emerge stories
| that are actually important to you and push back on the
| gold plating.
|
| if you have all three fixed, waterfall works just fine,
| actually even better.
| smadge wrote:
| > Businesses are paying exorbitant salaries and providing
| ping pong tables
|
| Businesses are paying market rate salaries to employees who
| generate them revenue. If anything engineers should be the
| ones questioning the exorbitant compensation and perks at the
| top of the org structure.
|
| > why shouldn't they have visibility into what's being done?
|
| Because they shouldn't be micromanaging. They should be
| setting high level goals and expectations and giving teams
| autonomy and trust. Intrusive surveillance and low level
| metrics create perverse incentives that detract from those
| high level goals.
| droopyEyelids wrote:
| Not related to your main point, but would you reconsider
| calling them 'exorbitant salaries'?
|
| Engineering is one of the only professions that is paid
| commensurate to the value they provide
|
| Calling our salaries 'exorbitant' leaves you without
| superlatives left to describe executives that get paid
| thousands of times our wage, and at least they do work
| compared to the owners of capital who are 'paid' incredible
| money without doing any work at all.
|
| To call an engineer salary 'exorbitant' you must be comparing
| it to the salary of people who function as modern serfs, and
| are not paid commensurate with the value they provide, or
| even enough to live a safe and satisfied life. Being paid
| enough for modest freedom and security is not 'exorbitant'
| though- no matter what you're comparing it to.
| Avicebron wrote:
| Outside of software the majority of American's function as
| modern serfs. I'm an engineer who doesn't work in software
| and live as a modern serf
| choeger wrote:
| > I thinks that's a completely reasonable expectation.
|
| Most often it is not. The problem is that management does not
| understand shit about software. And they usually don't care
| to learn about it. Hence this is about as effective as me
| asking for transparency regarding a COVID-19 vaccine. Yes,
| the practitioners could tell me they are in a phase-II trial.
| But to process that information fully and put it into
| context, I'd effectively need to study medicine.
| MattGaiser wrote:
| > making progress (or it's lack) visible to management.
|
| The challenge is that management is only looking through a
| small window and everything from promotions to raises to
| favours are dished out based on that window.
|
| Anything not in view of that window immediately obviously
| becomes useless to one's advancement in a company, so the
| window better cover everything which matters and it usually
| doesn't.
| narag wrote:
| _Making visible to outsiders what software development teams
| are doing, and making progress (or it 's lack) visible to
| management. I thinks that's a completely reasonable
| expectation._
|
| The devil is in the details and in this case literally
| because the granularity of progress is too fine-grained to be
| exposed away from its context. The project manager or
| whatever you call the nearest person with power over your
| time needs some leeway to organize, ask for some extra,
| compensate, forgive, and reward you, without higher powers
| micromanaging. Freedom is the premise of responsability.
|
| Absolute evil happens when customer demands access to hourly
| activity log for each developer in the (not on premises)
| project.
| alangibson wrote:
| I'm not here to defend Agile, but one of the things people get
| perpetually wrong is thinking about Agile as methods and tools.
| Agile is actually a set of values and principles. You were
| supposed to fill in your own methods and tools to support Agile
| values and principles, but everyone basically just said 'too
| hard; do Scrum'
| Buttons840 wrote:
| https://www.halfarsedagilemanifesto.org/
| alangibson wrote:
| > and we have mandatory processes and tools to control how
| those individuals (we prefer the term 'resources') interact
|
| This was/is literally true at a place I worked. Their
| official enterprise Agile process includes a long list of
| mandatory documents, one of which is a list of all sprints
| and sprint goals for the duration of the project, that must
| be checked into a document control system.
| kolanos wrote:
| http://programming-motherfucker.com
| shaunxcode wrote:
| Csp should replace it. Dog food and turtles all the way down. If
| you can't model your workflow in terms of processes and typed
| channels with buffers what business do you have implementing
| anything more complex (conways law etc.)
|
| THAT said agile was a breath of fresh air at the time and it got
| us to question a lot of assumptions related to how we specify and
| develop software.
| temac wrote:
| You want to replace Agile with CSP? _Interesting_. Why not
| replacing Agile with FSMs, though? Or continuations? Or monads?
| tabelle wrote:
| why are people still talking about agile?
| Glyptodon wrote:
| Because many companies are still transitioning to the
| realization that software is a core part of their business even
| if their product is physical.
| 0x262d wrote:
| it's fully mainstream. my company (mid sized tech company far
| from any coast) is adopting it for everyone right now.
| werber wrote:
| Because we're still dealing with it everyday. I can't even
| count the number of basic trainings I've gone through and then
| seen everything they preach go directly out the window
| Frost1x wrote:
| As many pointed out, unfortunately most businesses employing
| 'agile' don't seem to be 'agile' at all from management side,
| so we still have all sorts of broken practices used industry
| wide which are absolutely idiotic.
|
| I'm working with a team that the PM follows Agile like its a
| silver bullet solution but is obviously terribly flawed.
| dragonwriter wrote:
| The weird thing is that all the criticisms of misplaced focus in
| agile made in the article were criticisms commonly made _by_
| early Agile evangelists (including Poppendieck!) of pre-Agile
| approaches, and the things pointed to that are needed which make
| Agile irrelevant are the things that Agile methods were
| specifically advocated as superior for by those evangelists.
|
| The real problem doesn't seem to be that Agile is irrelevant,
| it's that Agile (and this is actually fairly quickly explicit in
| the Manifesto and accompanying Principles) cannot be limited to a
| siloed tech organization but must fully incorporate the business
| sponsor of the project, whether that's the firms business
| management for a software/services firm, whether it's an external
| customer for a firm doing bespoke software development, or
| whether it's an internal customer for an IT organization doing
| enterprise-internal development. And despite that being clear in
| the Manifesto and Principles, it very often is the case that
| "Agile" is seen as something the tech team is (or worse, _does_ )
| that stops at their boundaries, and that fundamentally doesn't
| work.
|
| There are other equally serious problems, like ritualistic
| adoption of fixed processes being described as "Agile", which it
| clearly is exactly what Agile is most opposed to; the use of the
| phrase "Agile (or Scrum) ceremonies" is a clear sign that an
| organization has been infected with this toxic mindset.
| redisman wrote:
| In my experience "Agile" whatever that means is still the best of
| all the bad options. Is there really a better methodology? I feel
| like it works pretty well as long as management doesn't pick and
| choose the easy parts of it and then add their own layer of BS on
| top, which is very common.
| AzzieElbab wrote:
| Here is the talk by Dave Thomas
| https://en.m.wikipedia.org/wiki/Dave_Thomas_%28programmer%29...
|
| https://youtu.be/a-BOSpxYJ9M
| say_it_as_it_is wrote:
| How many people here refused advice suggesting to go with one's
| strengths and instead took a different path in life, developed
| new capabilities, and acquired new strengths? Progress was slow
| and difficult. Yet, you persevered. You weren't agile, were you?
| kitotik wrote:
| A lot of the bastardization and commercialization of the Agile
| core tenets could have been mitigated by the early pioneers
| broadcasting the dirty secret:
|
| To deliver any real business value following these philosophies
| requires an extremely mature, experienced team. Not just great
| engineers, but also great communicators that actually care at
| least a little bit about the mission/product/goal.
|
| This simply _does not scale_ and is a complete antithesis of 99%
| of organizations culture and hierarchical structure.
| fourseventy wrote:
| I like the development methodology laid out my David Cancel in
| his book Hypergrowth. I like it because he has founded several
| large successful companies and actually used this methodology
| successfully. Unlike most of these "agile gurus" who have never
| sold a product to a customer in their lives.
| [deleted]
| jayd16 wrote:
| Did anyone actually read as far as the sub-header? "Agile" is
| used to scapegoat a lot of issues but gender equality is a new on
| me. Pigeonholing women into non-technical roles is a problem but
| I don't see how dumping agile would solve it.
| bdcravens wrote:
| Agile _as it is practiced_ has created a new set of roles, like
| "scrum master". However, if not agile, that role would probably
| be called "project manager", another role that female engineers
| are often pushed toward.
| Someone1234 wrote:
| Agile is the worst form of Software Development Methodoloy,
| except for all the others.
|
| Which is to say: To all the people jeering for Agile's demise,
| please provide a superior alternative. I came from a world
| dominated by Waterfall, and I never want to go back to that. A
| lot of companies get Agile wrong, and it isn't a panacea, but it
| is much closer to what developers are naturally inclined towards
| (e.g. rapid incremental improvements) than Waterfall ever was.
|
| So I challenge anyone who wants to replace Agile, please lean
| into how developers work rather than trying to mold their work
| onto your rigid front loaded methodology. Trying to bring in
| ideas of other industries, like engineering or architecture, that
| build physical goods and only have one shot at is a folly.
| username90 wrote:
| > To all the people jeering for Agile's demise, please provide
| a superior alternative.
|
| Give individuals ownership over different parts and then let
| them self organize, that is all you need if you hire competent
| people. I'll never work at a place which doesn't work like that
| again.
| closeparen wrote:
| To be fair, there are a _lot_ of engineers on the market with
| a small-but-positive value under a structured process who
| would be totally useless in an environment like this. I can
| see why it might be rational to managers.
| drapred7 wrote:
| The problem is that software engineers are paided poorly
| compared to bankers, executives, and a myriad of other
| occupations relative to how it used to be 30 years ago.
| Even doctors aren't paid like they used to be. So way too
| many smart people go into finance and real estate, which
| are jobs that really anybody could do, except that our
| corrupt system makes it worthwhile to pay the smartest
| people to come up with new ways to scam the public and the
| government. See: Fed policy, CDOs, sub-prime loans, QE...
| [deleted]
| jimbob45 wrote:
| The problem with Agile is that vanilla Agile almost certainly
| doesn't fulfill your company's requirements. However, if you
| put some serious thinking into tuning it for what you need, it
| will be serviceable.
|
| Agile would work much better if every implementation stated
| upfront, "Does not work right out of the box".
| downerending wrote:
| There are plenty of examples. The Linux kernel development
| process comes to mind.
|
| I suspect that most knowledgeable developers rolled their eyes
| when Agile was "invented". It's a mish mash of a lot of things
| that were already obvious at the time and some weird kool-aid
| like pair programming. And just one more in a long line of
| consultant enrichment schemes.
| sourcaustic wrote:
| Please do not aim to _replace_ Agile, you 'll just be creating
| new problems. Go back to the basics of the Agile Manifesto,
| understand where your organization fits in the problems that it
| aims to fix, then overview the different solutions proposed by
| various methodologies, pick and choose the ones that address
| the biggest problems that you're facing and adapt them for your
| own purpose. Start small, as each solution may introduce some
| processes and distract from the actual mission. Augment only
| when necessary. You're Agile.
|
| You don't need to buy entirely into a single methodology. When
| people say Agile in software today, they really mean the Jira-
| flavored Scrum. Some now claim that they've abandoned Scrum and
| you hear more about Kanban. Sometimes they really are
| switching, other time they're really just doing Scrum with a
| Kanban board. But again, they're often falling into the same
| traps of forcing solutions, rituals, and processes they might
| not really need into their flow.
|
| You want to be Agile? Start small. A simple checklist is a good
| way to start.
| drngdds wrote:
| Yeah. I maintain that most complaints about Agile are actually
| just complaints about crummy managers. It's really not that bad
| (in my experience) when the people you're reporting to have
| reasonable expectations and treat estimates as estimates.
| seph-reed wrote:
| For the most part. Nobody who wants to be a manager should,
| and everyone who could would rather not.
|
| The big drawback to good managers is that they stand up for
| their teams and don't kiss boot the way bad ones might.
| quicklime wrote:
| Agile is the worst form of software development methodology,
| second only to waterfall. It's still pretty shitty, though.
|
| One of the reasons Agile (with a big A) is so successful is
| that its peddlers have convinced everyone that there are only
| two options: Agile and waterfall. When you're up against a
| strawman, it's easy to win. But it's absolutely a false
| dichotomy.
|
| There's a quote in the article that I like:
|
| > Find me an actual tech company that talks much about Agile,
| and I will be astounded.
|
| In my experience, people at tech companies (at least the
| FAANGs) rarely talk about Agile, although they do talk about
| things like continuous integration/testing/deployment. They do
| _not_ obsess over methodologies for how to move post-it notes
| around a whiteboard (Scrum vs Kanban) or agonize over how to
| word a user story narrative, or other parts of Agile Theatre.
|
| People at some non-tech companies, especially those supposedly
| going through a "digital transformation", seem to have fully
| bought in to the crap that Certified Agile consultants are
| selling though.
|
| So a superior alternative to both Agile and waterfall is what's
| in use at a lot of the big tech companies. For example, the
| engineering culture at Google, which relies on design docs and
| a very good set of developer tools and infrastructure. It's not
| perfect, but it's far, far superior to Agile.
|
| And before anyone makes the argument that those non-tech
| companies are not doing "real Agile", but Google is, let's be
| linguistic descriptivists and accept that Googlers don't call
| their methodology "Agile", whereas the Scrum consultants at big
| corporates do.
| dionian wrote:
| Agile is supposed to be the rejection of methodologies and
| embracing of people over processes. That's the sheer irony in
| all this.
|
| "Individuals and interactions over processes and tools"
| ebiester wrote:
| I think you're debating a strawman there. The argument is not
| that we need to return to other pre-agile SDLC methodologies
| but rather take what we've learned and go further. From the
| article:
|
| > Now, continuous delivery is what's expected, and the industry
| is ready for the next thing. But that next thing shouldn't be
| another methodology, according to Mary.
|
| > There is no methodology in my field of software engineering
| that can conceivably last more than five to eight years," she
| said. "Everything that is 10 years old is obsolete. Everything
| that is 20 years old is archaic."
|
| > Furthermore, she said, methodology requires codification.
| Beginning with the Capability Maturity Model (CMM) in the '90s,
| software development methodology meant developers had to show
| they had standards and that they followed them, rather than
| demonstrating that their standards were constantly in flux
| depending on consumer needs. That's the definition of quality
| standards lean manufacturing practitioners in Japan originally
| espoused, Mary said, and they're not compatible with
| methodology. Instead, they're all about learning.
|
| > To that end, Mary is excited about all the ways artificial
| intelligence will allow software engineers to learn better and
| faster. Automated testing, continuous deployment and cross-
| functional collaboration are now table stakes, Mary and Tom
| agreed. Cutting edge companies will discover the next great
| approach through an engineering mindset and a willingness to
| learn.
|
| ___
|
| Consider that Mary and Tom Poppendieck were responsible for
| many of the Lean inclusions of the agile movement, which
| (largely) came from watching plant manufacturing at Toyota.
| Similarly, much of the DevOps movement was tied to this as
| well. If you want to talk about what is next, it is likely
| taking a first principles look at what we're doing today,
| questioning best practices again, and saying, "if we were going
| to make a manifesto in 2020, what would it look like?"
| hinkley wrote:
| > "Everything that is 10 years old is obsolete. Everything
| that is 20 years old is archaic."
|
| Which is not entirely true since some of the best parts of
| Agile are XP practices that almost everybody does by default
| now...
|
| Someone once said that the only successful Scrum projects are
| also doing half of XP (as in, things Scrum doesn't prescribe
| but are essential anyway). I am still looking for a
| counterexample.
| Someone1234 wrote:
| You claim I'm "debating a strawman" but then quote the
| article that literally says they have no alternative in mind
| (my chief critique) and point towards artificial intelligence
| to solve the issue _somehow_.
|
| The only "strawman" here seems to be taking my point about
| pre-Agile methodologies out of context, and using it to
| dismiss the entire idea that this article is
| unconstructive/has no actionable solutions.
| ulisesrmzroche wrote:
| You don't need to provide a viable alternative when you
| criticize something, this is a false dilemma.
| Someone1234 wrote:
| Nobody you replied to said they shouldn't be _allowed_ to
| criticize Agile.
|
| The criticism in this comment thread was that their
| advice wasn't actionable, not that actionability was a
| prerequisite in order to criticize Agile at all. There
| was no false dilemma here because there was no choices
| provided (false or otherwise), merely a weakness in an
| argument raised.
| ebiester wrote:
| The advice they are giving is to stop trusting methods,
| take the best practices that make sense, and trust your
| engineers to build a bespoke process from those building
| blocks.
|
| > "I don't care if it's Lean or Agile, there's no silver
| bullet where if you just follow this formula that somebody
| else followed, you're going to be great," she said. "So
| today, my favorite word is 'engineering.' Just let
| engineers be engineers."
|
| Maybe we need to call it the Lego process. SCRUM is Duplo.
| Waterfall is worse Duplo. Start there if you need, but get
| to Lego instead. Maybe Duplo is enough for you.
| Groxx wrote:
| Agile's pretty much only defined by being "not waterfall"
| (which is defined as "not agile, and worse") and "if it doesn't
| work, you did it wrong", so that's sort of a tautological
| statement.
| CraigJPerry wrote:
| Yeah people have short memories of the pre-agile role
| demarcation and wasted handover time between them.
|
| It was utterly frustrating to be powerless to improve
| specification quality and find out you built exactly what was
| asked but you were asked for the wrong thing.
|
| The silos were horrible. Devs were often as bad as BAs, dev's
| just were just crapping on the testers instead. Spare a thought
| for the production ops person at the very end of the chain.
| Here comes 3 months of developer work in one weekend and no it
| doesnt work but we're still going live because the entire tech
| org is invested in this release. Now you have smaller squads,
| you can postpone a release without it looking bad on the top
| person and thus affecting your career prospects.
|
| In agile models you have the power to fix crap processes that
| don't work. You can call out any BS on the retrospective and
| make it super visible when things are being swept under the
| rug.
| thomascgalvin wrote:
| > To all the people jeering for Agile's demise, please provide
| a superior alternative.
|
| The goal of Agile is to let smart people work incrementally
| towards a somewhat nebulous goal. The ceremony that's arisen
| around that tends to be put in place by people who feel the
| need to manage, but don't know how to help their developers
| achieve that goal.
|
| The alternative, as far as I've seen, is to hire smart, curious
| people, let them work closely with the end user, and pay them a
| lot of money. In this situation, the engineers will typically
| self-organize effectively.
| closeparen wrote:
| My org was like that when it was 20 people on one floor doing
| pretty much their own thing in groups of 2-4.
|
| Now it's 100 people across two countries, expected to
| collaborate closely with sibling orgs. Management philosophy
| has shifted to "we will ask a few handpicked experts to write
| down the best way to do a thing, and then everyone else is a
| machine for executing that procedure."
|
| If software engineering worked like that, we would have
| automated it.
| mywittyname wrote:
| I've been through three full-fledged "agile transformations" in
| my career. I hate agile so much. I hate it because it encourages
| dogmatic behavior instead of rational behavior.
|
| I think it has survived so long because it provides its
| practitioners with two ace excuses: when things fail, they say,
| "what we did wasn't really agile," and when somebody proposes and
| improvement they don't like, it's always, "that sounds like
| waterfall." A team can't recover from their agile transformation
| until both of those phrases disappear from the team lexicon.
|
| > "Way too much of Agile has been not about technology, but about
| people and about managing things and about getting stuff done --
| not necessarily getting the right stuff done, but getting stuff
| done -- rather than what engineering is about,"
|
| I'm not sure agile was ever designed to fix this. The whole
| process is really handy-wavy about the actual engineering: "we'll
| just make this a spike." The process also demonizes documentation
| and design work, which is antithetical to most engineering.
|
| That being said, I love iterative development, and I like the
| concept of stories as descriptions of functionality. But I do
| think agile, as taught by most consultants, is really designed
| for consultants who build CRUD web-based applications. Sprints
| are timeboxed so consultants can charge by the spring, and
| stories lack implementation details because companies hiring
| consultants don't want or need to know how their sausage is made.
| The further away your product is from that area, the less
| effective agile is; some companies really need to design their
| sausage well, up front, because they are going to be eating it
| for years.
|
| A process that's built up over years has become the way it is
| typically for good reason. And in my experience, teams forced to
| transition to agile will end up shoehorning their existing
| process into "agile" and calling it done, so most executives
| don't really see how their "transformation" failed.
| uDontKnowMe wrote:
| Tangentially related, has anyone tried to implement the ideas
| described in Juval Lowy's new book, "Righting Software"
| (https://www.amazon.com/Righting-Software-Juval-L%C3%B6wy-
| ebo...)? His methodology of project management seems much more
| systematic than week-by-week sprint planning.
| zwieback wrote:
| I thought it was dead already. The people that pushed agile where
| I worked already moved on the next hot thing twice. Now
| programmers may have a chance to go back to the roots of agile
| and do it right, without micromanagement from evangelists.
| csours wrote:
| If you consider that science advances, what did Agile improve on,
| and where has Agile been been improved upon?
| brundolf wrote:
| Agile is one of those words that's come to mean nothing at all.
| It can be anything from "iterate fast and do weekly stand-ups" to
| "spend all of your time allocating point values to planned sprint
| tasks so that management feels like they're in total control".
| It's been co-opted by the very bureaucracy it was designed to
| reign in.
| projektfu wrote:
| I agree with the title but find the reasoning hard to follow. It
| seems like the author keeps changing playing fields and tries to
| stitch a single narrative.
| 0x262d wrote:
| Agile/software engineering practices broadly suffer a lot from
| the fact that not only is selling software a business model,
| selling Agile is also a business model, and when you buy Agile
| consulting it's impossible to disentangle whether it's being sold
| to you because it works or because it makes that person money.
| They don't even know because it's their job and they convinced
| themselves of its usefulness.
|
| It can still be evaluated on the merits but IMO this greatly
| pollutes the speed at which software devs as a broadly conceived
| community can come to consensus understanding of this.
|
| Also I think the comparison to lean manufacturing has always been
| very shallow. I get the metaphor, I just don't think that human
| resources in engineering can be optimized like manufacturing
| processes. This quote is the best part of the article:
|
| > "You'd never hear anyone say, 'We help mechanical engineers be
| agile. That would be silly. And I mean that in the worst possible
| sense of the word".
|
| As for the rest of it, I'm not dying to hear what the person who
| invented Agile thinks we should do next lol.
| InternetOfStuff wrote:
| > This quote is the best part of the article:
|
| > > "You'd never hear anyone say, 'We help mechanical engineers
| be agile. That would be silly. And I mean that in the worst
| possible sense of the word".
|
| This quote is silly.
|
| To me, agile is just good engineering practice, applied to
| software. Of course mechanical engineers apply its principles,
| and have for decades before the term Agile was coined.
|
| And as such, this practice is far older than software.
|
| The Apollo space programme is my favourite example: the
| ultimate goal remained fixed (man/moon/before end of decade),
| but all steps of the way were discovered and redefined over the
| programme's course.
|
| Mission objectives were changed depending on what was learned,
| often even in flight.
|
| This was a very nice and agile (and sensible) approach,
| regardless of what it was called.
| rch wrote:
| What is currently being sold as 'agile' is also crafted to
| appeal to the type of customers who purchase business
| consulting services.
| raverbashing wrote:
| Yes, selling Agile is a business model
|
| Which bothers me much, much less than selling things like
| CMMI/PSP certifications or EUP/RUP which are done purely for
| paper pushing and selling the paper value.
|
| Agile is an improvement on waterfall and you don't need to be
| certified to do it.
| monksy wrote:
| "You're doing it wrong"
|
| First words of an agile consultant.
| ben509 wrote:
| "S/he was doing it wrong."
|
| First words of the next agile consultant.
| james_s_tayler wrote:
| "You're doing it wrong" is the meta of Agile.
| OrangeMango wrote:
| It's a good thing there is a limit to nested replies,
| because this could go on for a really long time.
| AnimalMuppet wrote:
| Typically, until the company runs out of money...
| bregma wrote:
| ... or until all the original team members have left and
| now work in places where methodology is not the primary
| job.
| hvis wrote:
| Agile consultants are not the only people who do that.
|
| https://i.imgur.com/ecsh9yp.png
| nogabebop23 wrote:
| "That's not agile. TO be agile it must include practices
| x,y,z..."
|
| First words of an agile zealot responding to any complaints
| or negative comments about agile.
| wpietri wrote:
| > selling Agile is also a business model
|
| Absolutely. And, having done some agile consulting long ago,
| I'd say it's more pernicious than that.
|
| The people who truly want to make deep change in pursuit of
| deep improvement are a small segment of the market. Worse, they
| don't need a lot of help. In the aughts, I had a few clients
| who really _got it_ after 3 months of focused work, and then
| they were off and running.
|
| But a large company that only wants to talk about change and
| maybe make some 5% improvements if they aren't too hard? That
| can be milked forever. Well, I can't, because I care about
| results. But consultants who either don't care or don't notice?
| They're golden.
|
| And I think this failure of the Agile movement has been obvious
| for a decade. I gave up on Agile conferences circa 2009, and
| wrote a long piece about this in 2011:
| http://agilefocus.com/2011/02/21/agiles-second-chasm-and-how...
| oceanghost wrote:
| It's also a way to get promoted.
|
| I've seen several director types get promotions promising to
| get faster and more reliable work out of existing engineers
| by implementing this new religion... Agile.
|
| The results were always predictable. Layering more meetings
| and stress on people who already have too much work to do,
| doesn't help things. But, you're still vice president.
| drewcoo wrote:
| You lost me at "software is a business model."
| allover wrote:
| If you're genuinely confused, I assume they missed out the
| word "selling" before "software".
| 0x262d wrote:
| This is correct and I edited the post to avoid this sort of
| criticism.
| thaeli wrote:
| > "You'd never hear anyone say, 'We help mechanical engineers
| be agile."
|
| I have literally heard this pitch.
| ashtonkem wrote:
| The chance of something being pitched is correlated more
| strongly with it making money than with it actually being a
| sane idea.
| Florin_Andrei wrote:
| > _The chance of something being pitched is correlated more
| strongly with it making money than with it actually being a
| sane idea._
|
| More generally, it's correlated to it bringing some real or
| perceived advantage to the person doing the talk.
|
| I mean, have you been watching the news lately?
| meheleventyone wrote:
| Yup, I've an Aunt who works for an environment agency that
| now does all her work using Agile down to Sprints etc. which
| is mildly confusing.
| mindcrime wrote:
| There really is no methodology called "Agile". There are
| things like Scrum, SAFE, AUP, XP, etc. Some of those may or
| may not mandate things like "sprints", but the essence of
| agile (the Agile Manifesto) doesn't even mention the term
| "sprint".
|
| The closest it gets to that is where it say:
|
| _We follow these principles:_
|
| <snip>
|
| _Deliver working software frequently, from a couple of
| weeks to a couple of months, with a preference to the
| shorter timescale._
|
| <snip>
| james_s_tayler wrote:
| The funny thing about the agile manifesto is that it
| doesn't actually say anything remotely related to
| process.
|
| It basically states a set of attributes your process
| should exhibit.
|
| Agile as I have experienced it in practice almost never
| displays those attributes.
|
| The whole thing makes very little sense. I mean read it.
|
| >"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
|
| That is, while there is value in the items on the right,
| we value the items on the left more."
|
| How the hell do you get from that to where we are today?
|
| What it ought to say is:
|
| "We value short feedback loops that minimize risk and
| maximize learning.
|
| We value flexibility.
|
| We welcome change.
|
| We don't know what we are doing, only what we intend to
| do. The outcome is a guess. Our guesses could always be
| better. We strive to make them so."
| meheleventyone wrote:
| Oh for sure, but that doesn't mean she isn't doing
| something she's been told is Agile and involves Sprints.
| mindcrime wrote:
| Yeah. :-( It bugs me to no end when companies do that,
| but what can ya do?
| 0x262d wrote:
| It wasn't by a Boeing exec, was it lol?
|
| https://www.bloomberg.com/news/features/2019-05-09/former-
| bo...
| vpeters25 wrote:
| > Also I think the comparison to lean manufacturing has always
| been very shallow. I get the metaphor, I just don't think that
| human resources in engineering can be optimized like
| manufacturing processes.
|
| Agile and Lean are empirical process controls, they are based
| on the same concepts. Ken Schwaber explains all this on the
| first chapter of his book "Agile Software Development with
| SCRUM":
|
| Defined process control: same inputs always result in same
| output (manufacturing widgets on a production line).
|
| Empirical process control: same inputs not always result in
| same output.
|
| Schwaber conceived SCRUM (and was among the founders of Agile)
| after realizing software development required an empirical
| process control: give 2 dev teams same specs, 2 different apps
| will come out (they might do the same thing, but in different
| ways)
| the_duke wrote:
| > I'm not dying to hear what the person who invented Agile
| thinks we should do next
|
| Agile has plenty of good ideas.
|
| The problem is the almost religious following and, as you
| mention, the whole industry that has sprung up around it.
|
| Even the initiators said that it was supposed to be a rough
| framework, to be adapted to your individual circumstances and
| teams. It was also a (much needed) counterpoint to the then
| prevalent waterfall model.
|
| Now we have consultants, people strictly following something
| they read in a book or learned in a course, adhering to strict
| structure of meetings/processes, and even a big association
| with a single software product, Jira. ("You are doing it
| wrong!")
|
| When you step back, a lot of the ideas make sense, and many
| teams will even implement similar workflows without having ever
| heard about "Agile".
|
| Common sense has to prevail though.
| AnimalMuppet wrote:
| > ... it was supposed to be a rough framework, to be adapted
| to your individual circumstances and teams.
|
| > Now we have consultants, people strictly following
| something they read in a book or learned in a course,
| adhering to strict structure of meetings/processes, and even
| a big association with a single software product, Jira. ("You
| are doing it wrong!")
|
| Yeah. Part of agile is that your process is an adjustible
| parameter. If you're doing it with a rigid process - _any_
| rigid process - then you are not actually doing agile.
| znfi wrote:
| I remember someone giving a lecture on software engineering
| methodologies who gave a pretty good summary by saying that
| "The methods are there to help your brain, not to replace
| your brain."
| rapind wrote:
| And yet I've heard the opposite argument that "It didn't work
| because you weren't strict when adhering to it."
| cs02rm0 wrote:
| _It was also a (much needed) counterpoint to the then
| prevalent waterfall model._
|
| It still is and it's barely in the fight still in some
| corners of the public sector.
|
| If Agile dies (and SAFe might succeed there) then there would
| be nothing left except Waterfall and people others would call
| cowboys.
| gridlockd wrote:
| > If Agile dies (and SAFe might succeed there) then there
| would be nothing left except Waterfall and people others
| would call cowboys.
|
| Saddle my horse.
| RealityVoid wrote:
| Haha, this was hilarious to read, mainly because, on some
| occasions, I've been a cowboy, at least in the context of
| this post. I like to think it worked pretty well, since,
| for what we were trying to do, the processes were
| fighting against us, so I just... did what I considered
| right technically, regardless of tickets and sprints and
| who's team should do what.
|
| Whether it was right, I'm not sure, but people have been
| happy with my work, so that allowed me a bit of leeway.
| nradov wrote:
| When you have a large program team with mixed experience
| levels who don't fully understand fundamental principles,
| sometimes the only way to keep your sanity is to force
| everyone to strictly follow a defined agile methodology (LeSS
| or SAFe or whatever). That isn't optimal, but if you have to
| deliver working software right now you can't wait around to
| figure out an optimal process for your unique circumstances.
| Pick something good enough and move forward, then improve as
| you go
| Jtsummers wrote:
| Agile doesn't ask you to figure out the "optimal process",
| it asks you to learn. One of the key things I've seen
| missed in almost every attempt at Agile/DevOps/whatever is
| the retrospective or the learning component.
|
| The team/organization has to become a learning
| organization. That means a number of things, but the
| critical one here is learning from past failures and
| successes and incorporating that feedback into their model
| (ideally continuously, but in Scrums it'd be the end-of-
| sprint retrospective). You start down a path, and you find
| it's difficult. You don't press on just because it's the
| one you selected, that's the way of idiots. You examine the
| hardships you're facing, and you address them.
| wpietri wrote:
| Absolutely. To my mind, the one vital agile practice is
| the weekly retrospective where the team looks at how
| things went, thinks a bit, and decides to try something
| in following weeks. Everything else is just tools people
| can try applying to solve the problem of the week.
| bregma wrote:
| > The problem is the almost religious following
|
| Yes. I have found doing agile "properly" to be too rigid.
| What we need is something more flexible than agile.
| james-mcelwain wrote:
| I don't know if something is wrong with me, but I simply cannot
| "decompose" a single feature into 500 different sub-task Jiras.
|
| I understand why it would be super cool if software worked like
| that, but I have to iterate on features holistically and
| sometimes speculatively.
|
| At least for me, software development has never been able to be
| so cleanly broken down into "first, implement the button" type
| tasks.
|
| But maybe I'm just dumb.
| mmcnl wrote:
| That's not agile, that's waterfall. With my team, I usually
| have just 2 or 3 "stories" that are taken up during a sprint.
| The rest is up to the development team. Works quite well. No
| one's asking to create dozens of tasks. A rough outline of what
| we're trying achieve combined with a high-level overview of
| what we think would need to be done is usually enough to get
| started in a sprint. If we fail, we fail, no one gets mad.
| That's agile if you ask me.
| stickfigure wrote:
| It sounds like you're trying to decompose software into
| developer tasks, which is not what (my interpretation of) agile
| is about.
|
| Forget the developer for a moment and take the user
| perspective. What's the first thing the user wants to do? Log
| in? Ok, that's a story. What's the next thing the user wants to
| do? See a list of widget prices? Ok, that's a story. What's the
| next thing the user wants to do? Change a price? Story.
|
| If you can't sit down and think of a dozen narratives like
| this, then the fundamental problem that you don't really
| understand how people are supposed to use your software or what
| your software is supposed to do.
| loopz wrote:
| Actually, those are stories developers tell themselves, not
| users!
| CyberDildonics wrote:
| Calling everything a 'story' is just another in a long line
| of trends that pretend making up a new name for something is
| progress.
|
| (Also a user doesn't actually want to log in, they want to do
| something and you are making them log in)
| ben509 wrote:
| To some extend, you could if you worked on the task and, as you
| worked, said, "what am I doing now and what do I need to do
| next?" and then plugged that into something.
|
| It wouldn't be a complete decomposition, of course, a person
| watching would see your thinking unfold. I think speculative
| decomposition would be very interesting, especially in
| retrospective if we could see the rabbit holes we went down.
|
| Decomposing is easy since we naturally have to do that as we
| work. Heck, those 500 tasks are probably in your shell, browser
| and commit histories, mixed in with a bunch of other junk.
|
| The problem is tools like Jira make this heavy-weight, doing it
| up front makes it nigh impossible, and having others review all
| this stuff and it becoming promises blows up the LOE
| significantly. And, I don't think I'd want to be under that
| much of a microscope as I work.
|
| But if it were very lightweight, where I'm just posting my
| thoughts and can see them as a quick dependency diagram, and
| maybe attach notes, commits and URLs to them, and other people
| can see them, that'd be pretty helpful.
| Jtsummers wrote:
| > But if it were very lightweight, where I'm just posting my
| thoughts and can see them as a quick dependency diagram, and
| maybe attach notes, commits and URLs to them, and other
| people can see them, that'd be pretty helpful.
|
| That's precisely the objective of "user stories" and other
| things. You write a high level version, put it in a backlog
| with priorities. When you get to it, you realize it's bigger
| than anticipated ("Oh, I can't just do X, I have to do A, B,
| and C."). So you turn X into three things, one of which you
| work on now, and the others in the backlog. Repeat until
| done.
|
| I don't think Jira is necessarily too heavy-weight, it's the
| way everyone seems to use it. They want to assign the tasks
| now, not treat them as backlog items or things that can be
| modified in the future. Which pushes them back towards big-
| design-up-front and entirely defeats the objective, you're
| back to low throughput, high latency development.
| wpietri wrote:
| Yeah, I think trying to perfectly describe the work in advance
| is Waterfall thinking. Most of what gets sold as "Agile" these
| days is Waterfall dressed up in Agile terms.
|
| But as an example of early Agile intent, here is how we worked
| in 2004: http://williampietri.com/writing/2004/teamroom/
|
| You'll note that we never did detailed planning more than a
| week in advance. We could have, but it would have been a waste,
| because it would have been speculation on speculation. Instead
| we'd agree on something small to build, get it working, and
| then see what we thought.
| HeyLaughingBoy wrote:
| It can usually be done. The problem is that people assume that
| now that you have that list of subtasks, you can iterate
| through them one at a time until you've built the feature.
| That's the major disconnect.
|
| What I do with my guys is I make them decompose the feature,
| but with the understanding that they'll probably be jumping
| from one subtask to the other, back and forth, as they
| understand what it is they'll be building. AND they'll probably
| come across new subtasks as they work through the feature.
|
| It makes Jira look crappy, but it Reflects Reality (tm) which
| to me is far more important than keeping Jira clean.
| Ididntdothis wrote:
| That's how it works. Touch something here, touch something
| there, learn from it and slowly build up the whole thing. I
| think Scrum and Kanban may work if you have a somewhat mature
| system where you add incremental features but if you do
| something relatively new and big the backlog can not reflect
| reality. Or it forces a workflow that doesn't make sense. I
| have seen it multiple times where people refused to make
| changes to something because their story was done already.
| Never mind that the design turned out to be unsuitable.
| mark-r wrote:
| I saw this happen before Agile was even a thing. The
| possibility of a bug in the spec was never a consideration.
| You had to hope your assumptions going in were correct, or
| your users were screwed.
| virgil_disgr4ce wrote:
| > but I have to iterate on features holistically and sometimes
| speculatively.
|
| YES. THANK YOU! I've been trying to tell people this for ages.
| Maybe other people are somehow capable of perfectly predicting
| every conceivable edge-case and consequence without even
| starting to work on something, but I can't. I have to start
| building something in order to see it clearly. And this ENRAGES
| certain kinds of managers, I have found.
| anon9001 wrote:
| Managers just want you to deliver on a predictable schedule.
|
| Here's how you can solve your problem: Make as many tickets
| as you can think of, it doesn't really matter if they contain
| the essence of the problem or not, it just matters that there
| are many tickets associated with the task. Once you have your
| tickets, estimate them with as much padding as possible. If
| the manager complains that you're padding a ticket too much,
| make two tickets and split the estimate.
|
| Once you have a big pile of tickets and estimates, you've
| bought yourself enough time to do the work. Go do the work,
| then mark all the tickets as complete. You'll figure out the
| edge cases as you go, as long as you've made enough tickets
| and time to do the job at a reasonable pace.
|
| If you have extra time left over, get started on the next
| thing, improve your tooling, or try to help someone else with
| their tasks. If you don't have extra time left over, make
| more tickets next time.
| james-mcelwain wrote:
| This is also what I do, but it seems so antagonistic and
| deceptive. I want my relationship with my PM to be
| productive and collaborative.
| gilbetron wrote:
| Managers want a fiction to present to their superiors - the
| most happy my managers are is when what you describe
| happens. I like your approach :) I might have to be more
| explicit in creating a fiction. The only issue is if/when
| you actually run into things that significantly delay
| things right towards the end.
| alistairSH wrote:
| Ack, please don't. As a manager, I'm pretty sure I'd see
| this as the bullshit it is and call you on it. We're not
| all morons.
| anon9001 wrote:
| Where exactly is the problem with my strategy? I'm also a
| manager of a small team. My main goals are to make sure
| everyone is not idle, not burned out, and not missing
| deadlines.
|
| My boss's goal is to try and get everyone to work every
| waking hour so we can deliver faster. My job is primarily
| to keep the peace between the executives and the workers.
| When I fail the workers, it looks like unpaid overtime.
| When I fail the executives, it looks like undelivered
| features.
|
| I think the actual purpose of agile, from a developer's
| perspective, is to create more time to deliver quality
| engineering work product. From an executive's
| perspective, agile exists to squeeze developers into
| completing tickets faster. As a manager, it's my job to
| keep both parties as satisfied as possible. If engineers
| have enough time to build and executives get enough
| deliverables, then the company succeeds.
|
| What's your strategy?
| alistairSH wrote:
| I read your comment as "create as many tickets as
| necessary to throw off management's understanding of the
| effort and complexity of the problem." Creating more
| tasks than necessary sounds like a waste of everybody's
| time.
|
| As I noted in a parallel comment, on my team, developers
| are never creating tasks on their own or in a vacuum.
| It's done as a team effort during planning meetings.
|
| Perhaps I should add that my boss (senior director) has
| never asked me about my board, velocity, or anything like
| that. Discussion is higher level - "is project X on
| schedule?" or "are you going to miss anything on your
| roadmap?" not "why is task X or story Y not done yet?" If
| your director is asking that, he has too much time on his
| hands.
| watwut wrote:
| Through, project managers lie about the being on roadmap.
| The answer to higher management is always "we are on
| time" to look good.
|
| Asking specifics from higher ups is just smart.
| alistairSH wrote:
| Perhaps project managers who aren't good at their jobs.
|
| I've reported to two different directors since moving
| into management. Both were very clear that they'd rather
| hear about problems early. And both have been nothing but
| reasonable when I've reported problems. Of course, the
| entire team needs to be reasonable for this to work, from
| the product managers to project managers to individual
| contributors.
|
| And as a manager, nothing annoys me more than an employee
| who tells me everything is fine then misses a
| deliverable. Tell me you're having problems so we can
| find a solution. Please. That's why I'm paid what I'm
| paid.
| [deleted]
| [deleted]
| gdilla wrote:
| What I find helpful as a product manager, I discuss each
| feature with engineers - and we collaboratively break it down
| into a bare-bones "MVP" version, but consider nice to haves as
| future stuff or TBD based on what we learn. That helps push
| scope down and manage holistic iteration. Every feature should
| have an MVP version of it. At least asking the question can
| help break down that first user story.
| texasbigdata wrote:
| How did you learn this?
| burner831234 wrote:
| I learned it through the job. I think thats the quiet
| secret. Engineering is best learned through a form of
| apprenticeship but so is product.
| loopz wrote:
| Too bad corps optimize away apprenticeship, and then
| wonder why their processes delivers less and less...
| danielrhodes wrote:
| You're right that there is a limit to the usefulness of
| breaking down sub-tasks. It's up to a team how granular they
| get.
|
| Here is why it is important:
|
| a) Risk management - if you break a feature down into sub-tasks
| at any granularity, you are creating an agreement (or at least
| a conversation) among your peers that this is how something
| will be implemented, and digging in beforehand to uncover areas
| which might impede shipping the feature sooner.
|
| b) You're going to have to break down the feature at some
| point. Being able to think through this ahead of time can be
| challenging, but often times is the meat of the work you do.
| You have to get into the hang of it -- think top-down or
| bottom-up ways of approaching it.
|
| But what if you don't have enough information or understanding
| yet to do that? Agile is not great for these tasks where you
| need to take some time learning or experimenting.
|
| I would offer you a couple extra tools here:
|
| - A "spike" ticket -- Agile is all about deliverables and
| commitments, but sometimes that doesn't work. So create a spike
| ticket, and define what it is you want to investigate. If you
| deliver something, great! If not, no worries. The important
| part is that in the future you've done work that enabled you to
| learn how to estimate or break down that task in the future.
|
| - A time-boxed ticket -- similar to the spike, but you just
| make sure you don't spend more than an allotted time on a task.
| Swizec wrote:
| Software is like gardening
|
| https://blog.codinghorror.com/tending-your-software-garden/
|
| The reality is that your ability to break things down depends
| on experience. I've built so many landing pages, for example,
| that I can tell you an exact breakdown of tasks. Been a part of
| so many SaaSes, I can tell you exactly what non-core features
| you'll need, when, and how much work they are. I can also
| predict where you'll hiccup.
|
| But ask me to build something new that's never been done before
| (at least by me) and the most I can do is shrug and guess.
| Maybe give you a rough sketch of an outline of subtasks.
| GrumpyYoungMan wrote:
| > " _I simply cannot "decompose" a single feature into 500
| different sub-task Jiras._"
|
| Nobody can; that's the primary failure mode of waterfall.
| Anybody who is telling you to decompose a feature into that
| many subtasks might claim to be doing agile but they really are
| trying to do waterfall.
| [deleted]
| mumblemumble wrote:
| > that's the primary failure mode of waterfall
|
| That's the primary failure mode of a straw man software
| development methodology called waterfall that Scrum
| practitioners like to use as a bogeyman to appeal to for
| rhetorical purposes during the inevitable arguments about
| niggly little details of how to implement Scrum during sprint
| retrospectives.
|
| I've never actually done real waterfall, but I did study it
| way back when I was in college, and I have worked in
| government contracts, which tend to handle the work in a way
| that is similar to the waterfall I read about in school. One
| thing I distinctly remember is that it was designed to be a
| flexible and iterative methodology that would have been
| difficult to cram into a ticketing system in the first place,
| let alone cram into Jira while simultaneously carving the
| work into tiny pieces, up front, all at once.
|
| FWIW, the only place I've ever been asked to do something
| like that is in ostensible Scrum shops. In fact, the only
| time I've ever seen anything that looks like the Waterfall of
| scrum lore is in shops that are trying to do Scrum. I am
| beginning to suspect that the Waterfall of Scrum lore isn't
| actually a thing that happens outside of Scrum at all. It's
| actually what naturally tends to emerge when you try to apply
| Scrum methodology in a situation where something along the
| lines of the real, textbook waterfall model would have been
| more appropriate.
|
| As a concrete example, I currently work at a team that
| ostensibly uses Scrum, but where QA is a separate department
| with its own practices that the dev team does not control.
| They do still want some ability to anticipate work that's
| coming their way, though, so they're monitoring the scrum
| board for that purpose. This is the moment where it gets
| messy, because we're then asked to document things ahead of
| time, and it's a minor crisis if we keep it flexible during
| the sprint because any changes to the set of tickets becomes
| an inevitable hassle as they complain that we've screwed up
| work product that they generate based on those tickets. It's
| absolutely something straight out of waterfall horror stories
| from Scrum lore. But it's only happening because we're
| doggedly insisting on something that's at least cosmetically
| similar to scrum. If we weren't doing that, we'd be freer to
| choose modes of interaction and business artifacts that are
| better suited to the reality we occupy.
| Jtsummers wrote:
| A reason you often see Waterfall-in-Scrum is because people
| who were using Waterfall wanted to get away from it, and
| they made it as far as Scrum (the name). They usually keep
| the same practices of massive design/spec documents that
| are developed in advance. They try to plan out the next 20
| sprints (hah, I saw a team that tried to plan out 60
| sprints 4-week sprints, it was kind of hilarious if I
| wasn't dying inside from the thought of it).
|
| The biggest difference for Waterfall-in-Scrum versus
| Waterfall is that they've sufficiently (hopefully)
| decomposed tasks to have short target dates for delivering
| something to a test team or facility. They don't use it to
| get feedback from customers (the actual users, not the ones
| writing the checks). They don't use it to replan when
| things go wrong. They just use the whip and OT and get back
| on track.
| wpietri wrote:
| Waterfall was the dominant model of software engineering up
| until the late 1990s. It is how managers want software (and
| projects generally) to work. I promise, it was real! Back
| then, a quarterly release cycle was fast; 12-18 months was
| more common. With the rise of the Internet, everybody knew
| that couldn't work, but didn't know what to do, so there
| was a lot of experimentation in the late 1990s: Scrum, FDD,
| Crystal, Extreme Programming, and more I've forgotten or
| that were never named.
|
| Out of this chaos, eventually came order. It turns out what
| mattered most in practice, just like before, was pleasing
| managers and executives. Effectiveness was generally
| secondary. So what we ended up dominating is Scrum, the
| most waterfall of Agile processes. Most shops "doing Agile"
| these days are still following a top-down, control-
| oriented, ineffective and unrealistic process, just like
| before. But now they use Agile labels for their mostly-
| unchanged process, albeit with a faster release cadence.
| james_s_tayler wrote:
| Nailed it.
| einpoklum wrote:
| In much (most?) of software being worked on these days,
|
| * A quarterly release cycle is indeed fast. * 12-18
| months between releases (ignoring perhaps bugfix/point
| releases) is quite common.
|
| You write that "everybody knew that couldn't work" - for
| some projects.
|
| Definitely agree with your second paragraph - except that
| Agile labels can be used even without a faster release
| cadence :-)
| ebiester wrote:
| This is not a question of agile or not. This is software
| estimation and design.
|
| To be able to decompose a feature, you need to learn how to
| build the software in your head before you go to paper.
| Consider a large billing page, for example.
|
| Step 1 is to look at the front end. What components do I need
| to build? (React might use components, or a set of partials and
| templates in rails, for example.) So, then, I know I need X
| subtasks, where I will build the pieces I need to expose that
| behavior to the client to start.
|
| I then look down into the backend. That might be a simple task
| on the backend, or given 20 minutes of looking, I might see
| problems that I'll need to tackle. The problems are their own
| subtasks. I may be able to group some of the front end to a
| single back end ticket, or I might need a separate subtask for
| each.
|
| Now, I'm likely to miss something. However, that's why this is
| an estimate rather than a concrete task list. It's to get
| started so that we know, at minimum, what it's going to take.
|
| It's not necessarily simple, but it is a skill that can be
| developed.
| wvenable wrote:
| > To be able to decompose a feature, you need to learn how to
| build the software in your head before you go to paper.
|
| Even easier than building the software in your head is
| actually building the software. I often don't know what the
| shape of the problem is until I've built something. The users
| often don't know what they want until they've seen something.
|
| The failure of Agile as implemented is that it's still all
| about extensive meetings and planning. Software is not like
| building a bridge where you write out the blueprints and the
| expensive part is then building the bridge. Software is the
| blueprint.
|
| To be truly _agile_ is to be able to get software features
| and changes running and out to users as quickly as possible.
| You can never get all the information -- if users could
| provide the details absolutely necessary to build the
| software on day one then they 'd be the programmers. Being
| experienced helps you naturally scope problems but you'll
| still be wrong from time time. Being able to iterate on users
| feedback and dealing with your own failed assumptions is the
| key.
| goalieca wrote:
| No, you're not dumb. Telling someone precisely how to work and
| then tracking every bit of it is called micro-management.
| jtdev wrote:
| Creating a huge list of tasks is actually what I would call an
| Agile anti-pattern. It's something that I unfortunately see all
| the time. User stories are meant to be written from a business
| or end-user perspective. It's a high level description of what
| is to be done, for who, and why, not how. I personally don't
| even like having tasks on the board, just give me a well
| written story and I'm happy to complete it based on what's
| written in the acceptance criteria.
| rezendi wrote:
| I wrote this, so I'm obviously biased, but:
| https://techcrunch.com/2018/12/09/jira-is-an-antipattern/
| danieldisu wrote:
| Don't get me started when they try to push all clients into one
| jira, each one of them with their own complexities, release
| cycles etc. Or when they try to measure team effectiveness
| using Jira un some way or another, every team is capable of
| doing more Jiras in the same time by just splitting them more!
| mindcrime wrote:
| _I don 't know if something is wrong with me, but I simply
| cannot "decompose" a single feature into 500 different sub-task
| Jiras._
|
| No, nothing is wrong with you. But let me note that the Agile
| Manifesto doesn't say anything about Jira, or anything
| prescriptive about how small to make your stories.
|
| If your methodology asks you to do that, I'd argue that your
| methodology is broken. But it's broken because it's shit, not
| because it's "agile."
| polotics wrote:
| Well "individuals and interactions over process and tools" is
| in the Manifesto, so I would say JIRA is implicitly covered.
| I am being asked to do "proper structured agile" by writing
| up many JIRA tasks in advance of learning what best to write,
| and I find it funny. It's not the disease though, just a
| symptom of having too many nonprogrammers around. Will
| resolve itself.
| mindcrime wrote:
| _I am being asked to do "proper structured agile" by
| writing up many JIRA tasks in advance of learning what best
| to write, and I find it funny_
|
| Yeah, it's hilarious how people are being told to do
| something in the name of "Agile" that is almost completely
| opposite of the spirit of the Agile Manifesto. _sigh_
| anthonyrstevens wrote:
| Nobody can. But anybody can ask "What is the _next_ task that
| needs to be done? "
| loopz wrote:
| So building constructions blindfolded is the norm? Sounds
| like recipe for entangled messes.
|
| It has always been at systems thinking, design and
| architecture, in that order. Doing it organically is a magic
| feat rarely done well.
| Buttons840 wrote:
| Is it a case of too many cooks in the kitchen?
|
| Company and developers are busy and successful, so they hire
| more, which continues until they are no longer successful.
|
| They remain busy, however, progress on the product is roughly
| constant. All the additional work capacity is spent on meetings
| and otherwise organizing the increased worker count.
|
| I believe the above describes every situation in which I have
| been asked to break down Jira tasks into unnaturally small
| tasks.
| grobins2 wrote:
| You're not the only one. My team and most teams in my company
| made the conscious decision to not use subtask.
| alistairSH wrote:
| _But maybe I 'm just dumb._
|
| No, not at all.
|
| Decomposing a new feature into digestible pieces is hard work
| and a skill that is learned over time. It's also a skill to
| know when something is small-enough, or has enough unknowns
| that further decomposition is wasteful.
|
| Good product owners and managers know this and are good at it
| themselves. And the decomposition is typically at a story level
| - "can we take story X, break it into 2 smaller stories, and
| still deliver something of value?" The tasks are usually pretty
| self-evident once you break down the stories a few times.
|
| For a lot of my work, if the story is "As a user, I need to do
| X" the tasks are simply broken into distinctly testable
| pieces.* Is there a database change? That's a task. Is there an
| API change? That's another task. Front-end change? Third task.
| And if you get half-way through and need to start over, that's
| life and it happens reasonably often. Yeah, there might be some
| re-testing. Or, a new story for next sprint.
|
| It's up to me, as the manager, to make sure the stakeholders
| are informed and on-board. At the end of the day, as long as
| the team is making progress, I'm happy. And if the team isn't
| making progress, it's probably my fault (and almost never the
| fault of an individual contributor).
|
| * In my world, tasks don't exist in isolation. They're all
| subordinate to a user story. Every task (piece of work) we do
| is done in the furtherance of a well-defined need of the user.
| And developers are never defining tasks on their own - it's
| done as a team.
| illuminated wrote:
| The main issue my teams have been facing with Agile methodologies
| is the number of the workflow interruptions built in. The only
| team members happy with those interruptions were Scrum Masters
| and PO's but that's because those were parts of their flows, so
| they had to have them in order to have their job done.
|
| The only long term solution for us was to have days dedicated to
| Agile ceremonies and days where no team member can be interrupted
| based on an agile ceremony need (there were few exceptions, like
| critical bug discovery, etc.). In weekly sprints, we had at least
| 3.5 days of uninterrupted time and in two-week sprints we had
| 7-7.5.
|
| That changed a lot the pace of those sprints as people had a lot
| of time to do their job and everyone was happy.
| projektfu wrote:
| Scrum has always been the problem, IMO.
| anthonyrstevens wrote:
| By "ceremonies", are you referring to daily standups? And/or
| something else?
| illuminated wrote:
| Everything but the daily standups... We had each day to begin
| with it, and it was great as it provided a more broad
| visibility into what is being done, if there are any issues,
| etc. But every other agile related meeting was a ceremony we
| have tried to manage as best as possible while not blocking
| its benefits.
| temac wrote:
| > At the time, software development was suffering from a mistaken
| belief: that building things fast and building things well were
| fundamentally opposed. Mary knew this to be untrue from her work
| in product development and manufacturing, where the 'lean'
| practices that sprung up in Japanese car factories and
| subsequently spread across the globe often ruled the day.
|
| If that's part of the original reasoning, then it was very
| random. R&D has not much to do with manufacturing. So I would
| greatly prefer an actual example from "product development"
| rather than car factories...
|
| I mean what build our software is e.g. gcc. I don't know if gcc
| is feeling lean, and actually I don't care much :)
| xnx wrote:
| One of the all-time most cursed diagrams I've seen:
| https://www.scaledagileframework.com/ . I could not believe it
| was not parody.
| cs02rm0 wrote:
| This has been following me around recently, I can't seem to get
| away from it.
|
| SAFe is everything that has ever been wrong with the software
| industry rolled into one terrible thing that is anything but
| agile.
|
| I can't fully express here quite what I think of it!
| karatestomp wrote:
| Message aside, that is a _terribly_ organized diagram. It looks
| like someone dumped all the things they wanted in it on the
| screen, moved them around just enough that they weren 't
| overlapping, then simply... stopped, having done no actual
| organization.
| MattGaiser wrote:
| > having done no actual organization.
|
| So it was done using agile diagram methods?
| peteri wrote:
| Anywhere that does SAFe is somewhere to avoid.
|
| The other issue that agile conferences don't have developers
| anymore.
| empath75 wrote:
| I was saying in a team meeting the other day that using jira
| stories as any kind of performance metric is wrong-headed and
| counterproductive and metrics should focus on the business value
| provided by the team and people looked at me like I grew a second
| head.
| bob33212 wrote:
| I had a situation where the CEO was bringing up complains from
| the PM to me about how there were so many Jira issues in the
| back log that I should have been hiring more people.
|
| I said that it would take me 5 minutes to go into Jira and
| close out all the existing issues if that is what they are
| worried about?
| karatestomp wrote:
| I've written something similar on here recently, but to
| repeat: I am, at this point, pretty sure that trying to
| combine manager-facing and team-facing
| planning/tracking/task/reporting tools into one thing is
| fundamentally a bad idea.
| [deleted]
| adamsea wrote:
| Two heads are better than one! ;)
| commandlinefan wrote:
| I don't want it to die, I want it to become what it was
| originally supposed to be.
| swagtricker wrote:
| This.
| kerkeslager wrote:
| Agreed.
|
| As far as I'm concerned, "agile" refers to the principles on
| this page[1], and ONLY the principles on this page. Not Scrum,
| not Lean, not Kanban, not Xtreme.
|
| The problem is, it's hard to sell a set of principles. To
| understand people and interactions takes months of working with
| people: it's much easier to sell them a process or a tool and
| leave. Customer collaboration requires building a relationship:
| it's much easier to negotiate a contract for your client and
| leave. Responding to change requires you to stick around and
| see what changes happen: it's much easier to sell them a plan
| and leave. And to arrive at working software you have to get a
| lot of things right: it's much easier to sell a bunch of
| documentation for software that doesn't exist, and then leave.
| Money ruins everything: the reason agile had to explicitly
| deprioritize the things on the right side of the list in the
| first place is that all the incentives in a software company
| push you toward the wrong priorities. The things on the right
| side of the list are all quick, easy wins that look good on a
| quarterly report.
|
| There are companies who I've worked with who do agile (the
| principles) well. There's nothing wrong with looking at
| Scrum/Kanban/whatever as inspiration, as long as you realize
| that they're just processes: individuals and interactions
| matter more. There's nothing wrong with using
| Pivotal/Jira/Trello/whatever, as long as you realize they're
| just tools: individuals and interactions matter more.
|
| [1] https://agilemanifesto.org/
| achenatx wrote:
| the essence of the article is that agile is mainly a project
| management methodology. It is for decomposing tasks into chunks
| that allow you to deliver something valuable in the given time
| frame. One of the best parts is that if you run out of time or
| money, you have something that is usable with what should be the
| most important features.
|
| What it doesnt give any guidance to is how to organize
| information about how to build the right thing. If a system is
| very large, without some methods to understand and communicate
| what you are building, it just becomes ad hoc. Agile is not a
| product management/requirements identification methodology.
| robjan wrote:
| The site has blocked Hong Kong (and possibly other) IP addresses
| for some reason.
|
| Here's an archive link https://archive.is/wip/OFF0F
| flohofwoe wrote:
| Call me jaded, but that's probably because the cow stopped giving
| milk, and they need to come up with a new cult/religion/ideology
| to continue selling books and conference tickets (and consulting
| gigs of course).
| baryphonic wrote:
| I think Zed Shaw had the best (or at lest most entertaining)
| take on being jaded about "agile." Though, fair warning, it is
| even more vulgar than the URL indicates. http://programming-
| motherfucker.com/
|
| He subsequently gave a talk comparing agile (and open source
| and consulting and startups and...) to fascist propaganda.
| https://www.youtube.com/watch?v=c5Xh2Go-jkM
|
| I'm not promoting it or saying I agree with it (I actually
| disagree with quite a bit of it), but it is entertaining.
| drewcoo wrote:
| Or a new metaphor to sell milk?
| joejerryronnie wrote:
| When I'm hiring scrum masters, seeing "Agile Coach" and "Agile
| Transformation" on a resume is actually a bit of a red flag for
| me. I don't need someone who can teach my organization how to
| theoretically run Scrum, I need someone who can engage with our
| dev teams, understand the expectations they're being held
| accountable for, the challenges in meeting those expectations,
| and tailor a methodology (probably Scrum-based) which puts the
| dev teams in the best position to succeed and be happy while
| doing it.
|
| This may be a bit different depending on the make-up and maturity
| of the team. Sometimes, we need daily engagement with team
| members and "structured" collaboration, other times we just need
| to make sure everyone understands the sprint goals and then get
| out of their way. The challenge has always been when upper
| management wants to see a single dashboard which boils all teams
| down into a set of pre-defined metrics - and then positively
| reinforces teams (or their managers) for hitting metrics instead
| of delivering solutions. Training your VP's can be exhausting.
| koonsolo wrote:
| There are only 2 things your agile team needs: a retrospective
| and a manager that wants to improve the process.
|
| Everything else can flow from there.
| _jal wrote:
| Having been through "agile conversion therapy" at two different
| companies and then having seen what the companies actually did
| several months later, I think most of the value of 'agile' has
| been realized. To get much more out of it, you need some
| combination of a more capable culture and better disciplined
| people.
|
| And I'm not talking about just engineering - I'm mainly talking
| about customers and management.
|
| Most of the gains come from tighter feedback loops between
| engineers and other stakeholders than tend to happen without an
| intentional effort. This works because it is simple - tell teams
| to talk amongst themselves every day, get feedback from customers
| more incrementally than you otherwise would, etc.
|
| Most of the rest of the promised gains need better disciplined
| customers and managers - ill-defined specs, dropping projects to
| pick something else up, only to switch back a couple months
| later, managers who don't pay enough attention to what's being
| done until it is too late, etc.
|
| Perhaps the problem is that it is a management fad aimed at
| engineers. It needs a v2 aimed at nontechnical people, "become
| competent at asking for what you need".
| dropit_sphere wrote:
| In practice, this can only happen in a few ways:
|
| - development becomes a 1st-class "business" activity a la
| accounting, sales---not that you necessarily _do_ it as aanger,
| but you 're looked down on if you can't
|
| - a culture of "ask about the internals" becomes prevalent,
| where anyone who bought software without knowing how it worked
| was looked on as an idiot
|
| - developer coup
| mjfisher wrote:
| This seems like as good an excuse as any to share a link to
| "Modern Agile" again:
|
| http://modernagile.org/
|
| I think it's probably a good reinterpretation of the original
| manifesto that is a bit more fundamental and a bit more direct. I
| like the concepts a lot.
| helen___keller wrote:
| I've come to best appreciate agile by calling "agile" whatever
| practices work best for my team.
|
| Sometimes we move things in and out of a sprint mid-sprint
| because new information came up and it's high priority? It's not
| ideal (and we'll discuss it in retro) but that's agile.
|
| We've sat a fat 5-point ticket in our backlog for 3 sprints
| straight because it needs a decent sum of meeting time and
| dedicated attention from multiple engineers who keep facing
| higher priority work and not quite having time for it? That's
| fine, we're being agile.
|
| Our backlog grooming meeting ended after 8 minutes because we had
| nothing to discuss and we're all focused on delivering? Very
| agile.
| HeyLaughingBoy wrote:
| Three sprints? LMAO. I've had tickets that sat "In Development"
| for the better part of 6 months because higher priority stuff
| kept coming up, but no one wanted to acknowledge that we had
| more pressing work to do :-)
| zabil wrote:
| IMHO the Agile manifesto still holds good. It applies to
| arguments in the article around processes (and tools) to
| ironically fix itself.
| brightball wrote:
| Ultimately, people need agreed upon terms for communicating
| planning and expectations.
|
| That's it. The more people are involved, the more complicated the
| process gets and all of these approaches evolve out of trying to
| find an agreeable and effective way of doing it so that everyone
| doesn't have to figure out a new solution every time.
|
| As much of a buzzword hell as it is, I really believe that Scaled
| Agile Framework (SAFe) is the closest thing to the right balance
| of trade offs.
| [deleted]
| zhenchaoli wrote:
| Distracting snake oil. That's what I think about when I hear
| agile.
| tremoloqui wrote:
| The terms "agile" and "Agile" have two separate meanings.
|
| Big 'A' - "Agile" is waterfall re-branded - an excuse for
| corporate empire building and business as usual. It involves
| lot's of meetings and not trusting those who build software to do
| the right thing.
|
| Small 'a' - "agile" is the implementation of the manifesto, which
| basically comes down to smart people figuring out how to work
| together towards a goal, often by taking small steps.
|
| Until the terminology is sorted out the discussion can't help but
| be confused.
| [deleted]
| ska wrote:
| In my experience "agile" was a loose rebranding of ideas that
| had been around for a long while (see all the other non-
| waterfall approaches that predate it) and "Agile" (i.e. the
| manifesto) was just one attempt at one of these sort of
| methodologies.
|
| Once it got popular, "Agile" was co-opted by all the usual
| players (cf "extreme" before it, to a lesser degree).
|
| The important idea is "agile" vs. waterfall, whether or not
| that includes anything directly recognizable as "Agile". Or
| call it something else, doesn't really matter.
|
| Recent history shows you can certainly do things directly
| recognizable as part of the Agile methodology while
| demonstrably not being agile, so modulo the no true scotsman
| fallacy it's a much less fruitful distinction to draw.
| dennis_jeeves wrote:
| >In my experience "agile" was a loose rebranding of ideas
| that had been around for a long while (see all the other non-
| waterfall approaches that predate it) and "Agile" (i.e. the
| manifesto) was just one attempt at one of these sort of
| methodologies.
|
| You are correct. The Agile term was probably marketed to the
| management types as a some breakthrough methodology to
| _finally_ control the budget for software development. Then
| it took a life of it's own as many things do.
| tremoloqui wrote:
| Most good ideas predate their branding.
| ska wrote:
| True, but they were already branded albeit not as
| successfully. And this is very much one of those things
| that is somewhat evergreen - it just gets a new branding
| every decade or so.
|
| I guess I'm saying "Agile" was/is one of several, and
| that's ok (good even). It's worth not getting bogged down
| on the "Agile" part and focusing on the more essential
| things.
| a_c_s wrote:
| Agree 100%: agile practices can be great.
|
| Hiring a consultant to teach 'Agile' is easy: the change of
| practices from something completely top-down to something that
| empowers the people at the bottom is the hard part and some
| orgs aren't capable of changing. Too many orgs are built around
| micromanagement, they don't know any other way.
| tremoloqui wrote:
| To these orgs it's a matter of trust and power.
| Frost1x wrote:
| Since businesses are the ones who employ software developers,
| 'Agile' is the only Agile that matters because that's the
| definition the people who pay money use.
|
| We can talk all day about principle philosophical differences
| and what is/isn't 'agile,' but there has been a consensus from
| businesses in industry that 'agile' is 'Agile.'
|
| Agile has become an excuse for terrible planning and offloading
| more and more work with ever increasing responsibilities to
| developers. At some point, enough professionals will reject
| following these terrible frameworks through different
| mechanisms. We're definitely not there yet, unfortunately.
| tremoloqui wrote:
| The solution imo is to remove those parts of the industry
| that are driving the mistaken consensus.
|
| Build software in small firms or consultancies who will treat
| it as a craft.
|
| Maybe more a hope than a solution.
| davnicwil wrote:
| The process is invented to help to do your job.
|
| Problems begin when that gets forgotten, and following the
| process _becomes_ your job -- not following the process is doing
| your job wrong.
|
| Always remember that your job is to build stuff, any way that
| works.
| AgloeDreams wrote:
| Spot on. The problem with much of Agile today is that Jira, the
| product is sold to management as effectively employee tracking
| tools that enable them to know who is good and who is bad and
| what was accomplished. It tends to turn engineers into ticket
| crunchers (chopping their heads off of thinking about products
| and isolating them from the customer) and causes planning to be
| incredibly near sighted or excessively structured.
| MattyRad wrote:
| I think the spirit of the article is summarized by Putt's Law
| https://en.wikipedia.org/wiki/Putt%27s_Law_and_the_Successfu...
| RcouF1uZ4gsC wrote:
| > At the time, software development was suffering from a mistaken
| belief: that building things fast and building things well were
| fundamentally opposed.
|
| I thing "good, fast, cheap; pick 2" is still generally valid.
| riazrizvi wrote:
| Note to self: Remember whenever you think "Good,fast,cheap;
| pick 2", it frames your choices as either "produce something
| not-good" or "produce something and take your time or hire lots
| of people". You are again regressing to your ivory-tower-
| inventor tendency, you spend too long perfecting and the
| perfecting gets worse and worse. Instead it's "fast+cheap,
| fast+cheap, fast+cheap" to minimize the time between customer-
| hypothesis and customer-trial. You do that until you achieve
| "good enough". This is the surest and most economical way to
| achieve "good". This is agile.
| MattGaiser wrote:
| > until you achieve "good enough".
|
| Or until the ever-growing pile of garbage that agile produces
| gets too tall and tips over. Then you throw away the codebase
| and start again :).
| analyst74 wrote:
| This is the way.
| namdnay wrote:
| Sometimes I'm not sure you can have just good and fast, however
| much money you throw at it. Some things just take time to work
| through.
| koonsolo wrote:
| Developers are your biggest cost, so I never understood why
| fast and cheap would be opposed to each other. And if you buy
| off the shelve, most of the time it's both faster and cheaper
| than building it yourself.
|
| So I always felt that fast and cheap go hand in hand.
|
| I think the triangle is:
|
| - features
|
| - quality
|
| - cost (=both price & time)
|
| Edit: I forgot to mention that you cannot just throw more
| engineers at a problem to make it go faster. There is such a
| thing as an optimal team size.
|
| Another edit (sorry it's Friday evening here;)): The faster you
| can get it done, the cheaper it will be.
| EdSharkey wrote:
| We have to peg quality with rigorous testing or else cost
| (time spent) will be variable upwards to infinity (due to
| accumulation of untenable technical debt).
|
| Therefore, if cost must be pegged due to limited time/funds
| and quality must be pegged due to existential risk then
| quantity/richness of features must float and be flexible.
|
| All good product owners will learn this truth eventually.
| OrangeMango wrote:
| > Developers are your biggest cost
|
| This is unlikely to be true. Bad decisions are your biggest
| cost.
|
| An employee has a "return multiplier" - for every dollar you
| spend on them, what is the return to the business? Sometimes
| it is high. If so, the developer is very cheap. Sometimes is
| it low, or negative. If so, the developer is expensive.
|
| Why would it be high or low? Part of that is developer skill,
| but mostly it is how well your organization runs itself and
| makes decisions.
| peterwwillis wrote:
| The core of Agile, Scrum, DevOps, XP, TDD, etc, is just to get a
| developer to truly understand what it is they're _doing_ and make
| a meaningful connection to the real results of it. But before
| they can ever begin to do that (which is a huge challenge in and
| of itself), the organization needs to _get the hell out of their
| way_ , but at the same time, _invest tons of money and effort to
| help them do what they should be doing_.
|
| If you just "step back" from trying to control the average bunch
| of engineers, they will miserably fail, because they have never
| gone to a school that taught them how to rapidly drive business
| value through software. If you hire the right people, they
| already learned all of that, and so they'll be successful.
|
| That's how the Netflixes of the world survive. Their organization
| and process would seem _totally insane_ to any "average" tech
| engineering organization. But it works for them because they
| learned how to work together the correct way, the business got
| the hell out of the way, and it also invested a ton in helping
| them do what they need to do.
|
| Agile does not give you any of that. Agile is just a promise of
| what _should_ be happening, but it doesn 't tell you how to get
| there at all. It's a pipe dream.
|
| Agile is not the problem, though. It's businesses thinking the
| engineers are simple tools to be used to produce widgets, and if
| they just shove enough extra business roles and processes around
| the engineers, that will end up creating value. But the solution
| is actually to _remove_ all that extra crap, and get the
| engineers to do everything in a way that the PMs and DMs and QEs
| etc are no longer necessary.
| betaby wrote:
| Interesting perspective. Could you please explain what do you
| mean by 'Netflixes'. What precisely they do and don't (in
| contrast with less successful companies)?
| mindcrime wrote:
| _Agile 's early evangelists wouldn't mind watching Agile die_
|
| It's easy to say that, but the obvious follow-on question is "and
| replace it with what, exactly?" Maybe the answer is in TFA, but I
| didn't read it yet. I hope they have _something_ to propose,
| otherwise this discussion is pretty vacuous.
| arminiusreturns wrote:
| I recently listened to a lecture about the future of programming,
| and there was a sentence that really stuck out to me. The speaker
| said something along the lines of "If you go to an agile
| conference, there aren't that many devs there and it's mostly
| management.*
|
| As an ops type usually only on the peripheral of sprints etc I
| feel I don't fully grasp the nuances of the different methods
| enough to really comment, but that just really got my attention
| for some reason.
|
| Found the video, linking at the timestamp that includes the
| manifesto for agile (which I think has some obvious flaws)
|
| https://youtu.be/ecIWPzGEbFc?t=3678
| vpeters25 wrote:
| Every time I see an "agile sucks" post, I take the time to read
| it and every time (so far) I have found they blame the process
| for some key part of agile they missed. Quote from the article:
|
| "Way too much of Agile has been not about technology, but about
| people and about managing things and about getting stuff done --
| not necessarily getting the right stuff done."
|
| This is the whole point of agile: progress on iterations, inspect
| and adapt at the end of each iteration.
|
| Your team might build the "wrong stuff" for an iteration, realize
| it (inspect), then make a course correction (adapt). If you end
| up delivering the "wrong stuff" is because you didn't follow this
| very core principle of agile.
|
| I find it hard to believe these so called "Agile Early
| Evangelists" can make such a statement. Their background in lean
| development should have made the familiar with empirical process
| controls, from where lean and agile come from.
|
| My guess the author quoted them selectively to fit the "agile
| sucks" narrative of the article.
|
| Edit: expanded last 2 paragraphs.
| arduinomancer wrote:
| Every time I see a comment on an "agile sucks" post I see
| people saying "well that's not true agile".
|
| Which sounds a bit like the "no true scotsman" fallacy.
|
| If so many people have trouble implementing agile maybe it just
| doesn't work?
| ebiester wrote:
| So, it gets complex.
|
| I have been privileged to work in a company that really thought
| about and worked to prioritize the four values on the left. I
| would follow those agile coaches to any place they wanted. I
| have been a staunch defender in real life and online, because
| I've seen it work very well. I also have been on teams with
| other processes and seen how much worse it can be.
|
| I will take the values of agile and push for those, and I'll
| take the lessons learned such as quick feedback loops,
| continuous integration, relative estimation, automated tests
| (which came from people like Kent Beck and Robert Martin
| pushing them so hard alongside agile), and the good stuff.
|
| However, after seeing how badly it can be weaponized against
| developers, I'm certainly ready to throw out the bathwater, and
| I think this is what they're talking about. I've seen far too
| much cargo cult agile and far too much command and control with
| a light layer of SCRUM.
|
| We have agile "coaches" who have never learned to code! They
| take a set of color-by-number technical practices but don't
| understand how or why they matter! I had to correct someone's
| slide that got the four values wrong, and their consulting
| group apparently had been copying and pasting them incorrectly
| from presentation to presentation!
|
| The values and principles of agile are great. The current
| implementation has some serious debt.
|
| (And while we're at it, we could update it. Too many people
| misunderstood the documentation part. Continuous attention to
| technical excellence needs to be upgraded to a value.
| Delivering frequently today means days instead of weeks.)
| vpeters25 wrote:
| > However, after seeing how badly it can be weaponized
| against developers, I'm certainly ready to throw out the
| bathwater, and I think this is what they're talking about.
|
| Poor management is a separate issue from agile. Even so, I
| would rather stay on a poorly managed agile shop than go back
| to a waterfall shop.
|
| As far as the "values on the left", I like to explain them as
| a 55/45 split (and adjustable depending on your reality): we
| still deal with processes and tools, we just take a second to
| think whether a process is actually needed when we can just
| talk to someone instead.
|
| Example: on a small team, you might just ask "can someone
| please approve my changes?" instead of having a whole jira
| workflow with code reviews and approvals.
| ebiester wrote:
| Again, you're fighting a strawman.
|
| The only alternative to Agile isn't Waterfall. The right
| alternative is probably something entirely new.
| loopz wrote:
| The alternative is always Doing What Works. Alot of Agile
| is superfluous Waste. With time it'll only grow more
| added layers of inefficiencies. The true costs and risks
| always get hidden away.
| interactivecode wrote:
| With these things the reality of agile is within corporate
| constraints. The Big managers will want to steer the company
| and dictate deadlines or goals. While the pure form of agile
| might work the reality of agile causes a lot of friction.
|
| Keep in mind though problems also show up with waterfall or
| young small startups. Its just which flavor of friction/pain
| project issue you are willing to deal with
| d--b wrote:
| One thing that's for sure is that Agile completely shifted the
| culture of software engineering, and generally in a good way. I
| am very thankful for that, and I think that this is where Agile
| has done its job.
|
| Then, the problem with frameworks like Agile is that smart people
| will use them wisely, and less smart people will try to apply the
| concepts without really grasping the ideas and not really gain
| anything out of it.
|
| But you can't really prevent people from reading the book, and do
| stand-up scrum meetings and sprints and shit...
|
| Unless someone comes up with something else (which most likely
| will be equally twisted) Agile is here to stay. I just wouldn't
| mind watching conversations about Agile die.
| at_a_remove wrote:
| I was exposed when it was still eXtreme Programming (back when
| "extreme" was the most nineties adjective you could have) and
| didn't much care for it then.
|
| I keep hearing it touted as this kind of universal cure-all but I
| just do not think it is applicable everywhere. On a personal
| level, the more any given thing is touted to me as the solution
| for any and all problems, the more suspicious I grow. The more
| fervor, the more I draw away. The more cultish it seems (convert,
| adhere, rituals, special names, and then finally the narcissism
| of small differences in practice as exemplified by that old Emo
| Williams routine), the less I want to participate.
|
| The more I have seen it shoehorned into places where it seemed
| ill-suited, the more this was revealed to me, yet the evangelism
| continues. Nothing like watching the tape backup guy, suffering
| from a flare of gout, hobble over to a room to perform his
| "stand-up" routine to hammer that home. Of course, we "probably
| weren't doing it right," but the more I have seen the slavish
| adherence to the strictures of Agile the more it seemed like this
| was an exercise in polishing a boss' resume so that he could say
| he had done The Things when he went elsewhere.
|
| Reader, he did.
|
| Perhaps the Agile that can be critiqued is not the eternal Agile.
| MattGaiser wrote:
| The project where extreme programming came from.
|
| https://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compens...
|
| Not a good start
| ChicagoDave wrote:
| The Agile paradigm has been corporatized and all of its
| capabilities turned into heavy process and oversight bullshit.
| But worst of all, management rarely sees the need to get
| involved, especially from the financial management perspective.
| It's very often a zombie project management apocalypse in the
| making.
| charles_f wrote:
| Agile is not a methodology or a process, it is literally[1] a set
| of values and principles which can be summarized by "stop being
| stupid and trying to reproduce what they do in construction
| engineering, and start discussing about the why and collaborate,
| doing things that matter, and being flexible, since after all,
| we're doing _soft_ware.
|
| The set of methodologies and processes that ensued, as well as
| the entire industry of coaches, consultants, evangelists and
| "practitioners" was probably coming from a good place - trying to
| propose an implementation for how to put in place those abstract
| values and principles, or to help with that. The
| commercialization, envy and corruption that followed is what the
| problem is. "Agile" has become a synonym for "cargo-cult
| brainless implementation of sprints and stand-ups to copy
| something called scrum but effectively doing things in a very
| much waterfall and old fashion that isn't even remotely close to
| the original intent".
|
| The problem is of semantics order. What does need to "die" is the
| "agile" industry, with cargo-cultish coaches whose only value is
| to repeat Scrum says X, XP says Y, Agile says Z, my other
| customers do , without trying to convey the reason behind those
| implements ; "agile" methodos like "safe" which have very little
| agility backed in and whose "Enterprise Architects" proponents
| usually don't get any of the intent.
|
| But take a look at the manifesto[1] and tell me that you want it
| to die, I feel like the arguments will be very complex. Re: the
| that we should become "engineers" (semantics and cargo-cult
| again), there's a very good reason why agile applies well to
| software, but not to mechanical engineers. The economic equations
| between those two practices are completely different[2][3], the
| "engineering" phase of mechanical engineering is cheap compared
| to the production costs and so iterations have effectively an
| extremely high overhead cost, whereas the "engineering" phase of
| software engineering represents most of the cost, and so
| iteration and adaptability have a very low overhead.
|
| But saying "agile needs to die" because of how the "agile
| industry" corrupted it is similar to saying "email needs to die"
| because what you see most is spam.
|
| [1]: https://agilemanifesto.org/
|
| [2]:
| https://www.developerdotstar.com/printable/mag/articles/reev...
|
| [3]: https://www.youtube.com/watch?v=RhdlBHHimeM
| kchoudhu wrote:
| They've all moved on to newer grifts, and don't need competition
| from legacy grifts.
| cesium wrote:
| When something develops to an extreme, it becomes its opposite.
| This is true for "agile". Agile has become synonymous with
| "Jira", which is a direct contradiction of its original premise.
| The original "Agile Manifesto" states: Individuals and
| interactions over processes and tools, Working software over
| comprehensive documentation, Customer collaboration over contract
| negotiation, Responding to change over following a plan. Ask
| somebody these days what agile means and they'll tell you "Jira"
| or some other tool combined with heavy process. Another example
| of people confusing the means for the end itself.
| temac wrote:
| And also ask people if they really want all of "Individuals and
| interactions over processes and tools, Working software over
| comprehensive documentation, Customer collaboration over
| contract negotiation, Responding to change over following a
| plan." That might not really make sense in some industries...
|
| And if they really want to consider all of that in a
| dichotomous way. Who really does not want "working software",
| and why would I even have to "prefer" that? this is just too
| much fundamental that we could as well say: we don't want to
| work on garbage projects, and it is stupid to have an extremely
| good documentation of a pile of crap. But why jettison
| documentation if "working software" is not even considered
| optional to begin with? I fucking want stellar documentation.
| Because why not? I'm tired of reading source code all day to
| try to understand what things were even supposed to do...
|
| In some industries "agile" in its original definition can make
| sense. In others, not at all. Yet, tons of people will pretend
| they do "Agile" regardless of what it is, what they _think_ it
| is, _and_ of what they do. This is sometimes some kind of
| management virtue signaling; except it is not signaling
| positive things anymore to those who work.
|
| It really has no meaning anymore. To be honest I'm not even
| sure it ever had, as implemented by most, out of the industry
| it came from (with associated practices that were also highly
| contextual)
|
| People should just avoid focusing on fashionable shallow words,
| and skip right to the ideas: if all of Agile and even all of
| Scrum is what will make your project shine, just do it, but
| writing essays about it is not really doing it, nor is
| pretending it is a kind of universal panacea, nor constructing
| consulting services around cult practices. If you must do the
| complete opposite; do the complete opposite. And tell everybody
| you are "agile" without an once of shame, if that can help
| raising money or stupid shit like that -- I mean what is even
| more agile than doing otherwise than "Agile" if it is a better
| idea in your context; so you are not even lying :p
___________________________________________________________________
(page generated 2020-04-24 23:00 UTC)