7 ms·

This matches my experience. We recently brought on a couple of PM consultants who are deep into Agile as a methodology, and decided to give it a go -- it's bee

This matches my experience. We recently brought on a couple of PM consultants who are deep into Agile as a methodology, and decided to give it a go -- it's been about six months now and productivity has basically ground to a halt as we spend more and more meeting time endlessly sorting tasks into different little arbitrary piles instead of actually making forward progress. It's made communication with the non-software part of the company much more difficult, because they keep getting hung up on the jargon; we have to slice up tasks arbitrarily to get them to fit into "sprints," which go out of date minutes after the morning standup when the first non-planned bug report lands. Sizing is frequently an exercise in post-facto book-cooking: 'How long will that bug take to fix?' is like asking 'How long is it going to take to answer 23 across in next Sunday's crossword puzzle?' It might be fifteen seconds, it might take all day; until I have a chance to look at the puzzle I'm just pulling numbers out of my ass. The short timeframes encourage everyone to twiddle around the edges of things instead of doing real feature development; the arbitrary milestones serve mostly to make everyone feel like they're constantly falling behind. I've discussed this with a bunch of people. Everyone seems to agree that we're doing Agile wrong, but even the strongest proponents of the methodology seem to be in complete disagreement on what the "right" way to do it is, or how that would be an improvement over the way we were doing things before. So yeah. Not a fan.

throwaway1979 12y ago
"Productivity ground to a halt for six months" My experience feels the same way. I am beginning to think Agile works for UI dev and small teams of inexperienced folks building relatively simple projects. If you have a large team building something complex, the constant meetings and tool updates destroy productivity. What's worse ... they destroy developer morale if you are actually a good dev IMHO.
- UK-AL 12y ago
  It's roughly 2-4 hours worth of meetings in 2 weeks. That "destroys" productivity?
  - jackmaney 12y ago
    Only 2--4 hours? I wish.
  - jjoonathan 12y ago
    No, incentivizing small tasks that look good in standups over larger, less-sexy tasks kills productivity.
  - zimpenfish 12y ago
    I've been in standups that lasted an hour a day. That'll destroy your morale pretty damned quick.
    - wilsynet 12y ago
      They are doing it wrong. 8 people should not take an hour to say: What did I do yesterday, what am I doing today, is there anything blocking me? There should not be a discussion of every point. The only discussion should be "oh let's talk about that impediment after the meeting with a smaller group of people" or "let me follow up with you after lunch". The standup is 10-15 minutes. If it is longer, it needs to be stopped. Period. Non-negotiable.
      - jackmaney 12y ago
        > There should not be a discussion of every point. The only discussion should be "oh let's talk about that impediment after the meeting with a smaller group of people" or "let me follow up with you after lunch". Guess what? Those things are still meetings. They still take up actual time that could be spent on getting shit done.
        lostcolony 12y ago
        They don't, however, involve everyone. The standup does. That's key. If person A needs to talk to person B about an issue, and it's done in standup, it wastes person C, D, etc's, time, even though they don't need to be involved. Doing it with just the required people is, obviously, required anyway, and the problem a lot of people doing agile have is they end up wasting everyone's time by bringing it up during standup.
- kabdib 12y ago
  The classic success cases for Scrum were projects that had (a) been done before, and (b) been done by the same team. So they had lots of experience. If you ask an assembly-line worker "How long is it going to take you to install this transmission?" they'll be able to tell you within a few seconds. But that's not engineering. If you ask someone who's written essentially the same app five or six times before "How long will it take you to finish feature X?" they'll be able to tell you with pretty high confidence. If you ask someone, "How long is it going to take you to finish designing and implementing that gozzlewog?" they won't have the foggiest idea. Ask them again, when they've re-implemented it a few times, and they'll have an idea then. Until then you can decompose the problem and do analysis on the pieces and make assumptions, but you still won't know how long it'll take until it's done because the industry has been doing this for like 70 years and the one thing we know is that scheduling unknowns and unknown unknowns is still very, very hard. Scrum works if you've done it before. Apply it to green fields or systems with known wicked behavior, and you're likely to fail in quite a few ways, including pissing off your developers and boiling off the good ones for better work environments.
  - madcaptenor 12y ago
    An actual example I've seen: you can ask a field technician "how long will it take to install this piece of equipment in the field?" and get a pretty good answer. You can't ask a data scientist "how long will it take to build a statistical model to predict how long jobs out in the field will take?" and get anything at all useful. And you certainly can't ask "how long will it take to build a statistical model to predict how long it'll take a data scientist to build a statistical model?"...
  - couchand 12y ago
    If you ask someone, "How long is it going to take you to finish designing and implementing that gozzlewog?" they won't have the foggiest idea. That's technically true but not useful. There are much better questions to ask, namely: - Will gozzlewog or foofaraw take longer to implement? - Is the difference minor or is it an order of magnitude? - Will shipping gozzlewog or foofaraw make a bigger impact on the business? - Is that difference small or large? All of theses are easier to estimate and are more useful, too.
