• Want to receive the latest contracting news and advice straight to your inbox? Sign up to the ContractorUK newsletter here. Every sign up will also be entered into a draw to WIN £100 Amazon vouchers!

Agile development

Have a read on wikipedia - it turns out I am a SCRUM master - I used it for Production Support on my last gig without realising it.
 
WHS

Management/customers love agile because they can change the spec whenever they like, and regular iterations mean they are always 'seen' to be delivering. What they never like about agile is the flip side: technical debt. They always ask "what is the business benefit?", and rarely agree to any refactoring work that's required to prevent the code turning into a POS.

The light dawns, except in the case I saw it was called "Prototyping". :D
 
15 months now. How does this help?

Alright I'll bite. Because if you weren't wet behind the ears you would have come up with the following without having to ask :rolleyes:

Yes you have, go back and read different agile methodolgies are - chances are you can say you've done some of it.

I spent a happy summer 'working' in an office with one of the gurus of Agile Development, he's written several books, and we had long chats about it.

Just don't worry. I've done plenty of gigs where they claim to do Agile development. So do a quick Google and you'll know more than anywhere I've been. Spot bits from previous contracts that look like it and call it 'agile'...

Look, Agile development has at it's core 'self-organising teams'. Ho ho ho. Can you imagine any management buying into that... So, in truth it never really happens in the commercial world.

Like most methodologies the management pick and choose the bits they believe will save money, get more work out of the staff, and generally ignore the parts that will get the job done.

WHS

Management/customers love agile because they can change the spec whenever they like, and regular iterations mean they are always 'seen' to be delivering. What they never like about agile is the flip side: technical debt. They always ask "what is the business benefit?", and rarely agree to any refactoring work that's required to prevent the code turning into a POS.

In my ‘confinement’, I’ve been having a look at this series (Autumn of Agile). He waffles on a lot, but comes up with some interesting ideas that I might put in to practice on a new venture I want to get going after the doctors have finished with me. The thoughts of others on the series would be appreciated.
 
Done it for years, started doing it nearly a decade ago.

Personally it is a load of cock, or what it is now is a load of cock. It started out quite well with the basics, ‘let’s not spec it out’ and ‘if they want to change it let them change it, will just take longer’

Now it is burnup charts, burndown charts, daily huddles, information radiators et. What you will find is there was a great hype about it about 7 years ago so all the consultancies started doing big business out of training courses, there really was nothing to the system so they just started making up total mince and feeding it to the big companies as the ‘agile standard’

I would be inclined to say it is worse than RUP now.
 
p.s. I've never had an agent have the first clue about it, so as long as you can talk through the method in an interview you'll be fine.
 
Done it for years, started doing it nearly a decade ago.

Personally it is a load of cock, or what it is now is a load of cock. It started out quite well with the basics, ‘let’s not spec it out’ and ‘if they want to change it let them change it, will just take longer’

Now it is burnup charts, burndown charts, daily huddles, information radiators et. What you will find is there was a great hype about it about 7 years ago so all the consultancies started doing big business out of training courses, there really was nothing to the system so they just started making up total mince and feeding it to the big companies as the ‘agile standard’

I would be inclined to say it is worse than RUP now.

I think alot depends on the manager, and alot depends on the buy-in of the client, and the make-up of the team.

<to op>you can use this sort of flannel in your interview ;)</to op>
 
Done it for years, started doing it nearly a decade ago.

Personally it is a load of cock, or what it is now is a load of cock. It started out quite well with the basics, ‘let’s not spec it out’ and ‘if they want to change it let them change it, will just take longer’

Now it is burnup charts, burndown charts, daily huddles, information radiators et. What you will find is there was a great hype about it about 7 years ago so all the consultancies started doing big business out of training courses, there really was nothing to the system so they just started making up total mince and feeding it to the big companies as the ‘agile standard’

I would be inclined to say it is worse than RUP now.

I've been on a very successful agile project and I don't think Agile is a "load of cock". That said, I will agree there is too much faff about "burnup charts, burndown charts" and FAR too many cheesy buzzwords like "information radiator" for my liking.

Tasks are broken up and micro managed in a Agile/SCRUM project, but they sometimes lose the plot. For instance, I have been in planning games with over 20 people debating for an hour whether a 'story' would take 1 1/2 days' or 2 days' development time. As the Americans say, do the math. :bang:
 
Agile

Agile

They are at pains to differentiate Agile from "Cowboy Coding". There isnt any real difference. What makes the differecne is the quality of team members.

If they work well together, leave their egos in the lockeroom and take ownership of various aspects of the project, then it works.

Does not work with juniors or c r a p programmers.
 

Advertisers

Back
Top