SRL Archive - General

I am searching some information about agile software development to complete my assignment. I just found some information about it and want to share here. Benefits of agile software development include:
1. Stakeholder Engagement
2. Transparency
3. Early and Predictable Delivery
4. Focusing on Business Value
5. Focusing on Customers
6. Predictable Costs and Schedule
7. Allows for Change
8. Improving Quality

Can you explain some more? This just looks like spam since you haven't included any real information.. :p

From: Zyt3x
Can you explain some more? This just looks like spam since you haven't included any real information.. :p

I don't want to be the one to say it, but, we might have a spambot on our hands here (no need to panic, I've seen their kind before)

From: cause
I don't want to be the one to say it, but, we might have a spambot on our hands here (no need to panic, I've seen their kind before)

I know, just checking to see if he's a spam bot or not

I think we have had the same topic of spam before. Agile development stuff.

Or maybe this is the real life of a software engineer, UML patterns might take the best from your brain.

From: Foundry
I think we have had the same topic of spam before. Agile development stuff.

Yup, and I responded with my utter hatred for the subject.

From: Brotein
Or maybe this is the real life of a software engineer, UML patterns might take the best from your brain.

Nope, real software engineers don't care for Agile.

From: Kevin
Nope, real software engineers don't care for Agile.

Not true -_-

6. Predictable Costs and Schedule
7. Allows for Change
8. Improving Quality


If you don't care about those, you're in the wrong business as a software engineer and/or developer.. And UML diagrams along with star schema and snowflake schema is pretty much stuff you must eventually know.

Yeah who doesn't hate UML diagram and having to learn every step of the waterfall approach.. Most annoying things on the planet.

When a senior hands you a 60+ page booklet of pure business logic and you must design whatever to meet the exact criteria with flexibility for management and updates, that's when knowing that stuff helps.

I don't think he's a spambot. Until he starts selling "CVV GOOD DUMPS I PROMISE CLEAN MASTERCARD" or whatever that even is, he hasn't really made a case to be a spambot. His first post was an introductory post on wanting be learn stuff from this community, although it was on some random thread it is hardly a spambot feature- also not a gravedig. This post could also be him looking for some help on a project about agile software dev.
Or he could be a spambot and my benefit-of-the-doubt personality got the best of mIt is not known whether humans domesticated the wolf as such to initiate dog's divergence from its ancestors, or whether dog's evolutionary path had already taken a different course prior to domestication. For example, it is hypothesized that some wolves gathered around the campsites of paleolithic camps to scavenge refuse, and associated evolutionary pressure developed that favored those who were less frightened by, and keener in approaching, humans.

From: Wu-Tang Clan
I don't think he's a spambot. Until he starts selling "CVV GOOD DUMPS I PROMISE CLEAN MASTERCARD" or whatever that even is, he hasn't really made a case to be a spambot. His first post was an introductory post on wanting be learn stuff from this community, although it was on some random thread it is hardly a spambot feature- also not a gravedig. This post could also be him looking for some help on a project about agile software dev.
Or he could be a spambot and my benefit-of-the-doubt personality got the best of mIt is not known whether humans domesticated the wolf as such to initiate dog's divergence from its ancestors, or whether dog's evolutionary path had already taken a different course prior to domestication. For example, it is hypothesized that some wolves gathered around the campsites of paleolithic camps to scavenge refuse, and associated evolutionary pressure developed that favored those who were less frightened by, and keener in approaching, humans.

I don't know, his only other post was extremely vague. Also he has edited both posts. I suspect an attempt to edit in links, perhaps hoping to circumvent antispam measures. Clearly unsuccessful though due to the 10 post limit, which explains why although both his posts were edited by him not a character in either has been changed.

From: Brandon
Not true -_-

6. Predictable Costs and Schedule
7. Allows for Change
8. Improving Quality

I'm aware of the Agile and SCRUM methodologies, and yes, those are advertised benefits… And yes, #7 is fairly well true, and in turn, #8 becomes true. #6 is no more true in the long run than any dreaded Waterfall methodology, however. And if you aren't aware of some of the disadvantages of Agile…

1. No step of Agile involves user testing outside of what the developer does on their own. You have no idea if the product you have completed is even desireable from a consumer standpoint because there are no designated prototyping steps or concepts of Alpha/Beta testing. - This can always be added obviously, but it is not a part of the native Agile indoctrine.
2. Because of the flexibility and allowed evolution of products, you get to a situation called scope creeping. This is when new features are consistently added to evolve with possible desireables and continuously push off the deadline - leading to wildly inaccurate costs and scheduling.
3. Product requirements are bare minimums. This is designed to save time and money on the design process; however, in turn, that leads to horrendous requirement testing and very loose definitions of 'done'.
4. Integration testing is done throughout the development process, which increases the development costs by a fair amount - and has caused many projects to fail.
5. Frequent feature sign off is represented entirely from a business standpoint; Agile is created by business men looking to quantify the software development process. There is no such thing as building a platform, or preparing for code reuse, or building a stable framework for your product as those are not business stories for feature sign off. Agile is very 'business story' oriented, as opposed to good development practices.
6. And my most disliked feature of Agile: due to the inherent public ownership of all products, all developers are typically considered equal and should be aware of the entire development process of every other developer. In teams of 3 and 4, this will not be as big a deal, however when teams reach 8 (or 50 in some extreme cases), you end up with more than half your time being spent in status or planning meetings. All developers are NOT equal, and likewise, not every developer should be treated as the lead engineer of any given project. It leads to vast amounts of wasted time and incredibly boring and tedious times at work.

I could definitely continue on and on with more disadvantages of Agile… But hopefully, these few examples with explanations outweigh his small list.

Nice (and amusing) to see this thread turning into an actual thread about agile development :p