progmanal 12y ago
"'How long will that bug take to fix?' is like asking 'How long is it going to take to answer 23 across in next Sunday's crossword puzzle?' It might be fifteen seconds, it might take all day; until I have a chance to look at the puzzle I'm just pulling numbers out of my ass." . I find this attitude to be a little disingenuous. Obviously every bug cannot be estimated perfectly, but the majority of the time there is some initial data to make a reasonable estimate with a margin of error. For instance to name a few: - Past experience with the module associated. - Whether or not it has been reproduced locally. - Similarity to other bugs that have come up in the past.
- jebblue 12y ago
  Some or several of the points you raised probably fit more into the "chance to look into the puzzle" phase so that doesn't really stand to reason against his point 100%.
- outsidetheparty 12y ago
  To be sure. And if we were doing routine maintenance on a longstanding codebase things might be a bit more predictable than they are. But we're trying to do new feature development on a new product, and my experience has been that beyond a very general sense of "this is going to be a big one" vs "this shouldn't take too long, unless I run into something unexpected" -- which is the same level of detail you get with or without Agile -- sizing isn't meaningful enough to be worth the time it takes to do.
- kabdib 12y ago
  Depends on the bug, sure. It's my job [or used to be :-)] to give estimates of bug fix times to management. It usually broke down to: - trivial (about an hour) - nearly trivial (maybe half a day or a day) - "I have no earthly idea". The last one of these that I fixed involved about twenty people, deep dives into our hypervisor and interprocessor communication mechanisms, research into some hardware details and three 100+ hour weeks about four weeks before we shipped. And we started out not having any idea where in the system the problem was (that took two of those weeks).
mklim 12y ago
What was your company doing before switching to Agile?
- jacquesm 12y ago
  Getting stuff done, but in the eyes of management not fast enough. Just guessing but this seems to be the rule. If you really need agile it will not help and if your team already rocks agile won't improve it, likely you'll already be doing something like it but customized to your needs. I've seen a couple of fairly efficient teams utterly ruined by switching to 'agile' and I've yet to see an inefficient team become more efficient by deploying it.
  - davidgerard 12y ago
    "No Silver Bullet" was written in 1986. https://en.wikipedia.org/wiki/No_Silver_Bullet https://en.wikipedia.org/wiki/No_Silver_Bullet One day someone in The Mgt. will read it.
- outsidetheparty 12y ago
  We're a very small team all of whom are skilled senior-level developers, working on a greenfield product. Basically boils down to back end guy, front end code guy, unicorn product designer/ front-end dev, and ops guy. (Agile proponents have told me "Oh, that's exactly the wrong sort of group for Agile, it works best with larger teams of lower-level devs." Other Agile proponents have told me "oh that's the perfect sort of team for Agile, it doesn't work with big teams of juniors.") The way it used to work was: Feature request comes from sales or upper mgt or customer or product designer. Designer does mockups or codes up a simple working prototype. Various team members look at it, we talk about how to implement it, everyone works on it as needed, we deploy it when it's done. If something else comes up in the meantime that's more important or more urgent, we set it aside in a different code branch until there's time to focus on it again. The way it works now is basically exactly the same, except with lots more meetings and jargon and taxonomizing of tasks and arbitrary milestones. (Agile proponents have told me "Oh, you were doing Agile already, you just didn't know it! Other Agile proponents have told me "oh, you're not even doing Agile now." Even its proponents can't seem to agree on what Agile is, which makes it really easy to tell its detractors that it's not Agile's fault, you're just doing it wrong...)
