Whats are drawbacks of Agile methodology?

[Manoj Kumkumath]

The reason for this question is post by Ilja Preuss

team doing iterative software development could still value

processes and tools over people and interactions,
comprehensive documentation over working software,
contract negotiation over customer collaboration, and
following a plan over responding to change

I am working on a project which follow Agile methodology. So far life is good. But I feel skeptical about how good this methodology will be when you have a client who knows nothing about technology, but never ready to comprise a dead line(Every thing should be ready be next Friday. I mean everything. I am paying money to you guys. )and always comes up with changes from the original plan. In these scenarios, isn�t it better to have comprehensive documentation and contract negotiation?

Any interesting/horrible experience anybody would like share?
-Manoj

[Ilja Preuss]

Originally posted by Manoj Kumkumath:
I feel skeptical about how good this methodology will be when you have a client who knows nothing about technology, but never ready to comprise a dead line

The preferred "Agile way" of managing a project is by scope, not by deadline. That is, you have a timebox you adhere to, and adjust the plan by changing what will be done until the fixed deadline.

(Every thing should be ready be next Friday. I mean everything. I am paying money to you guys. )

What does being paid by that guy have to do with your ability to do the impossible? That is, why does he expect you to get everything, just because he is paying you?

and always comes up with changes from the original plan.

Changes from the original plan are good - someone learned something, and you are able to accommodate to that new knowledge immediately. Being able to do that reduces waste and provides more value to the customer.

In these scenarios, isn�t it better to have comprehensive documentation and contract negotiation?

You mean, to prevent change? Wouldn't that just leading to the customer getting a system he actually doesn't want or need? How would that be good?

From what I can tell, what you need to do is making the costs of the changes obvious, so that the customer can make better decisions.

"OK, we committed to doing X and Y until friday. Now you also want to get Z done, because it's important to you. Obviously, we don't suddenly have more time until friday, so something else has to be postponed. We already started implementing X, because you said that it's more important than Y. Because Z seems to be less work than Y, we could split Y into Y' and Y'', and do X, Y' and Z until friday. Would that provide more value to you than X and Y?"

[Manoj Kumkumath]

Thank you for your thoughts.

I agree that Agile methodology provides benefits. I experienced it in my projects. There is no last time hiccups and things are predictable.

But let me compare how I do things now with how we used to do earlier.

Earlier I used to work for project based company who used to execute projects for external clients who usually don't have anything to do with IT. So we used to make documentation a must. These external clients are coming with a fixed deadline projects and I believe all the financial aspects are agreed even before writing the first line of code. But sadly the clients requirements evolve only during time. But they seldom accept that this is not what they first told us. So usually we go back to the documentation and say "see this is what we accepted. Now if you want a change, we can do it. But it will cost you more".

Now in my present company, we use agile methodology. But the products are for us also. So always there is a better level of understanding. So documentation is not a big issue.

I hate doing documentation. And I really love working in agile way. But I still fail to see how agile methodology takes away importance of documentation. In a bad day, I feel I have only my documentation to back me up.

[Manoj Kumkumath]

oops..
I didn't ask the question...

So do you feel that agile methodolgy won't be a good idea for some projects?

Also
Is there any scenarios where you won't suggest agile way of doing things?

[Scott Ambler]

