Reply to: Agile, again....

[northernladuk]

I agree with you but you forgot the sleeping bag.

[Bee]

Now this is the bit everyone needs to avoid.

This assumption that as the delivery date approaches everyone on the project will start doing 10-12 hour days and work weekends - I have never understood that.

It is a 'thing' made popular by stupid people who think that delivering a project should be a hard arduous task with pizza until 3 am and everyone living on coffee and doughnuts saying 'Ra Ra Ra' aren't we great.

For those who have been doing projects for years n years it is no different to any other job - you need to plan and you need to deliver - yes it is often bringing in new concepts etc - but so what.

I agree with you but you forgot the sleeping bag.

[SpontaneousOrder]

'Agile' and 'Scrum' aren't the same thing. Just to be clear.

When I say 'you', I mean 'one'.

*if* you estimate work early enough in advance that you can make use of a burn-down chart to predict roughly when you can deliver some chunk - or how much you can deliver before some important date, then of course producing estimates is *very* useful.

If you're estimating at the last minute before working of a task then obviously it's entirely pointless and you're just doing it because " it's the way".

If you're doing it last minute before the sprint, then that's good too so long as you are doing because you're about to tell a load of stakeholders what they're going to get in 2 or 3 weeks and you plan on delivering to those expectations. Otherwise you're again just mindlessly following a misunderstood formula.

Meetings are fine. Lots of meetings is fine too. As Cirrus pointed out on page 1 - "Individuals and interactions over processes and tools".

If your meeting is to facilitate interaction between individuals then of course it's good. If it's because some process says you should have one - then it might not be. Better to have 10 meetings per line of useful code, than to have 1 meeting per 10 lines of broken code.

[VillageContractor]

And this is where Agile falls down - it assumes that all tasks can be done in a 1 week sprint therefore anything we desperately need is only 1 week away.

However this is not the case if you have to hook into third parties etc who will have their own timescales and methodologies.

Which is why you still need proper architecture management for large projects.

In fact unless you are doing a front end change to a website which people are just consuming from then I am starting to see that Agile really quickly looses it's benefits.

Nonsense this is poor planning by a moron

[MrMarkyMark]

There's only one thing you need to remember about software development: always break your project into components - as small as you can get. Then you can run each component with a small team (yes - the smaller; the better )

You do of course need to agree interfaces up front. There are only two things you need to remember about software development: always break your project into components and make sure you define interfaces up front.

I know you're thinking that trying to define interfaces before you've designed a system can be tricky. So you need to make your interfaces very virtual. There are only three things you need to remember about software development: always break your project into components, make sure you define interfaces up front and make your interfaces very virtual. A classic virtual interface strategy is always to use views when accessing databases. Never write to tables, but always to views. The principle however can be extended to all manner of interfaces: the more layers on the interface; the more chance you can adjust the interface without screwing up your code.

Componentize and the world is your oyster

Agreed, but I hope they wouldn't stay views in the final implementation, because unless underlying indexing is good, performance could be a problem.

the more layers on the interface; the more chance you can adjust the interface without screwing up your code.

Agree to an extent, however the more application layers you have can increase complexity and degrade performance.

An example I'll give is you design a data warehouse.
If it is designed well you should be able to sit multi vendor reporting / dashboard tools on it easily and come up with the same answers regardless.
If you bury business logic in the reporting tool layer(s), this becomes a lot more difficult to achieve.

Of course no one will thank you for enforcing this at the time, however everyone will say what a great guy you are, when senior management decide, at a whim, to replace Business Objects with Cognos, or whatever.

[Cirrus]

Componentisation - That's the Key

IMO, it works for web sites and applications, in fact anything that can be compartmentalised, to an extent.

I can't see it would ever work, in the purest form, for a large system deployment.

There's only one thing you need to remember about software development: always break your project into components - as small as you can get. Then you can run each component with a small team (yes - the smaller; the better )

You do of course need to agree interfaces up front. There are only two things you need to remember about software development: always break your project into components and make sure you define interfaces up front.

