8 ms·

My Foreword to “The Art of Agile Development”

57 points by gregmac 5y ago

NKosmatos 5y ago
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 5y ago
  That's fine, it can be fixed in the next sprint.
- aynyc 5y ago
  It’ll go into the backlog.
Ecstatify 5y ago
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.
- Jtsummers 5y ago
  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 5y ago
    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 5y ago
      > 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.
    - brightball 5y ago
      The issue with waterfall is that planning it properly depends entirely on accurate estimates. Estimates are never accurate. You can’t possibly have all of the information present up front.
      - dilyevsky 5y ago
        In my experience with waterfall this was solved exactly same as with making sure scrum stories can be completed in a sprint - by padding the shit out of your estimates to the point most engineers can complete their tasks working a few hours a week.
    - corpMaverick 5y ago
      I think it is more correctly defined as "Big Upfront Design". This was a thing; months spent on analysis and design that filled several tomes.
      - Jtsummers 5y ago
        Big Design Up Front (the more common way of ordering the words) is related to, but is not, Waterfall. Waterfall is best considered an instance of BDUF (to borrow a programming term). V-Model and (often) Iterative & Incremental (slow-motion Scrum) each have varying degrees of BDUF as well, and there are plenty of other SDLCs out there that can be categorized as BDUF-lifecycles. Waterfall's principle failing for large scale projects is that it does not incorporate sufficient (if any) feedback or delays the feedback until too late in the cycle, and plans too far out to be reasonable (do you kwon with any real confidence what you'll have for dinner in 3 years, 2 months and a day?) V-model generally also plans out very far, but incorporates V&V as an ongoing activity (it's name is a bit of a pun, both incorporating V&V and usually being charted out as a V, vice a waterfall for Waterfall). I&I may have a big design phase, but it's usually not as fully designed as either Waterfall or the V-model because the iterations are meant to provide checkpoints for validating the design and potentially changing direction (like I wrote, slow-motion Scrum).
  - Ecstatify 5y ago
    Conversely we’re Agile™, 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.
    - Jtsummers 5y ago
      I'd agree with that. A principle quality of Agile (what was intended, though often not what is) is responsiveness to changing circumstances and reality. A commitment to the wrong development model is anti-Agile, though very common. It's, for most purposes, just as bad as Waterfall's commitment to building the wrong thing.
- Graffur 5y ago
  What does getting 'spotified' mean? A company doing Agile poorly most likely would do Waterfall poorly too.
  - Ecstatify 5y ago
    Spotified basically means your company decided it was Agile™ and forced the Spotify model on teams so essentially now you’re a cargo cult. https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf 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™
  - blakehaswell 5y ago
    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-engineering-culture-part-1/ https://engineering.atspotify.com/2014/03/27/spotify-enginee... [2]: https://engineering.atspotify.com/2014/09/20/spotify-engineering-culture-part-2/ https://engineering.atspotify.com/2014/09/20/spotify-enginee...
    - Ecstatify 5y ago
      Allegedly they never actually implemented the model either https://www.jeremiahlee.com/posts/failed-squad-goals/ https://www.jeremiahlee.com/posts/failed-squad-goals/
- EliRivers 5y ago
  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 5y ago
    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 5y ago
  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.
- thrower123 5y ago
  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.
  - g051051 5y ago
    > But this guidebook can help you through that journey—moving away from barren ceremonies to the vigor that we felt when James and I first used these techniques all those years ago. This explains so much...this was something they enjoyed, and somehow conflated that as some kind of proof that it would work for all software development.
- Zababa 5y ago
  We're technically agile at my work, which means that we follow a waterfall cycle of 2 weeks.
recursivedoubts 5y ago
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 5y ago
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.
- Graffur 5y ago
  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)
- Jensson 5y ago
  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!".