when you have a client who knows nothing about technology, but never ready to comprise a dead line(Every thing should be ready be next Friday. I mean everything. I am paying money to you guys

If your client is a nutjob then you're likely in trouble no matter what process you follow. At least with agile approaches this becomes very clear, very quickly, and you're able to do something about it.

Earlier I used to work for project based company who used to execute projects for external clients who usually don't have anything to do with IT. So we used to make documentation a must. These external clients are coming with a fixed deadline projects and I believe all the financial aspects are agreed even before writing the first line of code. But sadly the clients requirements evolve only during time. But they seldom accept that this is not what they first told us. So usually we go back to the documentation and say "see this is what we accepted. Now if you want a change, we can do it. But it will cost you more".

Yes, this is a very common and very stupid way of working. The client doesn't get what they want and likely wastes their money even though they think that they're managing financial risk. See Examining BRUF for a detailed discussion.

I hate doing documentation. And I really love working in agile way. But I still fail to see how agile methodology takes away importance of documentation. In a bad day, I feel I have only my documentation to back me up.

Wouldn't it be better to have working software backing you up instead? See Agile Requirements Change Management.

So do you feel that agile methodolgy won't be a good idea for some projects?

Also
Is there any scenarios where you won't suggest agile way of doing things?

Agile likely won't work when:
1. People are inflexible and/or unable to react to change, then agile is likely too hard for them.
2. Stakeholders are unwilling to be actively involved. The need to provide information and make decisions in a timely manner.
3. You don't have good developers. There's growing consensus within the community that agile developers are typically in the top quartile of the industry.

- Scott

[Reid M. Pinchback]

Originally posted by Scott Ambler:
Agile likely won't work when:
...

I'd add another one. It would be tough to make Agile (or any sane process for that matter) work well when one or more of the parties in the contract has a zero-sum-game mentality; in other words, they feel they win by screwing everybody else over as much as others are willing to let them. There are companies and people who will treat any contractual weakness as an open invitation to rip your throat out, metaphorically speaking. It is a stupid, inefficient way of working, but in some projects there is enough money involved that at the upper management level they want the deal anyways (and probably justifiably), yet at the developer level you are stuck with the nutjob behaviours. Trying to have any collaborative attitude or process, Agile or otherwise, will be tough in such situations... and odds are the code will reflect that.

[Jeanne Boyarsky]

Originally posted by Ilja Preuss:
What does being paid by that guy have to do with your ability to do the impossible? That is, why does he expect you to get everything, just because he is paying you?

However from the client's point of view you can "manufacture" more time between now and Friday by working more hours. This isn't agile (or any other process that I know of), but it does fit in with the triangle of cost/time/scope/quality. If he pays you more, it affects time/scope. Unfortunately, it also affects quality.

[Manoj Kumkumath]

Thanks all for your valuable feedback.

Scott,
In your article �Agile Requirements Change Management�, you are talking about Potential challenges to this approach and one item is "Your stakeholders might prioritize the requirements in such a way as to push an architecturally significant (read devastating) requirement several months out".

How much is the chance for such changes to come in a later stage of iterations Since we give so much importance to have a production quality software with relatively minimum requirement gathering efforts comparing to an iterative SDLC model? How best agile development deals with these scenarios?

It is a stupid, inefficient way of working, but in some projects there is enough money involved that at the upper management level they want the deal anyways (and probably justifiably), yet at the developer level you are stuck with the nutjob behaviours.

You said it and at these points in life I became a great fan of documentation.

Also I am wondering how well a new team can take up the existing application for support/maintenance especially in projects where you have more than 25 people working in team. You will have working software and you know the effect when you make a change. But how will you know what actually the application is doing? How easy it's going to be to go through the code and find out if you don't have a proper docs in place. I saw somewhere in net that having virtual development team can also spoil the show.
[ March 09, 2006: Message edited by: Manoj Kumkumath ]

[Reid M. Pinchback]

Originally posted by Manoj Kumkumath:
But how will you know what actually the application is doing? How easy it's going to be to go through the code and find out if you don't have a proper docs in place.

This can be a tough situation to be in with a large existing code base, and without docs or automated tests you are definitely living in an unpleasant space. Sometimes even with the docs it is an unpleasant space because what the docs say and what the code does might not be as much in sync as you'd hope. I like having the docs, but I dislike the absence of automated tests for that reason.

The non-lightweight-method approaches I've seen typically involve throwing small armies of QA people into the mix. While QA folks have their role, their participation doesn't magically turn any badness in the code base into something good. Also, since QA activities can have a real needle-in-the-haystack-search quality to them, sometimes it seems like they aren't all that much more likely to spot important problems than the developer him/herself. If even the developer isn't sure what the app is doing, then possibly *neither* the developer nor QA spots the problems - customers do instead (aka the Microsoft product release model ).

The only solution I've found for this is to start adding unit tests. Even if you don't know what the entire app is doing, at least you can add tests for what you think a particular section of the app is doing. Over time, as you learn more about the app, you add more tests. It definitely isn't an overnight process, something you do in bits and pieces over the span of weeks and months (depending on the size of the code base). At least that way you gain some confidence that you know what is going on in portions of the application. Works pretty well as long as you make the effort to write true unit tests and not get bogged down in too many unmaintainable integration tests.

[Manoj Kumkumath]

The only solution I've found for this is to start adding unit tests. Even if you don't know what the entire app is doing, at least you can add tests for what you think a particular section of the app is doing.

It really help to have test coverage when the same members are maintaining the application during it's entire life period. But consider a company where atrrition rate is high and bunch of new developers take over the application. Assume they have an issue, they can make changes to the code confidently since they have UTs to back them up. But how will they understand about architecture? How will they know about what class is doing what? May be you need tests which tells exactly what you are doing. That means you need developers whose code is very much readable. Ultimately you are looking for developers who are very good OOP and also good in expressing the concepts in code.

Don't you think this makes projects very much developer centric?

[Manoj Kumkumath]

If even the developer isn't sure what the app is doing, then possibly *neither* the developer nor QA spots the problems - customers do instead (aka the Microsoft product release model ).

means we need the customer interaction on a day to day basis. Usually what I have seen in projects is a developer to a business analyst and from business analyst to end user interaction. This middle man can some time really make your life hell ( Hope all the good analysts I have worked with will pardon me for this comment).

[Reid M. Pinchback]

Originally posted by Manoj Kumkumath:
Don't you think this makes projects very much developer centric?

If by that you mean do I think that the skills and professionalism of the specific developers influence the outcome (where the outcome is how well understood and maintainable the code is), then the answer is definitely yes. Not "developer centric" in the sense that only the original developer understands it - that is what you definitely have without readable code and good unit tests.

I've known people who believe that you can have a software process that, independent of whoever the specific developers are, will still ensure some good result. I'd like to believe that too, if I'd ever once seen or even heard rumour of a situation where it was even close to true. Depending on the website/forum you choose to hang out in you can find people who will fight ferociously for any particular methodology be it lightweight (e.g. agile, xp) or heavyweight (typical SDLC implementations). If lightweight processes have any one broad advantage (independent of tediously repetitive religious wars which people seem to just love participating in), I think it is that they don't ignore the obvious reality that individual skills have to influence the outcome, so improving skills and knowledge is something that should be integrated into the process.
[ March 09, 2006: Message edited by: Reid M. Pinchback ]

[Reid M. Pinchback]

Originally posted by Manoj Kumkumath:
This middle man can some time really make your life hell

Ain't it the truth?

I don't think that is even just specifically a B/A issue. You can get bad problems with any kind of middle-man (e.g. project manager) that creates a strong separation between two groups that need to be in sync with each other. Too much information loss and too much time lag. Also, when two groups (developers vs customer, developers vs QA, etc.) don't interact, they tend to make assumptions about each other's work that trivializes their role in the process. Not healthy. B/As I think are good as facilitators and information gatherers (particularly in complex business areas where the B/A knows the entire business scope better than either the developers or the end-users), but shouldn't continually gate information flow between key participants.
[ March 09, 2006: Message edited by: Reid M. Pinchback ]

[Manoj Kumkumath]

Depending on the website/forum you choose to hang out in you can find people who will fight ferociously for any particular methodology be it lightweight (e.g. agile, xp) or heavyweight (typical SDLC implementations).

I couldn't find any site which really fights for the poor old SDLC. But I could find a lot of sites which literally tells Agile is solution to all your problems.

If by that you mean do I think that the skills and professionalism of the specific developers influence the outcome (where the outcome is how well understood and maintainable the code is), then the answer is definitely yes. Not "developer centric" in the sense that only the original developer understands it - that is what you definitely have without readable code and good unit tests.

But regardless of methodology, don't you think this is true?

I don't think that is even just specifically a B/A issue.

My point here is that even in a agile way of doing things, do you really interact with end users or with a B/A? May be I am an unlucky fellow

[Scott Ambler]

"Your stakeholders might prioritize the requirements in such a way as to push an architecturally significant (read devastating) requirement several months out".

How much is the chance for such changes to come in a later stage of iterations Since we give so much importance to have a production quality software with relatively minimum requirement gathering efforts comparing to an iterative SDLC model? How best agile development deals with these scenarios?

I don't know, I've never actually had it happen to me in practice. If you have a good relationship with your stakeholders, something that I always ensure that I do, then it's pretty easy to get them to change their priorities on a few things. The reality is that business-critical requirements also seem to be architecturally significant too, although every so often this might not be the case. In those situations I discuss the requirement with the stakeholder, let them know what I think, and let them decide how to prioritize it appropriately.

Also I am wondering how well a new team can take up the existing application for support/maintenance especially in projects where you have more than 25 people working in team. You will have working software and you know the effect when you make a change. But how will you know what actually the application is doing? How easy it's going to be to go through the code and find out if you don't have a proper docs in place. I saw somewhere in net that having virtual development team can also spoil the show.

Handing the system off to another team is also a spectacularly questionable way to work, although many organizations choose to work this way. The answer is that you need to invest in system overview documentation that meets their actual needs. See Agile Documentation. You should also focus on writing high-quality source code with a full unit test suite. When you do that you'll discover it's a lot easier for outsiders to learn to use the system.

My advice is that some of the people on the maintenance team should also be on the development team, that way you don't run into these problems.

But consider a company where atrrition rate is high and bunch of new developers take over the application.

HR problems should be solved by HR solutions, not by bureaucratic processes. Address the actual problem, the high attrition rate, don't put a process band-aid on it.

But how will they understand about architecture?

A well written, concise overview document can do that. That's why the Agile Documentation article is important.

That means you need developers whose code is very much readable. Ultimately you are looking for developers who are very good OOP and also good in expressing the concepts in code.

Exactly. Sounds like an HR issue, doesn't it?

means we need the customer interaction on a day to day basis. Usually what I have seen in projects is a developer to a business analyst and from business analyst to end user interaction. This middle man can some time really make your life hell ( Hope all the good analysts I have worked with will pardon me for this comment).

Yes, this is also a spectacularly questionable way to work. Active Stakeholder Participation, not Business Analyst Middlemen is what you need.

I couldn't find any site which really fights for the poor old SDLC. But I could find a lot of sites which literally tells Agile is solution to all your problems.

Spend some time with the data management community, it's shocking. Also, see The Glacial Methodology, which is meant as a joke but I've actually gotten requests from companies for me to do training in it.

in a agile way of doing things, do you really interact with end users or with a B/A?

My teams interact with the actual stakeholders.

- Scott

[Manoj Kumkumath]

quote:
--------------------------------------------------------------------------------
But consider a company where atrrition rate is high and bunch of new developers take over the application.
--------------------------------------------------------------------------------



HR problems should be solved by HR solutions, not by bureaucratic processes. Address the actual problem, the high attrition rate, don't put a process band-aid on it.

Attrition is just one problem. If you are an non IT company and you give the contract to one IT company for developing a solution, why do you have to depend on them till the end of days. Some way down the line another company can offer you the same support for less price and at that point I am sure you want that to be smooth transfer.

[Reid M. Pinchback]

My point here is that even in a agile way of doing things, do you really interact with end users or with a B/A?

I believe the Agile philosophy is that developers tend to interact with end-users. I agree with that as a broad principle, but I know of counter-examples where you could run into snags if you are aren't flexible (agile?) about that issue because the end users/stake holders you *wish* were involved aren't even part of the same organization, or key players refuse to participate as much as would be beneficial.

That tends to be where I think B/As who specialize in an industry can be really useful; they've spent 5 or 10 years learning the busines processes that end-users in stove-pipe organizations don't even understand themselves (e.g. banking, trading). I also knew one B/A that had to extract critical info in bits and pieces over time from people who make it very clear to him they wouldn't be bugged frequently by development issues (people with big enough salaries and clout that they got what they want, period). Not claiming the situation was particularly efficient, just that people probably making 5 times your salary aren't always going to change their process to suit you unless they think it'll make them 10 times your salary.
[ March 09, 2006: Message edited by: Reid M. Pinchback ]

[Reid M. Pinchback]

Originally posted by Manoj Kumkumath:
Attrition is just one problem. If you are an non IT company and you give the contract to one IT company for developing a solution, why do you have to depend on them till the end of days. Some way down the line another company can offer you the same support for less price and at that point I am sure you want that to be smooth transfer.

I valid point, but I think we need to keep track of who is trying to solve what problem. In a situation like you've described, there probably isn't much motivation for the IT company to make transfers smooth! The client company is really the one who cares about the quality of the work, but in an outsourced situation that can be exceedingly difficult to achieve.

From what I've seen, if the contract terms for the outsourcing don't give you the ability to refuse payment for work that doesn't meet your standards, you are stuck with pretty random results. I can imagine how the IT/outsource firm internally could choose to be agile, I can imagine how the client could choose to be agile, but I suspect you are only going to truly see the benefits of agility if both those firms are willing to view themselves as part of one team, either because they are that professional and motivated or because the economics of the contract help to reinforce good behaviours and penalize bad ones. The former is less draining on people than the latter, because in the contract model somebody in the client firm has to have the job of being the mean paranoid SOB. I talked to somebody once that did that and apparently it worked for them for managing outsourced work quality, but I don't think it would have been much fun working on that project (particularly if you had to be the SOB).

I think people also need to be careful about that "for the same price" issue. Total cost of ownership isn't the same thing as bait-and-switch pricing. I'm inclined to believe you don't get what you don't pay for. Doesn't mean you shouldn't pay attention to economics, just that taking prices at face value is silly (and yet so many do it...).
[ March 09, 2006: Message edited by: Reid M. Pinchback ]

[Manoj Kumkumath]

That tends to be where I think B/As who specialize in an industry can be really useful; they've spent 5 or 10 years learning the busines processes that end-users in stove-pipe organizations don't even understand themselves (e.g. banking, trading). I also knew one B/A that had to extract critical info in bits and pieces over time from people who make it very clear to him they wouldn't be bugged frequently by development issues (people with big enough salaries and clout that they got what they want, period).

I agree. I do sometime feel that B/A are the people who happened to be there at the right time ( for a developer) at the wrong place(for him ).

I can imagine how the IT/outsource firm internally could choose to be agile, I can imagine how the client could choose to be agile, but I suspect you are only going to truly see the benefits of agility if both those firms are willing to view themselves as part of one team, either because they are that professional and motivated or because the economics of the contract help to reinforce good behaviours and penalize bad ones.

But in a pure business perspective, it may be highly required ( Ok not my area. So only logical assumptions). For an example, for an non IT company it makes real sense to outsource that work to a proven IT company since it provides them less cost and more freedom to do what they are best in doing. But in the same time they really won't like the dependency.
[ March 09, 2006: Message edited by: Manoj Kumkumath ]

[Scott Ambler]

Attrition is just one problem. If you are an non IT company and you give the contract to one IT company for developing a solution, why do you have to depend on them till the end of days.

Because you've chosen to work that way? Because you're unable to manage your business effectively?

Some way down the line another company can offer you the same support for less price and at that point I am sure you want that to be smooth transfer.

Yes, so why wouldn't you put that into the contract with the new vendor and stick it to them?

I believe the Agile philosophy is that developers tend to interact with end-users. I agree with that as a broad principle, but I know of counter-examples where you could run into snags if you are aren't flexible (agile?) about that issue because the end users/stake holders you *wish* were involved aren't even part of the same organization, or key players refuse to participate as much as would be beneficial.

Agreed, and there are ways to deal with that issue. BAs are one approach to dealing with outsiders, but perhaps you could get the outsiders to be involved if you tried a bit harder.

If you can't convince stakeholders to be actively involved with the project, perhaps it isn't important enough to be done in the first place. See Gaining Stakeholder Access.

That tends to be where I think B/As who specialize in an industry can be really useful; they've spent 5 or 10 years learning the busines processes that end-users in stove-pipe organizations don't even understand themselves (e.g. banking, trading). I also knew one B/A that had to extract critical info in bits and pieces over time from people who make it very clear to him they wouldn't be bugged frequently by development issues (people with big enough salaries and clout that they got what they want, period). Not claiming the situation was particularly efficient, just that people probably making 5 times your salary aren't always going to change their process to suit you unless they think it'll make them 10 times your salary

Sounds like another HR problem to me.

But in a pure business perspective, it may be highly required ( Ok not my area. So only logical assumptions). For an example, for an non IT company it makes real sense to outsource that work to a proven IT company since it provides them less cost and more freedom to do what they are best in doing. But in the same time they really won't like the dependency.

Sounds like the marketing pitch of an outsourcing company. You're right, once they've outsourced IT they've disposed of a mission-critical portion of their business which they will find very difficult to "insource" if they ever decide that it was a mistake to outsource it.

- Scott

[Reid M. Pinchback]

Originally posted by Scott Ambler:
If you can't convince stakeholders to be actively involved with the project, perhaps it isn't important enough to be done in the first place.

I love the smell of developer empowerment in the morning! Just brings to mind Monty-Pythonesque images of a half dozen developers on a sub-team on a 200-person project walking off in a huff because a senior manager in a different business line responsible for the operations of a 100-million+ division won't play nice with them.
[ March 10, 2006: Message edited by: Reid M. Pinchback ]

[Manoj Kumkumath]

Sounds like the marketing pitch of an outsourcing company. You're right, once they've outsourced IT they've disposed of a mission-critical portion of their business which they will find very difficult to "insource" if they ever decide that it was a mistake to outsource it.

I decided to wait and watch.

Reid and Scott - Thanks you very much for time and effort.

[Bert Bates]

Hey Scott and company -

This is a very interesting thread!

I wonder if you guys could throw in your two cents about these two quotes from wikipedia, which mention two other potential drawbacks to the Agile approach?

#1 -

wikipedia says a drawback of agile is: Agile processes seem to be more efficient than older methodologies, using less programmer time to produce more functional, higher quality software, but have the drawback from a business perspective that they do not provide long-term planning capability. In essence, they say that they will provide the most bang for the buck, but won't say exactly what the bang will be.

#2 -

wikipedia also says: "Agile software development processes are built on the foundation of iterative development"... While Iterative development approaches have their advantages, software architects are still faced with the challenge of creating a reliable foundation upon which to develop. Such a foundation often requires a fair amount of upfront analysis and prototyping to build a development model. The development model often relies upon specific design patterns and entity relationship diagrams (ERD). Without this upfront foundation, Iterative development can create long term challenges that are significant in terms of cost and quality.

Thanks,

Bert

[Ilja Preuss]

Originally posted by Bert Bates:
In essence, they say that they will provide the most bang for the buck, but won't say exactly what the bang will be.

But the same is true for non-Agile methods. Or do you actually know a long term project that delivered exactly in time, in budget, in scope?

Agile projects can, and do, provide long term extrapolations of what will be possible. The just don't cast it in stone, because they consider that it's just an estimate which will get more accurate over time.

software architects are still faced with the challenge of creating a reliable foundation upon which to develop. Such a foundation often requires a fair amount of upfront analysis and prototyping to build a development model. The development model often relies upon specific design patterns and entity relationship diagrams (ERD). Without this upfront foundation, Iterative development can create long term challenges that are significant in terms of cost and quality.

The premise of Agile methods is that, if done right, only a minimal amount of upfront foundation is necessary, most of those risks can be addressed iteratively. The role of an architect in an Agile team isn't to develop the initial architecture, but to guide the team in making good, iterative decisions over the course of the whole project.

Scott has an article about this on his AM website: http://www.agilemodeling.com/essays/agileArchitecture.htm#IterateAndIncrement

[Reid M. Pinchback]

Originally posted by Bert Bates:
but have the drawback from a business perspective that they do not provide long-term planning capability

I'm with Ilja on point #1. I don't think this is intrinsically an Agile versus non-Agile issue, particularly for the part I quoted. I'd argue that this has more to do with the quality of project management and the executive-level incorporation of the project information, particularly with how effectively you create an information feedback mechanism between developers and whoever is stuck wearing the project manager hat and the levels above them.

One of the hardest messages as a PM to get through to people is that plans and schedule estimates aren't random. They may not be perfect, but from a statistical regression-towards-the-mean they can get pretty good. If you have a process for creating them that is broken, particularly if those plans are created in a way that is *independent* of what the developers know or are experiencing, any notion of long-term planning and estimating is completely a game of smoke, mirrors, politics, and self-deception... but never anything even close to accuracy or consistency.

However the planning starts, for it to continue to have value it has to evolve sanely, which means it needs data, and Agile approaches like Scrum are big on getting exactly the kind of data you want to have as a PM. The difficulty isn't with having Agile people gather the data and massaging with it the PM into something meaningful. The difficulty is with getting people who don't understand projects or project management *listening* to what they are being told when the plan or estimate is now more accurate. Accurate software project estimates scare the stuffing out of the higher-ups.
[ March 19, 2006: Message edited by: Reid M. Pinchback ]

[Reid M. Pinchback]

Originally posted by Scott Ambler:
Sounds like another HR problem to me.

They definitely had a few of those. :roll:

[Bert Bates]

Accurate software project estimates scare the stuffing out of the higher-ups.

I was a consultant for a long time, and we used to joke that if 'upper management' really knew up front how much time and money any given project was really going to take, most projects would never even get started.

That said, I brought those two issues up because they have the ring of truth to me (although I tend towards believing in the Agile end of the continuum).

It strikes me that Agile would be tough on really large projects or on really complex projects. For instance, my gut reaction (not based on any deep thought or research!) is that I don't want to fly in a 747 that was built using Agile methodologies.

Unfortunately, I'm not in a position to be a great advocate for SDLC-esque approaches, but I'd really like to hear about situations when an SDLC-esque approach really makes the most sense.

[Reid M. Pinchback]

Originally posted by Bert Bates:
Such a foundation often requires a fair amount of upfront analysis and prototyping to build a development model. The development model often relies upon specific design patterns and entity relationship diagrams (ERD). Without this upfront foundation, Iterative development can create long term challenges that are significant in terms of cost and quality.

I also think this isn't truly an Agile vs non-Agile issue, but there is a kernel in here that has a bit of traction in terms of up-front versus iterative, but I think is really something else in disguise. I'll get to the something in disguise later. Long post, bear with me.

I don't personally object to the up-front model, but I object to the notion that the up-front work is invariably near-flawless. That is the fundamental difference I think between the up-front versus the iterative approaches, and it isn't an issue of textbook definition of their tasks, but of the behaviour you see in people (at least in large organizations) when something goes wrong.

When you work iteratively, it isn't a big surprise if you hit a problem and go "oops, we goofed, we have to really rethink this widget implementation before adding the next feature; time to haul out the heavy-duty refactoring plugin...". The problem may be unwanted, but in general why would people freak out over the need to change current code when changing current code is a routine situation anyways?

The up-front situation is different, and not necessarily because of the flesh-and-blood human being (i.e. another developer, so we should sympathize) wearing the architect hat. Anybody truly skilled enough to be an architect should be equally capable of coping with technical problems when it turns out the up-front work missed an issue. The true problem is often going to be with the people around the architect... even with developers around the architect. The unstated problem for up-front design is that some organizational dynamics make it near impossible to identify and take corrective action for big problems (sometimes even for small problems).

For companies *without* that kind of blame-averse/risk-averse dynamic, they could probably make solid cases for why up-front design works for them. Even if they don't talk about iterating, when the design breaks down, they'll end up with an iteration (which they may call "the next release"). Alas, for companies *with* the negative blame-averse dynamic, they'll stick with the design. Yes, the design now known not to work. The implementation code will duck and weave and contort until eventually, if everybody is really lucky, somehow something approximating the original design is achieved. It may be slow as a pig, cost 10 times as much to write the code and QA it, and require 10 times as much hardware to run it, but it will be done.

As a result of all that, Agile people can make a very legitimate case that for blame-averse organizations, the risk of up-front design is even higher than it is for iterative development, which tends to hit larger numbers of small (low anxiety) issues, not small numbers of show-stopping (high-anxiety) issues.

And now for the something in disguise, something I learned from a really smart team lead/boss I had once upon a time. Developers who spend a lot of their career working in the I/T and systems integration space think differently than those who work primarily in the application development space. Not good versus bad, just different. His view, I've come to find that he was correct, and that the issue matters for some classes of project.

If all your coders on a project come from the application space, iteration can spend a lot of time before somebody realizes that the project objectives are literally impossible because other things in the organization render the objectives impossible. This is particularly true when nobody does even a quick first pass at a data model to figure out who *outside* of your project will depend on your data, or vice versa. This isn't an Agile vs non-Agile issue, this is a "your skills reflect your experience" issue.

However, since these problems do come up, now the up-front argument seems to have legs. Now you can make the case "but if you did an up-front design and it went through all the organizational review processes, we would have obviously spotted that this project was impossible". It is a correct statement because often such reviews can spot problems, however, I don't think this indicates a fundamental limitation in the Agile/iterative approach because reviews aren't the *only* way to spot such problems. I think it just means that in such situations, for an Agile team, the team should have somebody working with them who knows about issues the other team members haven't encountered before or aren't in the habit of caring about.

If you include an integration-savvy person who has a hot list of issues they always watch out for, they'll rush to spew them out in the very first meeting of the Agile team. Those issues should end up on some Scrum list somewhere, and the nitty-gritty details dug into as appropriate. Problem solved.
[ March 19, 2006: Message edited by: Reid M. Pinchback ]

[Reid M. Pinchback]

Originally posted by Bert Bates:
Unfortunately, I'm not in a position to be a great advocate for SDLC-esque approaches, but I'd really like to hear about situations when an SDLC-esque approach really makes the most sense.

Probably the trick is assigning the most context-appropriate interpretation to the bit "makes the most sense". You'll definitely see SDLC used now in life-and-limb situations like Aerospace and non-R&D Pharma. SDLC inefficiencies tend to not matter to people because the software cost is often a miniscule part of total project cost, and the extra cost of the inefficiency is miniscule in comparison to the risks of whatever bad events scare people in that particular industry. Good news if you are an SDLC consultant or tool vendor, not so much for anybody else.

Add to that, for in life-and-limb situations I think what you'll really find is SDLC on steroids. Lots of process controls, basically CMP level something-more-than-1 plus SDLC. Definitely that tends to be the case in Pharma, don't know about Aerospace.
[ March 19, 2006: Message edited by: Reid M. Pinchback ]

[Ilja Preuss]

Originally posted by Bert Bates:
I was a consultant for a long time, and we used to joke that if 'upper management' really knew up front how much time and money any given project was really going to take, most projects would never even get started.

Well, telling management what a project will really cost is just the first step of being Agile. The second is giving them more options to get the most bang for the buck - by actually enabling them to manage the project.

It strikes me that Agile would be tough on really large projects or on really complex projects.

Interestingly, Jutta Eckstein is known for saying that Agile development is *especially* important for large projects. You might want to take a look at http://www.jeckstein.de/agilebook/index.html

For instance, my gut reaction (not based on any deep thought or research!) is that I don't want to fly in a 747 that was built using Agile methodologies.

So you wouldn't want to fly in a 747 for which you know that every part of it has been automatically tested daily, which already was able to fly at the end of the first week of development, and where all the involved vendors were continously communicating face-to-face?

[Ilja Preuss]

Robert C. Martin just posted an interesting small article on architecture in his blog: http://www.butunclebob.com/ArticleS.UncleBob.ArchitectureIsaSecondaryEffect

[Bert Bates]

Hmmm...

My bad here - I haven't been clear.

In the real world, I'm a fan of Agile development. That said, I'm currently tasked with creating a document that describes (at a high level) the spectrum of methodolgies from Agile to SDLC. I need to come up with a plausible argument that sometimes an SDLC approach is better than an Agile approach So, I'm not here to be converted . I'm here to try to find such a situation.

I brought up a couple of (I thought) plausible scenarios, but you've all done a (pretty) good job of addressing those scenarios. It's still not clear to me how you do Agile when you have a HUGE development team, so that might be a scenario. The other possibility is that it seems like Agile tends to need more senior developers to be successful - does that ring true?

Thanks!

[David Rocks]

i have probably worked on about 6 agile projects in the last 7 years and my personal belief is that none of them were very agile, ( except the one i managed ) .

im personally blaming the implementation and not the actual process.

i thought RUP was restrictive but probably the most 'agile' project i was on ( pair programming, test, test, test ) ended up a disaster because the core beliefs of scope, money, quality and time were forgotten. they thought mock objects and unit testing in groups of 2 would save them. the team ended up mananging the tests more than the functional code.

we believe agile is a panacea to our pains and i dont think it really is. a good RUP project will always go better than a bad agile project. will a good RUP project go as well as a good agile project? that's an argument but i dont think there will be much difference.

[ March 20, 2006: Message edited by: David Rocks ]
[ March 20, 2006: Message edited by: David Rocks ]

[Ilja Preuss]

Originally posted by David Rocks:
a good RUP project will always go better than a bad agile project. will a good RUP project go as well as a good agile project?

Are you saying that a RUP project can't be Agile? Don't let Grady hear that...

[Ilja Preuss]

Bert, I don't know how much time you have left, but "Balancing Agility and Discipline" should be interesting to you...

[David Rocks]

Originally posted by Ilja Preuss:


Are you saying that a RUP project can't be Agile? Don't let Grady hear that...

true , i actually believe if we strip, what i consider, the bad bits out of the RUP process and do the same with agile we are left with very similar methods of development.

its the actual ability to create software and not the process which is the major issue today.

[Bert Bates]

Thanks Ilja. Looks like a good book, but kind of overkill at this point.

Help!

I'm appealing to all you SDLC fans out there - I need just one REALLY good example of where SDLC might be better than Agile... an example so good that even us Agile fans have to give it a little credit

[Don Morgan]

Here are a few cases:

* If your team works well already using SDLC, and you are given a critical project, similar to other projects done in the past, with the same team, you may want to stick with what works. (note there are alot of conditions here). Perhaps later explore if Agile works better for you, but this would not be the time to change.

* If the business you are in requires a strict SDLC (say for auditing reasons in the medical, aerospace or nuclear industry), you need to follow the required SDLC. I suppose it is just a personal preference, but I would not want to be on the first flight on a 747 which was "able" to fly at the end of the first week of development (I can just see it now, a couple of people standing beside a crash site... "That test failed. I guess we'd better start work on the landing functionality next week!").

* If there are legal consequences and a legal need to assign blame if the software project fails, is late, or for the consequences of defects in the software. (documents leave a much better trail than undocumented discussion). Obviously though this is not the right frame of mind to approach a software project.

* If you are outsourcing/offshoring a large development project and want it done fixed cost.

[Scott Ambler]

If you're interested in an agile approach to the RUP, you might find The Agile Unified Process (AUP) to be interesting.

And, the price is likely right. ;-)

- Scott

[Don Morgan]

One other one....

* There may also be cases in hardware oriented or embedded systems where the requirements for the software are almost completely defined by the higher level system requirements, in which case it may not make too much sense to start coding until a good portion of the overall system requirements are well understood, and a SDLC may work better than a strict Agile process. I would need to think more about this though...

Also, the term SDLC is used quite loosely in industry. I have seen it applied to everything ranging from more of a waterfall type process to incremental and iterative development.