4 ms·

I'm pretty turned of anything to do with Scrum these days. It's such a cargo cult of process (remember the "people before process" part of agile?) and focuses s

I'm pretty turned of anything to do with Scrum these days. It's such a cargo cult of process (remember the "people before process" part of agile?) and focuses solely on the development process to the exclusion of almost everything else about the organization. I've seen too many organizations and teams try to use agile to "fix" things while completely ignoring issues like product development, customer development and even culture. Any gains from applying agile will still be barely incremental when compared to addressing the real issue of product development and doing so holistically. I think lean and even lean startup make some significant strides past agile in doing this, but even that is starting to show it's cargo cult side (a/b test all the things anyone?).

Morcane 14y ago
I agree completely. scrum pretty much throws the people over process overboard...I've never been in so many meetings (dailies with different teams in different timezones all over the day, sprint planning meetings, planning poker sessions, retrospectives, weekly team meetings), the amount of administration and email going around is insane. I feel like I'm in school again, having to account for every single piss I take. To put it bluntly: get lost with that shit.
navs 14y ago
Agile is singularly the most talked about thing in our university while simultaneously being the least understood.
quattrofan 14y ago
Well if I told at least 3 clients have introduced "agile" in an attempt to solve perceived process problems and "speed things up" but have in effect made things worse, what would you say? Agile is bollocks and just another excuse for consultants to fleece money from companies.
- jaggederest 14y ago
  > anecdote showing x in a negative light > therefore x is fraudulent I love your logic!
- wpietri 14y ago
  I think "Agile" can be used as an excuse for consultants to fleece money from companies. Indeed, I'm on record as saying that's mainly what's getting sold these days: http://agilefocus.com/2011/02/21/agiles-second-chasm-and-how-we-fell-in/ http://agilefocus.com/2011/02/21/agiles-second-chasm-and-how... But acknowledging that, I'd like to add two things: First, as a developer, adopting Agile methods (in particular, Extreme Programming) made my life a lot better, and probably kept me from quitting the industry in frustration. And when I started a company, we gradually put together a custom Agile approach we liked a lot. Second, any useful Agile method works mainly by surfacing hidden problems so that people can fix them. So if you are doing an Agile adoption right, things always appear to get worse before they get better. The test for me is whether people treat the adoption as a process and relentlessly fix problems as they appear.
- lucisferre 14y ago
  Are you responding to me? I'm confused since I basically agree or are you just agreeing?
wsc981 14y ago
"I've seen too many organizations and teams try to use agile to "fix" things while completely ignoring issues like product development, customer development and even culture." I've had the same experience. It went as far as developers wanting me to negotiate every little thing with the product owner so stuff could be done in a later sprint - even when there was plenty of spare time left in a sprint. For me this removes a lot of fun in my work. Same was with clients, developers tried to put all client incidents on the backlog. Even though some incidents could be alleviated with very little work and make a customer happy. I'm a developer myself and I can't thrive in such an environment. It was actually not very agile with regards to fellow developers from different teams or clients.
- adrianhoward 14y ago
  It was actually not very agile with regards to fellow developers from different teams or clients. This, I think, actually gets at the heart of the problem. The vast majority of the problems I encounter with people complaining about agile are due to a team/process that has the "agile" label - but isn't actually following any of the fundamental principles of any agile process. Agile is suffering the curse of anything that becomes popular. For example, Scrum teams that skip the whole inspect/adapt thing and seem to forget about basic stuff like the sprint review & sprint retrospective. The sort of team that adopts Scrum by sending off a project manager for a 2 day CSM course and think that's the beginning and end of it. Bah. On the bright side fixing them has become a lucrative sideline for me :-)
adrianhoward 14y ago
Any gains from applying agile will still be barely incremental when compared to addressing the real issue of product development and doing so holistically. Not to deny the massive importance of the customer/product development side - but I've seen places crash and burn badly when they don't have the core development practices to back them up. Implementing good old-fashioned XP-ish technical practices can give you considerably more than an incremental change - since without it you can't actually execute your good customer/product dev work.
- lucisferre 14y ago
  It's much easier to say there are considerable gains than it is to show it, as yet I've never actually seen it measured, just some gut feely stuff where the team says they do or, as I hear almost as often, don't like how the new system is working. Obviously, with any severely dysfunctional team---I mean some teams still don't even use a VCS---any sort of productivity oriented training should arguably result in significant gains. But these improvements are often looked at in isolation. Being more productive at building the wrong product is still not going to add value. So it really depends what you are measuring and Agilists constantly focus on measuring completely meaningless things, like developer velocity, while expecting the rest of the organization actually knows what it's doing when it prioritizes backlogs or says things are ready to be worked on. I was in a Scrum training session where the head of product management was concerned when the trainer explained that velocity was largely an arbitrary internal team barometer and couldn't be used to measure the relative performance of teams. He asked "then how can we [use Scrum to] measure their relative performance?" The irony of this was that the biggest productivity issue I could see was the lack of a clear and effective product development process. This meant that iteration after iteration we were constantly building in circles and with only a vague plan for the product. Scrum was not even beginning to address this. Of course Scrumistas, always claim that these failures are just the result of cargo culting, "doing it wrong(tm)", or just not understanding "Agile". The problem is that these organizations are paying those same people to teach them and are still apparently not getting it, so who is really at fault? It's clear to me both Scrum and XP processes fail at teaching organizations how to learn and improve as a whole. They fail because they focus way too much on explaining the process and pay only minimal lip service to larger organization issues like continuous improvement, product development, customer validation and even basic planning (unless you want to count planning poker, ugh). Bottom line is, they are oversimplifications at best but at worse are blatantly misleading organizations and software development teams. That isn't to say there are no good ideas in agile. I still feel a learned lots trying to be a proponent of agile and even Scrum and XP. But after repeatedly going through the painful process of failing, I eventually learned there was more to this and am finally moving on. I should also state I'm still a big fan of the principles of the manifesto, but in the end I no longer see the relationship between the manifesto and the manifestations of agile, particularly in Scrum and XP.

