5 ms·

The problem is that such an organizational change not just exposes the problem: it makes it worse. The intention also usually isn't "let's make things visible".

by cateye 13y ago

The problem is that such an organizational change not just exposes the problem: it makes it worse. The intention also usually isn't "let's make things visible". So, the unintended consequence is that things are amplified. And no, in such a situation this will not feel like progress. I don't suggest more planning. I suggest more profound thinking before changing things. Edit: you edited your comment.

amouat 13y ago
But why pick on Agile? The organisations clearly had problems that needed to be addressed which went beyond software methodologies. Should they choose a waterfall development model because it might hide the problems better in the short term? I agree that more thought may be required. But that has nothing to do with Agile. If anything Agile should be commended for bringing the problems into focus.
- cateye 13y ago
  Agile vs. Waterfall is a false dichotomy. The problem is that Agile approaches are perceived and promoted as a solution for these kind of problems. And I don't see well known Agile consultants do anything to change this view. That's why I wrote this.
  - wpietri 13y ago
    For all X, most X consultants see X as a solution for your problem, almost without regard to the problem. That isn't an Agile problem, except to the extent that Agile is the flavor of the moment. It's a problem with the industry. And really, with people in general. Many people want to buy magic beans. Some people will sell magic beans, either because they are cynical jerks (which is rare) or because they don't understand beans all that well (which is common). That doesn't make beans bad.
  - amouat 13y ago
    Right, so the problem is actually with false promotion and not with Agile at all. If you picked on the people or the culture making these claims it would make more sense to me. You spend time explaining why Agile can't solve a problem no methodology could solve, which seems rather pointless.
- SDGT 13y ago
  Agile and Waterfall, buzzwords in the same class in my world. It's an odd thing to witness; when management finds a new cure-all for their software development and IT management woes (in my place, these concepts have been extended to DBA's, BA's, Cognos jockeys, etc), as there is an almost childlike enthusiasm and loyalty to this new silver bullet concept. I feel like the rift occurs right about here, and the blinders go on for the suits while developers and other plebes shake their heads in disgust, as another wave of "paradigm shifting management strategies" sweep their inboxes with mandatory training meetings and promotional material from Gartner and the likes. The biggest issue is that we all want the same thing: Good Software Development, but the business environment seems to hammer technical workers with the same insanity wrapped in a new packaging, sold down the line from some haughty focus group that contracted an outside company for a $100k "Agile training package". The only place I've ever managed to get past all of this cruft is when freelancing with a small team directly with a client; this has never happened at my day job. Never do we worry about specific methodologies, just three people coding and skype / irc / email with clients. Treat people like humans, and learn to say no when appropriate. Good software development is just organized, civil cooperation.
  - taproot 13y ago
    I cant recall the quote but someone once said the best devepopment methodology was to hire a bunch of 10x developers, lock them in a room with a mission statement and leave them to their own devices. The problem with that is not much unlike waterfall, it provides little to no transparencyfor the employing party, very little accountability and almost no meaningful measureability.
    - UK-AL 13y ago
      "I cant recall the quote but someone once said the best devepopment methodology was to hire a bunch of 10x developers, lock them in a room with a mission statement and leave them to their own devices." This is why the majority of start ups fail. Developers have a ridgid vision of product, and then they spend 6/7 months building that product and then at the end you find out no one actually wants that product. Even though the product is good, its just solves a problem no ones interested in. You need have system to actually work discover if you are creating value. You need something to hold yourself accountable. In reality most successful start ups have a phase of constant learning, just to discover who are their customers, and what they place value on. And they normally have various metrics to hold themselves accountable. The best way I have encountered is agile development with experiments to find out what customers actually need. Then metrics to see how people react to changes. If your vision isn't going anywhere, then you need a fundamental rethink which again needs to be tested.
reinhardt 13y ago
How is more "profound thinking" different from more planning?
- jamiecurle 13y ago
  Profound thinking may involve asking "why are we doing this?", "what else could we do?" or "what if we don't do this at all?" More planning (at least to me) sounds like "let's break this down into a list of tasks that need doing". Basically profound thinking sounds like the creative exploration of the idea (and surrounding ideas) as opposed to a dogmatic execution of an idea.
