Agile

[m0n1k3r]

In the Pre-Agile days projects "Waterfall" was best practice.

It was common, but not best practice. Dr Royce recommended against it for any size project because it was simply too risky.

[tomtomagain]

As a graduate of a 'real' engineering degree I find the industry acceptance that specification can be changed at any point and that work casually thrown away truly shows the immaturity of the discipline.

We are meant to be in a creative manufacturing profession, not building a villa in Marbella on the cheap.

There is a massive difference between the engineering design and construction of a project such as a bridge or deep water oil platform and that of engineering design and construction of an IT project, such as a web site or trading platform.

The core difference being some projects involve atoms and some projects involve bytes.

Once you've built 100km of steel pipes of a certain diameter and quality and placed them on the seabed in water depths of 2000m then change is very, very expensive.

If you've built the software that models the flow of oil, gas and water through those pipes then decide that you wish to report on different KPI's or show the information in a different way then the cost of change is small.

It is not a sign of immaturity to accept change or alter the specification or requirements in a software project. It's a recognition that software does not have the physical constraints of a "real" engineering project.

The largest project I worked on had 10,000 people at peak, a budget of $10B and involved building out a 360m FPSO ( you can google it ) and positioning it 100 miles off the coast of Angola.

I had the privilege of working with some fantastic engineers, really clever men and women, who design and build the infrastructure that you and I all rely on for our daily lives.

One thing that really struck me though as a software guy is that their initial design phase,where they effectively build the "spec" that is later used to manufacture the facility, is much more like the software development - and they do that in an iterative "Agile" way.

So if you look at the "Back end" of a big engineering project, then it can seem like, they have designed everything perfectly and are simply following the spec ( not in reality, as problems occur and need to be solved ). Whereas if you look at the "Front End" of an engineering project it's much more akin to software development.

[CloudWalker]

My last gig were using the Microsoft T minus methodology

[minestrone]

There is a massive difference between the engineering design and construction of a project such as a bridge or deep water oil platform and that of engineering design and construction of an IT project, such as a web site or trading platform.

The core difference being some projects involve atoms and some projects involve bytes.

Once you've built 100km of steel pipes of a certain diameter and quality and placed them on the seabed in water depths of 2000m then change is very, very expensive.

If you've built the software that models the flow of oil, gas and water through those pipes then decide that you wish to report on different KPI's or show the information in a different way then the cost of change is small.

It is not a sign of immaturity to accept change or alter the specification or requirements in a software project. It's a recognition that software does not have the physical constraints of a "real" engineering project.

The largest project I worked on had 10,000 people at peak, a budget of $10B and involved building out a 360m FPSO ( you can google it ) and positioning it 100 miles off the coast of Angola.

I had the privilege of working with some fantastic engineers, really clever men and women, who design and build the infrastructure that you and I all rely on for our daily lives.

One thing that really struck me though as a software guy is that their initial design phase,where they effectively build the "spec" that is later used to manufacture the facility, is much more like the software development - and they do that in an iterative "Agile" way.

So if you look at the "Back end" of a big engineering project, then it can seem like, they have designed everything perfectly and are simply following the spec ( not in reality, as problems occur and need to be solved ). Whereas if you look at the "Front End" of an engineering project it's much more akin to software development.

Its not a sign of weakness to change a spec but it is a failure to change it after something has been built. BAs and PMs love Agile as it normalises this, if the spec is tulip and the users send it back after UAT well it can all be brushed under the carpet, ignore that there was clearly not enough effort put in at a crucial stage in the project.

And this "iterative Agile way" argument that gets pushed out every time agile is mentioned is equally tiresome, the Egyptians were working in this way on the pyramids. In software the practice is so tightly linked with agile I honestly believe people think Kent Beck thought it up first. Its not even the first formal methodology in software that advocated it.

There are loads of creative industries and most of them share working practices, oddly agile has never made it out of software, probably because this industry is filled cosseted autistic types who don't have the balls to say "can we just stop doing these feckin ludicrous stand ups every morning"

[Cirrus]

History is not always what you think it is

People are inclined to think that in the beginning was waterfall (specification-driven/plan-driven) and then came agile (stand-ups, post it notes, bowls of fruit and silly jargon).

I - and those of us here who came from an earlier era - will tell you waterfall only came along after quite a while. I read somewhere it took off after some huge USA Navy warship project which had been run successfully on what we would call agile lines. Somebody for some reason thought they needed to put together some big bureaucratic framework as a sort of audit trail type of thing. So they did it retrospectively and the practice took off. Even the Royal Navy always built models of ships up until a few decades ago.