couchand 12y ago
Taking on a new development process in the middle of a project is much harder than starting on a new one. In particular, as you mentioned there's an issue of legacy bugs. There's mounds of information available suggesting strategies for taking care of this, but ultimately you'll be in an unfortunate transition while you're still handling legacy bugs that makes it hard to move forward. Most of my experience with agile is in the XP flavors, where the mantra is no bugs. I know it's hard to believe, but I promise it's an achievable goal if the whole team single-mindedly works towards that goal. You're right, estimating is hard. The thing is, people are actually really good at relative estimation, it's absolute estimation that we completely suck at. That's the idea behind estimating in points: you free yourself from trying to think "how long will this take me?", which you'll inevitably get wrong, to "is this harder or easier than this other thing" which almost always is pretty easy to do.
- jackmaney 12y ago
  > The thing is, people are actually really good at relative estimation, it's absolute estimation that we completely suck at. That's the idea behind estimating in points: you free yourself from trying to think "how long will this take me?", which you'll inevitably get wrong, to "is this harder or easier than this other thing" which almost always is pretty easy to do. That sounds great on paper. However, every implementation of Agile that I've ever seen or heard of eventually translates points to time intervals ("How many points should this be?" "Well, a one day task is three points, so...").
  - lostcolony 12y ago
    Well, then, to give you a piece of anecdotal evidence; my experience where I currently am is that we never talk about how long it'll take, unless it's so small and trivial we can say "Give me an hour and I should have a first pass in place". Even then we're not saying it's ~done~, just that we're familiar enough with the code that we can get some prototypal code in place in a time frame. When actually estimating tasks, it's purely point based, and then those can and do vary with how much time they actually eat up, but tend to average out just fine.
