14 ms·

As a developer who has been quite unhappy in Agile environments, I don't actually think Agile is to blame, which the article alludes to. I think the issue with

• ravenstine 7y ago
  It seems like the measurements used by teams shouldn't be available to management because they will inevitably abuse that information.
  • pjmorris 7y ago
    Your observation is right on target, and it has been predicted and validated [0]. The people who originally developed agile understood this, but it's one of the kinds of things that doesn't really sink in in many cases. [0] 'Measuring and Managing Performance in Organizations', Robert Austin, Dorset House, 1996.
  • SkyBelow 7y ago
    But who ensures it isn't? Management who are the ones inherently attracted to having the metric to use? The ones who are able to withstand that pressure and not touch the information are likely the ones would could see the information without using it as a stick. I guess upper management could enforce the separation on a level lower management could not override, but I would assume such cases are rare.
    • apotheon 7y ago
      The solution is to stop blaming the methodology for the failures of management, and just accept that bureaucracy breeds mediocrity. Corporations grow into bureaucracy, inevitably. Choose accordingly when evaluating potential employers. Keep this in mind when running a business.
  • cjblomqvist 7y ago
    I'll bite. Management always seem to get the crap. To summarize, if engineers knew how to manage things better than management, why don't they? From my experience, teams without management seem to complain about that and end up with bad results. There are more factors at play, and honestly it's very rare that the engineers sees that (or even acknowledge that they don't know all the relevant factors, with all the implications that gives). Of course, just as with engineers, there are good and bad managers. But it seems pointless to always complain about management being the ones screwing it up all the time.
    • jamestimmins 7y ago
      Yeah I don't mean to imply that it's managers per se. Management seems suuuuper hard and I wouldn't want the task of assessing engineering productivity. I just mean that the "metrics" put out by Agile give the illusion of something useful to managers. It's totally understandable that folks in positions of authority would attempt to make use of them. But I think the illusion of objectivity is more damaging to teams than the acceptance of uncertainty.
      • ratww 7y ago
        I think it has a lot to do with bargain power. By using things like story points and other metrics intended to be internal to the team, developers have a lot of incentive to not lie on their estimates. On the other hand, management has incentive to push things to be finished quicker. By letting management having access to those metrics, they're automatically at a disadvantage when negotiating timelines and priorities.
      • shantly 7y ago
        I'd say that attempting to use the same tool to help a team communicate with one another and to communicate with management or stakeholders who aren't very close to the project (involved daily near the ground level) is essentially doomed. Management will either hate the answers they get or they'll ruin the tool's utility to the team, resulting in worse communication at every level and slower work. Or both. It's where I think Jira and other do-everything tools that try to be useful to both ICs and management fall down hard, every time I've seen them used. Management wants to see their burndown charts and such. They want projections out months on minimal data. They want to see the performance of people, not teams. Points become BS because everyone knows they're being watched. Totals are missed the first few sprints (of course they are, you're still calibrating WTF a point means for this team and this project!) and management gets pissy, exerts more control, implies ICs are failing at their job, project goes downhill from there. But look, we're Doing Agile! Such professionals we are.
  • hrktb 7y ago
    I am not sure it would even save the situation. Most agile methodologies assume a lot of constants to allow measurements to have any sense at all (for instance scrum assumes teams members are stable, of that knowledge over their work perimeter is good, etc.) We work in a field where inherently there are unknows, and measuring the unknown is not gonna be that useful, however we turn it.
    • apotheon 7y ago
      Scrum always looked to me like pseudo-waterfall with an Agile™ coat of paint.
  • LanceH 7y ago
    The failing after every step has been when they close the loop. That is, agile is used to score and measure velocity. This velocity is then used to impact future scoring. This nullifies Agile's use for measurement since management is now insisting that x number of points be completed per developer per sprint. The places I've had it succeed greatly have all been new development. We consistently scored stories. Product owners could then had a budget equal to the team's velocity to purchase from the backlog into the next sprint. What it really looked like was they got to arrange the order that the backlog would be picked up and how much would get done in a sprint was an estimate, but with consistent implementation it became eerily accurate over time. It has been my observation that it takes about 6 sprints to calibrate -- where the team scores consistently and the variances from sprints cancel out. Another point of emphasis is that velocity is a team score. Every failing effort I've been involved with used it to score individuals which inevitably ends up in scoring the stories higher so that an individual gets more points. It also results in cherry-picking easy points and ignoring tasks and bug fixes which may result in zero. It also (like bug fixes) results in everything being assigned points such that points become a proxy for time. If you're developing a new system and you have a bug fix, the team has already claimed the points for that bug fix. You should not make more points for the bug fix, your velocity should actually go down, giving a more accurate estimate in the future of how much new system is actually produced and not a measure of how much a programmer has worked. So, measurements should absolutely be available to management. But they shouldn't be used to impact future scoring.
    • apotheon 7y ago
      That assumes really good (measured against the norm) management. If your management is "normal" (or worse), giving management access to that just destroys the whole value of the scoring system. (Always remember that fifty percent is worse than the centerline, to say nothing of the still-within-a-standard-deviation "better" that isn't enough better to matter.)
      • LanceH 7y ago
        It really sounds like a "not true Scotsman" argument, but I've had Agile fail when the team failed to use Agile. As I wrote above, points inevitably became a proxy for time in one manner or another. Production was pinned to a certain number of points (say 15 per developer per sprint). I can't throw it all on management either. People who should know better will accept 2 days worth of points for conducting training or attending a workshop. Largely, though, I would say it's a simple matter of not understanding how Agile works at all. It has just become, "you score points for doing stuff" (in proportion to time, but it's not time, but it is).