For a lot of my career I used a model that was neither waterfall nor agile. I guess lots of people do it now. There isn't a name for it but basically there are no specs. The Business tell you what the problem is, what they've said, what contracts they've signed, what standards and interfaces they need to use, etc and you just go an build them a prototype based on common sense. When they see the prototype, they ask you for additions and ammendments.

And the system gets put into production, then upgraded now and again to fix faults and add further features.

Much more pleasant than the nonsense that goes on today.

[tomtomagain]

Its not a sign of weakness to change a spec but it is a failure to change it after something has been built.

I disagree. I don't believe it is possible to specify a computer programme to enough detail without actually writing it to guarantee that there will be no post-build changes required.

I honestly believe people think Kent Beck thought it up first.

He certainly did not think it up. But he did put a label on what most people where doing.

probably because this industry is filled cosseted autistic types who don't have the balls to say "can we just stop doing these feckin ludicrous stand ups every morning"

A stand-up is a just a management technique. Like everything they can be done well, they can be done very badly. I wouldn't get hung up on them.

[tomtomagain]

For a lot of my career I used a model that was neither waterfall nor agile. I guess lots of people do it now. There isn't a name for it but basically there are no specs. The Business tell you what the problem is, what they've said, what contracts they've signed, what standards and interfaces they need to use, etc and you just go an build them a prototype based on common sense. When they see the prototype, they ask you for additions and ammendments.

That's what I would classify as "RAD". It can work really well. You just need a smart motivated people who understands the business, talks their language and will get on with it.

Working in a RAD team for several years was easily my most productive time as a corporate developer.

But it isn't flawless and can cause problems. For example I worked in an environment where the motto was "Do, Win, Do". The theory being you just banged out a quick solution that "won". Then threw away the prototype and did it "properly".

Of course you can guess the punchline. We did the "Do, Win" bits well. But the second "Do" was always cancelled due to lack of interest. So we ended up with a big portfolio of little solutions after about 5 years that required a lot of maintenance.

Scaling up the team was difficult and quality became an issue.

[VectraMan]

What Tom said.

There are loads of creative industries and most of them share working practices, oddly agile has never made it out of software, probably because this industry is filled cosseted autistic types who don't have the balls to say "can we just stop doing these feckin ludicrous stand ups every morning"

FWIW I like doing stand ups. What I hate (and don't understand) is wanting to spend hours in meeting rooms trying to decide things that would be much better solved by people simply talking to each other day to day.

I completely agree about blindly following a process, but that's one that I feel does work.

[minestrone]

I disagree. I don't believe it is possible to specify a computer programme to enough detail without actually writing it to guarantee that there will be no post-build changes required.

Bulltulip. The issue with specifications is that the people that most often create them have no insight into the technical implications of what they are producing and that they fail to communicate effectively what they have produced until it is too late.

The concept of measure twice cut once is standard in other industries, with agile measure once, cut twice is promoted as good practice.

And taking a standard working practice and giving it an agile name ( release -> sprint, meeting -> standup) only adds to the arseholery of the agile cult. Its like people thinking Vanilla Ice invented rap.

[tomtomagain]

Bulltulip. The issue with specifications is that the people that most often create them have no insight into the technical implications of what they are producing and that they fail to communicate effectively what they have produced until it is too late.

As we used to say. The problem with our BA's is that they don't understand the business and they cannot do analysis.

But seriously I don't think it's possible to clearly state a computer programme in human language. Human language is ambiguous. Computers don't do ambiguity.

There's also a massive range of possible solutions to computer problems when compared to a lot of other types of project.

So for example if I ask 10 builders to build me a wall, 10m long, 1m heigh and check the results once they've finished, the chances are I'll get what I asked for.

If I ask 10 computer programmers to write me a programme to add up some numbers and check the results once they've finished I'll get 10 very different solutions. They'll all work but will work differently, use different technologies, look differently and so on. Because IT doesn't have the same physical restraints.

The concept of measure twice cut once is standard in other industries, with agile measure once, cut twice is promoted as good practice.

Or you can think of it as : Implement, Test, Refine, Repeat.

And taking a standard working practice and giving it an agile name ( release -> sprint, meeting -> standup) only adds to the arseholery of the agile cult.

True. But how else could consultants sell it if it wasn't a known thing?

Anyway - I'm sure you'd find that plenty of other professions give a funny name to their standard working practices.

Accounts have a whole range of bizarre exams, job titles, jargon and practices. And accountancy is just adding up.