How is work planned/done at your place?

[Soootylad]

No, I'm saying nail down their initial understood requirement, black and white. If they realise additional things are needed then additional costing is required.

"nailing down" a spec is time wasted when you could be "getting on with it"? Really not trying to be rude (a restraint you obviously don't have with the way you're talking to people) but you have one hell of an amateur approach mate, it's your process that would leave a bitter taste with any company worth their salt.

 

[Dj_Jestar]

Yes, so amateur that even the biggest of fish tout the same amateur rubbish that I do.

IBM, GDS, ThoughtWorks, Microsoft - the list goes on.

 

[Soootylad]

Yes, so amateur that even the biggest of fish tout the same amateur rubbish that I do.

IBM, GDS, ThoughtWorks, Microsoft - the list goes on.

You think IBM don't spec up a job and get on with it, just see how it goes at their contract rates?

Nope, you're in cuckoo land.

The kind of customer most people on this forum are talking about working for want things done in the way I'm saying, we're talking probably <£20k projects and not the multi-million pound contracts the above would demand.

Customers with modest budgets need them sticking to.

 

[mid_gen]

Agile is about delivering what the customer wants, not what was written down in a specification. These two things are very, very rarely the same thing. Do it right and you'll be delivering better quality, faster, and have happier customers.

If you've got customers that are happy paying extra to get what they want, why not milk em for it I guess....

 

[D.P.]

You think IBM don't spec up a job and get on with it, just see how it goes at their contract rates?

Nope, you're in cuckoo land.

The kind of customer most people on this forum are talking about working for want things done in the way I'm saying, we're talking probably <£20k projects and not the multi-million pound contracts the above would demand.

Customers with modest budgets need them sticking to.

Customers with multi-million dollar budgets will also want to know exactly how their money is pent, ensure delivery of their desired product by a specified date and will provide a long detailed specification document. We get 500page documents detailing exactly what needs to be done with milestones and deadlines set by the client that we must adhere to.

 

[D.P.]

Agile is about delivering what the customer wants, not what was written down in a specification. These two things are very, very rarely the same thing. Do it right and you'll be delivering better quality, faster, and have happier customers.

If you've got customers that are happy paying extra to get what they want, why not milk em for it I guess....

The problem is customers have fixed budgets and fixed deadlines and will provide a list of fixed requirements that they believe are correct and won't change. Sure, the latter point is often wrong and Agile tries to be a cure for that but it fails at the first 2 points and fails to take into account the clients demands. If you apply Agile management then you will be late and spend more engineer hours for the same money so the customer will be unhappy and the business was will become unprofitable. I stead if client specifications change then they realize they have have to extend the deadline and pay for the additional development. This means you are not late in delivering the product and can remain profitable, or in fact exploit the clients failures.

 

[mid_gen]

If you apply Agile management then you will be late and spend more engineer hours for the same money so the customer will be unhappy and the business was will become unprofitable.

You will work on a properly run agile project some day and change your tune!

Once the customer figures out they can work in a way that means they can get exactly what they want, on time, without paying extra, they'll be asking why you're stuck using those inefficient, slow, costly methods of software delivery.

When that happens of course, depends on the company

 

[touch]

Additonal work == not nailed everything down. It's obvious.

All I'm saying is accept that, embrace it.. there are better ways to maintain a relationship with your client. Certainly less wasteful than demanding a contract be drafted for everything.

It's not always less wasteful to write a spec/contract up front.
An agile approach works well with some clients but if you dont explain correctly what is required from them it wont work.
There's a big commitment from the client over the whole lifecycle of the project. One of the agile commandments is to have daily cooperation between developers and clients and if the client doesnt have time for it, the whole project can stall.
It can take days or weeks for a client to accept a release, provide feedback then discuss the next stage. What do the developers do when waiting for the client? You cant always continue with the build if you dont have confirmation that the previous release was what the client expected.

Agile done properly is a good solution for most projects, particularly smaller ones, but isnt always the answer.

 

[D.P.]

You will work on a properly run agile project some day and change your tune!

Once the customer figures out they can work in a way that means they can get exactly what they want, on time, without paying extra, they'll be asking why you're stuck using those inefficient, slow, costly methods of software delivery.

When that happens of course, depends on the company

