33 ms·

Dear Agile, I’m Tired of Pretending (2018)

• mpweiher 7y ago
  I agree that almost all of the orgs I encountered that were Doing Agile were pretty horrible. On the other hand, I've also been in orgs that were very successful in developing software in a way that we would recognise as being agile. We just didn't make a big deal out of it. And we didn't do standups (most of the time), or 2 week sprints, or retrospectives. We didn't even pair consistently: we split up on trivial stuff, paired on hard stuff, as needed and available. In one org we started without TDD, and even without having much in the way of automated tests at all. But when we discovered testing and TDD, boy did we ever embrace it. Not because anyone told us to (mid-to-late 90s, so no Agile Manifesto), but because the difference for us developers was night and day. So develop software. Concentrate on what helps you develop software. In my experience, you will probably discover something recognisably agile all by yourself. So when you discover that, help yourself to what helps you. Don't make a big deal out of it.
  • hef19898 7y ago
    Sounds a lot like TPS, I assume Toyota did a lot of the stuff before any books were written. Also, my personal experience, the more companies talk about Lean and Six Sigma the less they do it.
    • mpweiher 7y ago
      Similar with "culture". Companies with a great culture don't talk much about it, they just get shit done without much fuss and typically have some fun doing it. Because getting shit done is fun. On the other hand, if the company all about how fantastic the culture is...run! Or at least tread very, very carefully.
      • maxxxxx 7y ago
        Totally agree. Talking about culture or hanging up "inspirational" posters is usually a warning sign. Good organizations live their values and don't feel a need to constantly talk about them.
      • HeWhoLurksLate 7y ago
        That reminds me of my two favorite interviewee questions: "What's your company culture like?" - the way that the interviewer responds is a pretty good indicator of what their culture is like. "If someone does something exceptional, how do you reward them?" works in a very similar way.
        • rtikulit 7y ago
          Maybe even step back to first principles... “Can your company even recognize when someone does something exceptional?”
  • maxxxxx 7y ago
    What you are describing is exactly what Agile should be. You have a team of people who care about the craft and they slowly improve processes based on real world feedback and experience. If something doesn't work you drop it and try something else. This happens in environments where people respect each other.
    • rtikulit 7y ago
      Management does not want to hear that software development is a craft. They want it to be a trade, with fungible workers operating in a predictable process with fungible components. The great tragedy of Agile is that it was co-opted as the vehicle of this transformation. It was seized by management, weaponized to other purposes, and then aimed right back at us.
    • bloorp 7y ago
      Yeah, I've come to similar conclusions about Agile. It can be a great way for an already well-disciplined organization to think about the work they're doing. But many, many undisciplined organizations thought that Agile would be a catalyst for them to become disciplined. But the nitty gritty of "doing Agile" required EVEN MORE discipline than what all these organizations were already capable of exercising, so it just highlights all the frustrations everyone already has. That does seem to be the downside of Agile. It's a collection of maybe a dozen different techniques and practices. But if one of those practices falters, whether it's the TDD, or the business side still wants a certain deadline, or you don't bother to demo at the end of a sprint, then the whole house of cards falls like dominoes..... checkmate!
  • asdfman123 7y ago
    Build trust and respect instead of elaborate processes to compensate for the lack of them.
  • JoeAltmaier 7y ago
    Good advice for an experienced team. Couple it with good reporting (who's job is that?) and management could be good with it. Green teams may need more structure. But the structure should not take over; it should be a tutorial and get rethought as the team matures.
    • maxxxxx 7y ago
      You also need to give people the chance to make mistakes and learn from them. I don’t envy a lot of the young developers who get micromanaged all the time and never have a chance to try something.
  • bewo001 7y ago
    Agile has fallen into the hands of big consultants. Now the focus is on process, with more meetings and presentations than ever before.
    • ataturk 7y ago
      Am tired, just dead bones tired of all of it. It's all just this or that money making scheme with guys like me caught in the middle. I despised Waterfall, fell into scrum and in the past ten or so years kinda sorta saw one project where agile basically worked right. The rest has been mostly waste. I've worked on billion dollar systems on down to just little nothings. Doesn't matter, companies are struggling to make anything work. I think there's just too much complexity and they all believe IT solutions can manage that complexity. It's failing like never before while expectations have never been higher. Message to the Fortune 500: Just get rid of anyone with the title "scrum master" they're dead weight. You were fooled, deal with it. I am trying to move my team over to Kanban right now, but we have all this reporting crap up the chain all designed around CA Rally, the worst productivity tool ever made.
  • marcosdumay 7y ago
    > Doing Agile You mean the ones following one of those canned "agile processes"? It always amused me how people could read the Agile Manifesto and then conclude that it's best satisfied by following a canned process.
  • Zenbit_UX 7y ago
    Got any insight as to why TDD is such a great thing? From how Ive heard it described it seems to be a way for management to impose rules on how developers can approach writing a feature and not necessarily a benefit to the devs. If I understand it properly, it's essentially write a test so it fails then fill in the feature gap. The whole write first bit is just so you don't have to retest later to verify that your test didn't hit a false positive, right? Something a careful person would check anyways...
    • mpweiher 7y ago
      1. It's not a management-imposed thing TDD was discovered as technique by developers, for their own benefit. Management imposing it can be a bit of an anti-pattern, though it may be well-intentioned. I have certainly pushed teams to TDD, though primarily by example and by the positive experience you quickly get. Anyway, TDD has nothing to do with management imposition. It is really diametrically opposed, at most orthogonal. 2. "test didn't hit a false positive" Yes, that's a good thing, though hardly the main point. You write that a careful person does this anyway. I'd rather have a machine do that for me, and have less of a requirement on me to be careful. Computers are much better at being careful, and I want them to do the tedious stuff. I also am wary of claims of "you just need to be careful". Probably lots of bugs ahead! 3. So why is TDD so great? First, it's a design technique. Writing the test first forces you to think about how your new production code will be called. It also forces you to be clear about what the code is supposed to do, precisely, before you write the code. Writing the test tends to be significantly less difficult than writing (correct) code to solve the problem. You then write only the minimal code that is required to pass the test, which surprisingly also tends to be fairly trivial. Also, you know when you're done: when the tests are green again. So you've transformed one difficult step into two fairly trivial steps. Which sounds weirdly magical, but actually works in practice. Also, since you only wrote the minimal code that was required for the tests to pass, you know that you have good test coverage. After you've done a few, you're in a place to detect duplication and eliminate it by refactoring. This tends to be somewhat more intellectually challenging. However, you are truly refactoring, that is not changing the functionality, so you have a great safety net with the good test coverage you achieved before. So you get this small steps that are fun and easy, and you tend to not regress. Psychologically, it's also very pleasant, compared to the usual flow, which goes somewhat as follows: 1. I have a rough understanding of the problem, 2. I code a solution, which is at the limits of my understanding (because everything is up in the air) This part feels very good, "I am the master of the universe" 3. Then I should write some tests, but the incentives are a bit negative -> if the tests all pass, nothing happens, so why did I write the tests? also if nothing happens, how do I know I actually tested something? (not by "being careful") -> if the tests do show a failure, it's a distinct downer from step 2 (and so I probably subconsciously write my test so they don't fail) 4. I don't really want to refactor, because my solution from step 2 was already awesome! TDD: 1. I write a test. It fails appropriately. That makes me happy. 2. I write minimal code. Tests go green. That also makes me happy. 3. I refactor. The code now is much nicer and tests still green. More happiness. So with most normal development flows you get that initial rush and then a lot of downers. With TDD, you don't get quite the same initial excitement, but instead you get these nice regular dopamine hits without really much downside.
• lordleft 7y ago
  The best way I've seen agile described is "designing code in a way that acknowledges change.' I think there's a lot of value in understanding that you may have to go back to the drawing board when designing parts of your program. I have little regard for the entire industry that has risen up around agile, however.
  • FpUser 7y ago
    Exactly my thoughts.
  • marapuru 7y ago
    Yeah, coming to the point where it's never completely finished. You just always anticipate on going back.
  • collyw 7y ago
    That makes complete sense as a good way to go about designing software, but I don't think I have seen anywhere else describe agile in that way.
• commandlinefan 7y ago
  You don’t hear the name Joel Spolsky much any more, but he was pretty influential in software process thinking in the 90’s - not really for being particularly insightful or original, but more because he was one of the first people who thought of writing a blog about software design. One of his early “observations” about software project management was that “you wouldn’t buy a pair of jeans without knowing how much they were going to cost, why would you expect your manager to sign off on a software project without knowing how much it was going to cost?” The utter blithering stupidity of this perspective highlights how managers look at software design: the purpose of software methodology is to put a fixed cost on every software project. As long as that’s what they’re looking for, software methodology is going to continue to be a lost cause.
  • geezerjay 7y ago
    What's stupid in wanting to get an idea of how much a project costs in order to decide if it's a good idea to pursue, let alonr allocate resources?
    • danielbarla 7y ago
      Nothing, inherently, except perhaps the fallacy of comparing a pair of jeans to the rather chaotic and unpredictable world of bespoke systems development. One is inherently known (a pair of jeans you've presumably already manufactured), the other is one big unknown, basically.
      • ellius 7y ago
        Aircraft, hospitals, hotels — a million complex bespoke things are built every day. Cost and time projections are inevitable.
        • marcosdumay 7y ago
          > Cost and time projections are inevitable. As inevitable as blowing through the projections.
• RocketSyntax 7y ago
  "We don't want to follow the agile process..." followed by "why isn't agile working for us?!" I blame the ambiguous manifesto.
  • specialist 7y ago
    The Agile Methodology is to argue about The Agile Methodology.
• quadcore 7y ago
  Agile never gave organizations a holistic, viable alternative to Waterfall. Because there’s a difference between theory and practice. Product work is more about practice. When we complain about “AINO” (Agile In Name Only), we’re not being honest with ourselves. I agree with most of the article. Specially the keep-learning part. All Agile did was put software development teams unfairly under a microscope. I believe Agile has been tremendously beneficial for the industry globally, especially in some subtle ways. For example, Agile says you have to communicate a lot, if you want to get software done. Here is the subtlety: if, today, you stop telling the average programmer to communicate, they will stop and go back to silo mode, "naturally". At least some of them. If you think about software at the industry scale, you have to think about a wide population which require processes. I was once working in a nice little company where, one day, they introduced agile. It was so much beneficial. Before, the bosses thought that talking was simply a lost of productivity. You're a programmer right? So code, don't talk. So we would develop software without talking to each other. After we had daily meetings, scrums things and stuff. Our velocity has sky-rocketed. You have to realise that before Agile, a fair portion of all software development projects that were started would simply bust and never get shipped. The code is a complete monster or the budget is nuked. When I started in the company I just mentioned, I started working on a codebase that was the worse code I've ever seen in my life. You would touch one line and everything would stop working. It was a condensed piece of spaghetti with hacks on top of hacks on top of hacks. Software architecture? That requires some talking and thinking, forget about that, not permitted. Now I agree with you, agile is not much useful for a hacker who consistently get software done and understand deeply what's happening. edit: not that I'm an agile guru or anything. Actually I only know the thing superficially. I show up at the meetings, when I'm ask how hard something is, I answer, then I mess around with my office friends. Still I can appreciate it works much better than any process the bosses can come up with.
  • b_tterc_p 7y ago
    > You have to realise that before Agile, a fair portion of the software development projects that were started would simply bust and never get shipped. The code is a complete monster or the budget is nuked. This still happens, all the time?
• Isamu 7y ago
  Agile is not science-based, it is an ad hoc bag of techniques that seem to have merit. As such you have to be able to reason about what your practices are and you have to relate everything to concrete business goals. Your goal should never be to become "more agile". You should be looking to improve efficiency, to make sure you are building the right thing, to improve communication so that everyone is on the same page, etc. "Agile" is never going to magically improve anything.
  • FpUser 7y ago
    "Agile is not science-based, it is an ad hoc bag of techniques that seem to have merit" Each participant of "Agile" development should have this hung on their work place.
• taylodl 7y ago
  Uncle Bob wrote about this in The Tragedy of Craftsmanship (https://blog.cleancoder.com/uncle-bob/2018/08/28/CraftsmanshipMovement.html https://blog.cleancoder.com/uncle-bob/2018/08/28/Craftsmansh...). His perspective is Agile lost its way once the Project Managers stepped in. It seems to me the problem with Agile in practice today is there's too much focus on process and not enough focus on, you know, the actual software being delivered. Add to that a host of less-than-desirable ideas that have taken hold (don't even get me started on emergent architecture) and you realize modern Agile has become a cesspool. What to do if you're on an Agile team? There's value in the Lean Methodology. Remember, the whole point was to deliver software your customer needs to fulfill their business objectives. Continually assess your Agile practice and see if what you're doing still makes sense for the project you're working on right now and for the current stage that project is in. This continual assessment with a focus on the end goal of delivering software can go a long way to addressing Agile's modern ills.
  • F_J_H 7y ago
    I had not heard of "emergent architecture" until you implied you hated it, and so I thought I would Google it. I have no idea what emergent architecture is in the agile context, but the idea of emergence is fascinating to me, and has been ever since I read "Emergence: The Connected Lives of Ants, Brains, Cities, and Software" by Steven Johnson. We see the idea of emergent design everywhere in nature and society. I'm not suggesting everything can be built and designed "emergently", but certainly some things can be. See the book (and concept of) "the cathedral and the bazaar". The idea of something useful coming into existence without central planning is an enticing one, and so I can see the draw.
    • LyndsySimon 7y ago
      Thank you for that book recommendation - I just bought it and am looking forward to reading it :) I also had not heard the term "emergent architecture" in relation to software development. I'm intimately familiar with the concept of emergent order, though, and my grokking it was part of my "political awakening" in my 20s. It led me from being a libertarian-leaning conservative to an anarcho-capitalist. To put it another way, I believe that the system create by independent actors acting in their own self-interest naturally create the most efficient system possible within the constraints of the environment within which they operate. There's a name for this concept when applied to company management, but I can't recall it at the moment :(. I want to say the word has a Greek root, and it reminded me of "autarchy" ("self organized") but that wasn't what it was called.
• forgottenpass 7y ago
  I don't know any description of Agile better than meaningless buzzword. Buzzwords are not without value. They are a tool for selling a change without describing all the nitty gritty. "Agile" is a lie that before 2001 nobody at all had ever done iterative software development, and all software process ideas that came after 2001 are by definition "agile." "Agile", as with any other buzzword, is not for people who actually understand the details of the change; it's for someone who needs a handle onto concepts that would fly over their heads without a buzzword. Lets stop litigating the term, and move on.
• bpyne 7y ago
  Organizations have to find their own way of working. It's going to change based on the size of the organization, its goals, and its people. With the exception of 1.5 years in a software company, most of my organizations have been internal IT. What I find is that user areas, who initiate projects with us, often don't have a clear view of what they want but think it's going to help the organization. Our job is to build models quickly so that they can validate an idea. Only after iterating through a few models can they reliably say the benefit/cost of the idea. A very good engineer within my organization said to me, "Our job is to get something in front of them quickly so they can figure out what they don't want." Our successful projects have been ones in which we kept to this maxim. I think this is what the author was trying to say but I had a hard time following his writing style.
• nosianu 7y ago
  "Thou shalt not be negative" (HN) - well I'm sorry. Just some example text: > both Agile and Waterfall are focused on building. Design is about validating. or > So…what’s the way out? It’s a smart focus on clear outcomes, not output, with roadmapped outcomes replacing planned milestones, with trusted product teams, not project teams, empowered to vet assumptions and discover the minimal path to value. Satire? Enough words to fill a hot air balloon or two. "Smart" focus, "clear" outcomes, "outcomes" vs. "milestones"(?), "trusted" product teams (as opposed to... what?), "empowered" etc.? Far more interesting than the contents of many links that make it to the HN homepage is discovering the fact that they do so.
  • tootie 7y ago
    Honestly that statement is the nail on the head for me. There's a huge distinction between an output and an outcome and a huge distinction between a project plan and a road map.
    • nosianu 7y ago
      > between an output and an outcome and a huge distinction between a project plan and a road map. I mention neither of those. I'm not complaining about your reply, I think it shows how those texts are (to be?) used: Just like art. You project your own experiences into it, it's more about getting you to think. So naturally different people are going to react differently and read different things into the same text. That's perfectly alright - you get something out of it (only) if you put something in. If there is nothing to begin with, which may just be lack of experience (new programmer), you'll get less out of it. If you have two decades large project experience in various companies and teams you'll get a lot out of it. Let's attempt to make the best out of it then, out of any text, if we are presented with that opportunity and the headline got us to click on it :-)
      • itsdrewmiller 7y ago
        I think you misread the part you quoted, while GP read it correctly - it's comparing outputs and outcomes, not outcomes and milestones.
• _pmf_ 7y ago
  But think of your manager. He cannot stop pretending because that's all he has.
• deleted 7y ago
  [deleted]
• me_again 7y ago
  I have a theory that commercially successful software development methodologies are like diets: they have to be almost impossible to follow. This ensures that when you fail to lose weight/achieve bug free software, you blame yourself for not following the rules exactly, rather than the rules for not working.
  • dclowd9901 7y ago
    Then maybe there should be one rule (as was my most successful dieting effort): Is what you're doing helping make or save money? I know such a simple rule is probably causing a lot of you to cringe, but I can very easily fit just about any activity of value you or your team embarks on into that question, and it's a rule the entire company can get behind.
  • ff317 7y ago
    That's probably a very apt metaphor, but there's an upside too: many diets actually do at least temporarily help people in spite of their irrational basis, just because $random_diet causes the dieter to observe and reflect on their eating habits more carefully in general. Even a non-sense diet like "eat only foods colored yellow or red" probably does a lot of people a lot of good, compared to their usual state of being completely unconscious of their awful habits. Same goes for software development practices.
    • sombremesa 7y ago
      I think with this analogy you're presuming that people are exposed to a variety of foods and there is some positive correlation between action and awareness. However, for someone who only ever goes to McDonald's to eat, they'll just switch to french fries and ketchup for your nonsense diet.
  • Bartweiss 7y ago
    At the very least, I think it's common to judge methodologies by "how well does it work when it's done right?", when we should be using a three-part test. 1. How much value is there if it goes right? 2. How easy it is to get right? 3. How gracefully will it break down if it's not done perfectly? Methodologies don't have to shine on 2 or 3. NASA-style clean-room coding is the gold standard of hard-but-effective; you have to suck it up and commit entirely with a great team, but the results are unbeatable. Waterfall was "good, bad, bad", but used by lots of less-exceptional teams with hideous results. Agile, I think, improved #3, but not #2 so much. It's commonly sold by appealing to how much it can potentially help, but I think the more honest pitch is "it's tough to do right and it'll sting if we get it wrong, but it hurts a lot less than getting waterfall wrong."
• mcv 7y ago
  "It’s just that everyone does Agile wrong." Not everyone. Some are very successful with it. The problem is that everybody wants to copy that success and tries to cargo cult themselves through it without understanding it. "let’s stop pretending Agile was some sort of cure all." That's certainly good advice. Agile is more of an attitude than a solution, and attitude is not going to solve all your problems. Even if you are as Agile as you can be, you still need to solve your problems. It's just that being Agile might make you more flexible and effective at solving those problems. And Lean is certainly more comprehensive than Agile. And I don't think they contradict each other. In fact, they're very similar; they're both about empowering the people who are doing the actual work. "management thinks the focus should still be scope and deadlines and efficiency, ignoring that the deadlines are arbitrary and the requested time estimates are a form of waste." Then management is not Agile and hasn't properly learned what it is. That is sadly common. Agile is not magically going to solve bad management, but Agile does emphasize keeping management at a distance and empowering developers. "Agile actually tends to mask the core problem, which is a systemic, bidirectional lack of vertical trust." Does it mask that? I think it exposes it. Without that trust, Agile cannot work. Agile insists on that trust. I suspect that every case of broken Agile is caused by a lack of trust. Fix the lack of trust (or use a system that works without trust if you absolutely must). "Did you know story points were actually invented to obscure time and help alleviate this problem? That backfired too, didn’t it?" Yes I did and no it didn't. Every single team I've worked in over the past 6 years knew this and kept repeating it every time someone comes along and tries to match story points to actual hours. This first half of the article suggests the author has mostly worked in very toxic management cultures.
  • unreal37 7y ago
    I agree with a lot of what you said. My last company (before going self-employed) had an agile environment and it was mostly a good system to work in. I don't recognize the fairly strictly Agile (not AINO) environment I worked in in that article. Not perfect, but it worked and better than a lot of places that had no good methodology.
• awinter-py 7y ago
  IMO focusing more on systems than people in management is a mistake. To the extent your work isn't repetitive, the only job process can do is set a cadence on communication & decisions. Yes 2-week scrum does this but in my experience it distracts companies from the real goal of management -- attaching subject matter experts to projects, i.e. concentrating time & resources towards a goal. Process can get rid of bad people and share around your best people, but unless you have an assembly line, beware of any other claim.
• tootie 7y ago
  I was prepared for our weekly "I Hate Agile" post, but this one is actually really great. It's a lot of the arguments I make to Agile haters. The fundamental problem that drives most agile failures isn't in the team's execution, it's in the business' expectations. One side is signed up for incremental delivery, and one side is set up for a fixed scope and deadline and the result is misery. I think this article makes a lot of good points. Scrum isn't the complete answer, but it's a big step in an organizational transformation. I think it's suffered a lot from being oversold.
  • dsego 7y ago
    The author (https://medium.com/@charles.lambdin https://medium.com/@charles.lambdin) has a whole series of blog posts on this and similar topics, a very interesting read.
  • usrusr 7y ago
    “One side is signed up for incremental delivery, and one side is set up for a fixed scope and deadline and the result is misery.“ That's just one example of the general value I like to ascribe to "AINO": it gives you a useful mental model of the delta between what you have and a known good process, making it quite easy to name the missing pieces. This usually doesn't make it easier to actually fix their absence, but at least you know where to start with damage mitigation. When waterfall fails, you just throw your hands in the air and say "more of the same".
  • wayoutthere 7y ago
    I agree entirely! I often sit between the business and tech orgs, so the way I explain it to the business is this: I can get you detailed status reports and metrics, but they will slow progress and be expensive. So think about why you need that information: if there are legitimate business reasons with dollars attached, go for it. If it’s just to soothe your anxiety about the timeline, a therapist will be far cheaper and more effective.
  • Bartweiss 7y ago
    > One side is signed up for incremental delivery, and one side is set up for a fixed scope and deadline and the result is misery. This is a brilliant summary, thank you. The best 'agile' experiences I've had are situations where the 'clients' are directly involved, often within the same organization. Instead of a hard scope or deadline, there's just a shared interest in producing a valuable product efficiently, and the users are on-hand throughout the process for feedback and reevaluation. The worst experiences have been waterfall contracts, developed by an internal simulation of agile. The software team does frequent "releases" to business or management, who provide feedback and feature requests, but the actual recipients are uninvolved outside of occasional demos, or contacted only indirectly by non-programmers. The result is almost always thrashing, with time and effort spent pointlessly satisfying the forms of agile even though the real timeline and customer feedback are unyielding.
• mratsim 7y ago
  Pardon the interruption ...
• ltbarcly3 7y ago
  It's almost like there is "No Silver Bullet". https://en.wikipedia.org/wiki/No_Silver_Bullet https://en.wikipedia.org/wiki/No_Silver_Bullet
• nerdponx 7y ago
  Ah, yes, the old "you're not doing it right, so read these 3 books and follow 10 bloggers every day" argument.
  • unreal37 7y ago
    That was the weirdest part. "How many books do you read? Go read more books."
    • bendixso 7y ago
      Seriously. Just keep piling more bullshit on top of the bullshit
  • collyw 7y ago
    That would be more helpful than the far more common response of just "you are doing it wrong" argument with absolutely no indication of how to do it right.
• couchand 7y ago
  One of the most useful segments of the article: > So find a good booklist. Follow some good blogs. Here’s a start: If you haven’t read Sense & Respond, Lean Enterprise, A Seat at the Table, and Everyone Is a Change Agent, I suggest you do so pronto. Your leaders too. I'd add Peopleware to that list. > Start reading posts by John Cutler, Melissa Perri, Bob Marshall, Allen Holub, Laura Klein, Erika Hall, Neil Killick, and branch out from there. Anyone care to add their own handful of books and bloggers to these recommendations?
• curtis 7y ago
  Any software development methodology or process is going to come up short if it ignores the fundamental nature of software development, which is: We do not know what we're doing until we do. Any process or methodology that tries to extract promises out of the software development organization about things that are still in the we do not know what we're doing phase is going to result in disappointment at best and serious harm to the overall effort at worst. And it turns out that it's not unusual for software developers (and consequently software development organizations) to spend more time in the we don't know what we're doing phase than the we do know what we're doing phase. That sucks from a management point of view, but no amount of process is going to make the problem go away. The best you can do is manage the risk. We don't need good processes or methodologies nearly so badly as we just need management enlightenment about how software development actually works.
  • LarryDarrell 7y ago
    That's the truth, except, I can't tell clients that "I'll know how long it will take when I'm halfway done." The best I can do is look at prior work and multiply by the LarryDarrell Constant of 1.5.
    • lettergram 7y ago
      I usually do 2x my expectation. I keep track of my prior estimates and compare against my real time. I normally miss by about 30% - 50%, this leaves me a fair margin. It’s also been improving with time, which means I’m getting better at assessing my skills and problems. For me, I tend to work quicker than other contractors / employees, so I still often beat out the other quotes (time or money). That’s not always the case for others, so they margin of safety may not be there. In which case, multiply by a smaller constant.
    • curtis 7y ago
      I kind of lean towards double the schedule and cut the scope in half and hope that maybe we can deliver a little extra credit work. It's important to note that padding schedules is not just done in software, it's a common practices in all sorts of engineering. It's not bad that we do this, it's bad that management often doesn't understand that we do this and doesn't understand why. The understanding why part is actually really important, because that means management can be expected to do their part in managing the uncertainty or at the very least they can be expected to be careful about not making the situation worse.
• andrei_says_ 7y ago
  I love this talk by Dave Thomas, one of the people whose names are on the original Agile Manifesto. Among other things he speaks about the simplicity of the Manifesto, about the cultish movement and consulting services which rose around it and the cultish, distorted, complex vortex of BS that has formed around a super simple concept. https://m.youtube.com/watch?v=a-BOSpxYJ9M https://m.youtube.com/watch?v=a-BOSpxYJ9M
• jacques_chester 7y ago
  In my experience, these discussions boil down to anecdotes at twenty paces. I've seen software development done very poorly and done very well, sailing under a variety of flags. But on an eyeballing there are far more bad experiences than good that get labeled "Agile". Whether this is because of causal differences or because it's easy to affix any label to anything (and most experiences suck regardless of the label) is hard to tell without a control-group universe were the Agile Manifesto was never written. If anyone needs me, I'll be counting to twenty.
  • wayoutthere 7y ago
    I have a theory here... culture beats process, but companies without the culture have to rely on process. So you’ll find that companies with the right culture can deliver better results without needing a bunch of process, but companies without the culture end up having to force it with process. And tbh, despite how bad “Agile” process can be, it’s a lot better than pure waterfall.
  • chris11 7y ago
    How do you like agile at Pivotal? I'm curious, they have some really strongly heard opinions about how to do agile correctly.
    • jacques_chester 7y ago
      Pivotal on the whole does software development as well as I've experienced. When you hit the sweetspot for our core practices it's really impressive. Everything just sort of flows. Sometimes it goes off the rails. That is in the nature of things. But it goes off the rails as an exception, rather than as a rule. If there's a key to the magic it's (1) hire for empathy as well as smarts and (2) reflect on what can be done better.
• ryandvm 7y ago
  Agile is like Communism. It's never been done successfully and every time it fails the apologists always respond with, "well... they weren't doing it right."
  • goto11 7y ago
    I have experienced Agile being quite successful. Maybe that is an uncommon experience, but it is certainly possible.
    • tyingq 7y ago
      Curious if you had success with "generally following the Agile manifesto", or some specific framework like XP, Scrum, Scaled Agile, etc.
      • goto11 7y ago
        I have tried Scrum. I have also tried various pick-and-chose hybrid approaches which were generally less successful. For example having scrum-like sprints and daily stand-up, but still having a fixed feature set and fixed deadline. This doesn't really work. (You can have deadlines in Scrum, and you can have fixed feature set, but you cant have both!) This happens if management does not really buy into the process. The place where scrum worked was because management was willing and able to try something new and willing to learn. For what it is worth, I have also seen classic waterfall be successful. But I have also seen several big-scale disasters with waterfall, and in my experience waterfall carry much larger risk and is much harder to salvage when it goes off track.
  • eeZah7Ux 7y ago
    This is not 8chan.
    • blow_johan 7y ago
      Your mom.
• bezoisevil 7y ago
  Agile is the scam of the century
• acbabis 7y ago
  "Agile transformations" are bad, but I still think agile itself is fine. Teams of self-organized, competent developers tend naturally toward agile-like practices. I've seen agile's story-centric model of development help new developers grow by giving them responsibility for specific, testable units of work. As a lot of people have already said, the problems arise when managers expect agile to give them software on a timeline.
• bougiefever 7y ago
  I've been developing software for over 20 years, and I still can't estimate how long something will take me when I've never done it before. This uncertainty needs to become more than just a stick to beat developers about the head and shoulders with. Most of the time the PMs understand this, but there have been many projects where they just don't get it. I have suffered great anxiety from being forced to give estimates when the truth is I have no clue. It depends on how easy it is and how many unforeseen issues I encounter. It was so bad that once my husband asked me how long it would be before I was done cooking something, and I practically had a meltdown. That's when I knew it was time to leave that team. Can we stop pretending we can forecast the unknown? (edit typo)
  • java-man 7y ago
    I think there is a way to give an estimate (have been doing it myself for a decade), even for dependencies that are not known from the start. (I mean, reasonable dependencies. No one can account for unknown unknowns, but the software engineering field is not an art, more of a skill, we do have well established processes to minimize the surprises). Is this something that HN audience is interested in?
    • Bjartr 7y ago
      I'd love to hear what you have to say in the topic.
      • java-man 7y ago
        Sorry, tried to answer and apparently I was "posting too fast". One may start with enumerating the features that needs development (a.k.a. "user stories"). Also enumerate external dependencies, team overhead (more people working together means overhead is greater). For each feature enumerated in step 1, try listing as much detail as possible, also listing open issues and unknowns. For example, list all the UI elements under development. List all individual functions / use cases that need distinct functionality (classes, functions) to be developed. List all the test cases. List external APIs, enumerate different ways the said API can be used. Enumerate failures and possible recovery actions. I'll give you an example: a login dialog for an application. This starts as a two page requirements document, which balloons to around 120 items using this method. This alone should give a good idea at the start of the project. Keep doing it (enhancing the level or detail), while keeping the ratio of initial estimate vs real value - that will help in estimating the remaining portion of the work. The problem (the way I see it) is that we don't really have the tools to do this kind of tracking and analysis. Jira and similar systems don't even come close. Here is an attempt to apply the methodology using Excel: https://github.com/andy-goryachev/PasswordSafe/blob/master/Feature%20Matrix.xlsx https://github.com/andy-goryachev/PasswordSafe/blob/master/F...
• LifeLiverTransp 7y ago
  Agile is just using mindgames on the customer to better get away with the usual crimes of software development. Its basically a re-branded IKEA-effect. If you where a integral part of the development all the time, no matter how clueless- and calling the shots, you lost your edge and arguments to complain. Also the castastrophe happens in small, homeopathic dosages, so the "disaster" is distributed and thus not percievable. The rest is the same. Always was, always has been.
• Zelphyr 7y ago
  The biggest problem I’ve found with Agile hasn’t necessarily been Agile itself but the lack of buy-in from company leadership. Even when we’ve had professional Agile trainers come in and tell them that not only must they embrace it for us to be successful, but they themselves must go through the training. They usually waive it off as something they’ll get to eventually. Almost immediately we wind up with a bastardized version of Agile that basically doesn’t work because the leadership doesn’t understand why we “can’t just” do something.
• rayanm 7y ago
  Agile was dead to me when I finished my PhD and joined a company that paid a Scrum consultant more than they paid me to help us move tickets without knowing what was the project about.
  • kybernetikos 7y ago
    You'll probably find that the most highly paid people in most organisations only have a fairly abstract understanding of the work being done. This is nothing to do with agile.
    • rayanm 7y ago
      I am perfectly fine with paying more for a technical project manager, or a team lead who can help us glue things together and see the big picture. But I am not fine with hiring a consultant who doesn't know anything about our product and thinks that Agile has some magic to deliver products.
• peterwwillis 7y ago
  > let’s stop pretending Agile was some sort of cure all But we won't. That's why snake oil salesmen were so effective: we want to believe in the cure-all. No matter how often you chastise, people'll keep buying it, because they're aspirational. They want there to be greener grass on the other side, and they're willing to try anything to find it. The business doesn't actually care about Agile at all. It just has heard of the term and realized it has something to do with getting work done better. So leadership will say things like "We're an Agile organization now", not having the faintest idea what that means. A snake oil salesman doesn't need to know how snake oil works; he only needs to know what it promises, and how to sell it. You can have the perfect software development methodology and people will still do it wrong. But if everyone has the same goal in mind, is highly motivated, and is willing to cross aisles to work with other people to do the best job possible, a methodology will naturally arise. Self-motivating humans can get some crazy shit done. The best working organizations I've ever seen followed no methodology. They just did what was needed to keep a site running well and making money, and it was kind of wonderous.
  • alexandercrohde 7y ago
    I think this is one of the most realistic responses here. I think it's in most party's self-interest to keep playing the "agile panacea" game. 1. Salesman sells something that doesn't exist, pats self on back 2. Engineers asked to build integration/features on arbitrary timeline 3. Doesn't happen, everybody unhappy 4. Scapegoat needed. Says we didn't agile right. Project Manager hired / Deck of Fibonacci cards bought. 5. Go back to 1
  • giglamesh 7y ago
    People complain endlessly about snake oil, but honestly, have you ever heard a creaky snake?
• asses-in-chairs 7y ago
  Honestly, I'd rather kill myself than be subject to a daily groupthink circle jerk. I'm not interested in doing this shit before noon. But really, the entire day is ruined by a daily firing squad. Please fuck off, and find another reason to talk to me. Asses in chairs management is bullshit. This is just cover to make sure I show up before 10AM. I don't care about your roll call. The subway is crowded with pieces of shit, and I'll pass through it on my own time. If you cared, you wouldn't delegate QA to morons. You'd take an active roll in getting shit done, and you'd know as much about the technical internals as any engineer, and understand why things are the way they are, without resorting to brainless rituals.
• stcredzero 7y ago
  But but but, the problem is Waterscrumfall, not Agile as intended in the Manifesto Here's the thing. Corporations are hierarchical. Human beings are hierarchical. We're also communal, but start putting us into larger and larger group situations where we're facing competition, stress, and we must engage in concerted effort, and we go into hierarchical mode. Why does everything tend to go back to waterfall? It's because that's how management likes it, for reasons which go down to basic human nature in the kinds of environments technology companies create. Heck, even the financial markets demand fictional planning and forecasts of the unknowable future. Bosses want to be able to make plans. One thing which Waterscrumfall has achieved, is that the iterations are much faster. That even fits the "next quarter" mindset of the financial markets.
  • mbar84 7y ago
    Very well said. If there's a methodology that starts with: these are the people involve, these are their incentives and this is the expected outcome in game theory, then I think we'll be making progress on methodology.
    • stcredzero 7y ago
      Methodologies are pretty good about that in the short term. If Agile were bad at that, then it wouldn't have spread. I think the problem is more Agile in the long term. It's a more general problem faced by longer term software projects. The answer might be to have shorter term software projects. Make everything more modular, have a standard backplane into which everything can plug into, and enable competing short term projects. I think today's trend is to make corporations into ecosystems, and this change might be able to shape incentives positively.
• KZeillmann 7y ago
  Oh look, it's the weekly "Agile is bad" post. I've successfully worked on two teams (including my current job) where we're a truly agile dev team. We value interactions over processes and tools, collaboration over contracts, and responding to change over following a plan. Agile is not and has never been a cure-all. Scrum doesn't solve any problems. It's supposed to reveal the problems that exist and make them apparent to anyone looking at the scrumboard. If you don't change your team dynamic and just start looking at a JIRA board every day in 30 minute "standup" meetings, you're not agile. You're just cargo culting. I'm tired of people blaming "agile" -- which is mainly about self-organizing teams and adapting quickly to changing circumstances, for what's really a management failure.
• logfromblammo 7y ago
  The longer I stay in this industry, the more anecdotes I accumulate that suggest that software development is not exclusively software development. Software development is solutions development; but for a large subclass of problems, custom-built software that automates the tedious, predictable, and repetitive parts of the solution has been and always will be a competitive way to solve them. It's synecdoche, a metonymy for "software development [and other assorted disciplines of problem-solving]". Software is the hammer in the toolbox. Things that look like nails get hammered. The hammer is so useful to organizations that have many nail-like objects sticking up, that handypersons who only have a hammer in their toolbox can still work continuously, and may never need to do anything else but hammer things. This may become common enough that folks who also keep vice grips, screwdrivers, hand saws, duct tape, and penetrating oil in their toolboxes are forbidden from using those tools. They were hired for the hammer; they should use the hammer. And what's all this nonsense about non-hammer tools, anyway? We've never needed anything but hammers here, and that's the way we like it. Agile is about advising organizations with strict rules and style guides for nail-hammering to loosen up and let the hammerers determine how to wield their own hammers, and possibly also choose the length and width of the nails. Despite the amount I actually get paid, working upstream of the problem far enough to eliminate both the nail and the hammer--possibly using a more appropriate tool--is apparently above my pay grade. Agile never fixed that. It never even suggested that a non-hammer world exists. Even the CTO position might as well be chief hammering officer. The 'T' restricts the domain of authority. An organization that is agile instead of just Agile needs to have someone around that can meaningfully restructure the company itself, such that the assumptions already built in to its organizational hierarchy are not inevitably replicated in the processes of all of its subdivisions. That's why Agile never fixed anything. The CEOs still kept telling their CTOs to take charge of all the hammers and pound something out. Those companies founded to be Agile put different assumptions into their organization. When that changes, going through the motions of Agile won't help them any more.
• tetha 7y ago
  I'm currently experiencing this, and especially the whole delivery vs discovery, knows vs unknowns and their impacts on estimations. It's quite interesting, especially how differently you have to handle delivery vs discovery projects. Basically, my team consists of some devops engineers mostly working on maintaining and extending the config management, and some other technical consultants who deliver and execute projects, ideally fully standardized. For the standard delivery projects, it's extremely valuable to hammer the scope down into a precisely known constant and track the time spent to implement specific parts, as well as the delays incurred for different reasons. This allows for a strong, deliberate optimization of execution time with a measurable, predictable business impact as well as a reliable estimation of these tasks. Discovery projects on the other hand? Yeah. We're pretty good at giving a lower bound for the time necessary by tracking similar tasks in a job. Extending a database entity is going to take a roughly similar time each time. Packaging, downloading and extracting binaries isn't going to differ that much in time from the last 3 times we did that. If you can identify a bunch of similar tasks you've done some time ago already, you can give a lower bound - "The tasks we consider familiar will take about 2 weeks". But after that? Who knows. At that point we're rather estimating by asking: When do you stop feeling silly about it? Do you need a year to do this? A month? Two weeks? A week? A day? So usually we hand our project managers something like "This will take 2 weeks we know, plus 3ish weeks we don't know".
• bitwize 7y ago
  Agile in practice is a way for Corporate to have its cake and eat it too: get the results and productivity associated with outstanding programmers, using the programming talent they have/can hire, with a minimum of risk exposure. Part of this is the attempt (also seen in other corporate quality efforts like ISO9000) to distill skills into process: to produce a book of rules that, rigidly enforced on relatively unskilled workers, will cause them to perform at the level of highly skilled workers. Hence my repeated quip that "Agile is attempting to emulate a good programmer with an array of average programmers". Unfortunately for Corporate, It Just Doesn't Work That Way. Now I believe that Agile was started with good intentions, but today it is much more a motte-and-bailey doctrine. The motte being "Agile is the values in the Agile Manifesto". The bailey being "Agile is Scrum and SAFe, and all these meetings, ceremonies, and process are a necessary component of Agile". And I think this is why people fall into no-true-Agile discussions and eventually end up disappointed with something that showed a lot of promise. Agile started off a plea from programmers to Corporate, and it caught Corporate's ear. But once in Corporate's possession, it was deployed to serve Corporate ends only.
• SkyBelow 7y ago
  >Quit with the local optimizations already, and realize trust is the №1 issue. So how do you trust someone who would outsource your position if they believed it would save money and reduce their work load? Management and employees have an inherently adversarial relationship that is poisonous to trust. I think it can still develop at times, but under our current culture where everyone knows someone whose job was made redundant with little recourse for their employment, you might as well be asking for a coconut to grow in an active lava flow.
• karmakaze 7y ago
  I wish the post visited each of the principles. I can't find one I disagree with. It's all in the interpretation and implementation. Agile for me is not a single methodology that you develop. It's about refining and redefining processes that work for you team and org. Principles behind the Agile Manifesto We follow these principles: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicity--the art of maximizing the amount of work not done--is essential. The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
• jnwatson 7y ago
  In the same way that software is eating the world, software management is eating traditional company management. Software projects are getting more important, sometimes centrally important to the future viability to more and more companies that aren't traditionally software oriented. Software projects are moving up the stack so they touch every part of an organization. Agile is being blamed for problems that are really organizational, company-wide issues that a software team has to deal with because they now are central to how everything runs. The author's suggest to read more general business/organizational management type books is apropos, because the overall goal is agility of the entire organization, not just the software team.
• akkartik 7y ago
  "Stop unfairly putting dev under a microscope and letting everyone else hide in a black box. Why aren’t we just as concerned with how strategy teams operate? Or how legacy architects are constraints in the system?" Are other ladders in an organization not subject to performance review?! Managers? PMs?
  • outworlder 7y ago
    They usually don't get _anywhere near_ as much scrutiny. Dev gets performance reviews _plus_ the microscope.
• perfunctory 7y ago
  The root cause of the problem is that workplace is inherently undemocratic. While we live in democratic societies, we work in feudal organizations. Unless we fix that, nothing will change.
• btilly 7y ago
  Software development has some fundamental challenges that have been faced since the start, and always will. Understanding them matters. Here are some of the big ones. 1. Developers need to communicate with each other. A lot. This takes time. The amount of time goes up non-linearly with the size of the team. (The Mythical Man-Month claims a scaling law of n^2.) 2. Adding process + documentation of various kinds can turn that from unbounded time spent speaking to a large but bounded written effort. 3. Nobody is good at predicting schedules. 4. Good news travels, bad news doesn't (until the last moment). The traditional solution was to solve #1 with #2, put a lot of effort into schedules for #3, and get blindsided over and over again by #4. The average result was that the average delivered software project took over 2x what was estimated, cost over 2x, and was delivered with under half the promised features. But, no matter how delayed, usually didn't start slipping the promised deadline until about 2 weeks before the first official release deadline. And these were the success stories, since most software projects never really got delivered. What Agile opened up was the perspective that there were other approaches possible. For example we can solve #1 by having small teams, which makes #2 unnecessary, solve #3 by making projects small enough to not need good prediction, which creates a feedback loop to avoid #4. And that is not the only valid tradeoff. But this is not a one size fits all. Real world data shows that a team hits peak throughput at 5-8 people, declines, and doesn't get back to the same overall throughput until 20+. (After which it is almost linear, but with much lower individual productivity.) The teams as drawn on the org chart don't matter. The teams as they actually interact, do. If you understand your options, and understand the tradeoffs, you can figure out how to customize the right solution to the people/organization. If you don't understand the tradeoffs, the best that you can do is blindly copy what worked somewhere else and pray that you got it right. And if it turns out that you didn't, develop superstitions about what you should have done instead.
• amai 7y ago
  Agile works since 1947 at Toyota: https://en.m.wikipedia.org/wiki/The_Toyota_Way https://en.m.wikipedia.org/wiki/The_Toyota_Way
• petemill 7y ago
  It is a balance: We don't know how long something we've never done before is going to take, and at the same time, we often need some time boundaries so we don't go off tangent building some wildly ambitious re-write of the world. Perhsps the qustion we ask in projects shouldn't be "how long will this take?" but: "How long do you want to spend on this problem?".
• inlined 7y ago
  I’ve been a tech lead for 6 years and Agile has given me a lot of imposter syndrome because I can’t seem to make it work for me. The biggest point for our org is to cost work items and realize a consistent throughput for our team on which we can make scheduling predictions. Unfortunately my tasks tend to be nebulous. They involve investigating very large potential systems and breaking out smaller tasks, many of which won’t be fully understood till we’re in the trenches. How do I cost the time it takes to learn how Spanner will handle my design and update architecture accordingly? How do I cost “interrupt driven” work like getting buyoff on a given architecture? One of my OKRs was literally “Create a security model for a new foundational technology that is acceptable to all integrators, follows Google Cloud best practices, and can be represented in Kubernetes.” How would you break that into (bi)weekly sprints? You don’t even know what work you’ll have to do until you go to a committee of stakeholders and get told where you have to go back to the drawing board.
  • inlined 7y ago
    To expand a little, since the org wants accurate estimates we need to accurately measure throughout and the total quantity of work. Though throughout trends stabilize pretty quickly, the system falls apart when one task reveals another. Accurately breaking down and costing every sub task at sub-week granularity for a multi-year project is an almost insurmountable task. It requires effectively doing all the work in your head. I’ve seen one compromise and benefit to the system: Compromise: push back on scheduling until the date you give for coming up for a date of completion. This works best during the final phases of development. Benefit: with weekly throughput info, it’s easy to tell if someone is trying to do too much in a sprint.
  • keithnz 7y ago
    See, this is about agile going wrong.... back in the early days of XP, a term started popping up "Brain Engaged", meaning that you don't blindly follow perscribed processes. The manifesto tried to capture this in somewhat frilly language. So be agile ( not in the dogmatic process sense of Agile with a capital 'A'). You have to do something like "create a security...blah blah". You don't have to do anything bi weekly, what you need is a way of of doing that where you can get feedback as soon as possible, how do you iterate through possibilities and arrive at a good decision? how do you involve the people who need to be involved in a way that you get good contribution? How do you make it so it is robust, how do you progressively work towards the goal while minimizing risks and failing fast? If nothing else, the core of agile is feedback loops and communication with the various people involved at a rate that people need.
• chiefalchemist 7y ago
  > "So let’s get on board with continuous learning, and let’s stop pretending Agile was some sort of cure all." Did anyone - who has seen shiney new panaceas come and go - believe it was a cure all? What it is, like MVP, is a way to mitigate risk. It doesn't eliminate risk. It can only mitigate it. Furthermore, it still boils down to team and people. No tool will save a dysfunctional team. The key isn't the tool. The key is the key agreeing on the tool, and sticking to it. That is, tool is not a proxy for deep and solid team work.
• musicale 7y ago
  There is a similar problem in the research world; the work must be genuinely novel (and fundamentally unpredictable), but funding organizations such as NSF/NIH/etc. demand a timetable and specific deliverables. The problem is usually solved in three important ways: 1) making the deliverables as vague as humanly possible 2) promising experiments and not results 3) applying for grants for work that you have already completed, and using the money to work on the next grant's project The problem of having deadlines that are too far out is mitigated somewhat by the pressure to publish. Publishing has fixed deadlines but somewhat flexible deliverables.