• quanticle 7y ago
  I do think that "Agile" is to blame. In my view the Agile software methodology is like Communism or libertarianism. Whenever you point out the myriad ways that it can fail in practice, someone always jumps out to say, "Well, what you're not describing is not true Agile. True Agile has never been tried!"
  • jamestimmins 7y ago
    This is a great point. If there's a tool that no one can figure out how to use properly or effectively, it's hard to argue that the tool is well designed.
    • pflenker 7y ago
      You could say the same about vim though... Jokes aside, many resources about agile start with explaining how agile is “easy to understand, difficult to master”, and I think that’s true.
      • quanticle 7y ago
        The difference is that vim is a specific tool, and if I see someone struggling repeatedly to be effective with vim, I can gently suggest that they try some other tool. But if I see a team repeatedly to implement something that looks like an Agile methodology, what do I tell them? I suspect that many devotees of agile would speak at this point about getting management buy-in, or reforming the wider organization, but at this point "agile" just becomes shorthand for "reform your entire organization from top to bottom so that your management doesn't suck".
        • pflenker 7y ago
          If the team struggles, the org does not need to be changed. However, from my point of view, companies should increase support for their teams when transitioning to agile. Training would be a good start. I have taken a few agile trainings, and they have been among the best I had in my career.
  • 7y ago
• wdfx 7y ago
  But IMO agile is not at all about measuring productivity, I'm not sure how you'd come to that conclusion? There is, I admit, an element of it in the sprint planning, but that is only meant to be a tool to figure out how much work can be put into the next sprint. Agile does not care what your absolute value of velocity is. If however, some misinformed PM is obsessing over velocity then I think that is a very different issues and not really related to the essence of agile.
  • Someone1234 7y ago
    > But IMO agile is not at all about measuring productivity, I'm not sure how you'd come to that conclusion? It wasn't a conclusion it was a summation of what is happening when agile ideas are misused. I've seen it used that way too, it never ends way because nobody can measure a programmer's productivity/effectiveness.
  • chris11 7y ago
    But using agile does change how developers communicate progress to management. So agile processes can definitely indirectly impact how your productivity is perceived and measured.