- smoe 5y ago
  The problem with any development philosophy or dogma at this point is, that it will eventually be led by people that want to make money from it trough books, consultancies, certificates, etc. People that are willing brush over any downsides or compromise its original ideas in whatever way necessary to sell. We could replace agile with something else and it will end up the same way.
  - hpoe 5y ago
    We already have all the agile consultants have rebranded themselves "DevOps" consultants, or even better at this point "DevSecOps" all well ignoring completely everything DevOps is supposed to be about. These false priests of technology substitute their tools for their lack of understanding and ignore completely that just having a pipeline and doesn't mean you are doing DevOps.
about3fitty 5y ago
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 5y ago
  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.
  - g051051 5y ago
    You're lucky. During my most recent job search (January 2021) nearly every recruiter ping I got either stated that they were using agile as a selling point, or listed it in the job description as a required skill. If I have any say in the matter, I'll never work in an "agile" shop again.
- enra 5y ago
  Pretty much almost every Silicon Valley VC funded company or 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 I never have 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 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-tech/ https://blog.pragmaticengineer.com/project-management-at-big...
kleiba 5y ago
It's my impression that agile/scrum is now mostly viewed with a negative sentiment. Some years ago, it was the opposite. As someone who has never worked in the industry (only in academia), I'm curious: what is it that turned the tide? Could someone elaborate (a) why agile/scrum fell out of favor; and (b) what is its modern replacement? Thanks!
- abacadaba 5y ago
  Mostly being superseded by the PMOFO methodology the leading shops. [0] 0: http://programming-motherfucker.com/ http://programming-motherfucker.com/
- kelseyfrog 5y ago
  The consulting and training industry captured the c-suite mindshare and sold process over people.
- johncessna 5y ago
  As someone who joined the movement, believed in i, and still does, I had a lot to say about point a. I think the following best wraps it all up though. "Every great cause begins as a movement, becomes a business, and eventually degenerates into a racket" -Eric Hoffer I think another important thing to point is that most* software projects fail. Trying a new methodology is a good way to deflect blame and extend life into a bad business, team, manager, product. b) I don't think so. I think companies are still chasing agile. I personally hope it makes a resurgence. Unfortunately Waterfall is perceived as an urban legend vs the monstrosity it is/was on the industry by the new generations * I thought it was 50%. [1] suggests it's 75%, and this[2] suggests 90%+ [1]https://www.geneca.com/why-up-to-75-of-software-projects-will-fail/ https://www.geneca.com/why-up-to-75-of-software-projects-wil... [2]https://www.quora.com/What-percentage-of-software-projects-fail?share=1 https://www.quora.com/What-percentage-of-software-projects-f...