• rb808 7y ago
  I think most of the people who wrote the agile manifesto said "Agile" been warped into something they don't agree with. Its supposed to empower teams, not enforced from on high to increase pressure on teams. Heres's a good one by Dave Thomas. A quote: "Agile is an adjective not a noun". https://www.youtube.com/watch?v=a-BOSpxYJ9M https://www.youtube.com/watch?v=a-BOSpxYJ9M
• arendtio 7y ago
  > How does the first line of the Agile Manifesto begin? It is kinda funny. For me the first line has always been: > Individuals and interactions over processes and tools And when I am asked to explain Agile, that is always at the core of my message. Form a team, let them do their work and start learning how they can improve how they do it. From my perspective, the primary role of a (software development) Project Manager/Scrum Master is to create an environment where the team can optimize itself while not drifting into personal conflicts (create a healthy environment for collaboration and feedback). Everything else, like planning/risk management/change management/stakeholder management/reporting/presenting come afterward. Those other things are important too (and should not be skipped completely), but if the team doesn't work, most of the other tasks create little value.
• ngngngng 7y ago
  Most of my complaints about agile have centered around estimates. I'm of the opinion that anyone claiming to give accurate estimates for software development is a liar. But I would like to see an organization that only had the team lead give estimations. This would remove the temptation on individual team members to size too large and fill the time, while also keeping management happy that they're receiving estimates for tasks they requested. Measuring throughput would immediately become a lot more natural since team members wouldn't fall into the trap of "When a measure becomes a target, it ceases to be a good measure." I was actually just rejected from a job I applied to since I voiced a few small concerns with agile/scrum in the interview. My friend that joined that company recently reported he was doing maybe 10% of the work he and I were doing before he left my team. Even though I aced the technical portion they didn't want to risk hiring me since I asked their willingness to flex the rules of scrum.
