7 ms·

>Agile is a good case study for how good ideas get perverted quickly by consultants and companies. The points made in the Agile Manifesto having me nodding my

>Agile is a good case study for how good ideas get perverted quickly by consultants and companies. The points made in the Agile Manifesto having me nodding my head in agreement more often than not. But the implementations, like Scrum, are another matter entirely. It has become a management methodology, further and further removed from the developers. And that comes complete with all of the trappings you'd expect: process for the sake of process, empty metrics (like "velocity") that can be passed up the management chain, and so on.

hashkb 9y ago
Can you say more about how velocity is an empty metric? I'm an IC, sometimes tech lead, (e.g. not management) and j have always found it indispensable.
- another-dave 9y ago
  Velocity is too often used as a stick to beat people with — "Team B is doing 15 more points that you"; "Last month, we were doing an extra 5 points every sprint, but now we've stagnated — what happened?" The only worthwhile external measure of value is features that the team deliver (i.e. broadly counting improvements to non-functional requirements as features too). Velocity is meant to be constant (in an ideal world) to allow the Product Owner (i.e. someone _inside_ the team) a broad brush to provide estimates on when things may be ready — even used in this way, they depend on a stable team with a velocity that's not too volatile. They shouldn't be shared externally to try and show how productive the team are. For example, I've previously had management ask if our team can try a bit harder & deliver another 30 points per sprint. As points are meaningless outside of the team though, that's a false economy: I think they got the picture when I said our team could deliver another 1,000 points per sprint if they wanted us to.
  - srtjstjsj 9y ago
    Bad management can fail using any methodology. No process will make bad people do good things -- at best it can stop them bad things. The goal for a productivity process is to help good people to great things.
    - another-dave 9y ago
      Sure, but the parent was asking for an example of how it could become an empty metric — from my experience, this can happen when it goes outside the control of the team and "Goodhart's law" comes into play — When a measure becomes a target, it ceases to be a good measure. I'm not against meausring velocity, but I think it is a tool best used from within the team rather than from a management level > Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- maxxxxx 9y ago
  Once some managers get hold of velocity numbers they use them as the main metric. "How can increase the number of story points per sprint?" or "Why does dev A finish more story points than dev B?". Then you get all kinds of perverse incentives to game the system. Or: They start comparing story points between teams which in reality is a totally meaningless thing.
tootie 9y ago
Scrum is perfectly fine. In fact, it's a great way to achieve agility. But it only works if everyone understands both the process and the goals. For all the "scrum sucks" posts I've seen, I've yet to see anyone offer anything better.
- UK-Al05 9y ago
  Simple kanban and communication. Religiously following the 'process' is the opposite of agile. Being able to use your judgement to decide to do something is agile. In scrum you always do the same thing regardless if it's needed. Well in the implementations I've been in.
- sanderjd 9y ago
  What is better is coming up with a process that is right for your team, based on evaluating what has worked and what hasn't worked. For the teams I've been on, daily stand-ups have been a drag, and it has been a major improvement to eliminate them. Similarly, 100% pair programming has been unpleasant for the majority of the team, and it has been an improvement to stop feeling guilty about doing a lot of solitary programming. The criticism that scrum tries to get you to run a marathon as a series of sprints also resonates with me. It never seemed to allow time for more complex and vaguely defined projects to flourish, but rather we would look back and see an accumulation of short-term thoughts, but little cohesive whole. What has worked for me: code reviews code reviews code reviews, copious automated testing, a prioritized backlog, estimating size of work in some sort of abstract unit, burn downs, demos and retrospectives, short meetings with defined agendas, ignoring anything that makes up terminology, especially if any use of that made-up terminology includes a (TM) superscript.
ryandrake 9y ago
Is there an example of a company that has implemented the philosophy in the Agile Manifesto in a way that actually meets the needs of developers and managers? I read this all the time: The agile folks were right about software development, but Scrum/consultants/managers/process sucks! Everyone likes the Agile philosophy but then they all say it's never been implemented right. Reminds me of the "communism is the way--it's just that every time it's implemented it's done wrong!" argument. My criticisms of Agile are: 1. It doesn't scale to team sizes beyond the point where "individuals and interactions" can drive progress; and 2. it addresses developer needs but does not sufficiently address the requirements of the rest of the organization, including management. Developers gotta develop, but the rest of the business needs things like measurements, reports, status, ETA, sometimes proposals, change requests, etc. A methodology that does not address these artifacts is going to have a hard time fitting in.
- zdragnar 9y ago
  The agile manifesto was never intended to be a value proposition for the business per se, it was intended to be a promise of professional discipline. You don't ask the business if a refactor is okay, because the business doesn't know how to value or risk it. You refactor because that's what a disciplined professional does, in the course of their work. Think of another profession, if that helps. Teachers don't ask students or administrators if a test would be valuable after a given lesson. Builders don't ask if a hammer would be appropriate for a nail, or if they should use an air gun. There's a certain expectation that they should know and do these things. Scrum works if the scrum master functions as a mediator for the team to collaboratively prioritize work- ideally, this would be a role, not a job title. Scrum fails if the scrum master is just a project manager tasked with making sure the whole backlog entered by the product owner is done on time.
  - sanderjd 9y ago
    I think I agree with you, but I find your analogies quite lacking, which makes me question our shared premise. Teachers absolutely do have the cadence of tests after lessons dictated to them by administrators. Builders absolutely do negotiate with their customers over whether their "implementation" is sufficient or whether it should be "refactored" (ie. partially or completely torn out and re-done to improve the quality). I'm not sure where this leaves things, but it seems to me that the differing incentives and negotiation between stakeholders is perhaps inevitable.