wpietri 13y ago
If people are capable of more profound thinking, I'm all for it. But most people don't think in a vacuum; they think when forced by circumstances. And then what they think about are the obvious sources of pain and the obvious actors. From what I've seen, using scary stories to encourage people to think harder before experimenting just increases fear and inertia. That lengthens feedback loops that are usually too long already. I'd much rather people just try something thoughtfully now and learn from it.

by cateye 13y ago

amouat 13y ago

But why pick on Agile? The organisations clearly had problems that needed to be addressed which went beyond software methodologies. Should they choose a waterfall development model because it might hide the problems better in the short term? I agree that more thought may be required. But that has nothing to do with Agile. If anything Agile should be commended for bringing the problems into focus.

cateye 13y ago
Agile vs. Waterfall is a false dichotomy. The problem is that Agile approaches are perceived and promoted as a solution for these kind of problems. And I don't see well known Agile consultants do anything to change this view. That's why I wrote this.
- wpietri 13y ago
  For all X, most X consultants see X as a solution for your problem, almost without regard to the problem. That isn't an Agile problem, except to the extent that Agile is the flavor of the moment. It's a problem with the industry. And really, with people in general. Many people want to buy magic beans. Some people will sell magic beans, either because they are cynical jerks (which is rare) or because they don't understand beans all that well (which is common). That doesn't make beans bad.
- amouat 13y ago
  Right, so the problem is actually with false promotion and not with Agile at all. If you picked on the people or the culture making these claims it would make more sense to me. You spend time explaining why Agile can't solve a problem no methodology could solve, which seems rather pointless.
SDGT 13y ago
Agile and Waterfall, buzzwords in the same class in my world. It's an odd thing to witness; when management finds a new cure-all for their software development and IT management woes (in my place, these concepts have been extended to DBA's, BA's, Cognos jockeys, etc), as there is an almost childlike enthusiasm and loyalty to this new silver bullet concept. I feel like the rift occurs right about here, and the blinders go on for the suits while developers and other plebes shake their heads in disgust, as another wave of "paradigm shifting management strategies" sweep their inboxes with mandatory training meetings and promotional material from Gartner and the likes. The biggest issue is that we all want the same thing: Good Software Development, but the business environment seems to hammer technical workers with the same insanity wrapped in a new packaging, sold down the line from some haughty focus group that contracted an outside company for a $100k "Agile training package". The only place I've ever managed to get past all of this cruft is when freelancing with a small team directly with a client; this has never happened at my day job. Never do we worry about specific methodologies, just three people coding and skype / irc / email with clients. Treat people like humans, and learn to say no when appropriate. Good software development is just organized, civil cooperation.
- taproot 13y ago
  I cant recall the quote but someone once said the best devepopment methodology was to hire a bunch of 10x developers, lock them in a room with a mission statement and leave them to their own devices. The problem with that is not much unlike waterfall, it provides little to no transparencyfor the employing party, very little accountability and almost no meaningful measureability.
  - UK-AL 13y ago
    "I cant recall the quote but someone once said the best devepopment methodology was to hire a bunch of 10x developers, lock them in a room with a mission statement and leave them to their own devices." This is why the majority of start ups fail. Developers have a ridgid vision of product, and then they spend 6/7 months building that product and then at the end you find out no one actually wants that product. Even though the product is good, its just solves a problem no ones interested in. You need have system to actually work discover if you are creating value. You need something to hold yourself accountable. In reality most successful start ups have a phase of constant learning, just to discover who are their customers, and what they place value on. And they normally have various metrics to hold themselves accountable. The best way I have encountered is agile development with experiments to find out what customers actually need. Then metrics to see how people react to changes. If your vision isn't going anywhere, then you need a fundamental rethink which again needs to be tested.

reinhardt 13y ago

How is more "profound thinking" different from more planning?

jamiecurle 13y ago
Profound thinking may involve asking "why are we doing this?", "what else could we do?" or "what if we don't do this at all?" More planning (at least to me) sounds like "let's break this down into a list of tasks that need doing". Basically profound thinking sounds like the creative exploration of the idea (and surrounding ideas) as opposed to a dogmatic execution of an idea.

wpietri 13y ago

If people are capable of more profound thinking, I'm all for it. But most people don't think in a vacuum; they think when forced by circumstances. And then what they think about are the obvious sources of pain and the obvious actors. From what I've seen, using scary stories to encourage people to think harder before experimenting just increases fear and inertia. That lengthens feedback loops that are usually too long already. I'd much rather people just try something thoughtfully now and learn from it.