6 ms·

This is not true for agile. The agile manifesto was in fact drafted by software developers. Also, agile doesn't prescribe any process at all, in fact, it does t

by mmcnl 9y ago

This is not true for agile. The agile manifesto was in fact drafted by software developers. Also, agile doesn't prescribe any process at all, in fact, it does the opposite. Agile in essence is quite beautiful, unfortunately it gets twisted and turned upside down until it's just another methodology (which is exactly the opposite of its original meaning).

megaman22 9y ago
You can't argue that there hasn't arisen an entire industry of snake oil salesmen whose sole purpose is pushing Agile, and Scrum, and whatever.
varjag 9y ago
Some 10 years ago I attended a purportedly OO development conference which was by that time taken over by agile crowd. It was full of nice, chatty and energetic people. I was lost. It felt like slipping through a crack in the Universe, Sliders-style, into reality where you can't understand people discussing the things you do for years. There were few other developers attending, seemingly just as startled by all this. The whole thing ended with some Agile activity for all attendants which I can best describe as a mix of kindergarten class and Baptist sermon. I could not comprehend the intent, the procedure and the desired outcome (and whether it was achieved).
- emodendroket 9y ago
  Oh, you know, I'd forgotten about the paper airplanes and pasta sculptures.
- maxxxxx 9y ago
  That's how I felt when I attended my Scrum Master training. There was almost nobody in there who actually wrote code. The discussions were very abstract and about situations I had never encountered in work life.
  - rukuu001 9y ago
    Couple points re this. People attending SM training are often just middle managers learning enough to know WTF their SMs and PMs are talking about in meetings. Also, there's no requirement for SMs to be coders, it's a role a lot of BAs take on. Some experience in software development context is desirable tho. I found a lot of my SM training relateable to real life. My team went crazy for planning poker because it got a lot of assumptions out early. Standups were impossible because some people started at 1pm, others finished at 4pm. I see Scrum as a bag of tools to apply to teams. Some work, some don't.
dannyrosen 9y ago
There's working with agility and there's "Agile." One is a product one is not.
cc81 9y ago
I actually like vanilla Scrum and think often you need a formalized methodology for the team to follow. I've worked with a lot of different teams and there are a few things I've noticed being pretty common among developers (or sometimes being guilty of myself). 1. Not working on what you are supposed to be working on. Sometimes some developers feel that they should probably rewrite X or add Y and does so without consulting anyone first. Something it is good and sometimes it just takes time or adds regressions you did not need at the time. 2. Senior developers owning a piece of the code base. Often grabbing a huge chunk of work for themselves on it and then you don't hear from them for a while when they hack away. Sometimes they do good work and sometimes not and if they are sick or away and no one knows how their code works. 3. Junior (or some senior) developers being stuck for a long while without asking for help. 4. Ignoring the customer and building what you think should be built. None of those are automatically fixed with Scrum and I know some here will just say "Yeah, we have a professional team that actually talks with each other and does code reviews" so they don't need it. And I get that but for a lot of those small teams building some CRUD application at a large enterprise the formalized communication ways are a god send in my experience.
- deleted 9y ago
  [deleted]
- piva00 9y ago
  I agree with you that a formalized methodology is required for you to start with agile, be it XP, Scrum, Kanban or whatever the flavor the team itself feels more comfortable doing. What no one tells these teams is that the methodology/process itself should be flexible, should be allowed to change to accommodate the idiosyncrasies of their work environment. What I've noticed helping some small companies is that teams learn some framework and use that as their "agile" concept and then proceed to be overzealous of the process itself, completely forgetting the original manifesto. Like always, it's a strange whisper game...
  - gregmac 9y ago
    Adjusting the process literally is part of Scrum. At the retrospective, if something isn't working, you call it out and change it. That can be something as big as completely changing the methodology. I've never worked on a XP team but my understanding is formally there is no retrospective process - I would definitely want to put one in place if I did work with it. Any development process that doesn't allow for changing itself is shortsighted and ultimately self-defeating.
emodendroket 9y ago
Something like Scrum springing up is completely predictable though
ZenoArrow 9y ago
To me the key differentiator in agile approaches is whether it's business-led or developer-led. If developers can decide on what gets done and when, then agile can work quite well, but to me that's just a pipe dream in most cases. Unless a company's sole business is software, and the financial health of a company is strong, developer-led agile is a hard sell for business owners, even if it leads to long term benefits. So what happens instead is business-led agile which in my experience is worse than waterfall, as you get constant demands for poorly defined new features, with tight deadlines as that's being 'agile'. In other words, agile has just become a stick for companies to beat their developers with. That wasn't the original intention, but I would suggest that's at least part of the reason why management types like the term 'agile' so much.
- goalieca 9y ago
  Developer led as in you give me some requirements and a deadline and then get out of my way and let me decide how i will break down my task and coordinate with other team members? Give me waterfall please! :)
  - ZenoArrow 9y ago
    Interesting. What issues have you had with developer-led agile?
    - goalieca 9y ago
      That it’s not really developper led and is just another form of micromanagement. A developer led way of development would do away with sprints if it suited the purpose. It would prioritize requirements over stories if it suited the purpose. It gets even more frustrating when you have to start to work a certain way with scrum (eg frequent commits, vertical development, etc).
mannykannot 9y ago
Waterfall was also drafted by software developers, who noticed that many of the least tractable errors had their roots in poorly-specified requirements and poor design. It was a first pass at a problem that is still with us.
deleted 9y ago
[deleted]
jholman 9y ago
> The agile manifesto was in fact drafted by software developers Really? When I look at the list of authors of the Agile Manifesto, I recognize several names as belonging to people who have made a career out of coaching and advising. Several of those people made their careers by bragging about their involvement in a catastrophic failure. I mean, they're probably all better software developers than I am. But I think that sytelus's description seems to be right on, at least for many of the Agile Manifesto authors.

