5 ms·

I think there's a fundamental misunderstanding of agile. Agile isn't Scrum, agile isn't Kanban, Agile isn't even really the manifesto. Agile is, like lean manuf

by cwyers 7y ago

I think there's a fundamental misunderstanding of agile. Agile isn't Scrum, agile isn't Kanban, Agile isn't even really the manifesto. Agile is, like lean manufacturing (one of its inspirations), based around one really simple concept: the workers know the most about what they are doing and should be leading the charge on what they are doing. If your agile ceremonies end up being all about giving management control -- if your story points are used to tell management how much work is getting done, if management is using the daily standup to make sure people are on-task instead of being about commitments. If agile is just another way for management to exert control over software development, rather than being about ceding control to software developers, it won't "work." This is the same thing you see with lean/TPS, by the way. The joint GM/Toyota venture showed that without committing to these principles, adopting parts of TPS don't really deliver the full benefits.[1] As one UAW team leader said about why working for Toyota was preferable to GM: > The GM system relied on authority. People with rank, the managers, ruled regardless of their competence or the validity of what they were saying. It was basically a military hierarchy. At NUMMI rank doesn't mean a damn thing. Standardized work means we all work the objectively best way to do the job, and everyone does it that way. I might make some minor adjustments because of my height, for example, but I follow the procedure as laid out because it makes sense. We're more like a special forces unit than the regular military hierarchy. Management's delegated responsibility to the people who do the work, and that gives workers a sense of pride in their jobs. If management is asking the developers to adopt agile, but they aren't doing anything to adopt agile themselves, good luck. 1) https://www.researchgate.net/publication/245862516_Democratic_Taylorism_The_Toyota_Production_System_at_NUMMI https://www.researchgate.net/publication/245862516_Democrati...

throwaway55554 7y ago
> If your agile ceremonies end up being all about giving management control -- if your story points are used to tell management how much work is getting done, if management is using the daily standup to make sure people are on-task instead of being about commitments. If agile is just another way for management to exert control over software development, rather than being about ceding control to software developers, it won't "work." This is exactly what it has become though. It's not about developers, it's about managers and product owners. It's about numbers in a spreadsheet that managers can show upper managers. Management has sucked the life out of agile. It's become this rigid metric producing muck that gets in the way.
- cwyers 7y ago
  Bad management is Nosferatu: it's a blood-sucker by design. If you take Dracula out of the Carpathian Mountains and move him to Carfax Abbey, Dracula is not going to stop being a blood-sucker, he's just going to start drinking Lucy and Mina's blood. Agile is, to my mind, more likely to get you to the right place than something like waterfall. But all the methodology in the world won't save you if management is bad. Putting the blame in the right place is a good place to start, though. If you're living through a bad agile process, saying "I hate bad management" puts the blame in a more correct place than "I hate agile."
  - dragonwriter 7y ago
    Agile was a reaction against particular problems in management, the Agile manifesto is directed at them on a conceptual level, but the Agile body of work (unlike Lean) has largely avoided solutions to the problem Agile is a reaction against and largely consists of solutions to lower-level problems that take for granted that the high level problem is already solved. Which is why it seems to “work well” in young organizations with relatively small, hands-on engineering-heavy teams without several layers of non-technical (in practice, regardless of past experience) management—those aren't the places where the problems tend to exist in the first place.
  - jboy55 7y ago
    I'm going to steal your quote. Sometime I equate the near constant complaint about Agile processes with a hypothetical set of engineers complaining about a 'baseball' process. "The 'Baseball process' sucks because our psychopathic managers beat us with the bats to get us to work harder. If only we switched to the "soccer" process, things would get better because there's nothing for them to hit us with, they'll just punch and kick us. "
    - cafard 7y ago
      https://ronjeffries.com/xprog/articles/jatbaseball/ https://ronjeffries.com/xprog/articles/jatbaseball/
