21 ms·

Agile at 20: The Failed Rebellion

• xiden2021 5y ago
  Donald Trump Rips the shit out of the Xiden Occupation Regime: Death to Covid Terrorists! https://rumble.com/vka124-president-donald-j.-trump-delivers-remarks-at-turning-point-action.html https://rumble.com/vka124-president-donald-j.-trump-delivers...
• mblock 5y ago
  > We have found that the role of the project manager is counterproductive in complex, creative work. The project manager’s thinking, as represented by the project plan, constrains the creativity and intelligence of everyone else on the project to that of the plan, rather than engaging everyone’s intelligence to best solve the problems. Pretty much wish this was a defined part of agile, most of the time all my boss/pm is good for is maybe reminding me of meetings. They never understand what I’m working on to help, but they have power to make giant decisions and elevate problems I have been waiting for the client on for some time. Idk if this is a common theme. I read a comment here a while back I agree with: your project manager, a good one, should remove obstacles that could slow you down, and anticipate them. They will only really interact when they notice bad patterns; like you being too slow. And most of the time let you be unless you introduce to new team members or elevate issues. Focus on your major tasks, allow them to manager the small mundane.
  • ARandomerDude 5y ago
    Low-level drone with 8 different bosses here. I hate being micro managed as much as the next guy, but I've also had way too many coworkers over the past decade who can't seem to just sit down and get the job done. They fiddle and tinker and explore way too much. It's helpful to do that at times but many lack the discipline to produce software without a PM to answer to. I wish it were different, but it isn't. My current PM is great and if I found out the management wanted to get rid of him, I'd vouch him and go to war if I had to. Good PMs are indispensable, in my opinion.
    • ipnon 5y ago
      This is why Agile has a love hate relationship with the engineering public. For some engineers its a hindrance to dedicated work. For other engineers, they have the realism to see that many programmers need direction and direct feedback to be profitable for their companies.
      • watwut 5y ago
        The thing is, some people needed direction should not imply everyone get punished and loose any semblance of autonomy. Which is literally agile approach. Some people are issue, therefore everyone is subject to elaborate system of autonomy and individuality removal. Plus minus subtle intra team politics that allows you to circumvent the above.
    • clebiond 5y ago
      Can you elaborate more on what are the strong points of your PM? Asking for a friend...
  • ipnon 5y ago
    If your team is led by a manager, then it is solving a management problem, and if your team is lead by an engineer, then it is solving an engineering problem. Managers are not good at solving engineering problems, and managers can and will fill management-shaped holes with engineers until everyone is either burnt out or checked out.
    • black_13 5y ago
      Word.
• archeantus 5y ago
  I really enjoyed this read. I’ve been grinding for so long in the huge corporation version of agile that I don’t even know what is what anymore. It was refreshing to hear their take on project managers, as it matches how I’ve been feeling recently. They schedule 7 checkpoint meetings per week and I’ve given up on attending, I just can’t do it anymore. I hope that we can move past agile into a new world that is free of the baggage and process of yesteryear. Even if the core principles are the same, let’s call it something different so we can start fresh and impress upper management.
  • ipnon 5y ago
    This is how revolutionary Marxism functions. Nobody knows what the hell Marx wrote in those books, or what any of it means, but it cannot be argued in communist regimes that there is a system in place, and that the vanguard knows whats best. Replace Marxism with Agile, communist regimes with corporation, and vanguard with management, and you have the recipe for soulless employment.
    • koonsolo 5y ago
      > but it cannot be argued in communist regimes And here lies the difference: agile includes retrospectives. I It's the only thing you need for agile. And if you don't have that, you don't have agile.
      • invaliduser 5y ago
        Well, it depends. I have seen many teams where retrospectives are basically a lot of personal mea culpas, people talking about what they did not do right, and it was mostly about how they should have done things differently rather than how the process or organisation could be adapted. The overall feeling is that agile works great, scrum works great, so if something went wrong it's because of the human factor and that's what should be fixed... I don't know about communism, but at some places the implementation of agile sounds like a regime.
    • disk0 5y ago
      People (read: Twitter users)[0] have discussed the parallels between Maoist/Marxist theory and both Agile and extreme programming—albeit less fever-dreamy [0] A couple of said theory tweets, from memory https://twitter.com/mmabeuf/status/1352450003231506432 https://twitter.com/mmabeuf/status/1352450003231506432 https://twitter.com/mmabeuf/status/1323758677099270147 https://twitter.com/mmabeuf/status/1323758677099270147
• hahaahhlibs 5y ago
  Donald Trump Killing It in Arizona Right Now https://rumble.com/vka124-president-donald-j.-trump-delivers-remarks-at-turning-point-action.html https://rumble.com/vka124-president-donald-j.-trump-delivers...
• quickthrower2 5y ago
  It’s a very nice article. I’ve not seen agile done as originally visioned. Usually because the VP Engineering (or equivalent) and down wants to do it but the rest of the business isn’t interested. Also the pattern I’ve seen is over time businesses want more and more fine grained control over the engineering process, as if treating the team like replaceable workers doing well defined tasks (like Ray Croc I guess) leads to more efficiency. This doesn’t work when the burger and chips has zero cost of replication and your staff are not frying and serving chips, they are inventing new cuisines every day.
  • sz4kerto 5y ago
    Agile is not about "mean efficiency", this is a serious and widespread misunderstanding. Agile is a risk management method. You won't build things faster with agile in general. It's aim is to decrease the chances of spending 80 manyears on a project and then realising at the end that you've built the wrong thing.
    • beermonster 5y ago
      Well, a fluidity thing. But yes that’s related to risk. Being able to change direction at the drop of a hat. Also working with poor requirements which is a fairly common working condition in a lot of shops.
• justicezyx 5y ago
  My experience at Amazon Google and now Pixielabs tell a different story, all the points proclaimed in the agile manifesto are the desired states of daily work. People are speaking in the same or similar mental framework of building software, which is fully embodiment of the manifesto, or at least it's spirit.
