4 ms·

I think this pretty much cuts to the heart of what's usually wrong with the whole "agile" thing -- by micromanaging programmers to such a degree, instead of bei

I think this pretty much cuts to the heart of what's usually wrong with the whole "agile" thing -- by micromanaging programmers to such a degree, instead of being able to use that downtime to do things that practically everyone knows needs to get done, you have people sitting on their hands because everything has to go through the "backlog." IMO the solution is to stop treating programmers like cogs in a machine, and actually give them some amount of autonomy to make decisions.

ebiester 11y ago
On my agile team, we will say, "We see a problem here." We create an issue and start working on it, and alert the product owner as to why it is a problem and needs to take priority. We have that respect because we deliver working software. We are not the "fastest" team, but we get the latitude to make things better because we work with adults. We refactor as we go, even if the business value could have been delivered "faster" by compromising long term value for short term goals. But we also let them do their job and trust them to understand the strategic goals to the business better than we do.
- overgard 11y ago
  Yeah, I recognize there's some places that do agile in a good way (hence the qualifiers I put in); I've just been burned enough that I tend to be deeply skeptical of it. What I've noticed is that some managers fall in love with charts and measurements (because they can use those metrics to impress others in the organization), and anything that can't be superficially measured ends up either being devalued or outright banned. I remember one place I worked, they brought in consultants to "help" us create an agile process. After about four months or so, they declared the operation a success because the "velocity" had increased by 4x. (Which would be incredible if it were true). In reality, we were just measuring four times more things, and development was going much slower, but those charts sure looked nice.
smileysteve 11y ago
> instead of being able to use that downtime to do things that practically everyone knows needs to get done, you have people sitting on their hands because everything has to go through the "backlog." Oh man, this happened at one of my stricter scrum managed companies. There was a bug that people were noticing that should have meant that no other cards could pass QA. I recognized it as the small change that it was, made the branch, and had a peer ready to merge it, but got "a talking to" from the scrum master and product managers because they never recognized it as a bug.

ebiester 11y ago

On my agile team, we will say, "We see a problem here." We create an issue and start working on it, and alert the product owner as to why it is a problem and needs to take priority. We have that respect because we deliver working software. We are not the "fastest" team, but we get the latitude to make things better because we work with adults. We refactor as we go, even if the business value could have been delivered "faster" by compromising long term value for short term goals. But we also let them do their job and trust them to understand the strategic goals to the business better than we do.

overgard 11y ago
Yeah, I recognize there's some places that do agile in a good way (hence the qualifiers I put in); I've just been burned enough that I tend to be deeply skeptical of it. What I've noticed is that some managers fall in love with charts and measurements (because they can use those metrics to impress others in the organization), and anything that can't be superficially measured ends up either being devalued or outright banned. I remember one place I worked, they brought in consultants to "help" us create an agile process. After about four months or so, they declared the operation a success because the "velocity" had increased by 4x. (Which would be incredible if it were true). In reality, we were just measuring four times more things, and development was going much slower, but those charts sure looked nice.

smileysteve 11y ago

> instead of being able to use that downtime to do things that practically everyone knows needs to get done, you have people sitting on their hands because everything has to go through the "backlog." Oh man, this happened at one of my stricter scrum managed companies. There was a bug that people were noticing that should have meant that no other cards could pass QA. I recognized it as the small change that it was, made the branch, and had a peer ready to merge it, but got "a talking to" from the scrum master and product managers because they never recognized it as a bug.