Morcane 14y ago

I agree completely. scrum pretty much throws the people over process overboard...I've never been in so many meetings (dailies with different teams in different timezones all over the day, sprint planning meetings, planning poker sessions, retrospectives, weekly team meetings), the amount of administration and email going around is insane. I feel like I'm in school again, having to account for every single piss I take. To put it bluntly: get lost with that shit.

navs 14y ago

Agile is singularly the most talked about thing in our university while simultaneously being the least understood.

quattrofan 14y ago

Well if I told at least 3 clients have introduced "agile" in an attempt to solve perceived process problems and "speed things up" but have in effect made things worse, what would you say? Agile is bollocks and just another excuse for consultants to fleece money from companies.

jaggederest 14y ago
> anecdote showing x in a negative light > therefore x is fraudulent I love your logic!
wpietri 14y ago
I think "Agile" can be used as an excuse for consultants to fleece money from companies. Indeed, I'm on record as saying that's mainly what's getting sold these days: http://agilefocus.com/2011/02/21/agiles-second-chasm-and-how-we-fell-in/ http://agilefocus.com/2011/02/21/agiles-second-chasm-and-how... But acknowledging that, I'd like to add two things: First, as a developer, adopting Agile methods (in particular, Extreme Programming) made my life a lot better, and probably kept me from quitting the industry in frustration. And when I started a company, we gradually put together a custom Agile approach we liked a lot. Second, any useful Agile method works mainly by surfacing hidden problems so that people can fix them. So if you are doing an Agile adoption right, things always appear to get worse before they get better. The test for me is whether people treat the adoption as a process and relentlessly fix problems as they appear.
lucisferre 14y ago
Are you responding to me? I'm confused since I basically agree or are you just agreeing?

wsc981 14y ago

"I've seen too many organizations and teams try to use agile to "fix" things while completely ignoring issues like product development, customer development and even culture." I've had the same experience. It went as far as developers wanting me to negotiate every little thing with the product owner so stuff could be done in a later sprint - even when there was plenty of spare time left in a sprint. For me this removes a lot of fun in my work. Same was with clients, developers tried to put all client incidents on the backlog. Even though some incidents could be alleviated with very little work and make a customer happy. I'm a developer myself and I can't thrive in such an environment. It was actually not very agile with regards to fellow developers from different teams or clients.

adrianhoward 14y ago
It was actually not very agile with regards to fellow developers from different teams or clients. This, I think, actually gets at the heart of the problem. The vast majority of the problems I encounter with people complaining about agile are due to a team/process that has the "agile" label - but isn't actually following any of the fundamental principles of any agile process. Agile is suffering the curse of anything that becomes popular. For example, Scrum teams that skip the whole inspect/adapt thing and seem to forget about basic stuff like the sprint review & sprint retrospective. The sort of team that adopts Scrum by sending off a project manager for a 2 day CSM course and think that's the beginning and end of it. Bah. On the bright side fixing them has become a lucrative sideline for me :-)

adrianhoward 14y ago

Any gains from applying agile will still be barely incremental when compared to addressing the real issue of product development and doing so holistically. Not to deny the massive importance of the customer/product development side - but I've seen places crash and burn badly when they don't have the core development practices to back them up. Implementing good old-fashioned XP-ish technical practices can give you considerably more than an incremental change - since without it you can't actually execute your good customer/product dev work.

lucisferre 14y ago
It's much easier to say there are considerable gains than it is to show it, as yet I've never actually seen it measured, just some gut feely stuff where the team says they do or, as I hear almost as often, don't like how the new system is working. Obviously, with any severely dysfunctional team---I mean some teams still don't even use a VCS---any sort of productivity oriented training should arguably result in significant gains. But these improvements are often looked at in isolation. Being more productive at building the wrong product is still not going to add value. So it really depends what you are measuring and Agilists constantly focus on measuring completely meaningless things, like developer velocity, while expecting the rest of the organization actually knows what it's doing when it prioritizes backlogs or says things are ready to be worked on. I was in a Scrum training session where the head of product management was concerned when the trainer explained that velocity was largely an arbitrary internal team barometer and couldn't be used to measure the relative performance of teams. He asked "then how can we [use Scrum to] measure their relative performance?" The irony of this was that the biggest productivity issue I could see was the lack of a clear and effective product development process. This meant that iteration after iteration we were constantly building in circles and with only a vague plan for the product. Scrum was not even beginning to address this. Of course Scrumistas, always claim that these failures are just the result of cargo culting, "doing it wrong(tm)", or just not understanding "Agile". The problem is that these organizations are paying those same people to teach them and are still apparently not getting it, so who is really at fault? It's clear to me both Scrum and XP processes fail at teaching organizations how to learn and improve as a whole. They fail because they focus way too much on explaining the process and pay only minimal lip service to larger organization issues like continuous improvement, product development, customer validation and even basic planning (unless you want to count planning poker, ugh). Bottom line is, they are oversimplifications at best but at worse are blatantly misleading organizations and software development teams. That isn't to say there are no good ideas in agile. I still feel a learned lots trying to be a proponent of agile and even Scrum and XP. But after repeatedly going through the painful process of failing, I eventually learned there was more to this and am finally moving on. I should also state I'm still a big fan of the principles of the manifesto, but in the end I no longer see the relationship between the manifesto and the manifestations of agile, particularly in Scrum and XP.