Agile

[Old Greg]

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.

[Cliphead]

A few months into Agile my experience is it could be the way forward but too many folks still stuck in their old ways. Seems to me it requires a culture change more than a methodoligy change.

[original PM]

A few months into Agile my experience is it could be the way forward but too many folks still stuck in their old ways. Seems to me it requires a culture change more than a methodoligy change.

Yes agree with this.

One of the biggest challenges is people who think because they're in a senior position they can demand changes and expect no consequences.

Until you get people in those positions who understand that instead of fast tracked graduate areslickers it will alway be a struggle.

[bobspud]

So if you are not doing Agile what are you doing?
.

Same thing as you would be regardless of what the method was called...

Inflicting chaos.

Where agile goes badly wrong is where the product owner can't grasp foundations go before Windows and chimneys. These cases always end up with tulipe being delivered just because the owner wants to see a thin strip of end to end functionality and refuses to honour non functional requirements stating that we will pick them up at the end. By which time the budget is spent and you have a single threaded app that has to be shutdown to be upgraded when it's supposed to be five nines resilient..

Sadly I only know one guy that was clever enough to do the product owner job properly.

[Cirrus]

The Very Worst Thing About Waterfall

I booked a two week holiday hiring a plane in Florida. Due the collapse of the FAA due to 75% headcount cuts I had to cancel the whole holiday because my documentation didn't get sent in time. I lost many thousands of pounds but rebooked a few months later. Accommodation changes had been made and that made the holiday massively better than it would have been.

My wife ordered a blind for the landing window and when it came it was too narrow. She had measured it wrongly. We had to throw it away. A replacement has just arrived - a different one - and it's much nicer than the first one.

The very worst thing about waterfall is the crippling notion that what you say you want is something you then have to stick with it whether or not you subsequently see something better. If you try and change anything you are tortured with process and made to look like a feckless loser.

When I go out for a drink, I have no desire to write down precisely which pubs we should visit, at what times, and what beers I should drink, and I don't see why I need to do all that boring crap when building a system.

[LondonManc]

Bottom line is that developers develop because they hated essays at school. They preferred computer "stuff". As such, they hate documentation at work. They'll go for whichever methodology means least documentation.

As for Agile, it's not so much a methodology as a mindset. I've seen it work well and I've seen it go badly. It works best in an environment where you can deliver parts of a product, such as websites, with high value show and tell.

End user involvement and good communication are the key to any project - make progress, keep the user interested in what they first asked for and have someone play the bad guy by keeping the scope tight and you'll get things delivered, whatever the methodology.

[VectraMan]

The very worst thing about waterfall is the crippling notion that what you say you want is something you then have to stick with it whether or not you subsequently see something better. If you try and change anything you are tortured with process and made to look like a feckless loser.

When I go out for a drink, I have no desire to write down precisely which pubs we should visit, at what times, and what beers I should drink, and I don't see why I need to do all that boring crap when building a system.

Very well said. Spinal Tap's 12" high Stonehenge was built using waterfall - people blindly following a specification. Applying "measure twice cut once" to software is no less stupid.

[VectraMan]

Bottom line is that developers develop because they hated essays at school. They preferred computer "stuff". As such, they hate documentation at work. They'll go for whichever methodology means least documentation.

That's true. I regard documentation as a waste of my time. I do it, I see some value in it, but it's not what the client hired me for. Some numptie should be able to write documentation for me.

End user involvement and good communication are the key to any project - make progress, keep the user interested in what they first asked for and have someone play the bad guy by keeping the scope tight and you'll get things delivered, whatever the methodology.

I know I'm probably unusual in this regard but I've only worked on commercial products; i.e. where the software is either the product or part of the product. In that respect the end users aren't directly involved. The development team try to create the best product it can, and whilst obviously we try to target what the customers want experience shows there's limited usefulness in asking them directly. They tend to come up with dumb suggestions like "can you move this 3 pixels to the left". Asking sales people doesn't work much either. No doubt you'll scoff at this approach but it worked pretty well for Apple.

[bobspud]

Bottom line is that developers develop because they hated essays at school. They preferred computer "stuff" As such, they hate documentation at work. They'll go for whichever methodology means least documentation..

As for Agile, it's not so much a methodology as a mindset. I've seen it work well and I've seen it go badly. It works best in an environment where you can deliver parts of a product, such as websites, with high value show and tell.

End user involvement and good communication are the key to any project - make progress, keep the user interested in what they first asked for and have someone play the bad guy by keeping the scope tight and you'll get things delivered, whatever the methodology.

Yes it's those cretins that give all the methodologies a bad name. They are not just developers either. I sat in a meeting last week and a sales guy was looking at our proposal for a DC transition. The first thing he picked on when he needed to make cuts was 3 weeks of planning and documentation that we needed in order to bring the currently un-documented estate under some control before it gets rammed in a cloud. Its not surprising that developers and engineers alike pay little heed to writing up or reading solution documnts when project managers and other senior people show no interest in the value of the documentation in the first place.

[Bee]

Crap.

Today there is a lot of crap methodologies and a waste of money in crap certifications.
All are the same tulip.