FirstLvR 5y ago
As a dev on an ISV all I can say is that agile equals fail on every project we have tried The name sounds cool tho
snidane 5y ago
By 'agile', as one of the first people around the manifesto, Fowler means product development applied to software. If you're curious which fields benefit from it and which don't, it is all fields in which you create a product that users use or will use. Agile (product development) doesn't help any process which is not supposed to be used by users. Examples: software products with 100%, and no less, defined specs. Second use case is never released vaporware, such as everything for which waterfall methodology is used and specs are assumed to be 100% correct upfront and it turns out they are not. The only type of project with 100% defined requirements I'm aware of are one-to-one software rewrites. Agile for majority of devs and consultants (and not for the people around manifesto, such as Fowler) is conflated with a 2 week or so status reporting and planning process. It has nothing to do with product development as these status reports typically don't ask 'what is the status of the product' but the status report is typically about 'what everybody is doing and if they are busy'. This has nothing to do with the original agile manifesto and if you read through it you'll notice that this modern 'Agile/Scrum' time-boxed busywork and status report is in contradiction with its principles. Keeping devs busy is obviously the goal of this consulting scrum as that is what consultants charge for. Fowler himself gave up years ago explaining the difference. When words become popular, their meaning gets hijacked and repurposed. He explained this in a blog post of his https://martinfowler.com/bliki/SemanticDiffusion.html https://martinfowler.com/bliki/SemanticDiffusion.html
jdlshore 5y ago
(Author of The Art of Agile Development here.) Lots of negativity in this thread. I can't say I'm surprised. For what it's worth, I mostly agree with the negativity—"Agile," as commonly practiced, tends to be terrible. That's part of why I wrote the new edition. I say as much in the first paragraphs of the book: > Agile is everywhere. And paradoxically, nowhere. > In the 20 years after the Agile freight train roared into software developers’ consciousness, the number of companies calling themselves “Agile” increased by orders of magnitude. The number of teams actually taking an agile approach to their work? Not so much. “Agile,” the easily repeated name, is enormously successful. The ideas behind Agile—well, most of them are ignored. > Let’s fix that. If anybody would like to talk about the book, I'm happy to engage. If you're curious about the book, the first three chapters are currently up for free on my website, and there's a lot of excerpts from the remaining chapters posted too. Follow the links in the table of contents at the bottom of https://www.jamesshore.com/v2/books/aoad2 https://www.jamesshore.com/v2/books/aoad2.
- recursivedoubts 5y ago
  I think many aspects of Agile are sensible enough in most situations. My negative experience with Agile has mainly been through people who are ideological about it and insist, when agile fails, that it was not the fault of the process or some other factor, but rather the fault of the people who "didn't implement agile right." A bit of humility from the Agile community would be very welcome, as well as clarification of what types of problems it works well for and which ones it doesn't, where the dangers are, etc.
  - jdlshore 5y ago
    I can't grant you humility from the Agile community, or even necessarily from myself, but I can clarify what problems it works well for and doesn't, dangers, etc. Agile works well when organizational leaders are willing to invest in changing the constraints of their organization, and team members are similarly willing to work to customize the philosophy—'cause that's all it is, a way of thinking about software development—to their specific situation. Given those two things, I've yet to find a type of software development where Agile didn't work. People have used its ideas for web development, embedded systems development, back-end, front-end, Java, C++, JavaScript, etc. etc. But those two things can be really really hard, which is why I think cargo-cult Agile is so common. And trying to be Agile without them is dangerous, in that it can easily be worse than whatever it replaced. I talk about them more in chapters 4 and 5 of the book. You can find an excerpt of chapter 4, including a list of the investments needed, here: https://www.jamesshore.com/v2/books/aoad2/invest_in_agility https://www.jamesshore.com/v2/books/aoad2/invest_in_agility

57 points by gregmac 5y ago

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 5y ago
That's fine, it can be fixed in the next sprint.
aynyc 5y ago
It’ll go into the backlog.

Ecstatify 5y ago

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.

