18 ms·

"Then build it, however long it takes." (from the referenced article) This is always my favorite fantasy. No one would have issues with "Agile" if you had unli

• RangerScience 4y ago
  > unlimited time and money Yah. You run into a different issue even if you've got that. There's a lot of example of scifi/fant sagas where, as the author gains fame and (so it is assumed) gains more ability to say "no" to their editor(s), the series goes down in overall quality. AFAIK you can also see this is military R&D. (IMHO, you can see the flipside of that in a lot of web fiction with 1/wk+ release schedules) I'm pretty sure I'd never want to try touching a codebase built with unlimited time and money - I'd expect waaay too much code, mostly. IMHO, even if you have (functionally) unlimited time and money, spending unlimited time and money is still a bad idea. (Balance comes from opposing forces. If you don't have an opposing force, you can't be in balance. Budget and shipping can be treated as opposing forces.)
  • JohnFen 4y ago
    A business mentor of mine used to say that the two primary ways startups die is 1) by not having enough money, and 2) having too much money.
• yamtaddle 4y ago
  The best effects I've seen from agile practices have been getting everyone to frequently think about deadline/feature trade-offs, reducing the occurrence of surprise bad news. I'm sure this is possible without "agile", but it's a thing I've seen it aid with. The worst is probably standups-gone-wrong. There's little more demoralizing than a 20-person 3-team standup where you couldn't possibly care about what anyone says (because it's irrelevant to you) except three or four people, and you already know what they're going to say because you all, you know, talk, and then also having to turn yesterday's work into some epic (LOL) tale of adventure and adversity because your manager's in the meeting and that's the kind of dumb-shit tone they've set for it ("now—justify why I should continue paying you" with pointed, bordering-on-hostile follow-up questions to anyone without a sufficiently-convincing theatrical performance) and you'd like to keep your job. Starting every day with a half-hour of that shit. JFC. But, I'm pretty sure, overall, agile is one of those things where most places that it works, any halfway-reasonable system would have worked just as well, and places where it doesn't, no system was going to work.
  • darreninthenet 4y ago
    This is where a decent Scrum Master or Agile Coach makes such a massive difference... I've seen what you're describing so many times and it's a simple fix to get people to stop focusing on what they've done and to instead focus on what the team needs to do (ie focus on work not yet complete for the team and not what on the individual has done/will do)
    • marcinzm 4y ago
      People care and should care about what they get rewarded for. If promotions/raises/bonuses are based on the manager's view of your personal work, as is the case at most companies, then that is exactly what a sane person should focus on. Removing the manager from the standup or adding another layer of a Scrum Master won't change that but merely change how they get that same information. Standup at least provides an equal opportunity for everyone to sell themselves in those cases.
      • Pamar 4y ago
        So people with better communication skills would get rewarded more than people contributing more on the actual delivery side?
        • Scarblac 4y ago
          He's not suggesting that's how it should work, he's saying that's how it does work at most places. It's my experience too.
        • marcinzm 4y ago
          As the other comment said I'm simply noting the unfortunately reality that what matters is rarely actual delivery. Trying to avoid that reality won't make things more tied to delivery but simply more opaque as to what they're tied to. There's exceptions but in my experience those teams don't bother with these types of deep discussions on process. The process is somewhat irrelevant since the expectations are fairly clear and what they will be measured on is also fairly clear.
• duxup 4y ago
  I can't comment too much on Agile but I can say that I don't trust my instincts as far as "however long it takes". First project I finished on my own I felt was FAR from finished, but it had to get out the door. It was missing so much.... Customers LOVED IT. They still love it ... crappy code, missing what I thought were essential features, and all.
  • ericmcer 4y ago
    I am really struggling with this currently, I have agiled myself into a spiral of never being done. I am wishing I took a more waterfall approach so there was a fixed endpoint. For personal projects in the future I will adopt a more rigid design phase as you don't have designers and managers enforcing deadlines and sanity checking whatever tangents you go off on.
    • wpietri 4y ago
      You also have an agile option: release early and often! Use the feedback you get from users/customers to decide what to do next and when to stop. The problem with waterfall approaches to "fixed" endpoints is that at the beginning of a project you know the least. It can be comforting to imagine that you can fix an endpoint up front. But most projects worth doing result in a lot of learning along the way. I have heard of very few projects that did their 1.0 release and were so successful that they just stuck with that release forever.
• Waterluvian 4y ago
  It’s hard to have this conversation given the countless definitions of “Agile” but I think the majority of what I’ve experienced does not help with the concerns you raise. Proper project management to enumerate concrete goals with well-defined timelines is what you need, which is obviously not a novel part of any Agile interpretation. Often the desire for Agile comes from not knowing how to manage a project and reaching for the popular thing that people think will magically solve their lack of expertise.
  • ClumsyPilot 4y ago
    > Often the desire for Agile comes from not knowing how to manage a project Corporate Agile takes thr worst of Waterfall and Agile and combines them. It frees the management from budgeting for discovery and research, which are nessesary in waterfall. They can come unprepared. Then they demand all the things they expect from waterfall - hard deadlines, no surprises. Then thry change scope on the fly because 'its agile, right'. Agile does more to excuse poor managment than it does to enable developers.
    • trentnix 4y ago
      I think this mostly nails how Agile is largely practiced. Being prepared with a clear, concise, well-communicated vision of what you want to build is essential to developing quality software, regardless of the adopted process. Agilists frequently argued investing time and energy into crafting requirements is an “anti-pattern”, so being unprepared became the Right Way To Work TM. This is 100% dead-ass wrong.
    • and0 4y ago
      "Agile does more to excuse poor management than it does to enable developers." ding ding ding, maybe the most succinct description I've heard
• hinkley 4y ago
  > if you had unlimited time and money. If you had unlimited time and money, then you wouldn't need Agile. There's no intrinsic value in having 50% of the system working at 40% of the deadline.
  • lmm 4y ago
    > There's no intrinsic value in having 50% of the system working at 40% of the deadline. In practice that's usually more valuable than having 100% of the system working at 100% of the deadline. Almost all deadlines are fake, and most requirements are too.
• deckard1 4y ago
  > break everything up into smaller chunks. It gives you clearly defined guardrails This is only true if management respects the estimates. In my experience, they do not understand why Fibonacci or t-shirt sizing, etc. are used. They mentally convert the points to some "X days" and then beat you in the head with it. They want to micromanage and they do not understand they are building software. You can't break certain tasks down further and you can't parallelize many tasks. You can bring up Fred Brooks but it's a hopeless cause. They will never get it. Then as you inch towards their arbitrary deadline (that they tell no one, by the way, because it's better the developers don't know about deadlines until the last fucking minute because "agile" and not "waterfall") they suddenly act shocked that 9 women really can't make a baby in one month. But I digress.
  • wsc981 4y ago
    At the end, those complexity number end up representing some time estimates anyway. Cause you will get the velocity graph, showing how much points have been completed this sprint and how it compares to previous sprints. The graph is expected to stay somewhat level or increase as the team efficiency increases. It will decrease when members are away on holiday. If your team capacity stays equal and last sprint your team completed 20 story points, it’s kinda expected the next sprint another ~20 story points are completed. So in that case 20 story points will represent about 2 weeks of work for the full team. I also think for many people complexity translates into time needed to finish work. A more complex task will naturally take more time to complete than a simple task. So from my point of view, it’s fair (if after a couple of sprints) a product owner might get an idea that 1 point is equal to -say- half a day of work. PS: I am not a product owner and not a big fan of ”Agile”. I think daily stand-ups might be overkill in many situations (in my current remote team it’s more like a weekly stand-up) and I generally hate retrospectives. I just want to get shit done (which is luckily the practice we have in my current team). We do have a task board, but we don’t do the whole assigning points stuff. And I am mostly free to pick-up any task I feel like working on. This is much more agile to me than “Agile”.
    • Aeolun 4y ago
      That’s generally true for that specific team in that configuration, but as soon as you start plucking people off, and adding other people to the team everything is up in the air again. It’s also a bad habit to rely on it.
• kerkeslager 4y ago
  Okay, but I could equally say, "No one would have issues with 'Agile' if developers could get infinite work done in a week... but that's not how the world works." The fact is, there's a limited amount of work that can be done in a limited amount of time with a limited amount of money. Developers want the time and money to be unlimited, while customers want the work to be unlimited. But none of that is how this works: all three of these things are finite. The point of "Customer collaboration over contract negotiation" is that the customer is involved enough in the process to see that you're producing close to optimally with the time and money they're giving you. Committing to an amount of work in a sprint doesn't work, because it always ends up with customers trying to get more work into the sprint--more production than ultimately is possible. And, it's worth noting, setting boundaries around that and guarding to prevent that, starts to just look like "contract negotiation" with a shorter contract. Sprints aren't agile, they're Agile: a marketable idea that doesn't work. Part of the problem is that customers see it as their job to get more work for less time and money, so they try to set aside what developers are telling them, the "work is limited" part of the trifecta. They see developers as their subordinates, so they think their desired outcome, where time and money are limited but ability to produce is unlimited, is reality. If developers and customers are seen as equals, both bringing needed value to the table, then this doesn't happen, because everyone agrees on the limitations of the situation. But as soon as you start treating customers as superiors, their view of the limitations becomes dominant, with predictable negative outcomes.
• alliao 4y ago
  this is the truth. quite frustrating in training materials it's all about empowering employees when it is totally not.
• bdangubic 4y ago
  You can do this if you hire the right people. The only “process” that always works is “hire right people and the F out of the way.” The problem of course is that there are waaaaay too many software developers and roughly 93% are terrible at their job (this is just simple math, take anything and put millions of people to do it there will only be 5-7% that are actually good at it).
• Terretta 4y ago
  > spiral out of control Meanwhile, an '80s paper countering 'waterfall' with prototyping iterations called it the 'spiral method'. https://en.wikipedia.org/wiki/Spiral_model https://en.wikipedia.org/wiki/Spiral_model FWIW, the early '70s paper the DOD misunderstood as suggesting 'waterfall' had already said the right way was to build one to throw away -- but use the prototype to derive the usability, requirements, and design docs first.