dragonwriter 7y ago
> Agile is, like lean manufacturing (one of its inspirations), based around one really simple concept: the workers know the most about what they are doing and should be leading the charge on what they are doing. The difference between the Agile literature and the Lean literature (including Lean Software Development, which has its own body of literature separate from Agile) is that almost nothing labeled “Agile” actually addresses that central value (except the Manifesto, which does so at a conceptual but not actionable level). It all just skips to concrete decontextualized practices of exactly the sort that the Manifesto’s “people and interactions over processes and tools” is a reaction against, while the Lean body of work actually addresses (without narrow prescriptivism) higher level meta-processes and practices which empower workers to drive the process of evaluatibg and adapt the low-level work processes to acheive business value. Agile is basically the values of Lean accidentally recast in less-concrete way which empowers the kind of management consultant snake-oil solution vendors that it was a reaction against. While there are some decent ideas about low-level practices that are worth considering once you have the appropriate Lean organizational culture in place under the Agile banner, the body of work under that banner is mostly a distraction from the goals it notionally serves; better to ignore it all and focus on Lean than to make it front and center.
wool_gather 7y ago
Similar musings under the "Dark Scrum" heading by Ron Jeffries: > Every day, the team is supposed to get together and organize the day’s work. [... The ScrumMaster ...] knows his job. His job is to stay on top of what everyone is doing, make sure they’re doing the right things, and redirect them if they’re not. How convenient that there’s a mandatory meeting where he can do that, every single day! > In practice the Dark Sprint Review begins by someone reminding everyone what the team “promised” to do. (That is, what was demanded right before the team said “We’ll try”. That’s a promise, isn’t it?) Then we look at the pitiful failure the team brings us. https://ronjeffries.com/articles/016-09ff/defense/ https://ronjeffries.com/articles/016-09ff/defense/
- hinkley 7y ago
  If I keep up my training regimen, within two years I’ll be able to leap across the conference table and backhand the guy using the word “commitment” before he gets the last syllable out. It’s important to have goals.
  - wool_gather 7y ago
    Unfortunately in my case that's my manager, who I like quite a bit except when we discuss Scrum.
lbatx 7y ago
> If your agile ceremonies end up being all about giving management control -- if your story points are used to tell management how much work is getting done, if management is using the daily standup to make sure people are on-task instead of being about commitments. Story points being used for the team and to tell management how much work is being done are not mutually exclusive. I'm also not sure of your distinction between "on-task" and "commitments". If I've made a commitment, there are some tasks that need to be performed to meet that commitment, no?
- cwyers 7y ago
  In a daily standup, it should be about commitments _to your teammates_, not to management. In other words, Bob needs to do X before Alice can do Y, so Bob commits to Alice about his work on X. If there's problems, they can talk about it. That's not the same as some middle manager coming in and going, you need to do X to hit some KPI.
- kyllo 7y ago
  > Story points being used for the team and to tell management how much work is being done are not mutually exclusive. That's the thing though, in reality they really are mutually exclusive. As soon as management starts using a metric to measure the team's performance, that metric stops being useful for the team to improve itself, because now there is a perverse incentive to inflate the metric to get performance rewards.
  - cwyers 7y ago
    Yes. Goodhart's Law: "When a measure becomes a target, it ceases to be a good measure." As soon as management starts looking at story points, it's a scramble to get the most points possible in a sprint (or at least, to not let velocity go down).
    - jboy55 7y ago
      I had a VP, new to my company, come to me and say, 'Your velocity is pathetic, at my last company my engineers were doing 14-16 points a sprint, yours are only doing 8-10'. I tried to explain how that wasn't a thing and we could just start doubling our points. He seemed to indicate that's what I should do ... I started looking.
hef19898 7y ago
Just today I read a quote on Lean. It was Substance of lean vs. form of lean. And that only a minority is actually having the substance. Guess that applies to Agile as well.

by cwyers 7y ago

throwaway55554 7y ago

> If your agile ceremonies end up being all about giving management control -- if your story points are used to tell management how much work is getting done, if management is using the daily standup to make sure people are on-task instead of being about commitments. If agile is just another way for management to exert control over software development, rather than being about ceding control to software developers, it won't "work." This is exactly what it has become though. It's not about developers, it's about managers and product owners. It's about numbers in a spreadsheet that managers can show upper managers. Management has sucked the life out of agile. It's become this rigid metric producing muck that gets in the way.

cwyers 7y ago
Bad management is Nosferatu: it's a blood-sucker by design. If you take Dracula out of the Carpathian Mountains and move him to Carfax Abbey, Dracula is not going to stop being a blood-sucker, he's just going to start drinking Lucy and Mina's blood. Agile is, to my mind, more likely to get you to the right place than something like waterfall. But all the methodology in the world won't save you if management is bad. Putting the blame in the right place is a good place to start, though. If you're living through a bad agile process, saying "I hate bad management" puts the blame in a more correct place than "I hate agile."
- dragonwriter 7y ago
  Agile was a reaction against particular problems in management, the Agile manifesto is directed at them on a conceptual level, but the Agile body of work (unlike Lean) has largely avoided solutions to the problem Agile is a reaction against and largely consists of solutions to lower-level problems that take for granted that the high level problem is already solved. Which is why it seems to “work well” in young organizations with relatively small, hands-on engineering-heavy teams without several layers of non-technical (in practice, regardless of past experience) management—those aren't the places where the problems tend to exist in the first place.
