4 ms·

I should probably read the whole paper if I get the time… having been BURNED on hiring an “agile” development company recently. > increasing degrees of agility

I should probably read the whole paper if I get the time… having been BURNED on hiring an “agile” development company recently. > increasing degrees of agility This I can certainly agree with. But from my experience “agile” is code for ”we aren’t going to consider the future AT ALL, we’ll be paid to redo all this work”. I’m sure my experience is an outlier but I was managing an outside company to work on an App for us, not being in our wheelhouse at all. What we paid for what we received haunts me. I have never seen such poorly thought out, poorly documented, and just barely working code turned in as from this group that was touted for their excellence and speed. It was all disposable code. Nothing mattered because it was all supposed to be rewritten, at ridiculous hourly costs. Speed sure. But you know what, it’s like anything else and good in moderation. The abstract mentions only 15% of their data points were “true” agile and I get think I get why. Sometimes you need to think ahead and from what I’ve seen agile is bad at that. You’re just supposed to pay for duplication of work, when the forethought might have been the better asset allocation.

walshemj 5y ago
I wonder if the early 1994 project (SWIFT) I did with BT is in there - I know there was a presentation done at the IEEE on the Project.
goodpoint 5y ago
> ”we aren’t going to consider the future AT ALL, we’ll being paid to redo all this work”. This seems to be standard practice especially around modern "devops tools" * Release very often and very early * Break backward compatibility every 6 months at least * Completely ignore reliability, security and defensive programming at first. Rewrite everything over time. * Deprecate and replace major feature every year Essentially end users have no choice other than upgrade on every new release and fix the breakage.
galaxyLogic 5y ago
I think the whole movement is based somewhat on confusion since there seems to be no clear agreement on how we should measure "agility". Yes they can say that they are agile but if there is no way to measure that, there is no way to know if that is true or not. There are many good ideas in "agile" however. The idea behind doing things fast (and loose) is that you will fast get feedback, about whether what you are doing is the correct thing or not. Now when you realize that that what you are doing is not the right thing, that is when "agility" is needed. How easy will it then be to change what you are doing? If it is easy then your "degree of agility" is high. If not then no. And still, it's very hard to measure your "degree of agility".
- lumost 5y ago
  How often is the rapid customer feedback just that the product sucks because it was built poorly?
  - galaxyLogic 5y ago
    Good point. And then, if you truly are agile it should be easy and fast to fix those problems.
ransom1538 5y ago
"What we paid for what we received haunts me. I have never seen such poorly thought out, poorly documented, and just barely working code " I would have tried using agile practices. You would have seen the code that first Friday and raised your hand and stopped more production. Instead, it sounds like you waited for things to be done, later found out it was crap, then wanted a redo (not agile). Agile has sprints, with weekly checkins, you would have found all this out that first sprint and given feedback.

walshemj 5y ago

I wonder if the early 1994 project (SWIFT) I did with BT is in there - I know there was a presentation done at the IEEE on the Project.

goodpoint 5y ago

> ”we aren’t going to consider the future AT ALL, we’ll being paid to redo all this work”. This seems to be standard practice especially around modern "devops tools" * Release very often and very early * Break backward compatibility every 6 months at least * Completely ignore reliability, security and defensive programming at first. Rewrite everything over time. * Deprecate and replace major feature every year Essentially end users have no choice other than upgrade on every new release and fix the breakage.

galaxyLogic 5y ago

I think the whole movement is based somewhat on confusion since there seems to be no clear agreement on how we should measure "agility". Yes they can say that they are agile but if there is no way to measure that, there is no way to know if that is true or not. There are many good ideas in "agile" however. The idea behind doing things fast (and loose) is that you will fast get feedback, about whether what you are doing is the correct thing or not. Now when you realize that that what you are doing is not the right thing, that is when "agility" is needed. How easy will it then be to change what you are doing? If it is easy then your "degree of agility" is high. If not then no. And still, it's very hard to measure your "degree of agility".

lumost 5y ago
How often is the rapid customer feedback just that the product sucks because it was built poorly?
- galaxyLogic 5y ago
  Good point. And then, if you truly are agile it should be easy and fast to fix those problems.

ransom1538 5y ago

"What we paid for what we received haunts me. I have never seen such poorly thought out, poorly documented, and just barely working code " I would have tried using agile practices. You would have seen the code that first Friday and raised your hand and stopped more production. Instead, it sounds like you waited for things to be done, later found out it was crap, then wanted a redo (not agile). Agile has sprints, with weekly checkins, you would have found all this out that first sprint and given feedback.