cmdkeen 12y ago
Well there is an interesting concept - you're talking about jargon like "sprints" yet referring to "Agile" which is a very, very broad church. I like Scrum for the power of the retrospective, if people actually talk about issues, the the team really is empowered you can change those problems: a) Talk through how to handle bugs. There is no prescriptive answer, if you have a problem with defects then fix it, or develop a system to deal with them. You don't have to bring a bug into sprint after all, and if you do then get your Project Owner to drop an equivalent bit of work out. b) Refinement is a crucial part of the process, if you can't break up the task into 1/2 weeks worth of work for a team odds are you don't fully understand the task, which means you can't provide forward estimation, which means management can't trust you're numbers. c) "Project Managers" don't exist in Scrum, so a PM consultant guiding you on agile feels very, very wrong. If your organisation can't commit to you working full (pretty much) time on a project working on a set of things that have been committed to without pulling you in another direction then odds are Scrum isn't going to work for you. Scrum is very clear that there are certain things you need to do in order to say you're doing Scrum. Doing "Agile" screams following no particular sub methodology but cobbling something together. There's nothing wrong with that evolving, but it helps to be able to describe why you've gone in that direction. In your case it seems like you've had something foisted on you by external people talking out of their rear.
- outsidetheparty 12y ago
  > If your organisation can't commit to you working full (pretty much) time on a project working on a set of things that have been committed to without pulling you in another direction See, this is the thing: on the one hand it's supposed to be all about committing to a specific direction ahead of time and not letting yourself be pulled somewhere else -- on the other hand it's supposed to be all about developers being empowered to work on what's most important at the moment (I mean it's right there built into the name!) Those seem in direct conflict. We don't have organizational pressure pulling us in different directions -- we have reality pulling us in different directions. I'm not going to tell a customer "no, you can't have that bug fix or that new feature yet, we have a Methodology to follow." > "Project Managers" don't exist in Scrum. Right. Just project owners, product owners, scrum masters.... > In your case it seems like you've had something foisted on you by external people talking out of their rear. I think you're onto something there. (They keep changing their minds, too: one week it's fibonacci sizing, next week it's T-shirt sizes. One week it's scrums, next week it's kanban. The actual working process seems to stay the same, only the jargon shifts around.)
wilsynet 12y ago
A good policy is to not estimate bug fixes, to not associate any points at all with them. It creates a drag on velocity, but it's honest. If you need to fix a bug, it means that you are correcting an error from a past (implicit or otherwise) user story that shouldn't have been accepted as complete anyway.
goostavos 12y ago
>Everyone seems to agree that we're doing Agile wrong The fact that we've all heard this line (yet never heard a solution) should make it pretty clear that it's more of a management religion than an engineering practice. "You're doing it wrong" is the perfect built-in, pre-packaged defense to the Agile system that agile managers/consultants/etc can rattle off with zero effort and an air of superiority. Had a bad experience? Well, you were doing it wrong. It's not an issue with the system. I recently worked at a place that was the text book example of agile/scrum development methodologies -- Which I don't mean figuratively, I mean in the literal sense, their big claim to fame was that they were the subject of a case study on the success of Agile methodologies. So, having worked in a place that was studied for "getting it right," it's extremely annoying to see all critiques of agile had waved away under the flag of "you did it wrong" Just about every complaint in the article existed at this place as well. For me, at the tip top of the list was meetings. Planning would take hours. Sometimes it would be split up over two days. That is two days out of the 10 you have available for development eaten up by talking about what you're going to develop. Then there's a meeting to show what we did in those 10 days. Then another meeting to talk about what we think we did in those 10 days and how it could be better (which was of course done through stupid time wasting games ("I wish I could have ___" "I was happy when ___", "I should start doing ___")) Then layer on top of all that a whole hierarchy of people whose whole job description is to be "agile" -- which not a single developer was able to explain to me the meaning since the day I started. I'm ranting too much, but the whole agile thing just gets under my skin. It's such a massive waste of time. Leaving that company was a happy happy day. I now work at a place where 'planning' takes 15 minutes in front of a white board. Engineering discussions take as long as they need with the relevant parties whenever needed. Other than that, you're left alone to fucking do your job.
- logfromblammo 12y ago
  > ...doing it wrong... Back when I was a wee lad, with nary a keyboard callus upon my digits, I learned about a little thing called Murphy's Law. In brief, it says that if anything can be done incorrectly, someone will eventually do it that way. It was a warning to those designing things, to make doing the wrong thing impossible, or at least much more difficult to do accidentally. As a result, among those taught about Murphy's Law, "doing it wrong" was a design flaw. If, for instance, you could destroy radio reception in a handheld device by holding it in a particular way--a way that did not cause pain or discomfort in an ordinary human hand--it was the fault of the device manufacturer, not the user. If you can do Agile "wrong", then it is a problem with Agile. As for myself, I just think to myself that someone, somewhere, has weaponized an idiot, and has launched it against me. It is equal parts Inspector Clouseau, Mister Gumby, Ali G, Drunken Master, and a particularly evil djinn. He will do exactly what you ask, in the most malicious manner possible. He will follow a process with absolute rigor, and produce the worst possible outcome. I firmly believe that such people actually exist--individuals so brutally incompetent that they are indistinguishable from malicious trolls. So you might as well plan around a person intentionally trying to break your design while still maintaining the plausible deniability of not breaking any of your rules. Agile cannot hold up under the assault of a weaponized idiot. There are simply too many possible attack vectors.
Delmania 12y ago
The problem is your company has no idea of what it's doing. You don't estimate bug fixes or research and development. You time box them, and once you've spent all the time allocated, you report back to your team on your findings. If you can't fix the bug in a sprint, you simply work on it in a later sprint. Second, real feature developments sounds like an epic. Those are stories that will span multiple sprints. There are ways to handle them.
- outsidetheparty 12y ago
  Bug fixes, R&D, and real feature development are the entirety of what we do. If none of those fit into sprints, what is the point of having them? What is the benefit of describing a feature as an epic sliced into stories spanning sprints, instead of just, y'know, getting it done?
  - Delmania 12y ago
    No, they do fit into sprints, quite nicely. Time boxing gives you a deadline and accountability. Using research and development as an example, you go off, spend months researching a new search algorithm, only to come back to hear the customer tell your approach was wrong in restrospect. The sprint mechanism catches that sooner, preferably at the end of a single sprint, then months down the line. It's fail early fail often. Splitting a story into an epic forces the realization the feature is complex, and in many cases, seeing those numbers there quickly turns the feature from a must have into a "nice to have." A key point to agile is that you are presenting the output of your work to the customers at regular defined intervals so the customers can decided if what you're doing it worthwhile. The daily sprints are a mechanism to detect when something is wrong. Fail early, fail often is a fundamental component of agile.
    - outsidetheparty 12y ago
      > Time boxing gives you a deadline and accountability An arbitrary deadline, often forcing you to interrupt your flow and then spend extra time next sprint reorienting yourself to pick up the same task again. And artificial accountability. (Did Alice overrun her time-box because she was lazy? Or because the bug was really tricky? Nobody knows! Is Bob a rockstar, or is he just really good at plausibly over-sizing small tasks? Perhaps!) > you go off, spend months researching a new search algorithm, only to come back to hear the customer tell your approach was wrong in restrospect That's kind of strawmanny. In no methodology should someone be allowed to wander around for months with zero feedback. In "traditional" process the PM is in communication with the customer and keeps enough of a handle on where things stand to be able to pull the brakes when necessary. Agile seems to want to offload that work either into some vague diffusion-of-responsibility within the team, or to the customer herself (which seems bizarrely idealistic) or, most commonly AFAICT, to a de facto PM under another name. > so the customers can decided if what you're doing it worthwhile I have literally never met a customer who didn't want everything right now. A good traditional PM is able to manage those customer expectations. Few developers I've met have those skills or want to be spending their time doing that.
geebee 12y ago
Your analogy to estimating 23 across is pretty amusing. I like it a bit more than the claim that software estimates are like asking how long it will take to detect dark matter (another one I've heard), because honestly, I really shouldn't try to equate my work with something on that scale. That said, I actually think your analogy is, if anything, a bit too optimistic about estimates. In some ways, I'd stretch it to "you're good at puzzles. how long will it take to solve next week's puzzle". You know that puzzles are usually crosswords, sudokus, word scrambles, or chess problems, and you can usually get them, even the hard ones. There's variance, and sometimes you do get stumped, so it's a bit stressful, but at least you have some kind of prior history as a guide. But surprisingly often, it turns out to be something like encountering a rubik's cube for the first time. How long does it take to solve a rubik's cube? Well, once you know how to solve one, it takes less than 5 minutes. How long does it take to figure out how to solve one when you've never encountered it? Well, for some, never. For others, a month? For a few people, a day? But the answer is, it will take me anywhere from 30 minutes to a month to tell you how long it will take me to solve this problem (over 1 month, I give up). Then, my answer will be: 5 minutes.

throwaway1979 12y ago

"Productivity ground to a halt for six months" My experience feels the same way. I am beginning to think Agile works for UI dev and small teams of inexperienced folks building relatively simple projects. If you have a large team building something complex, the constant meetings and tool updates destroy productivity. What's worse ... they destroy developer morale if you are actually a good dev IMHO.

UK-AL 12y ago
It's roughly 2-4 hours worth of meetings in 2 weeks. That "destroys" productivity?
- jackmaney 12y ago
  Only 2--4 hours? I wish.
- jjoonathan 12y ago
  No, incentivizing small tasks that look good in standups over larger, less-sexy tasks kills productivity.
- zimpenfish 12y ago
  I've been in standups that lasted an hour a day. That'll destroy your morale pretty damned quick.
  - wilsynet 12y ago
    They are doing it wrong. 8 people should not take an hour to say: What did I do yesterday, what am I doing today, is there anything blocking me? There should not be a discussion of every point. The only discussion should be "oh let's talk about that impediment after the meeting with a smaller group of people" or "let me follow up with you after lunch". The standup is 10-15 minutes. If it is longer, it needs to be stopped. Period. Non-negotiable.
    - jackmaney 12y ago
      > There should not be a discussion of every point. The only discussion should be "oh let's talk about that impediment after the meeting with a smaller group of people" or "let me follow up with you after lunch". Guess what? Those things are still meetings. They still take up actual time that could be spent on getting shit done.
      - lostcolony 12y ago
        They don't, however, involve everyone. The standup does. That's key. If person A needs to talk to person B about an issue, and it's done in standup, it wastes person C, D, etc's, time, even though they don't need to be involved. Doing it with just the required people is, obviously, required anyway, and the problem a lot of people doing agile have is they end up wasting everyone's time by bringing it up during standup.
kabdib 12y ago
The classic success cases for Scrum were projects that had (a) been done before, and (b) been done by the same team. So they had lots of experience. If you ask an assembly-line worker "How long is it going to take you to install this transmission?" they'll be able to tell you within a few seconds. But that's not engineering. If you ask someone who's written essentially the same app five or six times before "How long will it take you to finish feature X?" they'll be able to tell you with pretty high confidence. If you ask someone, "How long is it going to take you to finish designing and implementing that gozzlewog?" they won't have the foggiest idea. Ask them again, when they've re-implemented it a few times, and they'll have an idea then. Until then you can decompose the problem and do analysis on the pieces and make assumptions, but you still won't know how long it'll take until it's done because the industry has been doing this for like 70 years and the one thing we know is that scheduling unknowns and unknown unknowns is still very, very hard. Scrum works if you've done it before. Apply it to green fields or systems with known wicked behavior, and you're likely to fail in quite a few ways, including pissing off your developers and boiling off the good ones for better work environments.
- madcaptenor 12y ago
  An actual example I've seen: you can ask a field technician "how long will it take to install this piece of equipment in the field?" and get a pretty good answer. You can't ask a data scientist "how long will it take to build a statistical model to predict how long jobs out in the field will take?" and get anything at all useful. And you certainly can't ask "how long will it take to build a statistical model to predict how long it'll take a data scientist to build a statistical model?"...
- couchand 12y ago
  If you ask someone, "How long is it going to take you to finish designing and implementing that gozzlewog?" they won't have the foggiest idea. That's technically true but not useful. There are much better questions to ask, namely: - Will gozzlewog or foofaraw take longer to implement? - Is the difference minor or is it an order of magnitude? - Will shipping gozzlewog or foofaraw make a bigger impact on the business? - Is that difference small or large? All of theses are easier to estimate and are more useful, too.

progmanal 12y ago

"'How long will that bug take to fix?' is like asking 'How long is it going to take to answer 23 across in next Sunday's crossword puzzle?' It might be fifteen seconds, it might take all day; until I have a chance to look at the puzzle I'm just pulling numbers out of my ass." . I find this attitude to be a little disingenuous. Obviously every bug cannot be estimated perfectly, but the majority of the time there is some initial data to make a reasonable estimate with a margin of error. For instance to name a few: - Past experience with the module associated. - Whether or not it has been reproduced locally. - Similarity to other bugs that have come up in the past.

jebblue 12y ago
Some or several of the points you raised probably fit more into the "chance to look into the puzzle" phase so that doesn't really stand to reason against his point 100%.
outsidetheparty 12y ago
To be sure. And if we were doing routine maintenance on a longstanding codebase things might be a bit more predictable than they are. But we're trying to do new feature development on a new product, and my experience has been that beyond a very general sense of "this is going to be a big one" vs "this shouldn't take too long, unless I run into something unexpected" -- which is the same level of detail you get with or without Agile -- sizing isn't meaningful enough to be worth the time it takes to do.
kabdib 12y ago
Depends on the bug, sure. It's my job [or used to be :-)] to give estimates of bug fix times to management. It usually broke down to: - trivial (about an hour) - nearly trivial (maybe half a day or a day) - "I have no earthly idea". The last one of these that I fixed involved about twenty people, deep dives into our hypervisor and interprocessor communication mechanisms, research into some hardware details and three 100+ hour weeks about four weeks before we shipped. And we started out not having any idea where in the system the problem was (that took two of those weeks).

mklim 12y ago

What was your company doing before switching to Agile?

jacquesm 12y ago
Getting stuff done, but in the eyes of management not fast enough. Just guessing but this seems to be the rule. If you really need agile it will not help and if your team already rocks agile won't improve it, likely you'll already be doing something like it but customized to your needs. I've seen a couple of fairly efficient teams utterly ruined by switching to 'agile' and I've yet to see an inefficient team become more efficient by deploying it.
- davidgerard 12y ago
  "No Silver Bullet" was written in 1986. https://en.wikipedia.org/wiki/No_Silver_Bullet https://en.wikipedia.org/wiki/No_Silver_Bullet One day someone in The Mgt. will read it.
outsidetheparty 12y ago
We're a very small team all of whom are skilled senior-level developers, working on a greenfield product. Basically boils down to back end guy, front end code guy, unicorn product designer/ front-end dev, and ops guy. (Agile proponents have told me "Oh, that's exactly the wrong sort of group for Agile, it works best with larger teams of lower-level devs." Other Agile proponents have told me "oh that's the perfect sort of team for Agile, it doesn't work with big teams of juniors.") The way it used to work was: Feature request comes from sales or upper mgt or customer or product designer. Designer does mockups or codes up a simple working prototype. Various team members look at it, we talk about how to implement it, everyone works on it as needed, we deploy it when it's done. If something else comes up in the meantime that's more important or more urgent, we set it aside in a different code branch until there's time to focus on it again. The way it works now is basically exactly the same, except with lots more meetings and jargon and taxonomizing of tasks and arbitrary milestones. (Agile proponents have told me "Oh, you were doing Agile already, you just didn't know it! Other Agile proponents have told me "oh, you're not even doing Agile now." Even its proponents can't seem to agree on what Agile is, which makes it really easy to tell its detractors that it's not Agile's fault, you're just doing it wrong...)

couchand 12y ago

Taking on a new development process in the middle of a project is much harder than starting on a new one. In particular, as you mentioned there's an issue of legacy bugs. There's mounds of information available suggesting strategies for taking care of this, but ultimately you'll be in an unfortunate transition while you're still handling legacy bugs that makes it hard to move forward. Most of my experience with agile is in the XP flavors, where the mantra is no bugs. I know it's hard to believe, but I promise it's an achievable goal if the whole team single-mindedly works towards that goal. You're right, estimating is hard. The thing is, people are actually really good at relative estimation, it's absolute estimation that we completely suck at. That's the idea behind estimating in points: you free yourself from trying to think "how long will this take me?", which you'll inevitably get wrong, to "is this harder or easier than this other thing" which almost always is pretty easy to do.

jackmaney 12y ago
> The thing is, people are actually really good at relative estimation, it's absolute estimation that we completely suck at. That's the idea behind estimating in points: you free yourself from trying to think "how long will this take me?", which you'll inevitably get wrong, to "is this harder or easier than this other thing" which almost always is pretty easy to do. That sounds great on paper. However, every implementation of Agile that I've ever seen or heard of eventually translates points to time intervals ("How many points should this be?" "Well, a one day task is three points, so...").
- lostcolony 12y ago
  Well, then, to give you a piece of anecdotal evidence; my experience where I currently am is that we never talk about how long it'll take, unless it's so small and trivial we can say "Give me an hour and I should have a first pass in place". Even then we're not saying it's ~done~, just that we're familiar enough with the code that we can get some prototypal code in place in a time frame. When actually estimating tasks, it's purely point based, and then those can and do vary with how much time they actually eat up, but tend to average out just fine.

cmdkeen 12y ago

Well there is an interesting concept - you're talking about jargon like "sprints" yet referring to "Agile" which is a very, very broad church. I like Scrum for the power of the retrospective, if people actually talk about issues, the the team really is empowered you can change those problems: a) Talk through how to handle bugs. There is no prescriptive answer, if you have a problem with defects then fix it, or develop a system to deal with them. You don't have to bring a bug into sprint after all, and if you do then get your Project Owner to drop an equivalent bit of work out. b) Refinement is a crucial part of the process, if you can't break up the task into 1/2 weeks worth of work for a team odds are you don't fully understand the task, which means you can't provide forward estimation, which means management can't trust you're numbers. c) "Project Managers" don't exist in Scrum, so a PM consultant guiding you on agile feels very, very wrong. If your organisation can't commit to you working full (pretty much) time on a project working on a set of things that have been committed to without pulling you in another direction then odds are Scrum isn't going to work for you. Scrum is very clear that there are certain things you need to do in order to say you're doing Scrum. Doing "Agile" screams following no particular sub methodology but cobbling something together. There's nothing wrong with that evolving, but it helps to be able to describe why you've gone in that direction. In your case it seems like you've had something foisted on you by external people talking out of their rear.

outsidetheparty 12y ago
> If your organisation can't commit to you working full (pretty much) time on a project working on a set of things that have been committed to without pulling you in another direction See, this is the thing: on the one hand it's supposed to be all about committing to a specific direction ahead of time and not letting yourself be pulled somewhere else -- on the other hand it's supposed to be all about developers being empowered to work on what's most important at the moment (I mean it's right there built into the name!) Those seem in direct conflict. We don't have organizational pressure pulling us in different directions -- we have reality pulling us in different directions. I'm not going to tell a customer "no, you can't have that bug fix or that new feature yet, we have a Methodology to follow." > "Project Managers" don't exist in Scrum. Right. Just project owners, product owners, scrum masters.... > In your case it seems like you've had something foisted on you by external people talking out of their rear. I think you're onto something there. (They keep changing their minds, too: one week it's fibonacci sizing, next week it's T-shirt sizes. One week it's scrums, next week it's kanban. The actual working process seems to stay the same, only the jargon shifts around.)

wilsynet 12y ago

A good policy is to not estimate bug fixes, to not associate any points at all with them. It creates a drag on velocity, but it's honest. If you need to fix a bug, it means that you are correcting an error from a past (implicit or otherwise) user story that shouldn't have been accepted as complete anyway.

goostavos 12y ago

>Everyone seems to agree that we're doing Agile wrong The fact that we've all heard this line (yet never heard a solution) should make it pretty clear that it's more of a management religion than an engineering practice. "You're doing it wrong" is the perfect built-in, pre-packaged defense to the Agile system that agile managers/consultants/etc can rattle off with zero effort and an air of superiority. Had a bad experience? Well, you were doing it wrong. It's not an issue with the system. I recently worked at a place that was the text book example of agile/scrum development methodologies -- Which I don't mean figuratively, I mean in the literal sense, their big claim to fame was that they were the subject of a case study on the success of Agile methodologies. So, having worked in a place that was studied for "getting it right," it's extremely annoying to see all critiques of agile had waved away under the flag of "you did it wrong" Just about every complaint in the article existed at this place as well. For me, at the tip top of the list was meetings. Planning would take hours. Sometimes it would be split up over two days. That is two days out of the 10 you have available for development eaten up by talking about what you're going to develop. Then there's a meeting to show what we did in those 10 days. Then another meeting to talk about what we think we did in those 10 days and how it could be better (which was of course done through stupid time wasting games ("I wish I could have ___" "I was happy when ___", "I should start doing ___")) Then layer on top of all that a whole hierarchy of people whose whole job description is to be "agile" -- which not a single developer was able to explain to me the meaning since the day I started. I'm ranting too much, but the whole agile thing just gets under my skin. It's such a massive waste of time. Leaving that company was a happy happy day. I now work at a place where 'planning' takes 15 minutes in front of a white board. Engineering discussions take as long as they need with the relevant parties whenever needed. Other than that, you're left alone to fucking do your job.

logfromblammo 12y ago
> ...doing it wrong... Back when I was a wee lad, with nary a keyboard callus upon my digits, I learned about a little thing called Murphy's Law. In brief, it says that if anything can be done incorrectly, someone will eventually do it that way. It was a warning to those designing things, to make doing the wrong thing impossible, or at least much more difficult to do accidentally. As a result, among those taught about Murphy's Law, "doing it wrong" was a design flaw. If, for instance, you could destroy radio reception in a handheld device by holding it in a particular way--a way that did not cause pain or discomfort in an ordinary human hand--it was the fault of the device manufacturer, not the user. If you can do Agile "wrong", then it is a problem with Agile. As for myself, I just think to myself that someone, somewhere, has weaponized an idiot, and has launched it against me. It is equal parts Inspector Clouseau, Mister Gumby, Ali G, Drunken Master, and a particularly evil djinn. He will do exactly what you ask, in the most malicious manner possible. He will follow a process with absolute rigor, and produce the worst possible outcome. I firmly believe that such people actually exist--individuals so brutally incompetent that they are indistinguishable from malicious trolls. So you might as well plan around a person intentionally trying to break your design while still maintaining the plausible deniability of not breaking any of your rules. Agile cannot hold up under the assault of a weaponized idiot. There are simply too many possible attack vectors.

Delmania 12y ago

The problem is your company has no idea of what it's doing. You don't estimate bug fixes or research and development. You time box them, and once you've spent all the time allocated, you report back to your team on your findings. If you can't fix the bug in a sprint, you simply work on it in a later sprint. Second, real feature developments sounds like an epic. Those are stories that will span multiple sprints. There are ways to handle them.

outsidetheparty 12y ago
Bug fixes, R&D, and real feature development are the entirety of what we do. If none of those fit into sprints, what is the point of having them? What is the benefit of describing a feature as an epic sliced into stories spanning sprints, instead of just, y'know, getting it done?
- Delmania 12y ago
  No, they do fit into sprints, quite nicely. Time boxing gives you a deadline and accountability. Using research and development as an example, you go off, spend months researching a new search algorithm, only to come back to hear the customer tell your approach was wrong in restrospect. The sprint mechanism catches that sooner, preferably at the end of a single sprint, then months down the line. It's fail early fail often. Splitting a story into an epic forces the realization the feature is complex, and in many cases, seeing those numbers there quickly turns the feature from a must have into a "nice to have." A key point to agile is that you are presenting the output of your work to the customers at regular defined intervals so the customers can decided if what you're doing it worthwhile. The daily sprints are a mechanism to detect when something is wrong. Fail early, fail often is a fundamental component of agile.
  - outsidetheparty 12y ago
    > Time boxing gives you a deadline and accountability An arbitrary deadline, often forcing you to interrupt your flow and then spend extra time next sprint reorienting yourself to pick up the same task again. And artificial accountability. (Did Alice overrun her time-box because she was lazy? Or because the bug was really tricky? Nobody knows! Is Bob a rockstar, or is he just really good at plausibly over-sizing small tasks? Perhaps!) > you go off, spend months researching a new search algorithm, only to come back to hear the customer tell your approach was wrong in restrospect That's kind of strawmanny. In no methodology should someone be allowed to wander around for months with zero feedback. In "traditional" process the PM is in communication with the customer and keeps enough of a handle on where things stand to be able to pull the brakes when necessary. Agile seems to want to offload that work either into some vague diffusion-of-responsibility within the team, or to the customer herself (which seems bizarrely idealistic) or, most commonly AFAICT, to a de facto PM under another name. > so the customers can decided if what you're doing it worthwhile I have literally never met a customer who didn't want everything right now. A good traditional PM is able to manage those customer expectations. Few developers I've met have those skills or want to be spending their time doing that.

geebee 12y ago

Your analogy to estimating 23 across is pretty amusing. I like it a bit more than the claim that software estimates are like asking how long it will take to detect dark matter (another one I've heard), because honestly, I really shouldn't try to equate my work with something on that scale. That said, I actually think your analogy is, if anything, a bit too optimistic about estimates. In some ways, I'd stretch it to "you're good at puzzles. how long will it take to solve next week's puzzle". You know that puzzles are usually crosswords, sudokus, word scrambles, or chess problems, and you can usually get them, even the hard ones. There's variance, and sometimes you do get stumped, so it's a bit stressful, but at least you have some kind of prior history as a guide. But surprisingly often, it turns out to be something like encountering a rubik's cube for the first time. How long does it take to solve a rubik's cube? Well, once you know how to solve one, it takes less than 5 minutes. How long does it take to figure out how to solve one when you've never encountered it? Well, for some, never. For others, a month? For a few people, a day? But the answer is, it will take me anywhere from 30 minutes to a month to tell you how long it will take me to solve this problem (over 1 month, I give up). Then, my answer will be: 5 minutes.