6 ms·

What makes agile software development agile?

14 points by azhenley 5y ago

alexfromapex 5y ago
Could someone summarize since it’s paywalled?
- chrisseaton 5y ago
  > Could someone summarize You mean you want some kind of abstract?
  - alexfromapex 5y ago
    No I mean the pay-walled content that I can't access
    - chrisseaton 5y ago
      The abstract is a summary. The abstract isn't behind the paywall.
- azhenley 5y ago
  The abstract is a good summary and isn't paywalled.
PicassoCTs 5y ago
The abandonment of hierarchy. Hierarchy is what poisons communication pathways and destroys the "updates" of the production goals through communication with the customers. Domain-castles start to come up, turning into silos, making it necessary to "enforce" communication via process-pathways. Agile was and in my eyes still is, the anti-thesis to anyone in it for the prestige, the power and control. Its the difference between "Military Orders" based hierarchical command and Mission based command.
- bartread 5y ago
  Absolute drivel. Lack of an appropriate and evolving structure in a growing organisation promotes chaos, miscommunication, and - probably the worst of these - cliques. You structure your organisation around the needs of the business and its markets, and you structure the touchpoints you need for feedback from those markets into that - you need to be intentional about all of this because it doesn't just magically happen.
  - PicassoCTs 5y ago
    Can you even imagine, what this sort of comment, costs us, in PR-work, in trust by the customers, in what the HN-company represents to the world? You do not say such things out here in public, you go through the proper channels, and i do not want to hear this "initiative" nonsense. If a comment is not approved by the comment-committee, we do not post it. Just because some startups work hyper-productive with everyone a shareholder principles- that does not scale to us. I do not want to have this discussion again, happily ever after. Clean up your act, proof that your comment is worth the time to engage, and then, when you earned your spurs, maybe then, we can have this talk about that precious hierarchy of yours. Just because hierarchy are the arcade chips, most large companies pay their loyal hordes, does not auto-instill a value to the company into it. If that were that way, there would not be a constant need to buy those little, "flatland" startups - with the money the hierarchy-galley earned by rowing.
    - bartread 5y ago
      > precious hierarchy of yours. I didn't say hierarchy, I said structure. There are many different ways to structure an organisation, which will vary according to growth, size, needs, and many other factors. If you want your organisation to function well it's worth putting in the time on structure.
giantg2 5y ago
"What makes agile software development agile?" Management saying so. Just my experience.
- simonbarker87 5y ago
  My last place would talk about agile approaches while having a very obviously waterfall project plan time line up on the screen.
  - goldcd 5y ago
    I think the two can co-exist. There's a lovely Jira plugin (portfolio), that'll project a waterfall/gantt chart out of teams backlog. I can definitely see the benefit of having long term visibility of when big features will be available to go to market. No customer cares about a flat backlog. Where it does horrifically wrong, is when somebody who doesn't like the projection decides to ignore agile to correct it. "I'll just remove this dependency, I'll increase this teams capacity arbitrarily etc." I think there are many methodologies that would work - I think every problem comes from somebody trying to corrupt the rules of the approach.
- hereforphone 5y ago
  Management read an O'Reilly book with 'Agile' in the title
- deleted 5y ago
  [deleted]
- goldcd 5y ago
  imho - What makes something agile, is getting a financial buffer applied to budgets, so a developer can spend an extra day building what's needed, rather than what was asked for, with the minimum of management overhead.
cgrealy 5y ago
"Development", (i.e. specifying, writing, testing and deploying software) can frequently be made agile. But 90% of the time, it's pointless since the business isn't agile. You have layers of management from the CEO through dept heads to unit leaders etc, and then you hit the actual devs/QAs/POs, etc... and agile starts here.
- lumost 5y ago
  When you get down to it, what does this even mean? What would an agile CEO do that made him agile? Would they change their mind on how the company was structured every 2 weeks? Or what the quarter’s priorities were? At the end of the day product development involves shipping improvements that matter in a reasonable timeframe. Usually this means that someone, somewhere has to manage a roadmap and make sure that people are getting the dedicated focus time to deliver major improvements over prolonged periods of time.
  - planet-and-halo 5y ago
    The main thing would be scoping and funding projects. Basecamp is a good example: they organize their projects in six-week increments, scoping them so that they are achievable in that time frame. Most companies fund and scope on much longer time frames where they commit upfront to delivering something, frequently without understanding the actual complexity involved.