• chmod600 5y ago
  I'm not an expert on this subject, but I feel like "agile" could be summarized as "a process for actively incorporating feedback early and often". That doesn't mean you need points or tshirt sizes or constant status meetings. You just need channels of communication with the right people and a chance to adapt to what they say.
  • beermonster 5y ago
    This is a good one line summary. And it’s something that good devs will already be trying to accomplish anyway. There’s also the part about breaking stuff down into small parts so that small cycles of meaningful dev can be accomplished. But that’s mainly to be able to release small and often - another thing you should already be doing to incrementally update your app avoiding big releases. It also stands in the face of waterfall development, though I see lots of teams doing test at the end still, making it waterfally. I also see too many agile teams that have iterations that never finish, get feedback in prod, create half complete features that are weird or don’t gel - all in the name of agile. I think the kids that get it were already doing it as it’s common sense. The rest end up sticking an agile badge on their practices when it’s all but.
  • asplake 5y ago
    That’s not a bad starting point. There’s more than one kind of feedback though! No matter how regularly you reflect on the process, if you’re ploughing through an unchanging backlog it’s still going to be a mediocre experience. Worse if the strategy keeps changing and you have no influence over it. Those unfortunately describe the experience of many - sometimes well-meant but an imbalanced and process-centric Agile with ironically little regard for the people doing the work.
  • jarl-ragnar 5y ago
    This is how I see agile too. With it’s links to lean, it’s about minimising waste by minimising work in progress. Since the biggest waste is building something no-one wants, getting a small increment into the hands of a user/customer as soon as possible is key. The problem, in my experience, is many development contracts are still structured in such a way that this becomes too difficult. Management fearing early exposure to the customer will lead to scope creep and cost growth.
• lalos 5y ago
  Agile got widespread adoptions because of the micromanagement undertone of it, starting with the daily scrum. It's a slippery slope, way to easy to over do. The risk is it starts something to be gamed/incentivized instead of actual progress.
  • balp 5y ago
    Agile and Scrum isn't the same thing. Even if Scrum in someways are agile. The "original" agile process, or the first videspread variant XP didn't mention any dailies. Scrum as such is much a way to adopt XP into a large cooperate environment.
  • rualca 5y ago
    > Agile got widespread adoptions because of the micromanagement undertone of it, starting with the daily scrum. I would put things differently: micromanagers leveraged the agile and scrum buzzwords to justify and convey an aura of legitimacy to micromanaging. I mean, how many orgs forced daily meetings where workers are forced to enumerate what they did and delivered in a short time frame, but mysteriously left out the part where a feedback cycle exists to revise plans other than performance evaluation plans?
    • smitty1e 5y ago
      Agile lives and dies by communication. Both amplitude and SNR matter, and have always been present in the proper ratios in the best engineering. Agile is very open to attack when it veers from a list of useful practices to try out in a given context and instead turns into dogma.
    • TedDoesntTalk 5y ago
      > workers are forced to enumerate what they did and delivered in a short time frame This is one example how processes supercede people even though that is against the original agile manifesto.
    • jq-r 5y ago
      Agreed completely. I was (and still are) on couple of different companies and teams practicing "Agile" and those daily standups are more like daily blamefests. God forbid you get stuck somewhere and need someone's help. Then you have to apologize because everyone thinks that you're lazy or incompetent and holding everyone down. Also if people wanted to know what I did yesterday, they could have a peek at the tickets they want us to keep up to date but no, they want us to say it anyway. Also that stupid "do you have any blockers" question. No I don't have any blockers, it is this bullshit technology/service everyone wants to use today, and discard tomorrow which I somehow need to be an expert of with 30 min of looking at some incoherent manuals. It seems to me, that all these buzzwords and meetings are just a way to always keep you "busy" (or at least looking busy), to always have some kind of fire below your feet so you don't "slack off" (or have a bit of free time to actually gain or sharpen the skills you need for the same company...). I'm just tired of this. In a way, good teams will be good, and bad teams will be bad, doesn't really depend on whatever process they have.
• S_A_P 5y ago
  Badly done agile made me lose interest in software development. Daily scrums that amounted to one upsmanship and lasted entirely too long. Planning meetings that were mired in politics. I went from wanting to learn the deepest minutiae of languages and practices to only coding the bare minimum at work. Only now (8 years later) am I just finding some joy in coding again, mainly because coding is not a large part of my day job. My dev jobs made me feel like I chose a path of arbitrarily short deadlines and stress while the non development folks largely coasted. I ended up blaming agile practices for a lot of it. I think it still deserves some blame because pushing back on bad practice implementation should be a bigger part of the manifesto.
• axegon_ 5y ago
  I never really understood the hype around (f)ragile (as one famous google engineer called it in a small closed circle a few years ago). I think the main problem is that in the past 7-8 years it has become more of an evangelism effort rather than anything. > The important piece that gets forgotten is that Agile was openly, militantly anti-management in the beginning. Yet here we are: The process just became an endless rabbit hole of filling jira tickets, workday schedules, and a bunch of other systems(including a shared google sheets table as it was in a company I used to work for with 5000+ employees) which easily eat up a day of your week. Detrimental if you are aiming for a deadline. And while I embraced wfh and felt insanely comfortable with it, it was used as an excuse for management to further push those things further down everyone's throats. The end result was that, at least from an engineering prespective, work became more of a marketing team meeting, filled with absurd abbreviations and processes which hold no value and only drag you down. Another problem is when you get an email from jira that someone assigned you a ticket called "Implement X in Y" with no further explanation when you click the link. It's absurd that in large companies(think 250+ people) your value is determined by how many tickets you've ticked off. "Implement X in Y" seems like just another one, but in many case those 4 words end up being 8 separate things, each of which can take several days but no one cares even if you described those in detail in the comments. You might think that story points solve that but they often don't. Imagine the following scenario: you are tasked to hook up a system to an s3 bucket to store data but you have restricted access to the aws console so you can't even create a bucket on your own. Then it turns out that the vpn is set up wrong and you can't even resolve the host if you are connected to the vpn. Then it turns out that the library you use has some bug in it or it's incompatible with some of the other libraries you use so you end up upgrading a bunch of libraries, patch up a large codebase and only then be able to get on with the s3 bucket thing. At first glance what you would assume is a 2 hour task tops ends up being a week and a half of your life. And it can be insanely demotivating when you have the same thing to report that you are working on the s3 thing in your daily scrum for a week and a half. Which is even worse when your managers have little to no tech skills beyond excel for instance. The point of my rant is that agile became the thing it was supposed to destroy - a time tracking system for the assembly line. Edit: those things don't seem to apply for small companies/startups because... Well they are small and you get to know everyone on day one.