• LeonigMig 7y ago
  Great rhetorically, not sure how comprehensible the logic was.
• thrownaway954 7y ago
  I just always double what I think it will take. I've been doing software now for 20 years and I have NEVER seen something come in on time. If I think it will take a month, I say it will take two. This has saved me more than I can count since I pad for the unseen circumstances that will occur.
• mizchief2 7y ago
  The whole point of Agile is to force the entire organization to recognize the fact that we don't know how long it will take to crate a satisfactory product. That doesn't mean just dev time but also figuring out what you want it to actually do throughout the process. Instead of thinking you can write a perfect requirements document, then can just design and build it (waterfall) doesn't work. The idea that you can have any sort of meaningful estimate even when you don't have perfect requirements is insane. Having an estimate with perfect requirements doesn't even work. The most effectivly analogy I've used lately is: "Take your car to a mechanic and say "My car is making a funny noise, how long will it take to fix?" and see what kind of response you get"
• alexanderdou 7y ago
  Perhaps I've just always been extraordinarily lucky, but I've never heard the developers I work with complain about our Pointing and Development cycle (and I'd like to think I do try my best to 1) proactively ask them for feedback and 2) recognize and squelch any of my own reactionary defensiveness that comes from feedback). One thing I see a lot in the comments is about time estimates and the amount of pressure that that brings and the rarity in which it works. In my teams we NEVER talk about time of delivery with Engineering. I've always been trained to think of pointing as an estimate of "complexity" (e.g. 1 point is roughly the complexity associated with a copy change). Then, by getting a track record of historical points completed in a week, we can transform our way from feature => complexity => time.
  • t0mbstone 7y ago
    Complexity only matters if it can be correlated to time. For example, if you ask someone to transcribe 10,000 pages of text, and you know that they type 60 words per minute, and that there are an average of 300 words per page, then you can estimate that it will take approximately 833 hours to transcribe. If we followed your method of estimating stories strictly by complexity, however, this is clearly only a one pointer story. After all, there is nothing complex at all about the dull task of rote transcription, and all quantities are known and established. When people talk about "complexity" in software development, what they are really talking about is how certain they are in their knowledge about all the things they have to touch. The more things they have to touch, and the more things they are unfamiliar with, the more things can unexpectedly go wrong. Each task should really receive two estimates: 1. How long do you think this will take? 2. How certain are you of this estimate, given all the factors you are aware of? That would be too much work, though, so people condense this into a single point value and hope for the best.
• mixmastamyk 7y ago
  So, Agile solved one problem when requirements are less than clear. Small batch sizes improve responsiveness, costing a bit of throughput. Like the old kernel HZ setting. Now you've got 99 problems, and responsiveness ain't one. Yet folks expect Agile to solve everything for some reason, and forget all the other issues around bags of meat working together. Those continue to need handling and still get out of control at times.
• sureaboutthis 7y ago
  People get far more done if they spend less time labeling things and thinking there's a new canned technique that's better than what's been done before.
• ChrisCinelli 7y ago
  “I estimate that 75% of those organizations using Scrum will not succeed in getting the benefits that they hope for from it . . . Scrum is a very simple framework within which the “game” of complex product development is played. Scrum exposes every inadequacy or dysfunction within an organization’s product and system development practices. The intention of Scrum is to make them transparent so the organization can fix them. Unfortunately, many organizations change Scrum to accommodate the inadequacies or dysfunctions instead of solving them.” This was Ken Schwaber, co-creator of Scrum. 10 years ago. Ten years after, things did not get a lot better for big corporations that were born with leaders used to waterfall. I agree with almost everything in this article and I completely agree with what Tootie wrote above: "The fundamental problem that drives most agile failures isn't in the team's execution, it's in the business' expectations. One side is signed up for incremental delivery, and one side is set up for a fixed scope and deadline and the result is misery." As the article rightly noticed being Agile is not just building faster. It is delivering "value faster". That also means: "do not build what does not need to be built" and every 2 weeks be willing to scratch what you have worked on. Instead in most of the big companies the business people present shiny objects to the leadership and their goals is to build those shiny objects. Nobody wants to say: "We were wrong". The result is a few projects were people worked for 1 year and then the project is abandon. Even if the idea was good, nobody wants to work on little improvements. It seems that Agile, Scrum, and most of classic agile lingo have a bad connotation for most of the people in these days. Some (over) simplifications that were made to make Agile easier to adopt ended up making things worse. People in big corporations are used to the "flavor of the month" Most of the people really do not look for a revolutions there. They are just looking to how they can seem smart to impress their bosses and being promoted. That how Scrum got in. And that is why it will never realize its full potential there. They do not want to change how they think and how they do things. I run a pretty successful team inside a bigger organization. I wanted to use story points. Start from scratch and have the team get a sense for what 1 point is. And my boss really wanted us to use story points. He only had one requirement we had to use this equation 1 story point = 1/2 day of work... Trying to explain him that one of the reason you use story points in the first place is to stay away from time did not go anywhere. All the other teams were using that equation and we could not be the only team that was not to using it. Frankly speaking, I think it is hard to work at the "inter-team" level if you cannot use the same unit. That's why in Agile you want truly autonomous teams. But big organization were not organized in that way. So you need to re-organize the company in a different way... but assuming there is the desire, who is going to drive that change? Who is going to take the risk of changing something that work in some way in a way that is not going to work too well for a few months? In my humble opinion, it is almost impossible to change an existing a waterfall organization and make Agile work inside of it. Only a leader with a lot of trust by everybody in the company and a lot of courage may be able to make it work. Most of the people that hate Scrum, Kanban or other flavor of Agile had experience with a "Cargo Cult" Agile preached in big companies and usually end up thinking that Agile is sooo screwed up. A big corporation will usually embrace embracing some things that usually really help (ex: standup meetings) and change a ton of other things that will make things worse. You like the Agile mindset, you are going to be a lot more successful if you start from scratch with new young people or people that really want to commit to make things great. For a new organization is easy to start with a simple "Agile template" and make sure that the team is really onboard with a continuous improvement mindset. Keeping regular retrospectives will make things evolve quickly in the right way.
• bassman9000 7y ago
  *And while we’re at it, we’ve got to stop treating dev teams like they work in a factory." Beautiful
• dnprock 7y ago
  I personally found that a good methodology: each team member has clear area of ownership/responsibility. John does X, Jane does Y, Ann tests X, Jeff tests Y. Everyone logs their own tasks. We define and work towards a sprint. No elaborate planning, no estimates. The peer pressure is enough to get everyone moving. Managers often tell me that my process is chaotic. They want more visibility and deterministic completion dates. We adopt Agile process. Now we have long sprint meetings. I think we get less done.
• todd8 7y ago
  In addition to the difficulty in making a meaningful estimate, I'm frustrated by how often management really wants to hear a particular answer and won't settle for anything but that answer. It can go like this: 1. Developers size development of X and says it will take roughly 12 months. 2. Management says the rest of the organization is going into system test in 9 months and needs X finished by then. Couldn't there be some way of speeding up the development of X without impacting the rest of the organization? 3. X's developers say no, not really. Now management tries one or more of the following: -- find someone else to size the work that X's developers will be expected to do -- hire some outside "expert" to size X -- hire contract programmers that claim to be experts in X that will join the X team -- suggest reduced functionality for X -- propose some modified "streamlined" component testing for X -- promise to provide X's required dependencies ahead of their scheduled completion dates so X's development won't be gated by these requirements Now jump back to step 1. Repeat until X's team relents and says that maybe, just perhaps they might be able to finish X in 9 months if everything goes perfectly even though the company has never done X before This is now passed up the management chain and it becomes part of the official overall system's schedule that planning, marketing, sales, finance, etc. is depending on. Iterating over all of these estimates is a big waste of time. Management has already decided that they want X in the system and will keep pushing until an estimate comes back that they accept. If X's team is lucky, some other team will fail to make their estimated completion date and X will end up with the 12 months it might take to finish X. Every team in the organization is hoping that it will be a different team that first has to admit that they will not make their date. This causes a kind of game of chicken where every manager is unwilling to be the first to admit that their team is going to miss it date. Consequently, every date in the organization cannot be relied upon. The distributed file system needs the TCP stack to be finished on time, but the TCP stack needs the ethernet device drivers to be finished on time and no one will admit slippage of any dates first.
  • tra3 7y ago
    > -- suggest reduced functionality for X Limiting the scope in a reasonable matter should reduce dev time, no? Assuming it's a true reduction in scope and not just lipstick on a pig..