Jtsummers 5y ago
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 5y ago
  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 5y ago
    > 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.
  - brightball 5y ago
    The issue with waterfall is that planning it properly depends entirely on accurate estimates. Estimates are never accurate. You can’t possibly have all of the information present up front.
    - dilyevsky 5y ago
      In my experience with waterfall this was solved exactly same as with making sure scrum stories can be completed in a sprint - by padding the shit out of your estimates to the point most engineers can complete their tasks working a few hours a week.
  - corpMaverick 5y ago
    I think it is more correctly defined as "Big Upfront Design". This was a thing; months spent on analysis and design that filled several tomes.
    - Jtsummers 5y ago
      Big Design Up Front (the more common way of ordering the words) is related to, but is not, Waterfall. Waterfall is best considered an instance of BDUF (to borrow a programming term). V-Model and (often) Iterative & Incremental (slow-motion Scrum) each have varying degrees of BDUF as well, and there are plenty of other SDLCs out there that can be categorized as BDUF-lifecycles. Waterfall's principle failing for large scale projects is that it does not incorporate sufficient (if any) feedback or delays the feedback until too late in the cycle, and plans too far out to be reasonable (do you kwon with any real confidence what you'll have for dinner in 3 years, 2 months and a day?) V-model generally also plans out very far, but incorporates V&V as an ongoing activity (it's name is a bit of a pun, both incorporating V&V and usually being charted out as a V, vice a waterfall for Waterfall). I&I may have a big design phase, but it's usually not as fully designed as either Waterfall or the V-model because the iterations are meant to provide checkpoints for validating the design and potentially changing direction (like I wrote, slow-motion Scrum).
- Ecstatify 5y ago
  Conversely we’re Agile™, 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.
  - Jtsummers 5y ago
    I'd agree with that. A principle quality of Agile (what was intended, though often not what is) is responsiveness to changing circumstances and reality. A commitment to the wrong development model is anti-Agile, though very common. It's, for most purposes, just as bad as Waterfall's commitment to building the wrong thing.
Graffur 5y ago
What does getting 'spotified' mean? A company doing Agile poorly most likely would do Waterfall poorly too.
- Ecstatify 5y ago
  Spotified basically means your company decided it was Agile™ and forced the Spotify model on teams so essentially now you’re a cargo cult. https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf 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™
- blakehaswell 5y ago
  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-engineering-culture-part-1/ https://engineering.atspotify.com/2014/03/27/spotify-enginee... [2]: https://engineering.atspotify.com/2014/09/20/spotify-engineering-culture-part-2/ https://engineering.atspotify.com/2014/09/20/spotify-enginee...
  - Ecstatify 5y ago
    Allegedly they never actually implemented the model either https://www.jeremiahlee.com/posts/failed-squad-goals/ https://www.jeremiahlee.com/posts/failed-squad-goals/
EliRivers 5y ago
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 5y ago
  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 5y ago
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.
thrower123 5y ago
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.
- g051051 5y ago
  > But this guidebook can help you through that journey—moving away from barren ceremonies to the vigor that we felt when James and I first used these techniques all those years ago. This explains so much...this was something they enjoyed, and somehow conflated that as some kind of proof that it would work for all software development.
Zababa 5y ago
We're technically agile at my work, which means that we follow a waterfall cycle of 2 weeks.

recursivedoubts 5y ago

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 5y ago

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.

Graffur 5y ago
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)
Jensson 5y ago
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!".
smoe 5y ago
The problem with any development philosophy or dogma at this point is, that it will eventually be led by people that want to make money from it trough books, consultancies, certificates, etc. People that are willing brush over any downsides or compromise its original ideas in whatever way necessary to sell. We could replace agile with something else and it will end up the same way.
- hpoe 5y ago
  We already have all the agile consultants have rebranded themselves "DevOps" consultants, or even better at this point "DevSecOps" all well ignoring completely everything DevOps is supposed to be about. These false priests of technology substitute their tools for their lack of understanding and ignore completely that just having a pipeline and doesn't mean you are doing DevOps.

about3fitty 5y ago

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 5y ago
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.
- g051051 5y ago
  You're lucky. During my most recent job search (January 2021) nearly every recruiter ping I got either stated that they were using agile as a selling point, or listed it in the job description as a required skill. If I have any say in the matter, I'll never work in an "agile" shop again.
enra 5y ago
Pretty much almost every Silicon Valley VC funded company or 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 I never have 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 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-tech/ https://blog.pragmaticengineer.com/project-management-at-big...

kleiba 5y ago

It's my impression that agile/scrum is now mostly viewed with a negative sentiment. Some years ago, it was the opposite. As someone who has never worked in the industry (only in academia), I'm curious: what is it that turned the tide? Could someone elaborate (a) why agile/scrum fell out of favor; and (b) what is its modern replacement? Thanks!

abacadaba 5y ago
Mostly being superseded by the PMOFO methodology the leading shops. [0] 0: http://programming-motherfucker.com/ http://programming-motherfucker.com/
kelseyfrog 5y ago
The consulting and training industry captured the c-suite mindshare and sold process over people.
johncessna 5y ago
As someone who joined the movement, believed in i, and still does, I had a lot to say about point a. I think the following best wraps it all up though. "Every great cause begins as a movement, becomes a business, and eventually degenerates into a racket" -Eric Hoffer I think another important thing to point is that most* software projects fail. Trying a new methodology is a good way to deflect blame and extend life into a bad business, team, manager, product. b) I don't think so. I think companies are still chasing agile. I personally hope it makes a resurgence. Unfortunately Waterfall is perceived as an urban legend vs the monstrosity it is/was on the industry by the new generations * I thought it was 50%. [1] suggests it's 75%, and this[2] suggests 90%+ [1]https://www.geneca.com/why-up-to-75-of-software-projects-will-fail/ https://www.geneca.com/why-up-to-75-of-software-projects-wil... [2]https://www.quora.com/What-percentage-of-software-projects-fail?share=1 https://www.quora.com/What-percentage-of-software-projects-f...

