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.
I totally agree ... Don't waste your time reading this article. And if you ever have the opportunity to write an article yourself, remember one simple thing - if you're going to write several hundred words of content, you should try to tell your target audience something they don't know!
Well it's working, it's on top of HN. The problem is the people clicking in the end. I didn't, cause I know with a title like that this gona be some cheap clickbait.
Sure, and I agree to a large extent, but if I'm doing woodworking and my blades are so fragile that they snap with the tiniest amount of friction, I'm probably not going to be very happy working like that for very long.
But why would you ever intentionally use (or vigorously defend) demonstrably bad tools? Just because you could do well with a bad tool doesn't mean you should or that you couldn't do better with easy-to-get other, better tools.
If you are forced to use an inferior tool like Agile, then sure, you want to make the best of it and be a craftsman who can still succeed.
That is an endorsement of being adaptable and self-reliant as an engineer, not an endorsement of Agile.
And if a tool is bad like Agile, it's useful to point it out and slowly steer the bureaucracy that feeds it into bastardizing whatever the next tool is, but hopefully inching forward to a better global state as well.
I'm an XP fan, but I'm always wary of saying "they didn't do real agile". It can descend into "No True Agile" pretty quickly, with a dash of victim-blaming.
Agile is actually hard to get to grips with. It requires lots of discipline. So did the pre-agile methods that worked best. And it gets half-done for the same reason that the pre-agile methods got half-done.
It's hard. Hard to do, hard to learn, tempting to stop.
Perhaps, but one problem often seen in large orgs (I've been there personally twice, and heard many more stories from close colleagues) is that they adopt the agile methodology (sprints, stories, etc), without adopting the culture shift (shit does not get added into the middle of a sprint, ever) necessary to make it work.
Agile process without agile culture objectively isn't True Agile. It's worse than everything it sets out to solve with the alternatives.
I disagree that Scrum is the whole of agile, so the concept of "sprints" doesn't exist for me. If the product manager wants to rearrange stories, that is his or her business. My business is advising on the relative complexity of stories and then undertaking to deliver the next story in the backlog. The roles are well-defined, after which, we talk to each other like we're adults trying to achieve the best outcome for everyone.
Putting aside that particular nitpick, it's easy to cargo-cult the practices. I sometimes use the analogy of the introduction of lean manufacturing in the US. At first what was introduced were the tools: boards, line-stoppages etc. But tools are just tools, by themselves they're not enough.
The uncomfortable, expensive and difficult truth in our industry is that people, process and tooling are not substitutable. You need the best of all three that you can get.
I'd prefer to say "misinterpret" than pretend to follow... but even so, following it as presented to its totality is still going to be sub-par.
Some of the points in the Agile manifesto are just arrogant, unjustified statements of fact or vague and useless comments.
Some people hate face-to-face interaction... and what the hell is a 'regular interval'... and sometimes a clear vision and direction from above achieves the very greatest of results that the team without it would have failed to produce.
Its not useless, but its not without fault either.
just use your brain. agile is only a problem when people follow it religiously instead of intelligently imo.
its just one tool in the box, not the ultimate methodology.