I have highlighted the relevant part for you. Here is a hint, the client dont, or cant. Clients approach developers with a an RFQ, based on that they secure funding which may take 1-2 years. They develop a specifications or what they think they want at the agreed budget and with hard deadlines set by them based on your RFQ. They want their product delivered to their specifications at their deadline at their budget. They don't care about fancy jargon and modern fads, they care about delivery of a high quality product meeting their requirements. Their requirements may well change and at that time new contracts can be developed and they can source new funding.

Agiel is great wihtin certain markets with certain client that understand the process with developers of a certain size and budgets of a certain amount. Agile is just a load of fancy new Jargon for a management rocess that has be widely used for well over a century. It isn't some new revelation that changes the face of the industry.


There is plenty of well informed critique of Agile, e.g.
http://www.softwaremetrics.com/Agile/Agile Method and Other Fairy Tales.pdf

I'm not even even reiterating that, although it is quite alarming why so many have faith in a methodology that has a severe the lack of any empirical evidence. I am just stating the obvious fact that most clients don't want an Agile approach and for many companies it is just doesn't work for them. A company approaches a develop with a 500 page specification with a hard deadline and multiple deliverables requesting a quote. If you tell them to forget the specifications you will use an Agile approach then you have just thrown a $100million project out the window. That isn't an effective way to stay in business!

 

[mid_gen]

When you've worked on a successful agile project, you will understand why people like it. I have worked on bad agile projects too, but not nearly as bad as some waterfall trainwrecks (lookin at you IBM).

I did the whole process of implementing agile methodologies at JPMC...yes it was painful getting the decades of entrenched waterfall processes in the PMO and reams of documentation out of the way, but the business stakeholders were very happy when we started turning out projects in a fraction of the time of their traditional methods, and having end users instead of 'analysts' involved from day 1 meant the business got what it actually wanted, not what a chinese whispers chain of interpretations thinks they wanted.

In my experience anything involving a UI results in a better end product if you work agile.

 

[D.P.]

I think you are just missing the fact that Agile just doesn't work for many types of projects, full stop.

For the projects my parent company does every new release will require around 6 months of testing logging hundred of hours of test data and extensive analysis done by multiple 3rd parties. Even being allowed to test requires approval from senior government and defense officers.

Do you want to do employ an Agile approach where you have 6 months and hundred of K spent between each iteration?

 

[melvis]

from my experience agile works well for internal projects where you will see the 'client' every few days without even trying, for external clients? forget about it, i wouldnt even consider agile for that

 

[Randomface74]

continuous deployment, stick something out there, measure everything, get feedback, do a bit more.

 

[D.P.]

from my experience agile works well for internal projects where you will see the 'client' every few days without even trying, for external clients? forget about it, i wouldnt even consider agile for that

I go along with that. We use some Agile techniques for our internal stuff.

 

[D.P.]

continuous deployment, stick something out there, measure everything, get feedback, do a bit more.

And if that "measure everything, get feedback" takes 6 months and costs the client 400k?

 

[Randomface74]

And if that "measure everything, get feedback" takes 6 months and costs the client 400k?

We're talking quicker than that, maybe multiple deployments per day.

 

[RDM]

We're talking quicker than that, maybe multiple deployments per day.

Which is not always possible with all projects, hence different software development methodologies exist.

 

[D.P.]

We're talking quicker than that, maybe multiple deployments per day.

And if you don't have any control over that? You can't magically do 500 hours of testing in 2 days.

E.g., you write a new flight control system for a euro fighter autopilot. Do you you really think they will be happy just to test code every few week. "Oopps, there was a bug and the plane crashed, Oh we didn't actually implement that feature yet despite it being in the spec you gave us because we do this cool Agile thing and we deliver software even when it isn't finished. Don't worry, we will keep re-iterating, you will lose a few planes and pilots in the process but this is the cool hip thing to"

 

[Haircut]

I think it really boils down to: release as often as you can.

For some things, control systems, defence contracts etc. that may not be very often at all.
For other things, websites and your general LOB applications that's likely to be much more often.

 

[mid_gen]

Agile isn't an either/or thing. You use the parts that are appropriate, where appropriate. You don't throw out all your quality control processes, you don't deploy to production every week just because you have a new build every week. The benefit of rapid iteration isn't that you update production frequently, it's that you have working version to put in front of users frequently and have a rapid feedback cycle.

Agile is like any tool, use where appropriate. Anything with a UI element usually benefits greatly from an agile approach.