• ChicagoDave 5y ago
  The Finance department never bought into it. They needed to provide funding to product owner initiatives that aligned with the business and then just let go of the process. C-suite and finance people will never do that.
  • undreren 5y ago
    Agile is (maybe a bit oversimplified) about releasing as often often as possible. Delivering sooner, not faster. To do this, decision makers must be close to the team, and ideally a part of the team. Either managers are part of the team, or the team a given the authority to make product decisions. Full time managers lose power and influence either way, and I think this is the real reason Big Corp never really bought into it except on paper.
    • beermonster 5y ago
      > Delivery sooner, not faster Well delivering sooner with less in it.
      • undreren 5y ago
        Precisely :-)
• throwaway290232 5y ago
  Agile is a generic umbrella term that involves a vast array of complex, subtle knowledge and skills. It's like saying "Engineer", or "Chef". Each has a shared skillset, to be sure. But each category's members can't just work the same way at all jobs, and there's no book on how to be an Engineer or Chef everywhere. The Agile Manifesto is a failure at trying to make Agile happen because it can't tell you how to make it happen, because it varies wildly. No manager can read a book on how to "Agile-ify" their org, they have to apply their brains and figure out how their specific version of "Agile" will work. But the skill-set required to do this is not a Managerial skill, it is a lower-level-worker skill. But it's also a very advanced lower-level-worker skill. And that's why things like "Agile", "DevOps", etc will fail. People at the higher end have no clue how to make it happen, and people at the lower end who have an idea how to make it happen don't have the power to make the organizational changes to do so. You need a way for the lower-end people to tell the higher-end people what to do, and have the higher-end people listen to them, and make the changes happen. This is very hard in a traditional organizational hierarchy, because higher-end people have big egos and bigger concerns over things like politics.
  • xamde 5y ago
    Nice explanation. Amusingly, it explains why NO kind of informed change can happen in a hierarchical organisation.
    • pjmlp 5y ago
      The old Microsoft (the new one is much better at this), you couldn't just go around sharing department knowledge, if you on lets say Visual Basic team wanted the deep knowledge for a Windows feature as means to product improvement, it was easier to have a neutral contractor somehow get hold of the information across departments, than asking directly as Microsoft employee.
  • emptysongglass 5y ago
    > And that's why things like "Agile", "DevOps", etc will fail. I completely disagree. Most team leads and technical managers where I've worked get promoted up from within a highly technical position. I wouldn't have any respect for my team lead or my PM if they didn't know what they were talking about. If my PM is going to try to tell me that I should work on this feature over this other feature or I should implement it in this way over this other way do you really think I'm going to listen to them if it's clear they have no idea what the implementation details are let alone the tools? Of course not. I'm making DevOps happen and I do that by knowing the tools and practices. I'm being given the power I need to make it happen. I earn the respect every day I come in and write the code or identify the weaknesses we need to shore up to move faster.
• habitue 5y ago
  I think the big divide here is between tech companies and non tech companies. Tech companies can look at the agile manifesto and use it as a heuristic guide, because engineers are already kind of on the same page about it. You don't need heavyweight process etc. Non tech-companies need the window dressing of tech companies to retain their best engineers, but ultimately agile is kinda telling them to turn everything upside down and also threatening to make them superfluous. Nobody is really up for that. So agile in non-tech companies is Kabuki theater and engenders cynicism, and agile in tech companies is basically superfluous "water is wet" advice no one even bothers to comment about. You'll notice a lot of these blogs about how agile has failed are coming from consultants, who are basically brought into traditional companies that are struggling with some part of this process, not tech companies.
  • pjmlp 5y ago
    Yes, pretty much this.
  • gonzo41 5y ago
    I totally agree, and I think another big reason Agile fails to cut through in companies is because anyone who wants to be Agile in a non tech company is fighting a crushing bureaucracy. So rather than innovating and climbing higher on innovation they leave due to the massive inertia that is encountered trying to change company culture.
  • misil 5y ago
    This very much resonates with my experience. I've seen this very process take place when working at a small tech startup that ended up being bought by a non-tech giant keen on undergoing a "digitalization" initiative. Our prior processes were lightweight, goal-oriented and effective. No one bothered calling them "agile", they were just the natural way to deal with an ever changing landscape of customer and system requirements. After the buy-out we were told to undergo a thorough transformation into this brand new unified top-down software development process the company had some consultants design for them. Complete with a baffling array of buzzword driven "agile" development practices and project/squad/team/chapter manager/lead/head roles to be filled. The more you kept inquiring what exactly those roles should entail, the more conflicting and vaguer the answers got until you realized that no one had the faintest idea how any of this was supposed to actually mesh together in practice. The license packages for the expensive project planning software we were to use where long paid however.
• andi999 5y ago
  If nobody does something there is a chance it doesn't work. The most problematic point to me seems to be point 3 'customer collaboration'. Does anybody know how to do that in real life? What does the sales team sell then? And more important how do you prevent feature creep from the customers side wanting more and more things during the process? To me I only see this working if you sell working time instead of a product.
  • jnwatson 5y ago
    The sales team sells what has already been delivered. In my experience, the customer collaboration happens through a proxy called the product manager. It is their job to hold meetings with customers to figure out priorities. You don’t “prevent” feature creep ever. It is part and parcel of development. You can, however, manage it by restricting when the goalposts change. In Scrum, that’s at sprint boundaries. The most important bit is that the customer chooses priority but the developers choose velocity.
    • pjmlp 5y ago
      Except most customers only pay when it goes live, or reaches major milestones, and then you are out of budget, struggling to find another parallel project to somehow keep the team in place, before management states it is time to move on.
      • CRConrad 5y ago
        > Except most customers only pay when it goes live, or... But with (real) agile, it went live early on, didn't it?
  • paavohtl 5y ago
    > To me I only see this working if you sell working time instead of a product. This is what we do at the consultancy I work at - billing is simply based on time & materials. We work from our customer's premises (when there isn't a global pandemic) and we have people from the customer integrated into our team, so customer collaboration is constant and continuous. Feature creep doesn't really happen, because all parties know what the budget is and how much our time costs.
• ankurdhama 5y ago
  Interestingly, one of the point in the manifesto says "Individuals and interactions over processes and tools", yet there are all sorts of processes and tools that now exists for Agile. What an irony.
  • cratermoon 5y ago
    The article mentions that as a problem with the industry, not an aspect of Agile itself.
  • TameAntelope 5y ago
    I've been implementing "agile" at my new company, and while we do use Jira, I've made it abundantly clear that it's just for my own sanity to track what we're up to. I could just as easily do this in a notebook, but it wouldn't be indexable or searchable, is all.
