[HN Gopher] My Foreword to "The Art of Agile Development"
___________________________________________________________________
My Foreword to "The Art of Agile Development"
Author : gregmac
Score : 28 points
Date : 2021-10-26 14:38 UTC (8 hours ago)
(HTM) web link (martinfowler.com)
(TXT) w3m dump (martinfowler.com)
| NKosmatos wrote:
| The very first link of the article "Manifesto for Agile Software
| Development" isn't working sine it's pointing at
| www.agilemanifesto.org but the correct link is agilemanifesto.org
| :-)
| willismichael wrote:
| That's fine, it can be fixed in the next sprint.
| aynyc wrote:
| It'll go into the backlog.
| Ecstatify wrote:
| I think I'd prefer to do Waterfall correctly than pretending to
| be Agile.
|
| I love the idea of Agile, hasn't worked at our company since we
| got spotified.
| EliRivers wrote:
| The highest quality software I ever worked on was waterfall all
| the way, and by God, was it high quality.
|
| The requirements were hammered out in brutal detail by an
| experienced specialist. Each requirement agreed with the
| customer, and then each requirement carefully worked into a
| design. Each requirement clearly linked with every part of the
| design that fulfilled it. The design reviewed and approved. The
| code written in literal style (using a variant of noweb), with
| discussion and commentary, and that noweb document compiling
| into the source code to be onwards compiled and also a
| beautiful document listing the full source code and the various
| commentaries and discussions of it (such that one understood
| the code not by looking at the code, but by reading the
| document, which was like a structured guided tour of the code,
| and to look at the actual code was to see a one-to-one
| relationship with the documentation).
|
| Each part of that document linked to a part of the design, and
| thus to the requirements. Tests had been written independently
| of the code, based on the design and the original requirements.
| Test documents were printed out, and an individual conducted
| every test on that document, writing down version numbers and
| so on, and writing down each results, circling PASS or FAIL,
| signing their name to it. Successful test documents were sealed
| in an envelope, with a date and signature, and put into storage
| against the customer requesting to see one (which happened
| every so often).
|
| The original requirements could, years later, be followed
| through the design, through the code, through the tests; the
| whole chain verified on demand.
|
| The software I worked on was developed over most of a decade (I
| was only there about four years), with a delivery a couple of
| times a year. The customer never once reported a bug. Every
| requirement was met. Other contractors had their part taken
| away from them and given to us, and when it was finished they
| took it and asked us if we could start working on the next
| generation product of the same.
|
| I have never before or since worked on such high quality
| software. It was only possible because we happened to have
| really high quality customers, who actually knew what they
| wanted and had the ability to say it and agree to it.
| foobarian wrote:
| Quoth the Tao of Programming:
|
| 8.3 There was once a programmer who wrote software for
| personal computers. "Look at how well off I am here," he said
| to a mainframe programmer who came to visit. "I have my own
| operating system and file storage device. I do not have to
| share my resources with anyone. The software is self-
| consistent and easy-to-use. Why do you not quit your present
| job and join me here?"
|
| The mainframe programmer then began to describe his system to
| his friend, saying, "The mainframe sits like an ancient Sage
| meditating in the midst of the Data Center. Its disk drives
| lie end-to- end like a great ocean of machinery. The software
| is as multifaceted as a diamond, and as convoluted as a
| primeval jungle. The programs, each unique, move through the
| system like a swift-flowing river. That is why I am happy
| where I am."
|
| The personal computer programmer, upon hearing this, fell
| silent. But the two programmers remained friends until the
| end of their days.
| hinkley wrote:
| Waterfall with WIP limits and continuous _delivery_ is far less
| painful than a lot of processes I 've used.
|
| Because waterfall generally has milestones as a coarser grained
| way of ensuring evidence of forward progress, all deliverables
| generated around the time of a milestone just become candidates
| for delivery. Do you want this version that is missing two
| features, this version that is missing one but the other might
| be buggy, or to wait another two weeks to get the whole thing?
| If you have anything that looks like QA or acceptance tests,
| those can be run on deliverables, keeping people a little more
| comfortable with the process than they would with strict
| Waterfall.
| Graffur wrote:
| What does getting 'spotified' mean?
|
| A company doing Agile poorly most likely would do Waterfall
| poorly too.
| blakehaswell wrote:
| Back in 2014 Spotify released some videos[1][2] about their
| engineering culture. From what I understand these were widely
| cited by consultants and the squad/tribe/chapter model was
| implemented verbatim at a number of companies. I'm guessing
| that is "getting Spotified".
|
| [1]: https://engineering.atspotify.com/2014/03/27/spotify-
| enginee... [2]:
| https://engineering.atspotify.com/2014/09/20/spotify-
| enginee...
| Ecstatify wrote:
| Allegedly they never actually implemented the model either
|
| https://www.jeremiahlee.com/posts/failed-squad-goals/
| Ecstatify wrote:
| Spotified basically means your company decided it was
| Agile(tm) and forced the Spotify model on teams so
| essentially now you're a cargo cult.
|
| https://blog.crisp.se/wp-
| content/uploads/2012/11/SpotifyScal...
|
| Our problem at the moment is we have no
| processes/documentation because we're Agile(tm)
| Jtsummers wrote:
| Doing Waterfall correctly is easy. Spend 1 year planning, 3-5
| years building, 1 year testing, then release. Find out you
| built the wrong thing, enjoy the earnings from your $10 billion
| government contract, and start another cycle.
| JohnFen wrote:
| People often describe waterfall in that way -- but I've been
| in the industry for decades, and if that's what waterfall is,
| then I have never seen anyone do waterfall even before Agile
| was a thing.
|
| I think that "waterfall" is often a straw man.
| Jtsummers wrote:
| > I think that "waterfall" is often a straw man.
|
| Every discussion where Waterfall comes up has someone
| saying this, I'm glad you've not experienced it. But it has
| existed, does exist, and will continue to exist (because
| enough project managers are idiots). One of my first jobs
| (I quit) was a failed project that persisted because of
| gov't money, but would have failed as a commercial venture
| (started circa 2007, failed to deliver at least through
| 2011, I was on board for a year and found an exit). It was
| 100% Waterfall, they literally delivered the wrong thing
| several years late and with around $1 billion spent. Great
| for the contractors, awful for the taxpayers.
|
| But yes, that is what Waterfall is. It's a large scale
| project executed linearly with limited-to-no-feedback.
| Large scale is somewhat subjective, but basically if it's
| done in less than a few months it's probably not at a scale
| where your choice of development model actually matters.
| Ecstatify wrote:
| Conversely we're Agile(tm), the company is looking for
| external solutions to replace everything that has been
| developed for the last 8 years.
|
| If the company from top to bottom isn't Agile then I don't
| believe you can truly be Agile.
| thrower123 wrote:
| To quote Fowler and all of his ilk, this means you're doing it
| wrong, and you must contemplate the principles of Agile further
| until you achieve enlightenment and discover True Agile.
| recursivedoubts wrote:
| they constantly try to escape
|
| from the darkness outside and within
|
| by dreaming of systems so perfect that no one will need to be
| good
|
| but the man that is will shadow
|
| the man that pretends to be
| sul_tasto wrote:
| In my experience, management cherry pick aspects of the agile
| method that disempower knowledge workers and destroy any sense of
| ownership over the product, while ignoring all practices and
| intentions of empowering knowledge workers. Until the Agile
| custodians address how their philosophy has been corrupted in the
| real world, I want nothing else to do with it.
| Jensson wrote:
| Agile in practice is like conveyor belt mass production but
| with each produced piece having unique requirements from each
| worker. Managers love it, the conveyor belt is constantly
| moving so a worker can't look at any piece for too long, so
| throughput is steady and the team always looks very productive!
|
| Edit: And then some will say "If you are stressed, why don't
| you just reduce the speed of the conveyor belt? Agile is meant
| to be customized!", or "If an item wasn't done properly you can
| just move it back to the start of the belt so you can look at
| it again!". My answer is "I just don't want that damn conveyor
| belt in the first place!".
| Graffur wrote:
| Yep. I have done it well but I have also experienced exactly as
| your comment describes. In those scenarios, some poor tech lead
| is appointed whose responsibilities include estimation, knowing
| the whole backlog, managing tech debt, managing risks and
| hiring for the team (instead of an empowered team doing all
| this)
| about3fitty wrote:
| Can anyone point me in the direction of companies that are
| pointedly not using Agile/Scrum?
|
| I understand that embedded and large systems are most likely to
| eschew agile as it's frequently not a good fit for the work, but
| I work in Python/Django mostly at the moment.
|
| Scrum especially seems to fail in spectacular ways vs. other
| production methodologies in that when Scrum fails, it can be a
| net negative to the company. I feel as if I were to restrict my
| job search to companies that have anti-"Agile" methodologies, I
| would be more likely to work in a true agile environment.
|
| I understand the pressures that create Scrum, as nature hates a
| vacuum, but I can't understand why there isn't any slack at all
| to experiment and fail in most smaller organizations. Perhaps
| we're disinclined to "hire smart people and get out of their way"
| nowadays, because we can only make data-driven decisions.
|
| I'm sure that the best products are made by a small dedicated
| team of competent individuals communicating openly with one
| another, and I'm equally sure that success is rarer among those
| orgs. But, as someone with a degree in psychology, it's plain to
| see how operationalizing healthy communication patterns can have
| a counterintuitive result.
| Jensson wrote:
| The FAANG companies mostly don't, likely many companies similar
| to those also doesn't. If you can get into this sort of
| companies it isn't terribly hard to avoid, I'll never work at
| an Agile shop again.
| enra wrote:
| Pretty much almost every Silicon Valley VC funded startup I
| know are not using Agile/Scrum. My impression is Agile/Scrum is
| popular on consulting where the software buyer is external and
| therefore it's somewhat a mystery what they want so you hedge
| the risk and in companies where engineering is considered more
| of a "cost" and not well understood than something that drives
| the whole business.
|
| Anecdotally, Coinbase and Airbnb didn't use Agile/Scrum and
| never interviewed in a company that mentioned that. Usually how
| it works that there the company knows what they want and there
| is some kind of roadmap of projects or experiments which are
| based on improving some kind of goal or metrics. Teams usually
| work in somewhat iterative phases, were you start with design,
| build the first prototype/mvp, test internally until you get to
| a stage to run an experiment with the users. During this time,
| your team meets every now and then, gets feedback from others
| and you do reviews with leadership. Then eventually if the
| experiment seems promising and the feature is good enough, it
| gets shipped. You can have sprints or not but no-one talks
| about or uses about story points, retrospectives, planning
| pokers, product owners, user stories or other agile ceremonies.
| You have goal and project to accomplish, and then the
| management/leaderships tries to estimate with the team how long
| things will take.
|
| Pragmatic Engineer had article about this too:
| https://blog.pragmaticengineer.com/project-management-at-big...
___________________________________________________________________
(page generated 2021-10-26 23:00 UTC)