5 ms·

The problem with agile is it is naive. It assumes everyone is acting in good faith and thus it can easily be turned against developers. What I've seen consisten

The problem with agile is it is naive. It assumes everyone is acting in good faith and thus it can easily be turned against developers. What I've seen consistently is managers are willing to turn responsibility over to developers but not control, and yet that's the core tenant of agile, developers are in control. I have never seen a company that practiced agile that did not have deadlines. "Sprints" alone are toxic. To sprint is to exhaust all of one's resources, and rest. When was the last time you were allowed to rest as a developer? Most companies just say, "Sprints start every other Monday". "Respond to changing markets" becomes "managers don't have to plan." "Developers are in control" becomes "all jobs now belong to developers." And finally, the most toxic element of all is the misapplication of agile. Agile works for websites and mobile, THAT'S IT. You cannot plan infrastructure in 2-week increments (yes I've seen this attempted).

jacques_chester 9y ago
> Agile works for websites and mobile, THAT'S IT. From your experience. This is a kind of No True Scotsman. If agile is working on massive multi-team, multi-site, multi-timezone, multi-company projects, then apparently it ain't agile. My experience is different. I've seen it work and not work. Right now I'm seeing it work. It works well; the core of which is asking what's sucking and how we can fix it.
- maxxxxx 9y ago
  "the core of which is asking what's sucking and how we can fix it." This seems to be a taboo for a lot of managers. They'll do almost anything to avoid listening to their own people and fixing the problems they mention. Only outside consultants or management further up can be listened to but not the people they manage.
  - jacques_chester 9y ago
    I think you're right.
- oceanghost 9y ago
  No, not just from my experience. Logically. The biggest risk in engineering is always the "dealbreaker." Some fundamental philosophical incongruity in the project. Usually, they take the form of a broken invariant. When I was an architect, it was my job to front run my team, management and plan for every conceivable scenario such that I would never have to utter the phrase, "That is not possible." You cannot plan a multi-year project in 2-week increments if I spoke metaphorically about websites / mobile apps-- what I meant was, you cannot design anything that really matters in weekly increments. Imagine trying to design the space shuttle two weeks at a time.
  - jacques_chester 9y ago
    Again, you're creating a No True Scotsman. Cloud Foundry is a multi-million SLOC distributed system developed by dozens of teams over many years, one week at a time. Yet it has an architecture that evolves on a multi-year scale. Nothing in agile precludes architecture. What's precluded is ignoring change. I don't know what else to tell you. A counterexample to your universal claim exists. So it's not universal.
    - oceanghost 9y ago
      ...pivotal... :)
      - deleted 9y ago
        [deleted]
kpil 9y ago
First, I think there is no other reasonable way to run a company than to assume that everyone is acting in good faith. Most people are. Weed out those that consistently are not. Trust but verify. The other remarks are all good responses to "cargo cult" Scrum. No, it's not about death-marching the teams, it's about keeping a sustainable and realistic pace by time boxing activities, and constantly assess the velocity. The end goal is to increase predictability and reduce the number of concurrent activities in all stages of the "delivery pipe". Limiting the Work In Progress is a "Lean" thing. Managers should have a goal and identified the needs, but premature detailed planning should be avoided. (Also a "Lean" thing) "All jobs now belong to developers" is clearly not ideal but probably a reaction to a high ratio of non-developers which is typically not a good thing if the main product or services are software or produced by software. I'll give you that dividing complex deliveries with many dependencies can be very hard - you probably can't plan or replace infrastructure in 3-week increments, but measuring and possibly delivering some sort of value in 3-week time-boxes is most likely doable, although realistically you'd probably go live in larger chunks. You still need a plan and most important a goal though. One reason to be a bit fundamentalist here is to challenge the structures within a product or a company - maybe the bottlenecks just get more visible? Is it possible to divide complex behemoths into smaller parts, for instance? Maybe centralized solutions drives down fixed costs while increasing dynamic costs - those are typically much harder to understand.
- oceanghost 9y ago
  Wherever you work, are they hiring? :-)