OnlyRepliesToBS 9y ago
It's a religion and all negative implements are always at the fault of the implementer. That is called unfalsifiability.

hashkb 9y ago

Can you say more about how velocity is an empty metric? I'm an IC, sometimes tech lead, (e.g. not management) and j have always found it indispensable.

another-dave 9y ago
Velocity is too often used as a stick to beat people with — "Team B is doing 15 more points that you"; "Last month, we were doing an extra 5 points every sprint, but now we've stagnated — what happened?" The only worthwhile external measure of value is features that the team deliver (i.e. broadly counting improvements to non-functional requirements as features too). Velocity is meant to be constant (in an ideal world) to allow the Product Owner (i.e. someone _inside_ the team) a broad brush to provide estimates on when things may be ready — even used in this way, they depend on a stable team with a velocity that's not too volatile. They shouldn't be shared externally to try and show how productive the team are. For example, I've previously had management ask if our team can try a bit harder & deliver another 30 points per sprint. As points are meaningless outside of the team though, that's a false economy: I think they got the picture when I said our team could deliver another 1,000 points per sprint if they wanted us to.
- srtjstjsj 9y ago
  Bad management can fail using any methodology. No process will make bad people do good things -- at best it can stop them bad things. The goal for a productivity process is to help good people to great things.
  - another-dave 9y ago
    Sure, but the parent was asking for an example of how it could become an empty metric — from my experience, this can happen when it goes outside the control of the team and "Goodhart's law" comes into play — When a measure becomes a target, it ceases to be a good measure. I'm not against meausring velocity, but I think it is a tool best used from within the team rather than from a management level > Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
maxxxxx 9y ago
Once some managers get hold of velocity numbers they use them as the main metric. "How can increase the number of story points per sprint?" or "Why does dev A finish more story points than dev B?". Then you get all kinds of perverse incentives to game the system. Or: They start comparing story points between teams which in reality is a totally meaningless thing.

tootie 9y ago

Scrum is perfectly fine. In fact, it's a great way to achieve agility. But it only works if everyone understands both the process and the goals. For all the "scrum sucks" posts I've seen, I've yet to see anyone offer anything better.

UK-Al05 9y ago
Simple kanban and communication. Religiously following the 'process' is the opposite of agile. Being able to use your judgement to decide to do something is agile. In scrum you always do the same thing regardless if it's needed. Well in the implementations I've been in.
sanderjd 9y ago
What is better is coming up with a process that is right for your team, based on evaluating what has worked and what hasn't worked. For the teams I've been on, daily stand-ups have been a drag, and it has been a major improvement to eliminate them. Similarly, 100% pair programming has been unpleasant for the majority of the team, and it has been an improvement to stop feeling guilty about doing a lot of solitary programming. The criticism that scrum tries to get you to run a marathon as a series of sprints also resonates with me. It never seemed to allow time for more complex and vaguely defined projects to flourish, but rather we would look back and see an accumulation of short-term thoughts, but little cohesive whole. What has worked for me: code reviews code reviews code reviews, copious automated testing, a prioritized backlog, estimating size of work in some sort of abstract unit, burn downs, demos and retrospectives, short meetings with defined agendas, ignoring anything that makes up terminology, especially if any use of that made-up terminology includes a (TM) superscript.

ryandrake 9y ago

Is there an example of a company that has implemented the philosophy in the Agile Manifesto in a way that actually meets the needs of developers and managers? I read this all the time: The agile folks were right about software development, but Scrum/consultants/managers/process sucks! Everyone likes the Agile philosophy but then they all say it's never been implemented right. Reminds me of the "communism is the way--it's just that every time it's implemented it's done wrong!" argument. My criticisms of Agile are: 1. It doesn't scale to team sizes beyond the point where "individuals and interactions" can drive progress; and 2. it addresses developer needs but does not sufficiently address the requirements of the rest of the organization, including management. Developers gotta develop, but the rest of the business needs things like measurements, reports, status, ETA, sometimes proposals, change requests, etc. A methodology that does not address these artifacts is going to have a hard time fitting in.

zdragnar 9y ago
The agile manifesto was never intended to be a value proposition for the business per se, it was intended to be a promise of professional discipline. You don't ask the business if a refactor is okay, because the business doesn't know how to value or risk it. You refactor because that's what a disciplined professional does, in the course of their work. Think of another profession, if that helps. Teachers don't ask students or administrators if a test would be valuable after a given lesson. Builders don't ask if a hammer would be appropriate for a nail, or if they should use an air gun. There's a certain expectation that they should know and do these things. Scrum works if the scrum master functions as a mediator for the team to collaboratively prioritize work- ideally, this would be a role, not a job title. Scrum fails if the scrum master is just a project manager tasked with making sure the whole backlog entered by the product owner is done on time.
- sanderjd 9y ago
  I think I agree with you, but I find your analogies quite lacking, which makes me question our shared premise. Teachers absolutely do have the cadence of tests after lessons dictated to them by administrators. Builders absolutely do negotiate with their customers over whether their "implementation" is sufficient or whether it should be "refactored" (ie. partially or completely torn out and re-done to improve the quality). I'm not sure where this leaves things, but it seems to me that the differing incentives and negotiation between stakeholders is perhaps inevitable.

OnlyRepliesToBS 9y ago

It's a religion and all negative implements are always at the fault of the implementer. That is called unfalsifiability.