SV_BubbleTime 5y ago
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".
jrm4 5y ago
Okay, so maybe I'm an old man, but I have a hard time looking at all these newfangled project management strategies (agile, scrum, waterfall, whatever) and it just seems like literally all of them are patchwork responses to the organization fundamentally being in limbo as to whether they are creating a product, working on a project (meaning, a thing that has a start and an end) or providing a service, which by definition doesn't fit well with "project management."
- walshemj 5y ago
  Waterfall was developed in the 50's and Agile Early 90's
- anotherhue 5y ago
  IMO, classical projects had a goal, an end. Modern dev work is often exploratory (in the user sense) so has to be grown. Or less kindly, the sponsors don't know what they want, so we do a lot of hill climbing instead of going directly to our target.
compiler-guy 5y ago
Success makes a project agile. Because if you thought you were using Agile development practices, and your project fails, the Agile partisans will tell you that you weren't really doing Agile; you implemented it not right. At least in my experience.
- Eikon 5y ago
  I heard this one a lot: "The issue is not the process, it's your implementation".
  - SV_BubbleTime 5y ago
    “No one has tried real communism yet.”
ransom1538 5y ago
Agile. Everything is due Friday. Dev: "WELL! I can't finish this by friday!" Ok well divide it in two parts, make first part done by friday. The second part goes in backlog. PM: "When is everything going to be done!!?" Answer: Friday. "What about X and Y in the backlog." Plan it for next sprint. Important part: Monday we re-group with PMs,POs figure out what is most important to work on this new sprint BY showing them FUNCTIONAL code that was finished the last sprint. There are no "roadmaps", no long term plans, it is due Friday.
- goldcd 5y ago
  I like the idea of technical debt - and think this is overlooked if you think of agile as top-down. Say if dev produce code that technically ticks your boxes, but they think there's an issue/oversight. Ideally you'd pick up the flaw, but letting them create an issue to track it is really important. Opportunity team (as I'm embracing the methodology) should take this debt as inputs, in the same way they would a screaming customer or pointy-haired-boss's ppt. #edit - If somebody commits to deliver something by end of sprint, I want to see it end of sprint. If they need to work the weekend to do it, then they work the weekend (and yes, I do know I sound like a dick). The reason why this is OK, is that commitment should only ever come from dev. I might like it to be done in a day and have no idea why it will take a week, but if I'd told it will take a week, it'll take a week and that's what does onto any projection.
goldcd 5y ago
My take as a PdO is that Agile is great for evolving an existing product. You know where you are, you know where you want to go (what customers are asking for), and you can break the transition into discrete steps. Can sit with the dev team and say in 6 months we want to be roughly here - and then tell them what you want to see in 2 weeks. If they deliver on commitment in 2 weeks, they've done their job, and everything else is on me. If they tell me there's a problem, or point out some stupid mistake I've made - I can take that on board (new stories, new prioritization), and explain to everybody above why there's a delay. Thing that I love most of all, is "we could make this better if". Hands down the things I'm most proud of, are when dev tells me something elegant and wonderful can be produced and I can say yes. Two places I think agile can go wrong: 1) Used where it shouldn't be. If there is some complex multi-year piece of work, somebody (product or architects) need to understand the vision. Nothing great is made 2 weeks at a time in isolation, and then presented 2 years later. 2) There needs to be slack in the system. To me the shining benefit of agile is that you can meander away from "the big plan" and add value where you see it. MVP should be say 70% of effort, with 30% we can all choose to use wisely. A complex system built from only MVP is going to be a turd.
indymike 5y ago
To me, agile means there is an expectation that the product will change as it is developed.
xkcd-sucks 5y ago
In externally facing communications re: client services, it's just plain English (which may or may not be true): "We follow an agile methodology": "We will accept arbitrary requests to project scope" "We have a RESTful API": "Our ad-hoc HTTP API is not stressful to use"