Nomentatus 9y ago
"Sprint" is such a wonderful example of how Agile can (and has often) been perverted (and in this case, inverted.) What is a sprint in RL? It's a race in which you only go a very short distance. As in: "Wanna run a few miles?", "Nah, let's just do a sprint and leave it at that." But stick-management willfully misinterprets Sprint as a very fast speed implying you should get an immense amount done in a short time by magical means. Which has led to the Agile guys backing off from the word, officially, I do believe. You won't find it in the Alliance Glossary, just "iteration": https://www.agilealliance.org/agile101/agile-glossary/ https://www.agilealliance.org/agile101/agile-glossary/ If overtime by software engineers were not exempted by law in many jurisdictions from being paid, I don't think this willful misinterpretation would happen so often.
- oceanghost 9y ago
  Thank you for your thoughtful reply.

jacques_chester 9y ago

> Agile works for websites and mobile, THAT'S IT. From your experience. This is a kind of No True Scotsman. If agile is working on massive multi-team, multi-site, multi-timezone, multi-company projects, then apparently it ain't agile. My experience is different. I've seen it work and not work. Right now I'm seeing it work. It works well; the core of which is asking what's sucking and how we can fix it.

maxxxxx 9y ago
"the core of which is asking what's sucking and how we can fix it." This seems to be a taboo for a lot of managers. They'll do almost anything to avoid listening to their own people and fixing the problems they mention. Only outside consultants or management further up can be listened to but not the people they manage.
- jacques_chester 9y ago
  I think you're right.
oceanghost 9y ago
No, not just from my experience. Logically. The biggest risk in engineering is always the "dealbreaker." Some fundamental philosophical incongruity in the project. Usually, they take the form of a broken invariant. When I was an architect, it was my job to front run my team, management and plan for every conceivable scenario such that I would never have to utter the phrase, "That is not possible." You cannot plan a multi-year project in 2-week increments if I spoke metaphorically about websites / mobile apps-- what I meant was, you cannot design anything that really matters in weekly increments. Imagine trying to design the space shuttle two weeks at a time.
- jacques_chester 9y ago
  Again, you're creating a No True Scotsman. Cloud Foundry is a multi-million SLOC distributed system developed by dozens of teams over many years, one week at a time. Yet it has an architecture that evolves on a multi-year scale. Nothing in agile precludes architecture. What's precluded is ignoring change. I don't know what else to tell you. A counterexample to your universal claim exists. So it's not universal.
  - oceanghost 9y ago
    ...pivotal... :)
    - deleted 9y ago
      [deleted]

kpil 9y ago

First, I think there is no other reasonable way to run a company than to assume that everyone is acting in good faith. Most people are. Weed out those that consistently are not. Trust but verify. The other remarks are all good responses to "cargo cult" Scrum. No, it's not about death-marching the teams, it's about keeping a sustainable and realistic pace by time boxing activities, and constantly assess the velocity. The end goal is to increase predictability and reduce the number of concurrent activities in all stages of the "delivery pipe". Limiting the Work In Progress is a "Lean" thing. Managers should have a goal and identified the needs, but premature detailed planning should be avoided. (Also a "Lean" thing) "All jobs now belong to developers" is clearly not ideal but probably a reaction to a high ratio of non-developers which is typically not a good thing if the main product or services are software or produced by software. I'll give you that dividing complex deliveries with many dependencies can be very hard - you probably can't plan or replace infrastructure in 3-week increments, but measuring and possibly delivering some sort of value in 3-week time-boxes is most likely doable, although realistically you'd probably go live in larger chunks. You still need a plan and most important a goal though. One reason to be a bit fundamentalist here is to challenge the structures within a product or a company - maybe the bottlenecks just get more visible? Is it possible to divide complex behemoths into smaller parts, for instance? Maybe centralized solutions drives down fixed costs while increasing dynamic costs - those are typically much harder to understand.

oceanghost 9y ago
Wherever you work, are they hiring? :-)

Nomentatus 9y ago

"Sprint" is such a wonderful example of how Agile can (and has often) been perverted (and in this case, inverted.) What is a sprint in RL? It's a race in which you only go a very short distance. As in: "Wanna run a few miles?", "Nah, let's just do a sprint and leave it at that." But stick-management willfully misinterprets Sprint as a very fast speed implying you should get an immense amount done in a short time by magical means. Which has led to the Agile guys backing off from the word, officially, I do believe. You won't find it in the Alliance Glossary, just "iteration": https://www.agilealliance.org/agile101/agile-glossary/ https://www.agilealliance.org/agile101/agile-glossary/ If overtime by software engineers were not exempted by law in many jurisdictions from being paid, I don't think this willful misinterpretation would happen so often.

oceanghost 9y ago
Thank you for your thoughtful reply.