I'm convinced the main point of scrum is simply so that everyone has to be in the office at 9 or 10 everyday.
That's also probably what annoys me about it the most :-/
Agile Ruined My Life
41–50 of 137 posts
Re: Agile Ruined My Life
#421. Involve end users (aka customers) in the process as much as possible, since if they don't like the end result your work was wasted.
2. Do work in small chunks. Releasing every 1-3 weeks gets changes out in front of real users quickly. The shorter your cycle the less likely you are to spend lots of time on something useless.
3. Write tests!
The specific details of any agile methodology are, IMO, less important. If pair programming or TDD or stand-up meetings help you with those three points, great. If not, don't do them.
Re: Agile Ruined My Life
#43Implementing scrum turned our team from productive and mostly free of overhead to overbearing, involving a lot of long ass meetings (all meetings are long if you have to stand) and produced a lot of additional confusion. The interesting thing is that previously, with our specs and our so-called waterfall approach were were more agile. It happened naturally as we naturally did incremental development and we naturally…
whenever unit tests or test driven development comes up the proponents act like anyone not doing things this way is incompetent. I think the reverse is true Can you elaborate on what you mean by this last part?
Re: Agile Ruined My Life
#44As a young software developper, what really bores me with Agile, is the name, the shiny box you put things into, where it should just be named "Good practices for software developement". It's the mentality of selling things as products, with some kind of prebuilt ideology and aesthetic built along with the core, that really makes me run far far away. I don't want to be sold a product. The fact that it led people to t…
The name probably makes more sense for people who wrote software before it came about. Even "non-agile" development processes have evolved in response in the last 8 or so years.
Re: Agile Ruined My Life
#45Earlier quoted context omitted.
Exactly! Factors contributing to the success of a development project, in decreasing order of importance: 1. the skill of the team 2. the determination of the team to succeed 3. appropriate choice of technologies 4. process In my experience management agendas are much more likely to interfere with 1-4 than to help. There needs to be some kind of hippocratic oath for development managers and process enthusiasts. Every…
They're forgetting it because they want to forget it. Businessmen want (for reasons that are somewhat rational) to commoditize everything, including labor. Programming labor has been stubbornly difficult to commoditize. Programmers differ in skill in very deep and complex ways, and can't just be swapped out like assembly line workers. This is immensely frustrating to the bean counters. Anything that comes along and p…
Re: Agile Ruined My Life
#46As a young software developper, what really bores me with Agile, is the name, the shiny box you put things into, where it should just be named "Good practices for software developement". It's the mentality of selling things as products, with some kind of prebuilt ideology and aesthetic built along with the core, that really makes me run far far away. I don't want to be sold a product. The fact that it led people to t…
Except that in many, many, cases, you do. :-)
Not "you" in particular, but "you" as in enough of a client base that it matters. This is basically the issue with methodologies, regardless of what the contents of a methodology are!
Being agile is applying those best practices as you suggest. This comes from years of experience on your team - either learned directly or through mentor-ship/apprenticeship, and will vary depending on the problem constraints and environment.
Employing Agile Methodology is applying a pre-defined "solution" to a "problem" that exists, usually because the best practices are not applied at best, but most likely because they are completely foreign to the problem scope.
It's the hammer/nail problem. There is a whole market of people looking for solutions to their half finished projects. There are many people selling hammers, screwdrivers, chisels, drills etc. etc. They all run into the same fundamental issue: not working with a complete toolbox.
The solution to the problem seekers is to hire competent, experienced and most often expensive programming teams and allow them to properly define the problem scope and solution. This is complicated by the fact that often "you" cannot judge the competency or the experience of the people you need to hire.
No amount of ignoring that very hard problem will make it go away. Not whatever process IBM was flaunting 20 years ago, not agile, and not whatever people come up with next.
Hackers are painters after all, and you need to have good painters on your team if you are looking for a good painting. It's very similar to hiring a trades-person to renovate your house. In the end, you find one with a good track record and you essentially get what you pay for.
Re: Agile Ruined My Life
#47Re: Agile Ruined My Life
#48i read the comments here and wonder if the problems people are expressing here about agile are actually caused by agile, or rather, the people implementing agile? my money's on the latter. agile, like any process, can be abused by those who don't understand or are too process-oriented.
If there is no way to tell, does it matter?
I mean, if Agile requires a perfect implementation, support from everybody, very smart people and luck, is it any good? If I have all that, I can do whatever with any methodology.
Re: Agile Ruined My Life
#49I'm convinced the main point of scrum is simply so that everyone has to be in the office at 9 or 10 everyday.
Re: Agile Ruined My Life
#50i read the comments here and wonder if the problems people are expressing here about agile are actually caused by agile, or rather, the people implementing agile? my money's on the latter. agile, like any process, can be abused by those who don't understand or are too process-oriented.
...if the problems people are expressing here about agile are actually caused by agile, or rather, the people implementing agile If there is no way to tell, does it matter? I mean, if Agile requires a perfect implementation, support from everybody, very smart people and luck, is it any good? If I have all that, I can do whatever with any methodology.
It's easy to see the flaw in many failed implementations: they don't manage their schedules, they don't have successful iterations, they don't manage their technical investments, and the only thing they don't do that agile suggests isn't usually worth doing is writing lots of specifications and documentation beforehand.