This time On Agile Methodologies

Hi,
I've been reading more about SW development methodologies. I found this article: The New Methodology by Martin Fowler and I wanted to share it with you. I find it excellent, specially for people who are developing business applications, it has openned my eyes.

To summarise, Fowler says that (and I agree): ... as modern organizations evolve and adapt to their environments rapidly so should software development.

Traditional development methodologies (waterfall lifecycle) were created upon the assumption that requirements never change. Software were created based on a snapshot of the organization's situation. Projects (price, time and design) were planned in advance and any deviation from them were considered a mistake which had to be corrected.

Agile methodologies are based on the assumption that organisations, users, and their requirements change. Agile methodologies are designed to adapt to changes: they are selfadaptive. To achieve that, users and developers work together and expect change all the time. Requirements, specs and code are reviewed constatly and changed when necessary. For Agile(rs) (is that a word?) things cannot be predicted. They aim for a good quality software that meets the needs of the clients and not for meeting the deadlines and not running over the budget.

It makes a lot of sense, doesn't it?

I have two questions though:
1. Will a client invest his money in a project without knowing how much $$$$ and time it will take?
2. Agile methods focus on the creation part of the software (for example until you finish a complete version). But there is nothing about what comes next. (at least not to my knowledge) If you are working in an bank for example, you may find that not every project is about new application but maintaining the old ones. Do you still use agile methodologies for everyday maintenance?

Excellent read - thanks :)

We've been working a large contract for customer for almost 3 years now. It was supposed to take 18 months - that proved impossible. Even after we delivered the first 2 of 5 sub-systems, the first ones requirements changed dramatically. We got extra $$'s for re-working that portion.

I don't think the customer would have accepted an open ended, no $$ max contract - but in reality that is what they ended up with.

We've done a good job a "managing expectations" differently over the past 6 months so that us poor developers don't take all the grief for the project status. We realized we were doing development, implementation and general project management. We started to focus on only development - the customer hired a consultant to help them understand project management and become responsible for implementation.

We now charge $$'s for any work done outside the scope of the original project and outside the scope of development.

We expect to be nearly done with all coding in the next 2 or 3 months and expect the be paid for the implementation phase - which was not even a phase that the customer understood 3 years ago.

szlamany thanks for your comments.
I think you are experiencing the most common of the situations in software development, changes in requirements. I believe it's not always the client's or the analyst's fault. Situations (and requirements) change always. I think that the most important change to come is a change in our attitude.

I found this article Incrementalists and completionists it has a very good description of two different personalities in SW development.

Maybe what we need in every (agile) SW development project is a combination of incrementalists and completionists, the former to do the everyday job, the latter to keep in mind the big picture.

I think the very definition of software has to change. Everyone thinks that they want software like they want a lawnmower.

I think what they really want is a solution to a problem, and they will never know the extent of the problem. The trick will be to change peoples' minds into believing that they do not want a lawnmower, and instead want a piece of your intelligence and a slice of your service.

This is not something you can pick up at a hardware store (or a software store).

LOL. 2 kinds of people buy lawnmowers: 1) those who don't currently have one, and 2) those that do, but have broken them

It's not like they're thinking, boy, I've got to get a lawnmower, so I can plant some grass seed, and grow a yard!

Software is different. People have a program that they want solved, usually, and are willing to try anything that they think can solve their problem.

(lucky the hardware stores don't sell cows!)

Quote:

---

Originally Posted by Mutant

I have two questions though:
1. Will a client invest his money in a project without knowing how much $$$$ and time it will take?
2. Agile methods focus on the creation part of the software (for example until you finish a complete version). But there is nothing about what comes next. (at least not to my knowledge) If you are working in an bank for example, you may find that not every project is about new application but maintaining the old ones. Do you still use agile methodologies for everyday maintenance?

---

Along with what was already said about having a price but the project changes changing the price as well. I was reading a java book about one of the agile concepts (nunit testing) and in it he talked about the developement cycle. I think as 'features' of an application change due to customer demand you should discuss the the 'cost' of that change both in time and money to the project. Then you let them decide if they still want it or what kind of a priority it should be. This makes the client more in control and accountable for lengthing deadlines or inflated costs. You figure your original estimate was for what was originally asked for but as what is being asked of you evolves then the cost and time should evolve with it. This also targets the second question and the agile cycle would restart with a new phase or feature release or upon the next major change. So for existing projects you could tie up loose ends and then decide ok with the next feature we will start to use agile concepts.