@Kevin; your number 6 is completely off topic from OP's..

Not sure if that was a rant based on experience or not.. Indeed agile is good for small projects but horrible for large ones.

Predictability of costs and schedules is certainly valid and had nothing to do with developers being equal or working in teams of 50.. This is the same whether you work in a large or small team. So do go on.. If as a junior developer you cannot predict how long it'll take you to complete a task or goal and an estimated cost as well as costs of mistakes, you're fired. As a senior it's even worse with the business aspect intact.

#6 has no disadvantage.. I didn't read the other points because I had no problem with them in your previous reply.. Not sure how predictability and scheduling can be your most hated aspect..

From: Brandon
If as a junior developer you cannot predict how long it'll take you to complete a task or goal and an estimated cost as well as costs of mistakes, you're fired.

They should consider that junior developers need some time to practice in the company, at least a year or two. You can't expect if you hire a just graduated employee, that he or she will understand how long tasks are going to take. Only stupid companies will fire people for that. It is just backfiring because with the current lack of good programmers, you might have just fired someone with potential.

@Brandon I fail to see how my #6 is off-topic unless the topic is merely 'Agile benefits' as opposed to 'Agile.' And if that's the case, I don't really see how many topics or discussions would get very far if you're only ever allowed to discuss the most beneficial aspects of a subject.

My reasoning for my distaste in Agile is entirely experience oriented. And I will absolutely acknowledge it is most definitely better in small teams than teams of medium or large size. That being said… In any sort of a larger professional environment, you will typically find yourself in teams of medium size as opposed to small. I've had projects of 3-4 people that have been absolutely great in Agile. The projects are small, design is small, user-testing after the fact is less of a problem, scope creeping can't happen on nearly the same scale, platforms are typically not nearly as necessary, and meetings are much fewer and farther in between.

However, once you get into larger projects, meetings will increase exponentially; that is a definite disadvantage of Agile, and is very related to the Agile methodology. If you pay people to spend 50% of their time meeting about a project instead of working on it, less time is spent developing, and the project costs more. Period. Whether or not it was successfully predicted, it costs more as a result - AND from a morale standpoint, developers tend to dislike their work more, put out lower qualities of development, and many times will leave the company. I don't really see how that isn't a disadvantage.

As for His #6 being my most hated… I didn't say that, nor did I mean to imply it. My list was an entirely separate numbered list not correlating to his numbers - it's simply a list of disadvantages. In small projects #6 is very true. In larger projects, costs aren't very predictable due to a few of the reasons I mentioned.

And with Juniors being fired for inaccurate time assessments, I don't see how that relates to the subject as much; nonetheless, I agree heavily with MasterBB. I've never been to/heard of a company that would fire a junior developer for that. Now… A dev with 1.5+ years of experience with the company is a different story…

From: Kevin
6. And my most disliked feature of Agile..
As for His #6 being my most hated.. My list was an entirely separate numbered list not correlating to his numbers..
And yes, #7 is fairly well true, and in turn, #8 becomes true.

Then what exactly are you talking about? What is "my most hated".. You agreed that we're talking about the same #7 and #8 but somehow a different #6 ? If your list is indeed different from his, then you completely lost me in this discussion. The point of my very first reply was to point out that OP's #6 , #7 and #8 has not many disadvantages and that not all developers hate them.

I'm not sure exactly how predicting costs and predicting schedules or completion time whether it be in Agile or not can be a disadvantage. I've mentioned this before. Is it no longer a good thing to do predictions/forecasting?

Maybe this will help: http://www.linkedin.com/groups/Predictability-in-agile-software-delivery-4685263.S.5802369075149549572


My favourite answer is:

Steve G.
Problem Solver

What good is a prediction of how long a project will take to complete and how much it will cost when it is based on a flawed prediction of what completion of the project really means and compared with a flawed prediction of the business value of the completed project.

Now I'm not sure if this is a flaw in prediction/forecasting itself or in choosing Agile for the wrong project.


As for firing of a junior dev, I do agree that a senior (maybe systems analyst jr/sr instead of dev) would take care of scheduling of tasks.. I guess..

From: Brandon
Then what exactly are you talking about?

He had presented a list of pros, I presented the opposite side of the coin: a list of cons, including a detailed explanation for why each of my statements held true. Throwing my statements into that specific order as you just quoted would be quite confusing… However, that is not the order I stated them, nor do they each remain relevant to the exact same point of discussion as a result.

I acknowledged that 6, 7, & 8 are advertised benefits. I agreed that 7 & 8 are true. I disagreed with his 6 actually applies to the Agile methodology however. That portion of the reply is what was directly involved in your comment. Then I gave a counter-list of disadvantages to Agile along with detailed reasoning for each of my points, based on experience with multiple companies who use Agile as well as experience having had read the Agile handbook, analyzed from a developer standpoint.

In no way am I stating that accurate predictions of time or cost are in any manner negative. That is not what I'm trying to say. I'm trying to say that Agile, as a methodology, is incapable of accurately delivering those predictions, in projects of any medium or larger size. The larger a project is, the less accurate Agile is. I have already acknowledged that Agile is much better in a smaller environment; however I vocally made my negative points to apply to a more generic and average project styling, which tends to consist of more than a few months or people in size.

From: Kevin

In no way am I stating that accurate predictions of time or cost are in any manner negative. That is not what I'm trying to say. I'm trying to say that Agile, as a methodology, is incapable of accurately delivering those predictions, in projects of any medium or larger size. The larger a project is, the less accurate Agile is. I have already acknowledged that Agile is much better in a smaller environment; however I vocally made my negative points to apply to a more generic and average project styling, which tends to consist of more than a few months or people in size.

Ohh I see. In that case I am in agreement.