Erik Meijer: AGILE must be destroyed, once and for all

Re: Blaming the tools...

This is true. However, I have been in 3 days of meetings before to plan a 2 week sprint. Go figure.

Re: Blaming the tools...

@Phil

Quite so. That is why bad programmers become the managers.

Re: Blaming the tools...

True, but I've seen a lot of good code in software that ends up fundamentally useless and vice versa.

Re: All methodologies will fail in the right conditions

"The real mistake is to pretend that there is a single process that can fit all situations well enough."

...this. And there seems to be a fundamental problem with understanding what Agile means - it's not adhering to any one methodology but an agreement between stakeholders and development teams that we live in an imperfect world and must collaborate to organise an efficient process accordingly. For example, Scrum doesn't work for agencies whose teams are responsible for a number of unrelated projects. In this case Agile doesn't say 'find another methodology', it says adapt something whose fundamentals help avoid team, communication and legal problems and so avoid widening the divide between different parties involved in a project. It's also a response to traditional development methodologies creating software that's already obsolete when it goes into production, rather than products that might be imperfect to start with, but generate substantial value even in that state. Being successful in business is usually about being pragmatic, and Agile is all about pragmatism.

Re: move fast and break things

Then again he did once work for Microsoft and man, have we been buying the results of the 'move fast and break things' approach for years now.

Re: Project Managers

I've worked with good and bad PMs. Often times I have to stand in, as I'm the poor sap who has the BA title appended to my name. A good PM keeps people focused on the task at hand and gently steers the ship towards the goals. They cut out scope creep, keep the numbers looking good for finance, and if necessary, throw themselves in the line of fire when management comes calling, wondering why something isn't being delivered on time, under budget, and with pristine quality.

The newer PMs often come out of school and/or training with a specific set of tools in hand they are to use, and when one tries to upset that particular apple cart, they have a tough time. I've noticed in my travels the PM is the one who struggles to move from one methodology with one set of tools to another, as they are raised in a world with specific metrics and reports. You put story points and velocity in front of them when it used to be IT spend and burn rate, and suddenly the foundation of their world takes a huge hit. The PMs I've worked with who have multiple methodologies under their belt tend to take whatever crap their current company throws at them. Just like any other professional, experience and thick scar tissue is what makes for a good PM.

And it's a job I never want to do. Ever.

Re: Smoke and Mirrors

That is not all that it is, but it certainly is massively misunderstood by a lot of its proponents. One of the points of Agile is that you implement features on an interative basis. There is no "done" in an Agile project, just an ongoing process of improvement and feature addition. This is not actually what most business customers want, but it's just the kind of term that marketing chumps love, so they start making up their own amorphous definitions for their own purposes and of course it's the developers who suffer when we can't do the impossible.

Re: Smoke and Mirrors

Actually Agile is more of a way for developers to say to management "Hey, this is what we have worked on, these are the problems we found and this is what we are delivering". Things only really get bad when you have a project manager who promises the board delivery dates beyond the capability of the process, and I have seen this at high government IT levels.

We use an agile system not just as a means of structured development but also as a monitor for bad developers. The number of apparent 'back end developers' who can just about scrape through a PHP fizzbuzz test is sorely in contrast with the numbers who do not even know the differences between and object and a class.

Again, this implies that the overall aim of the project isn't actually known whilst the work is going on.

For your house building example, that's like saying "I want to build a shelter to sleep in" up front, rather than saying "I need to build a house with all the modern expectations of a house which are XYZ".

Agile doesn't mean you don't design up front for the end aim of the project. It doesn't mean you give up on good software design practices. You will analyse the needs of the Kitchen aspect of the project, and decide you need worktops, and cupboards, and you need water, and space for a fridge, oven, microwave, and power for each of them, and the ability to rearrange things, and to meet safety regulations (i.e., plug sockets, etc).

However once you've done that, you can start work on it, you don't need to have the bathroom designed (well, it needs access to the water stack in the house, etc), nor do you need the garden landscape design completed. Which is what waterfall model would require before you even started clearing the site.

And sure, the first kitchen appliance might require refactoring of the kitchen a bit (hardly knocking the house down!) ... oh, the analogy is stupid at this point.

Of course, contractor development methodology is even less restricted, although dealing with clients often means you need to be more waterfalley in terms of getting the requirements and specification done up front.

And if you truly are doing your own thing, then enjoy!

@Mike Bell

but remember your working with software here not hardware - the walls pull apart to allow the bulldozer through.

@Mike Bell.

I have worked on government IT projects where if you were to build a house in the way they structured their projects you would put the roof down before the foundations had been laid.

Re: What a revolutionary idea agile seems

Actually getting the customers input to the problem before the "solution" is set in concrete.

Who knew?

Hehe. Quite.

We all know that in general the customer doesn't know how to explain (well enough for a spec to be written) and/or know (usually case of both..) what it is that they need (was going to say want, but they usually want truckloads more than what they actually need).

Rapid development cycle and the customer being more directly involved greatly alleviates the problem which is probably the most useful part of agile.