I know you're thinking that trying to define interfaces before you've designed a system can be tricky. So you need to make your interfaces very virtual. There are only three things you need to remember about software development: always break your project into components, make sure you define interfaces up front and make your interfaces very virtual. A classic virtual interface strategy is always to use views when accessing databases. Never write to tables, but always to views. The principle however can be extended to all manner of interfaces: the more layers on the interface; the more chance you can adjust the interface without screwing up your code.

Componentize and the world is your oyster

[MrMarkyMark]

And yet it is used for large roll-outs. Not very well, but it is used.

Sure, I'm under no illusion that some muppets try, but I could never see it working due to the points raised above.
A mixture of methods has always worked well for me.
IMO, large systems are best delivered by waterfall, with the right people engaged to make that happen.

[milanbenes]

And yet it is used for large roll-outs. Not very well, but it is used.

that's because it's the fashion innit

Milan.

[WTFH]

I can't see it would ever work, in the purest form, for a large system deployment.

And yet it is used for large roll-outs. Not very well, but it is used.

[MrMarkyMark]

+1 for that

because they can change their mind ever week and it will get done....

which works fine until you release that the decision you made 10 weeks ago now means the last 10 weeks work needs to be binned!

IMO, it works for web sites and applications, in fact anything that can be compartmentalised, to an extent.

I can't see it would ever work, in the purest form, for a large system deployment.

[milanbenes]

+1 for that

because they can change their mind ever week and it will get done....

which works fine until you release that the decision you made 10 weeks ago now means the last 10 weeks work needs to be binned!

it's Agile innit

Sprinting around circles, what's not to like ?

Milan.

[original PM]

The only reason companies want agile is that it allows them to hide their inability to make decisions and stand behind them.

+1 for that

because they can change their mind ever week and it will get done....

which works fine until you release that the decision you made 10 weeks ago now means the last 10 weeks work needs to be binned!

[eek]

And this is where Agile falls down - it assumes that all tasks can be done in a 1 week sprint therefore anything we desperately need is only 1 week away.

However this is not the case if you have to hook into third parties etc who will have their own timescales and methodologies.

Which is why you still need proper architecture management for large projects.

In fact unless you are doing a front end change to a website which people are just consuming from then I am starting to see that Agile really quickly looses it's benefits.

The only reason companies want agile is that it allows them to hide their inability to make decisions and stand behind them.

[original PM]

was involved in a Project earlier this year, new Project new .net implementation of one of the Business Suite products with integration to other existing Business Suite products.

One of my contributions was to confirm that all of the .Net Business Suite products involved have enough capacity for the new Demand.

I said to the PM, can you share numbers of Users, peaks of concurrent activity, data transfers, volumes of data, frequency.

This was in February.

They wanted to go live in September.

PM says, we haven't done that yet, capacity planning.

I says, why not ?

PM says, this is an Agile project and we're gonna do that in July/August.

I said Agile or not, adding capacity to these .Net Business Suite systems has considerable lead times, and if you start doing your calculations in July/August there won't be enough time to get the capacity in place before your goLive.

PM says, oh.

Milan.

And this is where Agile falls down - it assumes that all tasks can be done in a 1 week sprint therefore anything we desperately need is only 1 week away.

However this is not the case if you have to hook into third parties etc who will have their own timescales and methodologies.

Which is why you still need proper architecture management for large projects.

In fact unless you are doing a front end change to a website which people are just consuming from then I am starting to see that Agile really quickly looses it's benefits.

[MrMarkyMark]

was involved in a Project earlier this year, new Project new .net implementation of one of the Business Suite products with integration to other existing Business Suite products.

One of my contributions was to confirm that all of the .Net Business Suite products involved have enough capacity for the new Demand.

I said to the PM, can you share numbers of Users, peaks of concurrent activity, data transfers, volumes of data, frequency.

This was in February.

They wanted to go live in September.

PM says, we haven't done that yet, capacity planning.

I says, why not ?

PM says, this is an Agile project and we're gonna do that in July/August.

I said Agile or not, adding capacity to these .Net Business Suite systems has considerable lead times, and if you start doing your calculations in July/August there won't be enough time to get the capacity in place before your goLive.

PM says, oh.

Milan.