• onlyrealcuzzo 7y ago
  As a developer become engineering manager become director of product, I agree with you wholeheartedly. But I think the bigger problem is that often developers and management (at all levels) give very little thought into "delivering value" and a lot of thought into "doing whatever they want". I can't fault individuals (workers, management, or executives) for trying to do what's best for their careers rather than what's best for the company. As a manager, I think management's primary objectives are to set up their reports for success and to figure out how to align their reports' incentives with the company's incentives in the best possible way. Management, I have seen, often does a terrible job 1) actually knowing what "value" is, 2) figuring out how to measure that they're actually delivering value, and 3) figuring out how to align delivering value with the worker's own incentives. If you can't do these things, you have NO chance to do agile effectively. It's easy to go through the motions of Agile, but you will gain nothing if you can't define and measure value (and hardly any companies can -- it's not easy!) But as you pointed out, even if you can accomplish the prerequisites, it's still INCREDIBLY difficult to attribute an engineer to value. You can execute effectively, but be on a project that turned out to be useless. Making the button green might be easy, but because of previous technical debt, making it blue might be really hard, etc...
  • nahname 7y ago
    >...problem is that often developers and management (at all levels) give very little thought into "delivering value" That sounds like a cultural problem. From my experience, tools do not solve cultural problems. Leadership changes cultural problems.
    • onlyrealcuzzo 7y ago
      It is. I'm saying that it seems to be a problem at the vast majority of companies of all sizes.
  • markus_zhang 7y ago
    TBH I think it's normal for any person to put their own interest on first priority. The key is to hire people who actually share the same interests. I fully agree with your point actually.
• willis936 7y ago
  I worked in fake agile for a few years. It took me a while to place my finger on why I never really loved everything about it, but I eventually decided that it felt like it was a façade to a management power grab. It gave the ability to micro manage workers to those who don’t understand the problems or even the product. If agile is necessary to be productive then you already have too many people involved. If it isn’t necessary then it introduces a lot of overhead for a little bit of book keeping (which isn’t inherently bad).
  • jfim 7y ago
    It's the burgerization of software development, where every engineer can be turned into a generic fungible burger-flipping engineering unit, and the output measured in the number of burgers flipped. The software architecture is falling apart, the tech debt overshadows the actual debt of a small country, our subject matter expert quit the company over being micromanaged, and the clients are abandoning our buggy software for our competitors? What went wrong, we closed all of those JIRA tickets, surely that must be good for something.
    • meheleventyone 7y ago
      Ticket driven development isn't just an agile issue though. Project management has always loved granular tasks and the assumption that at some point they are all worth the same effort.
    • xpe 7y ago
      I largely agree. I’ll add this — To a large extent, many management systems are about reducing the failure modes — but I don’t see why a system must downplay creativity and deep thinking about the core business engine (often the software).
  • hirako2000 7y ago
    I remember a time I worked with a team not using the agile process. We were agile. When I worked in teams following the agile process, we were rigid. Agile shouldn't be a process, mgt see it as such. It becomes a process. Clever engineers hate poorly thought out processes. Agile as a process is a contradiction in itself. Agile is no process. Let the team find their ways and iterate as often as possible, along with a few other proven principles. Points becomes estimates for managers, they will see it as such and build huge waterfall projects documents to track everthing, and they will pressure teams to deliver shitty software when they feel the stories are sand bagged. Strange world we live in.
• snarf21 7y ago
  Exactly, here are the principles of agile: -- Value individuals and interactions over processes and tools -- Value working software over comprehensive documentation -- Value customer collaboration over contract negotiation -- Value responding to change over following a plan That doesn't sound like "agile" anywhere I've seen it implemented. The issue is that you need real buy-in from all levels of the company for any process. I've always said that a "bad" process executed consistency and with real buy-in will outperform any "good" process with only lip service commitment.
  • arcboii92 7y ago
    The only place I've worked where Agile was like this was, surprisingly, one of New Zealand's major banks. The buy-in for Agile started at the executive level, and they made a call that everything was Agile. Obviously, this would've been an absolute mess for most teams. But my team functioned perfectly. The woman who was our scrum master was originally a project manager in the bank. But with the Agile reshuffle she went over-the-top with her retraining. This was horrible in some areas, where she would follow processes to a T, but she would catch herself, and recognise the importance of those principles. She grew into the role well, and the team was eventually working great!
  • AnimalMuppet 7y ago
    > -- Value individuals and interactions over processes and tools And we're going to do agile! It will be great! How are we going to do so? According to this rigidly-defined process, that's how.
  • genezeta 7y ago
    You know the problem with those principles? They are not a methodology. Most of the problem described in the article -and everywhere- is precisely that "the theory is good but everybody is doing it wrong". But that doesn't really help, because it overlooks the fact that the origin of all this is just a pile of generic, hard-to-argue small-time guru ruminations. I mean, it is not necessarily bad advice: "These are valuable things and we think that in particular these ones are more valuable than those other ones". Okay. Probably. They do look good. Let's say they are. Now what? Oh, that's left as an exercise to the reader. It's funny. Just yesterday I almost had an argument over one of these things. I heard Karen say to the guy on my left that "Agile means less documentation", so I raised my eyebrow. "Agile means less defined documentation, more open, because documentation has no value at all" - she added. I was about to point out that that is not at all what it means, but then she went further and told him that what he needed to do was to "work as a team and become more involved in collaboration". That, right there, is the problem: pretending a bunch of cool sounding expressions can be a substitute for actual things like writing down what they wanted the guy to do.