14 points by azhenley 5y ago

alexfromapex 5y ago

Could someone summarize since it’s paywalled?

chrisseaton 5y ago
> Could someone summarize You mean you want some kind of abstract?
- alexfromapex 5y ago
  No I mean the pay-walled content that I can't access
  - chrisseaton 5y ago
    The abstract is a summary. The abstract isn't behind the paywall.
azhenley 5y ago
The abstract is a good summary and isn't paywalled.

PicassoCTs 5y ago

The abandonment of hierarchy. Hierarchy is what poisons communication pathways and destroys the "updates" of the production goals through communication with the customers. Domain-castles start to come up, turning into silos, making it necessary to "enforce" communication via process-pathways. Agile was and in my eyes still is, the anti-thesis to anyone in it for the prestige, the power and control. Its the difference between "Military Orders" based hierarchical command and Mission based command.

bartread 5y ago
Absolute drivel. Lack of an appropriate and evolving structure in a growing organisation promotes chaos, miscommunication, and - probably the worst of these - cliques. You structure your organisation around the needs of the business and its markets, and you structure the touchpoints you need for feedback from those markets into that - you need to be intentional about all of this because it doesn't just magically happen.
- PicassoCTs 5y ago
  Can you even imagine, what this sort of comment, costs us, in PR-work, in trust by the customers, in what the HN-company represents to the world? You do not say such things out here in public, you go through the proper channels, and i do not want to hear this "initiative" nonsense. If a comment is not approved by the comment-committee, we do not post it. Just because some startups work hyper-productive with everyone a shareholder principles- that does not scale to us. I do not want to have this discussion again, happily ever after. Clean up your act, proof that your comment is worth the time to engage, and then, when you earned your spurs, maybe then, we can have this talk about that precious hierarchy of yours. Just because hierarchy are the arcade chips, most large companies pay their loyal hordes, does not auto-instill a value to the company into it. If that were that way, there would not be a constant need to buy those little, "flatland" startups - with the money the hierarchy-galley earned by rowing.
  - bartread 5y ago
    > precious hierarchy of yours. I didn't say hierarchy, I said structure. There are many different ways to structure an organisation, which will vary according to growth, size, needs, and many other factors. If you want your organisation to function well it's worth putting in the time on structure.

giantg2 5y ago

"What makes agile software development agile?" Management saying so. Just my experience.

simonbarker87 5y ago
My last place would talk about agile approaches while having a very obviously waterfall project plan time line up on the screen.
- goldcd 5y ago
  I think the two can co-exist. There's a lovely Jira plugin (portfolio), that'll project a waterfall/gantt chart out of teams backlog. I can definitely see the benefit of having long term visibility of when big features will be available to go to market. No customer cares about a flat backlog. Where it does horrifically wrong, is when somebody who doesn't like the projection decides to ignore agile to correct it. "I'll just remove this dependency, I'll increase this teams capacity arbitrarily etc." I think there are many methodologies that would work - I think every problem comes from somebody trying to corrupt the rules of the approach.
hereforphone 5y ago
Management read an O'Reilly book with 'Agile' in the title
deleted 5y ago
[deleted]
goldcd 5y ago
imho - What makes something agile, is getting a financial buffer applied to budgets, so a developer can spend an extra day building what's needed, rather than what was asked for, with the minimum of management overhead.

cgrealy 5y ago

"Development", (i.e. specifying, writing, testing and deploying software) can frequently be made agile. But 90% of the time, it's pointless since the business isn't agile. You have layers of management from the CEO through dept heads to unit leaders etc, and then you hit the actual devs/QAs/POs, etc... and agile starts here.

lumost 5y ago
When you get down to it, what does this even mean? What would an agile CEO do that made him agile? Would they change their mind on how the company was structured every 2 weeks? Or what the quarter’s priorities were? At the end of the day product development involves shipping improvements that matter in a reasonable timeframe. Usually this means that someone, somewhere has to manage a roadmap and make sure that people are getting the dedicated focus time to deliver major improvements over prolonged periods of time.
- planet-and-halo 5y ago
  The main thing would be scoping and funding projects. Basecamp is a good example: they organize their projects in six-week increments, scoping them so that they are achievable in that time frame. Most companies fund and scope on much longer time frames where they commit upfront to delivering something, frequently without understanding the actual complexity involved.