FirstLvR 5y ago

As a dev on an ISV all I can say is that agile equals fail on every project we have tried The name sounds cool tho

snidane 5y ago

By 'agile', as one of the first people around the manifesto, Fowler means product development applied to software. If you're curious which fields benefit from it and which don't, it is all fields in which you create a product that users use or will use. Agile (product development) doesn't help any process which is not supposed to be used by users. Examples: software products with 100%, and no less, defined specs. Second use case is never released vaporware, such as everything for which waterfall methodology is used and specs are assumed to be 100% correct upfront and it turns out they are not. The only type of project with 100% defined requirements I'm aware of are one-to-one software rewrites. Agile for majority of devs and consultants (and not for the people around manifesto, such as Fowler) is conflated with a 2 week or so status reporting and planning process. It has nothing to do with product development as these status reports typically don't ask 'what is the status of the product' but the status report is typically about 'what everybody is doing and if they are busy'. This has nothing to do with the original agile manifesto and if you read through it you'll notice that this modern 'Agile/Scrum' time-boxed busywork and status report is in contradiction with its principles. Keeping devs busy is obviously the goal of this consulting scrum as that is what consultants charge for. Fowler himself gave up years ago explaining the difference. When words become popular, their meaning gets hijacked and repurposed. He explained this in a blog post of his https://martinfowler.com/bliki/SemanticDiffusion.html https://martinfowler.com/bliki/SemanticDiffusion.html

jdlshore 5y ago

(Author of The Art of Agile Development here.) Lots of negativity in this thread. I can't say I'm surprised. For what it's worth, I mostly agree with the negativity—"Agile," as commonly practiced, tends to be terrible. That's part of why I wrote the new edition. I say as much in the first paragraphs of the book: > Agile is everywhere. And paradoxically, nowhere. > In the 20 years after the Agile freight train roared into software developers’ consciousness, the number of companies calling themselves “Agile” increased by orders of magnitude. The number of teams actually taking an agile approach to their work? Not so much. “Agile,” the easily repeated name, is enormously successful. The ideas behind Agile—well, most of them are ignored. > Let’s fix that. If anybody would like to talk about the book, I'm happy to engage. If you're curious about the book, the first three chapters are currently up for free on my website, and there's a lot of excerpts from the remaining chapters posted too. Follow the links in the table of contents at the bottom of https://www.jamesshore.com/v2/books/aoad2 https://www.jamesshore.com/v2/books/aoad2.

recursivedoubts 5y ago
I think many aspects of Agile are sensible enough in most situations. My negative experience with Agile has mainly been through people who are ideological about it and insist, when agile fails, that it was not the fault of the process or some other factor, but rather the fault of the people who "didn't implement agile right." A bit of humility from the Agile community would be very welcome, as well as clarification of what types of problems it works well for and which ones it doesn't, where the dangers are, etc.
- jdlshore 5y ago
  I can't grant you humility from the Agile community, or even necessarily from myself, but I can clarify what problems it works well for and doesn't, dangers, etc. Agile works well when organizational leaders are willing to invest in changing the constraints of their organization, and team members are similarly willing to work to customize the philosophy—'cause that's all it is, a way of thinking about software development—to their specific situation. Given those two things, I've yet to find a type of software development where Agile didn't work. People have used its ideas for web development, embedded systems development, back-end, front-end, Java, C++, JavaScript, etc. etc. But those two things can be really really hard, which is why I think cargo-cult Agile is so common. And trying to be Agile without them is dangerous, in that it can easily be worse than whatever it replaced. I talk about them more in chapters 4 and 5 of the book. You can find an excerpt of chapter 4, including a list of the investments needed, here: https://www.jamesshore.com/v2/books/aoad2/invest_in_agility https://www.jamesshore.com/v2/books/aoad2/invest_in_agility