Then – management – or you call “the business” – see an error made by “IT” – and try and put a process around it to ensure that it *never* happens again.

And so the hole in the wall then gets a little smaller, and a little shape appears off to the left.

But that’s OK – because the business accept that, it it’s still easy to get through. But then somebody else makes a mistake, and so the risk averse management team decide another process is needed.

So the hole becomes smaller and more complex.

Then – staff turnover – nobody remembers why the holes have taken on that shape in the first place, just the fact that everybody was shit scared and spent all their time covering their arses, so they continue to make the shapes.

Business gets upset because they now have to contort themselves, IT get upset because they’ve got all these processes that get in the way of actually delivering, but they’re not willing to remove the processes due to fear of management.

Forget the wall analogy. Collaborate openly and honestly with everybody, and you can do amazing things.

I prefer to call our methodology a hybrid Agile and Waterfall approach simply because so many people believe it is synonymous with Cowboy Coding. I’ll emphasise that I still advocate the same specifications up front that Waterfall has, just that mine tend to be about one fifth the size of what most Waterfall specifications I have seen. A good senior architect or developer can often play the role of interpreter during the development phase, converting a looser specification into a locked down one for those developers that require it. Making those decisions later in the process still allows a lock down approach but at a point in time more likely to get a good result.

Thanks for your comments.

To many PM’s and developers agile means developing by the seat of their pants with little or no documentation. In the end the client gets exactly what the want but at the expense of enormous timeline and cost blowout.

A strong application of an agile methodology across the analysis and design phase with a waterfall approach the development, test and implementation has worked well for me in the past.

Good luck with it:-)

Agile requires good developers and good developers are hard to find. But the alternative is building things with bad developers and I’ve never seen this get great results.

A project manager is a key resource regardless of the methodology. In an agile methodology they act more as facilitators though rather than de facto architects or analysts and that adds a lot to the efficiency.

That Agile doesn’t have any requirements or specification up front is a fallacy. The point is to know what to specify and what to leave for the developers to interpret. A fat specification is hard to read and often creates more problems than it solves.

Good developers always find a way and can make any methodology work but a good developer does extrapolate and interpret well during the development lifecycle. Agile is a methodology that encourages good developers to be better. Waterfall doesn’t encourage this as much and is probably the methodology of choice if your development team is not very good.

Your view of Agile where the developer analyses, architects and delivers (a skill set that is rare) places a lot of accountability on a resource group that is possibly overstretched? Are your developers also talking directly with clients in the interest of shortening the delivery cycle?

You didn’t discuss the role that your production managers play in this process? Whether agile or waterfall, a Project Manager unites your team and if they’re good at their job, they create an environment where collaboration takes place. Communication falls apart in any environment regardless of the methodology you practice if value isn’t placed on trust, empowerment and accountability.

Agile works well when you’ve clearly scoped your project with your client, agile doesn’t mean you do away with documentation. It’s bad practice not to reference requirements, client agreement and evolving needs. These production line workers (that I have seen) seem to have enough common sense to include a placeholder in their specs of dropdown list values and focus more on functionality, business rules and then user interface design.

There are reasonable criticisms of Waterfall, but people are at the heart of your development process and those that are interested in finding the best solutions for the client, getting the best commercial outcome for the project are going to look for opportunities to increase maturity in the entire project delivery lifecycle regardless of the methodology in question.