There's "Agile", the buzzword that all sorts of advice-givers have capitalized on commercially, and then there's the Agile Manifesto [1]. The Agile Manifesto has merit and is a set of values, not a methodology - it would precisely agree with your advice to chiefly "use your brain". It's unfortunate that the latter has been turned into a Frankenstein's Monster of the former. [1] http://agilemanifesto.org/
I hate to disagree since you support me, but thats not true.
The agile manifesto has plenty of problems that should be obvious with some thinking. Some of the statements are outright ludicrous and naive as much as others are valuable insights (but even then, only if you haven't thought about the problem very much and tried to approach it in reality).
I shipped software very quickly before learning much about agile at all... I ship it even faster afterwards, but not because I agree with it all... in fact I am convinced I am better off for ignoring the more harmful aspects and selectively choosing the ones that have a measurable benefit.
> The agile manifesto has plenty of problems that should be obvious with some thinking. Some of the statements are outright ludicrous and naive as much as others are valuable insights
Are we talking about the same document? What are the problems and harmful aspects that you're referring to? (Please quote the relevant part) This comment feels either a bit like a content-free middlebrow dismissal, or we're referring to different documents.
> Individuals and interactions over processes and tools
Have you seen this in practice and experienced how people work day-to-day? Leave them to their own devices and it varies a lot by personality. Some people need micro-management for instance... there is also thing that process is very important, and this point is self contradictory given that a lot of the agile manifest essentially describes process or a strategy for creating one... and as for ever relegating the importance of good tools.... ick.
?
(p.s. thanks for calling it out, its good to take these things seriously imo. its shows passion and care. :) )
I think one's assessment of the manifesto is largely dependent on how generously you read it.
> Individuals and interactions over processes and tools
needs to be read in conjunction with:
> while there is value in the items on the right, we value the items on the left more
Which means I can interpret it a way that is true, but not that interesting.
That is, I believe that a great developer with crappy tools will produce better software than a crappy developer with great tools
But I'm not sure what that really tells me other than "hire great people".
I guess, to some extent, it means "if the process says I should do X, but the team thinks it's a bad idea, then I should listen to them", but even that's is not a necessary conclusion from the statement.
In the non-software world, you only need to spend a little bit of time looking at workplace deaths to see that many of them are caused by teams that decided to ignore safety protocols.
Ultimately the only thing I really take from the agile manifesto is that doing the exact opposite is bad, but so what?
I don't want to ever work in development team that:
- Thinks that "following a process" trumps "investing in good people"
- Prioritizes writing documentation for software rather than making it work
- Has watertight contracts but ultimately disappoints the customer
- Sticks to "the plan" even when it's obvious that the circumstances have changed.
"Individuals and interactions" is not saying "hire good people", although I can see why you could read it that way. I've always understood it to be saying, "Get people together in a room and talk and figure out what to do", instead of "rigidly follow an arbitrary process".
For example, let's say that we did some project planning a month back, which says that we should start on a certain new project tomorrow. Everyone on the team is grumbling and no longer feels like that's a wise expenditure of resources. What should we do? Stick to our goal and follow the process, or get people together, work it out, and set new goals? Agile is saying, especially when you consider other bullets like "Responding to change over following a plan", that people subscribing to the Agile Manifesto value getting individuals together, collaborating, and responding to change more than following their plan.
But that is the point of the sentence. A process does not care about individual variation. What the manifesto is saying is exactly what you are saying.
Yeah, and that's a difference between a mature engineering discipline and software development. Though one could argue that software is so young as an industry that we have no clue what processes could be actually effective, so it's too early to set up one.
