3 ms·

"agile" is great. "Agile" has been fucked to death by consultants and execs who just heard "wait you can make developers completely fungible and i can get somet

"agile" is great. "Agile" has been fucked to death by consultants and execs who just heard "wait you can make developers completely fungible and i can get something in 2 weeks rather than waiting for 2 years?" and never bothered to listen to anything else.

grimjack00 8y ago
That is how I view it: - "big A" Agile has books and approved tools and coaches from outside the company holding week-long all-day workshops. - "little a" agile has devs/QA/etc. suggesting ways to make the process of building and shipping software smoother. I'm currently working on a "little a" agile team. Upper management doesn't really care what our process is, as long as they get their quarterly release with (most) of their priorities.
- bunderbunder 8y ago
  I'm becoming increasingly convinced that, to be successful, a team's agile practice needs to largely fly under the radar of upper management. As soon as upper management catches wind, you'll need to justify every little process flow change to them, or they'll start demanding regular reports with burndown charts and plots of velocity over time and crap like that. At which point, you're done. Things officially suck forever. That isn't to say that I think Scrum coaches and whatever have no value to offer. I've done a 1-week Agile training course, and I thought it presented some really great ideas. But their potential value is severely undercut by the fact that there's no way to bring one in without attracting the attention of the mothership.
  - bogle 8y ago
    I had that once, the bit where management wanted to see the burndowns and velocity, then fixated over same. The only way to move past it was to stop producing them. I did, as the Lead/SM/Dev Manager, have the clout to say no, so that was lucky. I explained it's the working software you need but I don't think they were happy.
  - GVIrish 8y ago
    > As soon as upper management catches wind, you'll need to justify every little process flow change to them, or they'll start demanding regular reports with burndown charts and plots of velocity over time and crap like that. I think that's a management problem you'll run into with any development methodology you use. There are a lot of management types that slavishly focus on metrics whether or not they make any sense, and they can do tremendous damage to any organization. Give those people a tool and they'll find a way to misapply it, whether it's velocity, or performance reviews, or LOC, or whatever. Prime example of this was stack ranking at Microsoft. How much productivity was lost due to the political maneuvering and backbiting caused by their misunderstanding of bell curves?
wnevets 8y ago
The moment someone says they're a certified scrum master you know you're fucked.
GVIrish 8y ago
That's a strange reading of Agile to me. Agile is not about making developers fungible, it's about building high performing teams of people. That takes time, and it is set back any time you have to replace someone. There's plenty of Agile literature that points out the hit to velocity when there's turnover. As for 'i can get something in 2 weeks rather than waiting for 2 years', that's about not waiting 2 years to find out that you've been building the wrong thing or that the software sucks. Maybe as you deliver features you'll find out that the application is good enough in 18 months. Maybe you'll find out after several months of sprints that the product owner is bad at getting requirements and you need to do something different. Or maybe you'll find out that it is taking longer than original estimated to deliver functionality so important dates need to be adjusted accordingly. In the old waterfall model, all that bad news may not come out until 2 years later when the software is released. And in the old model the customer is not getting useful software until 2 years out, rather than much sooner with a minimally viable product. Agile is not a panacea and any methodology will fail if attempted by dysfunctional/incompetent groups of people. But if there's one benefit of Agile, is that everyone should find out much sooner that things are going awry.
- flarg 8y ago
  I've worked in waterfall and agile for 15 years, and the key lesson from Scrum is that it effectively exposes bad news early on. The scrum ceremonies do just that and nothing more. Once you get the bad news open and dealt with a lot of other work is made more worthwhile.

grimjack00 8y ago

That is how I view it: - "big A" Agile has books and approved tools and coaches from outside the company holding week-long all-day workshops. - "little a" agile has devs/QA/etc. suggesting ways to make the process of building and shipping software smoother. I'm currently working on a "little a" agile team. Upper management doesn't really care what our process is, as long as they get their quarterly release with (most) of their priorities.

bunderbunder 8y ago
I'm becoming increasingly convinced that, to be successful, a team's agile practice needs to largely fly under the radar of upper management. As soon as upper management catches wind, you'll need to justify every little process flow change to them, or they'll start demanding regular reports with burndown charts and plots of velocity over time and crap like that. At which point, you're done. Things officially suck forever. That isn't to say that I think Scrum coaches and whatever have no value to offer. I've done a 1-week Agile training course, and I thought it presented some really great ideas. But their potential value is severely undercut by the fact that there's no way to bring one in without attracting the attention of the mothership.
- bogle 8y ago
  I had that once, the bit where management wanted to see the burndowns and velocity, then fixated over same. The only way to move past it was to stop producing them. I did, as the Lead/SM/Dev Manager, have the clout to say no, so that was lucky. I explained it's the working software you need but I don't think they were happy.
- GVIrish 8y ago
  > As soon as upper management catches wind, you'll need to justify every little process flow change to them, or they'll start demanding regular reports with burndown charts and plots of velocity over time and crap like that. I think that's a management problem you'll run into with any development methodology you use. There are a lot of management types that slavishly focus on metrics whether or not they make any sense, and they can do tremendous damage to any organization. Give those people a tool and they'll find a way to misapply it, whether it's velocity, or performance reviews, or LOC, or whatever. Prime example of this was stack ranking at Microsoft. How much productivity was lost due to the political maneuvering and backbiting caused by their misunderstanding of bell curves?

wnevets 8y ago

The moment someone says they're a certified scrum master you know you're fucked.

GVIrish 8y ago

That's a strange reading of Agile to me. Agile is not about making developers fungible, it's about building high performing teams of people. That takes time, and it is set back any time you have to replace someone. There's plenty of Agile literature that points out the hit to velocity when there's turnover. As for 'i can get something in 2 weeks rather than waiting for 2 years', that's about not waiting 2 years to find out that you've been building the wrong thing or that the software sucks. Maybe as you deliver features you'll find out that the application is good enough in 18 months. Maybe you'll find out after several months of sprints that the product owner is bad at getting requirements and you need to do something different. Or maybe you'll find out that it is taking longer than original estimated to deliver functionality so important dates need to be adjusted accordingly. In the old waterfall model, all that bad news may not come out until 2 years later when the software is released. And in the old model the customer is not getting useful software until 2 years out, rather than much sooner with a minimally viable product. Agile is not a panacea and any methodology will fail if attempted by dysfunctional/incompetent groups of people. But if there's one benefit of Agile, is that everyone should find out much sooner that things are going awry.

flarg 8y ago
I've worked in waterfall and agile for 15 years, and the key lesson from Scrum is that it effectively exposes bad news early on. The scrum ceremonies do just that and nothing more. Once you get the bad news open and dealt with a lot of other work is made more worthwhile.