by mmcnl 9y ago

megaman22 9y ago

You can't argue that there hasn't arisen an entire industry of snake oil salesmen whose sole purpose is pushing Agile, and Scrum, and whatever.

varjag 9y ago

Some 10 years ago I attended a purportedly OO development conference which was by that time taken over by agile crowd. It was full of nice, chatty and energetic people. I was lost. It felt like slipping through a crack in the Universe, Sliders-style, into reality where you can't understand people discussing the things you do for years. There were few other developers attending, seemingly just as startled by all this. The whole thing ended with some Agile activity for all attendants which I can best describe as a mix of kindergarten class and Baptist sermon. I could not comprehend the intent, the procedure and the desired outcome (and whether it was achieved).

emodendroket 9y ago
Oh, you know, I'd forgotten about the paper airplanes and pasta sculptures.
maxxxxx 9y ago
That's how I felt when I attended my Scrum Master training. There was almost nobody in there who actually wrote code. The discussions were very abstract and about situations I had never encountered in work life.
- rukuu001 9y ago
  Couple points re this. People attending SM training are often just middle managers learning enough to know WTF their SMs and PMs are talking about in meetings. Also, there's no requirement for SMs to be coders, it's a role a lot of BAs take on. Some experience in software development context is desirable tho. I found a lot of my SM training relateable to real life. My team went crazy for planning poker because it got a lot of assumptions out early. Standups were impossible because some people started at 1pm, others finished at 4pm. I see Scrum as a bag of tools to apply to teams. Some work, some don't.

dannyrosen 9y ago

There's working with agility and there's "Agile." One is a product one is not.

cc81 9y ago

I actually like vanilla Scrum and think often you need a formalized methodology for the team to follow. I've worked with a lot of different teams and there are a few things I've noticed being pretty common among developers (or sometimes being guilty of myself). 1. Not working on what you are supposed to be working on. Sometimes some developers feel that they should probably rewrite X or add Y and does so without consulting anyone first. Something it is good and sometimes it just takes time or adds regressions you did not need at the time. 2. Senior developers owning a piece of the code base. Often grabbing a huge chunk of work for themselves on it and then you don't hear from them for a while when they hack away. Sometimes they do good work and sometimes not and if they are sick or away and no one knows how their code works. 3. Junior (or some senior) developers being stuck for a long while without asking for help. 4. Ignoring the customer and building what you think should be built. None of those are automatically fixed with Scrum and I know some here will just say "Yeah, we have a professional team that actually talks with each other and does code reviews" so they don't need it. And I get that but for a lot of those small teams building some CRUD application at a large enterprise the formalized communication ways are a god send in my experience.

deleted 9y ago
[deleted]
piva00 9y ago
I agree with you that a formalized methodology is required for you to start with agile, be it XP, Scrum, Kanban or whatever the flavor the team itself feels more comfortable doing. What no one tells these teams is that the methodology/process itself should be flexible, should be allowed to change to accommodate the idiosyncrasies of their work environment. What I've noticed helping some small companies is that teams learn some framework and use that as their "agile" concept and then proceed to be overzealous of the process itself, completely forgetting the original manifesto. Like always, it's a strange whisper game...
- gregmac 9y ago
  Adjusting the process literally is part of Scrum. At the retrospective, if something isn't working, you call it out and change it. That can be something as big as completely changing the methodology. I've never worked on a XP team but my understanding is formally there is no retrospective process - I would definitely want to put one in place if I did work with it. Any development process that doesn't allow for changing itself is shortsighted and ultimately self-defeating.

emodendroket 9y ago

Something like Scrum springing up is completely predictable though

ZenoArrow 9y ago

To me the key differentiator in agile approaches is whether it's business-led or developer-led. If developers can decide on what gets done and when, then agile can work quite well, but to me that's just a pipe dream in most cases. Unless a company's sole business is software, and the financial health of a company is strong, developer-led agile is a hard sell for business owners, even if it leads to long term benefits. So what happens instead is business-led agile which in my experience is worse than waterfall, as you get constant demands for poorly defined new features, with tight deadlines as that's being 'agile'. In other words, agile has just become a stick for companies to beat their developers with. That wasn't the original intention, but I would suggest that's at least part of the reason why management types like the term 'agile' so much.

goalieca 9y ago
Developer led as in you give me some requirements and a deadline and then get out of my way and let me decide how i will break down my task and coordinate with other team members? Give me waterfall please! :)
- ZenoArrow 9y ago
  Interesting. What issues have you had with developer-led agile?
  - goalieca 9y ago
    That it’s not really developper led and is just another form of micromanagement. A developer led way of development would do away with sprints if it suited the purpose. It would prioritize requirements over stories if it suited the purpose. It gets even more frustrating when you have to start to work a certain way with scrum (eg frequent commits, vertical development, etc).

mannykannot 9y ago

Waterfall was also drafted by software developers, who noticed that many of the least tractable errors had their roots in poorly-specified requirements and poor design. It was a first pass at a problem that is still with us.

deleted 9y ago

[deleted]

jholman 9y ago

> The agile manifesto was in fact drafted by software developers Really? When I look at the list of authors of the Agile Manifesto, I recognize several names as belonging to people who have made a career out of coaching and advising. Several of those people made their careers by bragging about their involvement in a catastrophic failure. I mean, they're probably all better software developers than I am. But I think that sytelus's description seems to be right on, at least for many of the Agile Manifesto authors.