• AndrewKemendo 5y ago
  The fundamental problem with Agile is the fundamental problem with all product development: The customer doesn't know what they want Agile assumes as a first principal that including the customer throughout the development process will align the building team and the customer to come to the same conclusion. This is almost never actually true. Having built and managed a lot of products I can state fairly confidently that the amount of time the customer has, and clarity about the problem they want solved is orders of magnitude more ambiguous than is required to actually build and deliver something to their satisfaction. In my opinion successful products, and I mean ones with significant flywheels with customers and viral growth and stickiness are with few exceptions - accidents. It was someone who had an interesting thought and a lot of people for whom the product was good enough for their desire that they often didn't even know they had You can't write down how to do that, it's like asking a nobel prize winner how they came up with their discovery. It's not repeatable. Some people have better intuitions than others and these are the people who are repeatably successful with products. But it doesn't generalize. That said, the fundamental problem isn't wrong in theory, it's just naiive in practice.
  • catmanjan 5y ago
    I thought agile hedged against that by getting product in front of customers early - they may not know what they want but if you show them 100 things they don't want you'll probably be close
    • pjmlp 5y ago
      That is the theory, except on the customer side you actually need the people that will use the product. Usually what happens is that you get a customer team, that is supposed to voice how the organization wants the software to be. So the same mismatch is bound to happen anyway. And when they do involve the people from the field, depending on the company culture, they might even be quite positive on the demos (cause being negative isn't good) and then completely find it unusable on final delivery. Agile misses that many engineering teams lack people skills to actually navigate and avoid these scenarios. EDIT: several typos
• RandomLensman 5y ago
  Senior management in a lot of places is by now trained and groomed to see everything as a process, so principles don't cut it. Similarly, consultancies need to sell "products", i.e. implementable processes and change, so again principles are a problem. Lastly, in a lot of places the actual users or product owners from the business side are only involved via representatives, so there is no closed loop to run.
• forgotmypw17 5y ago
  I've seen Agile at a handful of shops, a couple dozen projects. I've seen it implemented well just once... The "scrum master" was a dedicated role, filled by a technically able person, who sometimes helped a little bit with the coding. This individual had read several books and taken a course on Agile. They were sincerely passionate about Agile and wanted to implement it effectively. The "project manager", a DIFFERENT PERSON was part of the "business", and interfaced primarily with the scrum master, but they were with us for several hours of both planning and retro. Our sprints were 2-3 weeks. At the end of the sprint, we spent AN ENTIRE DAY on retro. Before the next sprint started, we spent AN ENTIRE DAY on planning. We used a physical board which was matched by the tracker. They were kept in sync by individuals and validated by the DEDICATED DOCUMENTATION PERSON. We broke down the tasks relentlessly, until there were almost no 3-point tasks, maybe one or two 5-point tasks, and everything else was 1-pointers. I think this one is the most bang for your buck, lowest hanging fruit, easiest to implement winner. Someone has to enforce it vigilantly until everyone is used to it. Those three things are, IMNSHO, the keys to getting halfway decent Agile going. Edit: Was one of the least soul-crushing and nicest experiences in professional software development. The planning meetings were a serious effort, but also a pleasure because I liked everyone on the team, and the large time windows made it not seem rushed, so we had time to joke around and shoot the shit.
  • TedDoesntTalk 5y ago
    This sounds soul-crushing and I hope never to work in such an environment.
    • porker 5y ago
      > This sounds soul-crushing and I hope never to work in such an environment. It isn't. Soul-crushing is doing "Agile" where the "scrum master" tells you how long each ticket will take, where the client is invisible and never involved, and where retro is 1 hour at the end of the sprint and focused on blame.
      • chris11 5y ago
        That example does sound really bad. But I would feel disengaged if everything was broken down to 1 point stories at the beginning of the sprint.
• travisgriggs 5y ago
  I was at OOPLSA 1998 where it was going viral. Participated in the early C2 wiki. Participated in some of the early "workshops" on this upstart rebel movement. Raised in a christian tradition, and somewhat a student of history of christianity, I was fascinated by parallels that unfolded in months` time what took place over centuries in christianity. 5 years after the movement began, I found that it felt as watered down, abstracted, and diverse as christianity spent 2000 years becoming. I could bond with a fellow programmer as an "agilist" and at a very vague level, there was some abstract similarity (e.g as christianity might be to "be kind", agile might be to "be lightweight"). Everyone took the parts they wanted and formulated what fit for them. Which was/is both a good thing and a bad thing.
  • mjburgess 5y ago
    We are unfortunately saddled with "religion" as the archetype of this behaviour. Perhaps we could call it, "social virtue mythology". What is a social virtue mythology? It answers the following questions: * Why is there evil in the world? (ie., why arent things perfect) * How do you overcome evil? (ie., become perfect) * Who is good? Who is evil? * In what or who should I place my trust? * etc. Today we can see many such competing virtue mythologies.... Why is there evil in the world? New Atheists: Religion; Feminism: Patriarchy; Socialists: Capitalism; Idenity-Woke: Essentialism. Personally I regard this as wholely "mythological" because the questions these social-virtue systems are designed to answer "take place" in a utopian/dystopian reality. Ie., many people eventually discover that there is no need of this type of mythology: reality is itself flawed. We aren't "owed" a utopia, and thus there is no question to answer. Here, in agile then we see these patterns even in this thread. Some commenters are still trying to answer the question, "why isnt software design/construction perfect?" as-if there can be a virtue/vice answer, ie., "because we have failed to...". Rather, no. These problems are irresolvable. The reality of software is intrinsically broken: there is no customer to give you the requirements, there is no habit which elicits them, there is no mechanism to build reliable software, and so on. Many are extremely loath to confront this reality, especially as adolescents; ie., that they are powerless to build their utopia. The really-existing world has irresolvable contradictions that admit no virtuous resolution.
• marsven_422 5y ago
  It's all about people not process, if you do not have the right people you are doomed.
• baxtr 5y ago
  The biggest problem I have with agile is the absoluteness of its proponents. “There is no other truth than agile, and if you don’t agree you’re old/immoral/…”. It’s the sad combination of not being open to test other approaches and condemnation of people questioning it.
  • ricardobeat 5y ago
    I haven't met anyone who is a real agile evangelist since ~2010, don't see how this could be the biggest problem. Most common is the manager or consultant pushing Scrum who doesn't even know what the Agile manifesto is.
• leokennis 5y ago
  Okay, so agile was a very nice and principled idea. And what we got from that through corporate senior management involvement is some sort of “scalable agile framework” or a minimal surrogate of “agile scrum”. Might not be ideal, but it still generously beats the waterfall with quarterly “slave galley-style” weeks of overtime to make it to “the release” and to be able to deploy things that actually already became irrelevant 5 weeks into the release cycle.
• eesmith 5y ago
  Agile both succeeded and failed because it's defined as "not waterfall." Since no one does pure waterfall, everyone does Agile. Even this essay encourages that interpretation: "Everyone in this group had deep experience writing software, and they were all looking for an alternative to documentation-driven, heavyweight software development processes that ruled the day." Did that "everyone" include Mac development in the 1980s? Or Amiga development? Not from what I've read of the history. Did it rule the day for the development of gcc, the Linux kernel, Perl, or CPython? No. I pulled out my 1996 copy of Steve McConnell's "Rapid Development." Page 271 says: > In addition to providing explicit support for morale, Microsoft gladly trades other factors to keep morale high, sometimes trading theme in ways that would make other companies shudder (Zachary 1994). I've seen then trade methodological purity, programming discipline, control over the product specification, control over the schedule, management visibility -- almost anything to benefit morale. The Zachary 1994 citation is the book "Show-stopper! : the breakneck race to create Windows NT and the next generation at Microsoft" at https://archive.org/details/showstopperbreak00zach https://archive.org/details/showstopperbreak00zach . A quick read (search for 'documentation') shows Windows NT development did not use a 'documentation-driven, heavyweight software development processes'. And of course oodles of small software projects in the microcomputer and early web era were written with no formal software development processes at all. This "rule the day" statement must therefore be interpreted within a narrow context.
  • p0nce 5y ago
    I don't buy the thesis that everydone was doing software development wrong until a few consultants gathered at a ski resort.
    • SideburnsOfDoom 5y ago
      Anecdotally, as someone who was doing software development in the late 1990s, yes we were doing it wrong, and Agile spoke truth to that. Getting this message out was an important change. And if that took "a few consultants gathered at a ski resort" issuing a manifesto, then so be it. Was "Everyone" doing it wrong? Mathematically improbable. Were the vast majority, the mainstream, stuck in a dysfunctional waterfall system? Oh hell yes. And the usual answer to the failure of up-front planning was "Clearly we didn't plan up-front enough, we need plan even longer". It's a self-reinforcing pathology. So is the use of JIRA, but that's another story, post-agile, not pre-agile.
• beny23 5y ago
  If waterfall is the first Death Star is SAFe the second?
  • CRConrad 5y ago
    Yeah. But the twist at the end is that it's really just the first one resurrected.
• fukmbas 5y ago
  Agile creates administrative debt at levels beyond comprehension. I'd rather hire another engineer than sacrifice productive hours.
• brakmic 5y ago
  The problem was described more formally as "Dark Agile" some time ago. http://darkagilemanifesto.org/dark-side-of-agile-janes-succi-splash-2012.pdf http://darkagilemanifesto.org/dark-side-of-agile-janes-succi...
• tablet 5y ago
  There is an article that explores the same problem "Post-agile process agnosticism" [1] The main idea is that (as a programmer): "You don’t give a fuck about process name, until you have full rights to modify and change the process." [1] https://medium.com/fibery/post-agile-process-agnosticism-d4a67a59a6f7 https://medium.com/fibery/post-agile-process-agnosticism-d4a...
• sorokod 5y ago
  The basic premise of Agile is that it is a part of an adversarial system. The adversaries are "devs" on one hand and "business" on the other. While the purpose of the devs is to be an executive arm of the business, the actual goals of each are coined in different languages to the point that they are frequently not aligned. It is important to recognise this, and carefully manage the necessary give and take. Finding the right balance is tricky and higly context-specific.
• madrox 5y ago
  I believe agile fails for the same reason devops fails. The people who did ops or waterfall project management didn’t go anywhere. They just got told they’re using a new buzzword with the same responsibilities. Try telling a classically trained project manager that we should have less process and watch their head explode. Of course they revert to what they know the moment there is a breakdown.
• shsbdncudx 5y ago
  Here we are 20 years later and we still can’t agree what agile even means. That is where it failed. It’s not concrete enough, and maybe it was never meant to be. I feel like they had a great idea, gave birth to something, but then failed to nurture it and we are still evolving a solution. Ok we got scrum but we all know that’s a complete shit show. What agile is really missing is that it doesn’t touch on leadership. We like to blame management and say they should let us do what we know, but we don’t lead. Decentralised control only works when everyone leads. Let’s add a line to the manifesto and fix it: “Lead from the bottom over centralised control”
• happyweasel 5y ago
  A lot of time, especially with Scrum, team communication is now formalized and non-team members participate and evaluate "the process" (indirectly). This can extinguish direct,non-formal-communication and can lead to CYA attitudes in teams... "A Process" can never be about "the people". Let's say someone would implement Scrum for football teams. Every team could follow the process to the T, n times training, 2 times weight lifting per week, daily meetings, n times cardio work, mobility training, strategy planning/training etc etc.. At the end, in the game there would still be good or bad teams. And the good team would probably be p*** off because they have to do so much formal stuffs just to "do the process right" and ensure "every checkbox in the process list has been ticked off". So yeah, I guess it is up to agile teams .. let's deliver in increments and let's ensure it is what the customer needs. Everything else is secondary.
• yobbo 5y ago
  I don't think there is an understanding of why agile works, and why it is (essentially) impossible to implement in most places. One subtle, but necessary, effect of the original scrum sprint planning is that it splits accountability between product owner, team, and master. The effect is that, upon failures, there is a way that developers can rightfully blame the product owner or master. Part of the point of time-boxing increments is checkpoints of accountability, so that once the "contract" of a sprint has been fulfilled, the devs can not be held accountable for its product value. If this mechanism is not in place, it means the product owner/master (or whatever title) is just another name for plain old manager with mandate to overrule anything, and in the worst cases with influence over careers of the devs. This is the high entropy state most organizations converge to. In these cases, all product failures will be blamed on the devs (in effect, if not verbally.) In an effective agile organization, there can't exist mechanisms where blame/consequences for failures can be shifted downwards postfact. But this is also the basis for most old organizations. Hence, implementing agile in older organizations will never work.
• Amin699 5y ago
  Best of luck
• stunt 5y ago
  I avoid working at companies that 1) use SAFe, or 2) assign dedicated Scrum Master for dev teams, or 3) use crappy project management tools. To me that's an indicator that decision makers in those companies have no understanding about software development.
  • AH4oFVbPT4f8 5y ago
    what are the non-crappy project management tools youve used ?
• greatgib 5y ago
  In my opinion and experience, the best functioning and delivering teams are the one doing Agile without even thinking or saying that they are doing Agile. It is team that are working intelligently with trust between members. Each member does it job, feels responsible and autonomous. Enough to do by itself everything needed for the project to succeed and with other members trusting him to be able to do what he needs to do without micro management.
  • ellen364 5y ago
    Agree completely. The tough part for me has been experiencing a team like that, then moving and having no idea how to help create a similar environment with my new team. Any tips?
    • greatgib 5y ago
      In my opinion, to start with, you need to have "senior"/experienced members. Most junior still need to be taken care of before they could be blindly trusted on some topics. Also, in my experience, most of cases like this happened in places were the management was kind of "absent" or "defective" in some way. For example when you have the next level of management hierarchy in another place/country. In such a case, often, the dev/engineers are considered autonomous and they are just trusted and expected to "take care" of all the technical things, with little supervision. If you are already inside a team, I think that there is little to do to create a similar environment, except trying to get the maximum "power"/"position"/"space" from the company, and using that to organize yourself with the persons you are interacting with in your team. Trust is the key element. But other members have to earn your trust, and on the other side, you should also ensure to worth the trust of your company by being reliable and deliver. Most of the time, even management will let you a lot of "space" if you are use to reliabily take over "loads" off of their shoulders. The worst case scenario is when there are persons in management that have "bullshit" jobs like "scrum masters" where they have to do "something" to justify their work. Otherwise, if you are in the lucky position of creating a team, the best thing is to try to have a multi disciplinary team with most of the people with a specific responsibility on some components of your system. This is the exact opposite of saying that you have a an agile pizza team with all members that should be equal on all subjects and easily be interchangeable at will on whatever subject...
• ChrisMarshallNY 5y ago
  That is too bad. When I first read the Manifesto, I said “These folks got it!” I tend to work that way, now. Myself. Things get difficult in teams. Especially cross-disciplinary teams, and aggregate efforts. Much as we like to denigrate managers (DISCLAIMER: I was one), they are necessary; and not as a “necessary evil.” Good managers can be amazingly effective and well worth it. Unfortunately, like in any vocation, the good ones are rare. The same goes for good software developers. The Agile Manifesto was written by a group of working software engineers, with decades of experience, at the top of their game. Precisely the type of engineer that today’s hiring process tends to filter out. They don’t really represent the current field of practitioners. Like so many “perfect world” scenarios, the Agile Manifesto was designed for a “perfect audience.” As the article points out, when the manifesto hit the real (imperfect) world, the wheels fell off. To make matters worse, the designers tend to get huffy, and blame the people making a hash of it; which doesn’t make friends. They may be technically correct, but humans are messy, chaotic beings, that tend to have highly individual worldviews, abilities, intelligence, education, experience, workflows, and motivations. Most folks expected to actually implement an objective bear little resemblance to the ones that developed the plan. If the planner fails to account for this, then (in my opinion, as a planner) it’s the planner’s fault. That kind of sums up human history. Groups of elite thinkers develop a Grand Plan, then it gets bloodied and bruised, once it hits the proletariat. Sometimes, with horrendous results (Cultural Revolution, anyone?). As someone that actually designed a successful system for the proles[0], I can report that designing real-world solutions for a distributed, heterodox, self-driven, target audience is difficult, messy, unintuitive, humbling, frustrating, and, quite often, absolutely infuriating. Not the kind of work that folks at the top of their game like to do. Frankly, it sucks, but I think that it’s also the best way to make something that actually has a chance. I wanted to add that follow-through is also important. When I designed the system I referenced, I did it with an understanding that it would be a years-long commitment. It's like having children: Making them is fun. Having them is easy. Raising them, however, is not fun, and not easy. But we need to do it. For myself, I spent ten years, traveling around, giving presentations, classes, gladhanding, answering questions that I thought "should have been obvious," suffering some withering attacks, and fine-tuning the system, as I realized I screwed something up. I also went around, looking for successors. I wanted to become obsolete (which I have). But that’s just my experience. YMMV. [0] https://littlegreenviper.com/miscellany/bmlt/ https://littlegreenviper.com/miscellany/bmlt/
• Guthur 5y ago
  I've been giving this some thought recently. Ultimately I blame Scrum, it is so poorly aligned with sustainable software engineering and so widely open to interpretation that its no wonder that every project seems to inevitably end in big rewrites. Scrum gives all the godly power to a product owner, invents a baby sitter in the scrum master and leaves everyone else to be the "dev team". I know there will be statements about it should be collaborative blah blah, but the fact is the named roles have gravitas and the amount of responsibly in the product owner individual is untenable. There is also then the wildly misunderstood aspect of estimation. In my experience the only value beyond saying a feature is easy or hard is that it does spark discussion among engineers, the irony being if said discussion goes on for too long it usually gets shut down. Adding estimates to work you are going to do within the next 2 weeks seems of limited value, it changes no behaviour you will still do the work. I feel we would be better served by reinforcing the principle that all of our purposes within the organisation is to deliver a quality product for the customer. Product development is responsible for taking ideas and generating specifications for product features while software engineering are responsible for taking specifications and implementing them within a software product. This simple process should be monitored and systematically improved to deliver better on the core principle.
• lloydatkinson 5y ago
  I think one of the biggest indications of failure (because it’s been morphed into something shit by all these business manager types, and not because it’s fundamentally flawed) is the fact that we have dedicated “scrum masters” that never rotate.
  • tkiolp4 5y ago
    I’m the only one who find the role (and the name) “scrum master” shocking? First and foremost anyone’s can become a “scrum master” in a few weeks and get a certificate that proves it. I don’t take it seriously because of this. Secondly, we don’t have “linux masters” or “python masters” or whatever; why do we need the silly title of “x master”? Imho, it makes a disservice to the people who actually hold such role.
• johan_larson 5y ago
  The problem I see with various flavors of Agile is that they don't fit in particularly well with how things actually get done at companies. For example, teams running Agile are very reluctant to give both a delivery date and a fixed set of features. They're willing to promise one or the other, but not both. And that's a problem, because the whole rest of the organization really wants to know when they can announce the release to customers. Planning for releases tends to be a really big deal, the pressure to make promises of both functionality and delivery dates is very strong. Also, Agile methodologies tend to assume you are in close contact with the customer, who can tell you what they actually want and decide how things should work. But this is rarely the case; typically you have a PM or something like that who is in touch with the customers, and is supposed to understand what they want. But this person is rarely senior enough to actually make decisions; important decisions are made by a dev manager or a project lead or someone like that, with the PM just providing input and perspective. Finally, Agile has this notion that everything is supposed to be handled informally, verbally, person to person. And that's fine for small tweaks to the product. But as soon as you start building something big enough that it takes months and crosses team boundaries, it gets really useful to have an actual document explaining how something is supposed to work. Such a document is an invaluable record on what has actually been decided, and anyone joining the project or wanting to contribute to it absolutely should read it. But Agile tends to discourage creating such documents in the first place. Given that Agile clashes so hard with how actual organizations get things done, it rarely gets adopted in anything approaching a pure form. The practices that tend to get picked up might be called Agile-light: sprints, daily meetings, and task estimation in points.
  • loki49152 5y ago
    The fundamental insight behind what became agile is that it isn't actually possible to have both a guaranteed delivery date and a guaranteed set of delivered features. The reality of software development just doesn't allow it. Businesses don't "get things done" by operating as if they can have both. That's why projects fail, businesses cut corners, and then inevitably ship broken products or don't ship at all. Most of the "agile methodologies" are nonsense dreamt up by borderline con artists attempting to sell their services. The fact that it's an either / or choice - and that nothing can get around that choice - is inherent in the nature of the work.
• tkiolp4 5y ago
  In my opinion the “problem” (what problem?) is not Agile but the mismatch between what tech companies want and what technical people usually want: - tech companies want to push decent features live every 2 weeks (the usual sprint duration). They follow the mantra “move fast and break things”. Technical debt is fine for them as long as money flows. They want to beat their competitors. This makes totally sense from a business perspective, of course - certain tech people (in my experience) don’t want to move fast and break things. They don’t want to break things, they want to produce products of quality, stable, with minimal defects... if that comes fast that’s fine, but usually it takes time to produce something of quality (at least for average developers—-I am one, and the vast majority of developers are). This makes sense from the point of view of someone who cares about their craft That’s the mismatch. Companies love Agile (even if it’s done wrongly); tech employees usually hate the very notion of estimates, sprints (are we even in a rush?l, story points, etc.
• g051051 5y ago
  > They were developers, programmers, scientists, and engineers. They were still slingin’ code* and working with their stakeholders to solve problems. This is important. Utter nonsense. They were consultants looking to sell consulting services. Just in the next paragraph: > Many of these people already had a methodology they had created and/or were proselytizing.
• hamstergene 5y ago
  Agile taught me about refactoring but in reality I get less opportunity to refactor bad code than I've had under Waterfall-type process. My understanding of our evolution into Agile has always been like: 1. Big Ball of Mud: work without a plan 2. Waterfall and alike: make a very elaborate plan and stick to it 3. Agile: work without a plan, but promptly refactor issues caused by lack of foresight Waterfall worked well but is too slow to respond to change, so Agile replaces one-off planning with iterative refining. So far, great idea. However, if the backlog is never short of business requests, and business requests are always higher priority than refactoring, then when will refactoring ever be done? If we don't have architects anymore, but also don't designate time to refactor, we are de-facto doing Big Ball of Mud with stand-ups.
  • Jtsummers 5y ago
    Agile != "work without a plan". Only morons and the misguided take it to mean that. Of course, many companies seem to be run by morons so I suppose it's reasonable to interpret it this way because it's become a common experience for many.
• temac 5y ago
  > The Agile movement is not anti-methodology, in fact many of us want to restore credibility to the word methodology. We want to restore a balance. We embrace modeling, but not in order to file some diagram in a dusty corporate repository. We embrace documentation, but not hundreds of pages of never-maintained and rarely-used tomes. [...] The problem is: the manifesto states clear dichotomous preferences without nuance, and it certainly not for example states that it embraces well-maintained and useful documentation but that "[we value] working software over comprehensive documentation". See? It is written "comprehensive". Not "shitty". And I even agree that maybe "comprehensive documentation" can be a dangerous concept if taken too far, but that's pretty much true for anything taken too far, and actually I have never seen a problem in this direction, but pretty much all the time and extremely often in the opposite way (I could say : a comprehensive lack of documentation...). So maybe de-emphasizing "documentation" was not that smart... Either it was very poorly written or there is an attempt at rewriting history. At the end of the day, you can't just hand wave the shortcomings originating directly from the text by just stating "oh but we did not mean that, wasn't it obvious?" -- well... no! it was not! Likewise for the other "values". They seem to have been written because of a perceived lack of balance (and maybe there are even again some adjustments to be made and they are not exactly intended to mean what is written...) in the personal experiences of the signatories, however there is no provision against balancing too much in the other direction, or against inappropriate applications in specific contexts (the "preferred values" are actually extremely context and project dependent) So maybe people actually got what was written, or maybe the whole thing was so vague that they got random outcome from a mostly cargo cult application. And in a few case, intelligent practice in a good context, so good outcomes; but when that happens, would the successful team have done poorly with other preferences of "values" or with other stereotypical day-to-day practices (weird btw when processes are to be deemphased)? > What do you mean you’re going to start building the software before you’ve gathered all of the requirements and estimated every piece of functionality? That’s insane! Like, the significant software from the 80 or 90 was written like that (in inappropriate contexts)? And when it was (again, in inappropriate cases), was the solution to settle on the four stated value preferences? Why? From where does that even come from? Where is the evidence? How can it be applied? Why can't I write precisely the opposite and say "see? here is my solution!" -- if not just because of the obviousness of some outcome: yeah not valuing working software enough will probably not lead to better working software. My point, however, is that stating that you value working software more cannot yield to actionable things in not completely dysfunctional environment, because whatever their current practices are everybody will say they want that and what they are currently doing has value to achieve that goal. And the other value preferences are highly contextual. There is no silver bullet. Not in technical areas. Not in project management. Especially not when project management is not interested in the technic; that is: in the project, if the project is of a technical nature...
• spamizbad 5y ago
  I think one piece of the Agile origin story that’s missing is that it was heavily influenced by software contractors - people who worked on software that had a definitive “end”: either because it was feature-complete, it was time sensitive, or the client had a fixed budget. Many of Agile’s problems arise when you begin to apply them to long-running products that undergo continuous cycles of improvements - stretching years rather than months.
• stolsvik 5y ago
  There's just too much ceremony and process with agile. How do you feel about http://programming-motherfucker.com/ http://programming-motherfucker.com/ ?
• dalbasal 5y ago
  Agile is like a perfect example of a lot of things. Publishing a "manifesto" makes the revolution analogy on-the-nose. Dissident manifestos tend to share a the same failure point. They're heavy on critique of the system that they want to overthrow, hand-wavy on the system that they want to enact. The Communist Manifesto, to pick on the obvious example, is mostly about capitalism, other (wrong) versions of socialism.. notably reactionary socialism. It's also about the struggle to bring about revolution. There's surprisingly few paragraphs about what communism will do differently, once the revolution takes place. Liberal revolutionary manifestos was similar, with French and american revolutionaries settling (or not) on a system of government only after overthrowing monarchy. The agile manifesto does outline a lot of how agile works, but the most compelling part was its description of "waterfall" and all its ills. Liberalism and communism, in their idyllic literature, never really contended with the fact that these were alternative methods of "ruling over a population." Agile never contented with Agile was as a people management system. Well... Agile is a way of telling developers what to do. It is a people management system. Where its completely unlike the political analogy is that agile was derived from working systems. It wasn't just an idealization. Ironically though, it ends up in the same place. What worked well for particular teams became the ideals. I think the ultimate stinker though, was the "political economy" of agile. A company where everything works great isn't going to tear out their process and bring in consultants to implement a new management system. It's companies that are failing to produce software well that do this.
• drewcoo 5y ago
  Once people started telling me to stop talking about chickens and pigs, it was clear that the chickens were in charge and agile was then Agile. Arbitrarily chosen pig and chicken link: https://helpingimprove.com/agile-commitment-scrum-pig-chicken-part-1/ https://helpingimprove.com/agile-commitment-scrum-pig-chicke...
• agent327 5y ago
  Three months ago I found myself writing a proposal for work that would take several times the budget that was available. A manager had an idea: why not do it 'agile'? We would have two-week sprints, and at the end of each sprint a meeting with the customer to present work and define the direction of the next sprint. Great idea, right? So my next task, obviously, was to define the content of all the sprints and write them down in the proposal. I was well aware of the absurdity of the whole thing but did it anyway, carefully planning out what would be done in each sprint. Sure, it sounds stupid, but just look at how cute it is! It's like a whole bunch of little waterfalls! People pay good money to see such nice waterfalls, you know!
  • Jtsummers 5y ago
    Last office had a team with 5-years of well planned out sprints. I could never dissuade them from the notion that this was "agile". They didn't use the end of each sprint to change direction if a problem was coming up, sticking to the plan for months after things started going wrong. Then they sat down and redid the next 4 years or so of sprints. Repeated after the next year. I guess it was more agile than making a 5-year plan and never changing it, but changing the plan annually is hardly responsive either.
    • agent327 5y ago
      In my case, the proposal is contractually binding, so the contents of the sprints are fixed. Also, the customer won't be available during the period when the work takes place (holidays in Europe, you know), so they wouldn't be able to provide input anyway. Of course I'm assuming that they'll kick us off next week. Right now the project is in the "let's delay starting until missing the deadline is guaranteed" stage. One more week, and then my careful planning will have become officially impossible and it will be panic all around, and demands that I work days, nights, and weekends to make up for the delay they themselves caused. Do you want to guess who isn't allowed to go on holiday because of this incredibly urgent project? :-(
• Andy_G11 5y ago
  Could it be that firms are simply claiming to be "Agile" irrespective of how they actually work because "Agile" has good PR? Customers may think that "Agile" teams are stacked with experts all working in a state of grace, effortlessly pulling off technological miracles. Behind the scenes, however, most of the work may have to be delivered by junior devs under the supervision of stressed-out micromanagers who use top-down bureaucratic control to progress the work.
• nerder92 5y ago
  I totally love this part: When “Agile” ideas are applied poorly, they often lead to more interference with developers, less time to do the work, higher pressure, and demands to “go faster”. This is bad for the developers, and, ultimately, bad for the enterprise as well, because doing “Agile” poorly will result, more often than not, in far more defects and much slower progress than could be attained. Often, good developers leave such organizations, resulting in a less effective enterprise than prior to installing “Agile”. I can totally relate with this experience in a previous company I've worked with. They effectively starting the transition to Agile, but the execution was so poor and the general culture was so immature with a lot of chain of command and top-down that it ended up being a total toxic nightmare. I end up blaming Agile for this at first, but now i'm realizing that was not the tool.
• nrvn 5y ago
  It’s been a long while since I read the manifesto last time. > Responding to change over following a plan “Responding to change” is treated as a right to bust WIP at any moment in time. All engineers I have worked with want a roadmap and a plan that has enough room and flexibility to be changed due to some external circumstances (bespoke “change”). > Working software over comprehensive documentation This statement puts two characteristics of a software product (be it SDK, library, source code package, binary, whatever) into contradiction. Working software is accompanied with comprehensive documentation. > Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Late requirements change is what all engineers hate… And as stated in a number of comments here customers want no more than a faster horse. Best products ever made were not made based upon focus group feedback. > The best architectures, requirements, and designs emerge from self-organizing teams. Are scrum masters an antipattern then or just a sign that the team in question is not self organized and immature? Bottom line: any “agile” methodology I’ve come across and experienced myself for the last several years is a mix of cargo cults, religious ceremonies and abusing the word “agile” to justify chaos, incompetence, ignorance and arrogance. What in essence all the agile methodologies are meant to be is the domain specific extension of the PDCA cycle. https://en.wikipedia.org/wiki/PDCA https://en.wikipedia.org/wiki/PDCA
• mikewarot 5y ago
  I did agile back in the late 1980s, in the days of MS-DOS and Turbo Pascal. The customer had a problem, he knew he wanted a computer in the solution. The first person he contacted to solve the problem hired me to write the solution. He hated the hardware chosen, and went off to make is own choices. Having chosen acceptable hardware, he hired a different person to solve the problem. They also hired me, we pitched a solution. It took about 2 months to code. The program worked as promised, met all the requirements. Up to this point, it was essentially waterfall. We agreed that a wider sale/deployment would be contingent on me working directly with the customer on-site in an agile fashion. I wrote code, he brought a random power plant worker in to try it out (in the days before everyone knew how to run a PC), and we iterated. Everyone was quite happy with the product for years, until networks, Windows and other reporting systems made it obsolete. Nobody knows the details of what is useful until there is a prototype to work with, and get the feel of. Agile is the way people have been solving problems forever. There seem to be a lot of "No True Scotsman" threads here. Since I did this before "agile" was a thing, I don't have to worry about it. 8)