SV_BubbleTime 5y ago

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".

jrm4 5y ago

Okay, so maybe I'm an old man, but I have a hard time looking at all these newfangled project management strategies (agile, scrum, waterfall, whatever) and it just seems like literally all of them are patchwork responses to the organization fundamentally being in limbo as to whether they are creating a product, working on a project (meaning, a thing that has a start and an end) or providing a service, which by definition doesn't fit well with "project management."

walshemj 5y ago
Waterfall was developed in the 50's and Agile Early 90's
anotherhue 5y ago
IMO, classical projects had a goal, an end. Modern dev work is often exploratory (in the user sense) so has to be grown. Or less kindly, the sponsors don't know what they want, so we do a lot of hill climbing instead of going directly to our target.

compiler-guy 5y ago

Success makes a project agile. Because if you thought you were using Agile development practices, and your project fails, the Agile partisans will tell you that you weren't really doing Agile; you implemented it not right. At least in my experience.

Eikon 5y ago
I heard this one a lot: "The issue is not the process, it's your implementation".
- SV_BubbleTime 5y ago
  “No one has tried real communism yet.”

ransom1538 5y ago

Agile. Everything is due Friday. Dev: "WELL! I can't finish this by friday!" Ok well divide it in two parts, make first part done by friday. The second part goes in backlog. PM: "When is everything going to be done!!?" Answer: Friday. "What about X and Y in the backlog." Plan it for next sprint. Important part: Monday we re-group with PMs,POs figure out what is most important to work on this new sprint BY showing them FUNCTIONAL code that was finished the last sprint. There are no "roadmaps", no long term plans, it is due Friday.

goldcd 5y ago
I like the idea of technical debt - and think this is overlooked if you think of agile as top-down. Say if dev produce code that technically ticks your boxes, but they think there's an issue/oversight. Ideally you'd pick up the flaw, but letting them create an issue to track it is really important. Opportunity team (as I'm embracing the methodology) should take this debt as inputs, in the same way they would a screaming customer or pointy-haired-boss's ppt. #edit - If somebody commits to deliver something by end of sprint, I want to see it end of sprint. If they need to work the weekend to do it, then they work the weekend (and yes, I do know I sound like a dick). The reason why this is OK, is that commitment should only ever come from dev. I might like it to be done in a day and have no idea why it will take a week, but if I'd told it will take a week, it'll take a week and that's what does onto any projection.

goldcd 5y ago

My take as a PdO is that Agile is great for evolving an existing product. You know where you are, you know where you want to go (what customers are asking for), and you can break the transition into discrete steps. Can sit with the dev team and say in 6 months we want to be roughly here - and then tell them what you want to see in 2 weeks. If they deliver on commitment in 2 weeks, they've done their job, and everything else is on me. If they tell me there's a problem, or point out some stupid mistake I've made - I can take that on board (new stories, new prioritization), and explain to everybody above why there's a delay. Thing that I love most of all, is "we could make this better if". Hands down the things I'm most proud of, are when dev tells me something elegant and wonderful can be produced and I can say yes. Two places I think agile can go wrong: 1) Used where it shouldn't be. If there is some complex multi-year piece of work, somebody (product or architects) need to understand the vision. Nothing great is made 2 weeks at a time in isolation, and then presented 2 years later. 2) There needs to be slack in the system. To me the shining benefit of agile is that you can meander away from "the big plan" and add value where you see it. MVP should be say 70% of effort, with 30% we can all choose to use wisely. A complex system built from only MVP is going to be a turd.

indymike 5y ago

To me, agile means there is an expectation that the product will change as it is developed.

xkcd-sucks 5y ago

In externally facing communications re: client services, it's just plain English (which may or may not be true): "We follow an agile methodology": "We will accept arbitrary requests to project scope" "We have a RESTful API": "Our ad-hoc HTTP API is not stressful to use"