- jboy55 7y ago
  I'm going to steal your quote. Sometime I equate the near constant complaint about Agile processes with a hypothetical set of engineers complaining about a 'baseball' process. "The 'Baseball process' sucks because our psychopathic managers beat us with the bats to get us to work harder. If only we switched to the "soccer" process, things would get better because there's nothing for them to hit us with, they'll just punch and kick us. "
  - cafard 7y ago
    https://ronjeffries.com/xprog/articles/jatbaseball/ https://ronjeffries.com/xprog/articles/jatbaseball/

dragonwriter 7y ago

> Agile is, like lean manufacturing (one of its inspirations), based around one really simple concept: the workers know the most about what they are doing and should be leading the charge on what they are doing. The difference between the Agile literature and the Lean literature (including Lean Software Development, which has its own body of literature separate from Agile) is that almost nothing labeled “Agile” actually addresses that central value (except the Manifesto, which does so at a conceptual but not actionable level). It all just skips to concrete decontextualized practices of exactly the sort that the Manifesto’s “people and interactions over processes and tools” is a reaction against, while the Lean body of work actually addresses (without narrow prescriptivism) higher level meta-processes and practices which empower workers to drive the process of evaluatibg and adapt the low-level work processes to acheive business value. Agile is basically the values of Lean accidentally recast in less-concrete way which empowers the kind of management consultant snake-oil solution vendors that it was a reaction against. While there are some decent ideas about low-level practices that are worth considering once you have the appropriate Lean organizational culture in place under the Agile banner, the body of work under that banner is mostly a distraction from the goals it notionally serves; better to ignore it all and focus on Lean than to make it front and center.

wool_gather 7y ago

Similar musings under the "Dark Scrum" heading by Ron Jeffries: > Every day, the team is supposed to get together and organize the day’s work. [... The ScrumMaster ...] knows his job. His job is to stay on top of what everyone is doing, make sure they’re doing the right things, and redirect them if they’re not. How convenient that there’s a mandatory meeting where he can do that, every single day! > In practice the Dark Sprint Review begins by someone reminding everyone what the team “promised” to do. (That is, what was demanded right before the team said “We’ll try”. That’s a promise, isn’t it?) Then we look at the pitiful failure the team brings us. https://ronjeffries.com/articles/016-09ff/defense/ https://ronjeffries.com/articles/016-09ff/defense/

hinkley 7y ago
If I keep up my training regimen, within two years I’ll be able to leap across the conference table and backhand the guy using the word “commitment” before he gets the last syllable out. It’s important to have goals.
- wool_gather 7y ago
  Unfortunately in my case that's my manager, who I like quite a bit except when we discuss Scrum.

lbatx 7y ago

> If your agile ceremonies end up being all about giving management control -- if your story points are used to tell management how much work is getting done, if management is using the daily standup to make sure people are on-task instead of being about commitments. Story points being used for the team and to tell management how much work is being done are not mutually exclusive. I'm also not sure of your distinction between "on-task" and "commitments". If I've made a commitment, there are some tasks that need to be performed to meet that commitment, no?

cwyers 7y ago
In a daily standup, it should be about commitments _to your teammates_, not to management. In other words, Bob needs to do X before Alice can do Y, so Bob commits to Alice about his work on X. If there's problems, they can talk about it. That's not the same as some middle manager coming in and going, you need to do X to hit some KPI.
kyllo 7y ago
> Story points being used for the team and to tell management how much work is being done are not mutually exclusive. That's the thing though, in reality they really are mutually exclusive. As soon as management starts using a metric to measure the team's performance, that metric stops being useful for the team to improve itself, because now there is a perverse incentive to inflate the metric to get performance rewards.
- cwyers 7y ago
  Yes. Goodhart's Law: "When a measure becomes a target, it ceases to be a good measure." As soon as management starts looking at story points, it's a scramble to get the most points possible in a sprint (or at least, to not let velocity go down).
  - jboy55 7y ago
    I had a VP, new to my company, come to me and say, 'Your velocity is pathetic, at my last company my engineers were doing 14-16 points a sprint, yours are only doing 8-10'. I tried to explain how that wasn't a thing and we could just start doubling our points. He seemed to indicate that's what I should do ... I started looking.

hef19898 7y ago

Just today I read a quote on Lean. It was Substance of lean vs. form of lean. And that only a minority is actually having the substance. Guess that applies to Agile as well.