Reply to: Agile

[dx4100]

Agile works just fine on the right type of projects and if its done properly.

Currently working in a pretend agile environment and its hilarious to watch how badly everything is going. But they won't listen to how to improve things....

Five days until I am out of here and onto the next gig and thank god!!!!

[Bee]

Crap.

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

[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.

[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.

[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.

[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.

[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.

[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.

[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.

[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.

[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.

[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.

[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.

[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.

[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.