• jusob 7y ago
  I was in a company that did Agile well (my first time using it). Team velocity was never used to measure the output of the team, only to better predict how much work we could fit in a sprint. The other big think was that they saw Agile as a framework, each team was free to do a different "implementation" and use different tools. Team velociyy had different units in different team and couldn't be compared.
  • apotheon 7y ago
    I worked for an employer that had a different PROCESS.md document in every project repository. At every retrospective, we'd evaluate the process for that project to determine whether it needed updating. It was awesome. Eventually, things changed, but for a while there it was awesome. Things got done well, in reasonable amounts of time, with a lot of attention to quality work. I think the beginning of the end was probably around the time when the company (a software development consultancy) started using fine-grained hourly measures of time pre-sold to clients. This started happening around the time investors in certain clients got more involved in trying to dictate company policy, and I'm pretty sure it was all part of an attempt by investors to ensure there were "better metrics" for evaluating their investments. You can't measure something without it directly affecting the measured thing's state. In this case, it started having detrimental effects on almost everything. Previously happy and productive devs started burning out, mediocre devs became new management favorites, more bugs got into production, projects suffered under less and less reasonable goals (including at one point my task effectively being to solve one of the Hard Problems of software dev -- cache invalidation), and so on. In the US, management culture seems to have a monomaniacal focus on metrics. (I'd say "simplistic metrics", but the way they use them guarantees they're always simplistic.) This is driven, in part, by bureaucratization, which is in turn driven by a bunch of other things (mostly stemming from politics, directly or indirectly) in our business culture. Many managers would complain that without metrics they can't evaluate team productivity, individual value to the organization, and other important stuff, and they're right. The solution is not to double down on those metrics obsessions, though; it's to replace those managers with managers who are capable of effective, qualitative evaluation, instead of the almost purely quantitative approach that holds the high ground.
• darkstar_16 7y ago
  This is absolutely correct. For example, what is the point of a sprint in Agile ? Do what one can finish in a sprint but try and finish "modules" while maintaining quality and carry over rest to next sprint. What does management read? Finish ... modules ... current sprint?
• RankingMember 7y ago
  You've hit the nail squarely on the head. The problem with Agile isn't Agile itself, but the fact that humans can't keep themselves from using the data it produces to their own non-Agile ends.
  • geebee 7y ago
    But maybe Agile is the source of problem with Agile. Agile, to me, is like the nitroglycerine of development methodologies. The explosive instability of Agile isn't a problem from outside that corrupts Agile - it arises from the methodology itself, which inherently invites abuse.
• vosper 7y ago
  > for folks in management roles, the opportunity to 'score' engineers based on Agile metrics is too attractive. One nice thing about this is that the metric is visible. Then you can optimise your performance against it. Is this necessarily productive, or in the real interests of the company? Maybe, maybe not. But I look at this as a kind of a favour: if your boss is complaining "velocity is too low" well, at least you know what you're being measured by. Put some extra points on those stories. Undercommit. Make your boss happy and get them off your back. You'll be doing the same work either way.