I personally think Agile is mostly a scam built around some very small nuggets of common sense wisdom, which has then been propagandized by legions of clueless methodology consultants to mediocre teams and management, and spun into mediocre books and conferenceware. Just my personal opinion, ymmv etc.
That said, this is a badly written article which doesn't convey much useful information or convincing argument. I am surprised it is on the HN front page,leave alone being the top ranked article (at the time of writing this comment).
Agile and TDD have been exhaustively discussed before on HN and an HNSearch will bring up much better arguments, both pro and con, from people who can clearly explain their viewpoints.
True, the article is basically a rant, but I tend to agree. I've felt like the agile train left my station long ago and it wasn't for trying. After being invited to attend a free 'workshop' from one of the holiest purveyors of agile out there, I left with the feeling that it definitely was all for those who did not know how to actually 'do the work'.
The trends I've been seeing and trying to do are as follows:
* full stack responsibility. You own the task front (js/html) to back (db), including testing.
* no f-ing standups. Communicate normally with your colleagues, no prescribed check in with them.
* no iterations. Release whenever; it may sound crazy but kanban style release whenever you're ready to push features out, in my mind, is the way to go.
* engineers, again, run the company. This in my mind is the biggest thing - having those 'with power' also be engineers and the product being the most important product.
All the above are the opposite of what I've seen with the agile movement. Keep teams small, keep them close and your product will reflect that.
Another huge, HUGE thing is to get the fucking mba management types out of the office. Can't stress this enough: if you can't code, you don't belong. You're making a tech company but you don't understand the basics of how the product is made.. So, you own a furniture making company and you don't understand what glue, oak, and lathes are..? Fail.
That's my real life experience and opinions regarding agile. I've tossed away all the agile stuff for a new project I'm doing and like the poster says, it's all based on common sense. You can run your company or project any way you want. I have friends that have millions in revenue every year with their small shops and they don't do any agile stuff. Yet they're one of the leaders in their space and when my friend, the engineer ceo, told me "we have no iterations or deadlines except when it has to be done by", that was a big wakeup. I was thinking "THAT'S how I want to do things".
True, agile is a collection of "very small nuggets of common sense wisdom". But one thing that often gets missed is that common sense is often very hard to implement properly; this is where a good agile trainer will help.
I can think of dozens of changes I should make to my every day life based on common sense (don't get stressed, spend more time with firends and familly, save for the future etc). Why don't I do them? Because it's difficult to align these "simlple" truths with the overall complexity of my environment and competing pressures. There's always complexity in the system, agile just simplifies one part and moves complexity into other areas e.g. having a highly trained and skilled team.
I'm surprised no one has brought up Steve Yegge's Good Agile, Bad Agile [1], which speaks well to both Google culture and scaling (good) Agile. One of the comments on that post mentions it. It's worth reading (and being Yegge, that'll take awhile).
Agile is like anything else: some well-meaning (and arguably useful) principles that get warped by bad managers and bad companies. The natural evolution for any such idea is to turn it into an industry and there are any number of people who are willing to sell you training, lectures, books and programs for Agile (with a capital-A). You need to separate the industry from the idea.
Exactly. And note the date: 6 years ago. I think the collective wisdom has been acquired. The IT community needs to name it in a way that makes these lessons learned common enough that the next time someone is burned by Bad Agile, they won't rewrite one more iteration of this same post.
It's useful to distinguish big-A and small-A agile.
Big-A Agile is a management buzzword, something you can become certified in and certainly a scam.
Small-a agile is a number of mostly common sense principles on how to approach process. It is emphatically not the process itself. While it cannot be meaningfully certified, it can be taught and learned.
Someone else linked to the agile manifesto. I'm just gonna go out on a limb and paste the punchline:
Individuals and interactions over processes and tools
Furthermore, I think it's best to consider Agile in its proper historical perspective. When it first emerged, its principles -- as you've enumerated from the manifesto -- were uncommon enough to be novel and insightful. In this context, the Agile philosophy was a legitimate reaction to the problems of its day. Whether or not it's been an effective remedy to those problems is a matter of hotly contested argument. But one is, perhaps, inclined to be more charitable to Agile when fixing it into historical place.
In principle, I don't think it's fair to call Agile -- the core, original theory -- a "sham." Rather, the "sham" is all the rigidity, trappings, and liturgy that have grown up around Agile since it reached its saturation point. At some point, Agile started to ossify into a shadow-image of everything it was intended to fix. But I think that failing reflects the nature of its practitioners more than it does the core philosophy.
I haven't heard that argument before. Interesting.
For me, big-A Agile refers to the Agile Manifesto for Software Development, and is the Agile that people are talking about in posts like this. It may be a software development buzzword, and yes there are certifications and they are scams, but I find the values and principles in the Agile Manifesto to be fairly sound and relevant within the context they were first produced in, as basically a reaction to waterfall in larger companies developing business software with average developers.
Small a agile is an English word meaning quick or flexible or something.
I am not saying I am right and you are wrong, just that is how I have usually thought about it.
The problem with these "only good programmers will create good products so stop with the Scrum already" rants is that in real life we have more than enough mediocre engineers and we just have to come up with best possible products with those.
I work as a quality assurance consultant. Usually companies buy my services when everything is messed up. Now if I try to solve their problems by saying "hire better engineers", nothing gets fixed. Nothing gets fixed because there is only so many good engineers available and the company usually don't have enough money to hire him/her.
But if I teach them to follow Scrum, it is really easy to add code reviews, testing (unit and functional), planned releases, etc.
It could be argued that one does not need Scrum to get those done or that it does not matter since team of better engineers will at some point do better job. But have problems in our hands right now and those must be fixed yesterday. So until some other methodology than Scrum get popular enough, we'll use that.
So in real life Scrum makes getting the best out of normal team so much easier. Sure there are always rockstars who don't need any process, but in reality you, me and most of us, are all pretty dumb and just have to live with the fact.
In the last few companies I have worked for, Agile was not lightweight, and became a significant hindrance to productivity. In fact, there was an "Agile consultant" brought in to make us more agile at one company I worked for. He ended up making our process 3-4x more convoluted and process intensive. He also succeeded in making the work not fun anymore. In my last job, "Scrum" meetings could take 30 minutes or more on many occasions, and our "sprints" would regularly change scope or be canceled mid way through.
I know that isnt Agile, but the problem is that many managers(and apparently consultants) think that is the way to do it. In my opinion, work getting done is not because you implement a process or methodology. Work gets done when you have a good team in place and trust them to do their job. Many companies seem to think that they can promote a non technical person to manage a development team. The problem with this is that they have no idea how software is built so implementing a methodology that promises consistent results no matter what the inputs are seems reasonable to them.
I am by no means representative of anyone other than myself, but I find I am most productive when a) I know the problem domain inside and out b) I am given some leeway with architecture and design c) I am not bogged down in process.
As projects get larger, its not as easy to allow for those conditions, so getting smart people on board is imperative. Agile should allow for managers to get some transparency and a view into the process, but little more...
Agile and Scrum have some good things going for them.
They teach developers that building things is always an iterative process. A well designed product will still require incremental on-the-fly improvements to get it right just as code does. Sometimes a design will require a refactor just as code does. Needing a 'complete' design doc before building a product is a fallacy.
They teach project managers that if they just let the designers and developers get on with it they can usually self-organise and manage their time better than if done top-down by a non-technical outsider.
They teach producers and 'product owners' that constant interference can be detrimental to a production process. Developers should be allowed to develop.
Best of all if done right they allow everyone scope to make mistakes yet still fix them and good mistakes that they can try out and keep.
However, there are downsides: scrum has no role for designers in the day-to-day production. Either they are pushed to the role of product manager or they have to work independently a sprint ahead. An ideal system would put the designers into the heart of the scrum team.
Top-down scrum is where it all goes badly wrong: producers and managers insisting that designs are complete before a line of code is created, managers taking the role of scrum-master, sprints being nothing more than waterfall milestones etc.
Let me say this. I have found scrum in particular to be used as a management tool (report back tool), and not a developer tool. It doesn't matter where i go. It starts with the greatest of intentions, and ends up where management are sticking there fingers in the pie half way through. And by that I mean they don't use priorities on the backlog to manage the process. They use the standup meetings as a moan session when things don't go there way. To me scrum in its purest form is where the developer drives the process. Most projects will perform better if they just let them do that.
Agile is a management tool. It helps manage developer time, feature bloat, organizational blocks, communication overheads and user expectations. It also helps you measure performance and identify bottlenecks in your own process. Like other comment said, it helps getting a couple things done instead of having a huge pile of stuff half done.
I disagree. I've met a LOT of developers who believe they know more than the customer, the QA team, the UX team and the DBAs. And they are, most often, wrong.
I think it takes a special sort of programmer to run a project to be honest. They are out there, but they are hard to find!
This kind of somewhat understandable but ultimately clueless ranting just tells me one thing: no way in hell I'm ever going to trust a programmer who cannot (or can not be bothered to) distinguish between marketing bullshit and the real thing.
This kind of attitude will show up in other matters, most importantly understanding what actually needs to be developed, what the priorities are and why they are important.
I'm surprised how many people here seem to be ignorant of Agile. Take for instance the certification scam accusation that is liberally thrown about: only Scrum has certification, and even that has always been controversial. As far as I know, no other Agile flavor tries to sell certification. But even so, Red Hat sells certification, does that make Red Hat Linux a scam?
There are scammers and greedy consultants in every area of IT. None of that has fuck all to do with Agile in particular. So why are people so hell bent on using this against Agile?
How well a team works together depends on far more than how smart the component engineers are. One clever engineer may be sufficient for a Suduku problem, but it is a matter of scale.
This fellow is basically arguing that we don't need government because people get along just fine on their own. Which is absolutely true on an individual scale, and not at all true as soon as two people live next door to one another.
In my experience 90% of software problems are social problems. He seems to care only about technical problems, and assumes those are solved by the magic of intelligence. I believe that if you can not explain to someone else how to do what you do, you aren't actually a master of your craft. Appeals to hire smarter coders sound incredibly hollow unless they are accompanied by techniques to make the average coder smarter.
There are much better critiques of Agile out there, mostly having to do with how it has been sold. I'm not sure what he thinks he is contributing to the discussion.
Any process can be harmful. It can also be incredibly useful, and the lack of process is at least as harmful as process applied badly. I recommend the book "The Checklist Manifestos" for examples. It proposes that the goal of process is to handle routine complexity and make cooperation routine, leaving human attention and effort free to focus on the actual hard problems.
No. Process is important; it's necessary. There are at least two prongs to this problem: one is you can't manage what you don't measure, and process gives you a way of tracking functionality implemented, defects, defects resolved, etc. There's nothing inherent to programming that gives your manager or your team any sort of knowledge about how far along you are, or just as importantly, when you will be done. You can hack all you like and -- even if your code is visible to all -- there's no way of guessing how far along you are, or if that needs-to-be-fixed-yesterday bug is close to resolution.
The other prong to this problem is you can't remember what you don't record. Well, you may have an eidetic memory, but unless the company generates deliverables besides code that explain what the code does or is supposed to do, a change in team X years down the line may mean the company forgets why Joe wrote the widget wrangler in the way that he did, and accordingly the widget wrangling module becomes an unmaintainable black box. Generating these deliverables is a part of the software process, whether Agile or otherwise.
And there will always be a process. This arises simply as a consequence of the fact that management needs to know how well you're doing, and if you're performing in a cost-effective manner, to many decimal places of precision. And if the process isn't agile, it could be something far less pleasant.
Agile Processes (big A) may sound scammy to you, like their proponents are trying to sell back to you shit you already know. But you only know that shit because you're a software developer. Management can't do what you do, and they're the target audience of Agile Processes like Scrum and XP. It gives them a ready-made Industry Best Practice that they can decide with confidence to adopt company-wide, with little perceived risk because it's so proven and widespread. Compare and contrast with the success of the "open source" meme in convincing companies to adopt, and participate in, free software.
No, it's even worse. You can't manage what you can't measure. And so far no one has found a metric to measure creative output like painting, writing poetry or writing software. Whatever metric you choose to measure and evaluate your team, and esp. what ever metric you reward is going to lead your team optimizing their performance for that metric.
You want to measure LOC, programmers WILL write more lines. Want to measure and reward less defects, programmers WILL create less defects etc. But will your software be sexy, appealing to users, creative, innovative, trend setting solution to old/new problem?
Is Agile (big A) really as "proven" as proponents make it out to be?
I'd love to see some citations in the form of "Product XYZ that you know and love is developed using Agile" as opposed to the usual "My cousin's friend's brother's girlfriend used Agile for an internal CRUD tool and it went totally great".
In the real world, the few times I've worked at places that attempted Agile (Scrum both times) I've only seen Agile fail miserably.
I would like to add one thing to that: Process is necessary, but it should never be the solution.
This is where people tend to wrong at the very start. Any attempt to implement Agile (or any other method) with the illusion that process can solve the problem will always go horrible wrong.
Process is, actually, just tax. If you need to follow a prescribed process in order to be in any way an effective coder then you are mediocre at best and so is your work and your project.
Discipline is just a tax. If you need to structure and test your code, then you're a mediocre coder at best, and so is your work and project. Just write whatever you feel like, it'll turn out ok. You're awesome, how could you possibly code anything less than exactly what the client wants?
Nonsense. Agile is a discipline, just like properly structuring your code and testing it. It's discipline at a macro scale, on the team, rather than the individual programmer. You might argue over whether its specific practices are better or worse than other methods, but arguing against any development process at all is absurd.
The problem with Agile development is the same problem that has affected many modern revolutions: The revolution against the current ruling class gets co-opted by the current ruling class[1]. The revolution then ends up changing nothing more meaningful than the colors on the flag.
Agile was supposed to help developers escape the obstacles of poor management and poor managers. It's really about developers owning the development of the software, and being given more creative authority. Non-developers play a support role, if they're present at all. That part is all fine and dandy, and it's The Good Part® of agile. Let the guys who make software be responsible for making software. Brilliant!
Managers, of course, don't want to get marginalized. If they see a movement towards Agile, they would rather bring it in themselves, so that they can control how it's implemented. And they implement it in a way that a) fits their existing biases about software development b) doesn't marginalize themselves[2]. Both of those goals are met by taking the agile process, and turning into The Agile Process (engraved on stone tablets, up on a pedestal).
Agile should be less process, but when the transition is implemented by process guys, it just ends up being different process rather than less. And naturally, the one role in agile that ex-managers can step into (aforementioned support role) is more important in this set-up, because it's about owning and managing the process. So the revolution happens, and nothing changes. Instead of developers having more freedom, the old managers just have a new title. That title still comes with the authority to make developers fall in line, except that "in line" now refers to a different set-in-stone collection of steps and rules.
tl;dr Meet the new boss, same as the old boss.
[1] I'd rather not derail this thread into history and politics so I'm avoiding details.
[2] b) is actually a subset of a). One of management's existing biases is that management and process is an important part of software development.
This isn't a knock of managers; everyone thinks the same about themselves. Hell, Agile itself basically originates from developers having the same bias. They just happen to be more correct ;).
"Agile is not a silver bullet" is more to the point, and applying it dogmatically can counterproductive.
But regular communication, short, well defined sprints and a prioritized backlog available to all can do wonders in terms of getting a small amount of stuff done rather than a large amount half done.
Well, agile and TDD (not necessarily together) are good for two kinds of projects.
(1) If you're building simple web apps for small town clients in a framework like RoR, you can break things into little tasks and estimate with laser-like accuracy. This fits in great with an agile methodology
(2) If you're writing security-sensitive string parsing code or any algorithms with tricky components, TDD is a big win. When I was in grad school I converted a very slow program for solving a quantum system (worked for N=5) into a very fast program (worked for N=64) by building very detailed test scaffolding. I don't know if I could have built the fast but complicated app without the tests.
Now, I've got another app where I almost want to use TDD but I'd wind up building a whole Potempkin village of mock objects and I just can't bear the line count I'd need to first write it all, find bugs in, and then maintain.
(1) Being able to estimate with laser-like accuracy is not part of what's agile. Estimation is not part of the agile manifesto at all - Kanban for example can be done without a single estimate. It just limits the number of tasks that you have in parallel. Scrum on the other hand does deal with estimates, but it mainly postulates that you can't estimate large chunks of work at all and small chunks not necessarily correct. So there are all kinds of observed correction metrics built in that help you to get a better estimate - no one vouches for a correct one though.
(2) If you can't use TDD because you have to build a whole set of mock object you might have a tightly coupled system. Writing a test is not dead line count, it helps to formulate boundary conditions and expected behavior. It's certainly not useful for all kinds of project but it's certainly not limited to security sensitive or tricky algorithms. If the behavior is simple, then the test is simple as well. If the behavior is complicated, then the test will be as well - but at least you'll think about how it is supposed to be.
I dunno. In a way I think he is right in some ways in that most of the times people say they are doing agile or scrum it is a sham and they are not really doing agile and also it generally doesn't tell you much about how well they work.
Also I think that process can very easily get in the way. I was actually thinking maybe things would work better for small teams if you just handled everything in a group chat room with a history like campfire.
But I still have hope that someday I'm actually going to use TDD for a project and then have way fewer regressions to deal with. Still haven't had the discipline I guess to really learn and apply TDD after all these years although I have sort of done it a little a few times.
And also a few other things like short iterations and getting the simplest useful software going which I always thought were part of agile, those things help. Although it has always been a battle for me to get managers or even users to stop adding features and do an initial release so I haven't been very successful in that aspect.
I don't know if the quality the individuals on the team is everything but it is a good point that it is probably more important than anything.
I also would really like to believe that having a real QA team as part of the process would improve things, although I have never had that luxury either so it may be a false hope. But that would be something in the process category.
An agile process isn't just there to manage the developers, it's there to engage and manage the customer as well.
In my experience, customers rarely know exactly what they want out of a software project, large or small. Complicated documents, produced up front get ignored because of TL;DR and projects start on faulty specifications that describe a solution to illusory requirements. So, inevitably, there will be a disparity between documented requirements and the desired outcome.
Iterative delivery - a key feature of agile as I have experienced it - gives the customer multiple chances to try-out and feedback on working software along the way. Furthermore, by making the customer part of the solution early they are as instrumental as the implementers in ensuring the validity of the software and - therefore - the success of the project.
Incidentally, I think this is why many customers (internal and external) are suspicious of and hesitant to engage in a truly agile process. That is, they would become equally liable for the success of the project because of the decisions they are required to make. They are part of the solution and therefore potentially party to the blame for any failures. It's much safer for them to be more likely to fail and avoid the blame than it is to risk complicity in a failure, however less likely that failure might be as a result of the process.
What agile does that the author missed (or at least declined to mention) is that it gives a name to and formalises an approach that attempts to manage the customer as well as the implementers. It compensates for the fact that customers can't always be expected to fully understand their own requirements and for the inevitability that they change their minds.
Just differentiate between what Agile is and how people are pushing Agile on you. Different things entirely.
Agile is best practices around iterative and incremental development. Period. Yes, there's a manifesto and there's Scrum and all sorts of other things, but at the end of the day Agile is a marketing term. A place to go find out what people are trying in order to get better.
Two secrets here. One, team success is about 90% dependent on who is on the team. Good teams do well. Bad teams do poorly. But if you're going to have more than one team, you need some way to measure and talk about what they are doing, so you have to have something.
Agile -- when done correctly -- is just the minimum amount of something you need to get your work done. It is the minimum amount of process. After all, it's not like you can have no process at all. Whatever you're doing already is a process.
I've seen hundreds of teams struggle with Agile, and to me the problem is that we do a really bad job of balancing the difference between "here's a best practice that worked awesome for about 80% of the teams that tried it" and "These are the rules. You must do this." In many shops, Agile is just another way of micro-managing teams, sadly.
I can't help that. I also can't help the fact that lots of folks are out to make a buck on certifications and such. I don't think that makes Agile bad. Heck, I'm not even against certifications, although I'd never get one. I just think we take things too far.
I like the idea of having a marketing blurb "Agile" where I can go to find out what kinds of new stuff is being done. It helps me pick better reading material.
The second secret is that most teams, frankly, are not that good. So you need some kind of way to demonstrate that as well. Making things incrementally and in small iterations lets you see how bad teams are early on. You fail early and often. Then at least you have a bit of a shot at trying to help.
But believe me, I feel your pain. Sounds to me like you are a lot more upset at modern marketing and management attitudes than Agile. Remember that we technical folks have a way of over-doing whatever we get into, as I was writing in my blog before your post appeared! (It's still very strange to me watching HN how the same topic comes from multiple writers at the same time) http://tiny-giant-books.com/blog/agile-means-stop-focusing-o...
I got involved with this stuff before the term "Agile" existed. At the beginning, it was a bunch of professionals (mostly developers) sincerely trying to find better ways of working. Extreme Programming, for example, came to be because the developers were really interested to experiment with how their team got stuff done.
It breaks my heart that in the ensuing decade it has turned into exactly the kind of bullshit, top-down, PHB-fluffing idiocy that early agilists were trying to get away from. If you look at the Agile Manifesto, the focus is supposed to be on a) people, b) shipping working software, c) collaboration, and d) being adaptable. That is sure not what it has become.
In my view, we made a crucial mistake: we didn't think about money and power enough. Now the Agile industry is 98% selling idiotic certifications and homeopathic doses of process improvement to organizations that don't really want to change anything at all.
Mad. It makes me mad. Sorry we screwed it up, everybody.
> In many shops, Agile is just another way of micro-managing teams, sadly.
I think this is a big source of the complaints, yeah. If I had to narrow it to one specific mis-implementation of agile, it'd be having daily standup meetings turn into daily mini-performance-reviews with the boss. Iirc the Official Scrum Rules try to avoid that by decreeing that the scrum-master should be just another team member, and not a project lead or other kind of supervisor/boss, but afaict that recommendation isn't often followed.
"The second secret is that most teams, frankly, are not that good. So you need some kind of way [...]"
Agree. Let's not forget the HR challenge most organizations have today. It's hard to find, hire, develop and keep talented people in the company. I heard the other day: "every job seeker is a potential low performer". The basis of that is that most talented, highly qualified people is either managing teams or freelancing/consulting, and inevitably making interesting amounts of cash either way. So the chances of finding this profile on every Agile team is low.
In this scenario, Agile has its intrinsic value of providing teams members of various competence levels with some minimum rules of conduct, processes and tools. Maybe good teams will think they are all about bureaucracy, or they'll think it's something the management layers of the company can look and understand, like a burnout chart.
That's why I cut the second sentence of the quote above in the middle. Sometimes, as a manager, you need a "way", like the Japanese word for "Do", to keep discipline and make things moving forward.
> The second secret is that most teams, frankly, are not that good.
It's so important to remember this, as well as the corollary: I'm not that good myself. The article included this line:
> If you need to follow a prescribed process in order to be in any way an effective coder then you are mediocre at best and so is your work and your project.
I'm not sure if I agree with the statement itself, although I certainly think -- and know no one who doesn't think -- that the quality of your staff is more important than your process. But I'm sure I disagree with the way this statement is used to dismiss the idea of a prescribed process. One of the main goals of such a process is to get as good work as possible out of mediocre staff. Because there aren't enough high quality staff to go around. You won't get great work out of mediocre workers, but if you can get pretty bad work instead of total garbage, in many environments that's a big win. (In the startup environment that is hn's focus, pretty bad might be just as bad as total garbage.)
I have nothing to say but to offer words of encouragement in your effort to write e-books to undo some of the damage.
It breaks my heart to see something that emerged from technical people to make their lives better and make them more effective be co-opted to the point where it's scorned by the same technical people who have the most to gain.
> [Obligatory plug and disclaimer: Agile professional
You sell process for a living. You claim, "After all, it's not like you can have no process at all. Whatever you're doing already is a process." When you said that, you accidentally got something right.
Programming is a process. It's the only one that fucking matters if you're a shop that sells software. All the other process comes from snake oil salesmen as yourself, or pointy haired bosses who don't know a fucking thing about programming.
Programming. Either learn and do it, or get the fuck out of its way.
Just because something doesn't have a name and isn't written down anywhere doesn't mean it doesn't exist. If you don't like agile, it doesn't mean you have no process. It just means you are following another process. Assuming you have a project that actually involves interacting with multiple programmers, your ability to interact with them is a key part of getting the job done.
If you're a lone cowboy doing it all alone, then good for you, but please state that upfront in your blog posts about how the software world is doing it wrong so we know you are evaluating things from a very unusual position.
If you aren't a sole programmer, then you've got a process. Maybe it's better than agile processes. If so, please, tell us what that process it.
This whole article reads like a racecar driver dismissing automotive technology because the only thing that matters is the skill of the driver.
Even for really talented developers - imo just because they are talented (they can code and can solve problems) doesn't mean they can play well within a team - especially in a team without any processes to guide them through.
I personally find the author's view on processes to be very naive - and a bit offensive, it's almost like saying if you employ processes, then you are stupid.
The notion that some 'good,' 'quality,' or 'talented' programmer is somehow entirely autonomous is entirely a fallacy. I'd trust a team of 'mediocre' programmers that follow process and get it done than place blind trust in a couple cowboys or post-docs who have some claim to genius in a prior life.
Sure, some are better than others. But to those who somehow believe that Great Programmers can do anything, get over yourselves. They (read: you) probably aren't nearly as good as you think.
[+] [-] plinkplonk|14 years ago|reply
That said, this is a badly written article which doesn't convey much useful information or convincing argument. I am surprised it is on the HN front page,leave alone being the top ranked article (at the time of writing this comment).
Agile and TDD have been exhaustively discussed before on HN and an HNSearch will bring up much better arguments, both pro and con, from people who can clearly explain their viewpoints.
[+] [-] equalarrow|14 years ago|reply
The trends I've been seeing and trying to do are as follows:
* full stack responsibility. You own the task front (js/html) to back (db), including testing.
* no f-ing standups. Communicate normally with your colleagues, no prescribed check in with them.
* no iterations. Release whenever; it may sound crazy but kanban style release whenever you're ready to push features out, in my mind, is the way to go.
* engineers, again, run the company. This in my mind is the biggest thing - having those 'with power' also be engineers and the product being the most important product.
All the above are the opposite of what I've seen with the agile movement. Keep teams small, keep them close and your product will reflect that.
Another huge, HUGE thing is to get the fucking mba management types out of the office. Can't stress this enough: if you can't code, you don't belong. You're making a tech company but you don't understand the basics of how the product is made.. So, you own a furniture making company and you don't understand what glue, oak, and lathes are..? Fail.
That's my real life experience and opinions regarding agile. I've tossed away all the agile stuff for a new project I'm doing and like the poster says, it's all based on common sense. You can run your company or project any way you want. I have friends that have millions in revenue every year with their small shops and they don't do any agile stuff. Yet they're one of the leaders in their space and when my friend, the engineer ceo, told me "we have no iterations or deadlines except when it has to be done by", that was a big wakeup. I was thinking "THAT'S how I want to do things".
So, it can be done. Good luck. :)
[+] [-] ryandvm|14 years ago|reply
I don't really have a problem with the tenets of Agile, but the Church of Agile, its high priests, and its associated industries are bullshit.
[+] [-] papatron|14 years ago|reply
I can think of dozens of changes I should make to my every day life based on common sense (don't get stressed, spend more time with firends and familly, save for the future etc). Why don't I do them? Because it's difficult to align these "simlple" truths with the overall complexity of my environment and competing pressures. There's always complexity in the system, agile just simplifies one part and moves complexity into other areas e.g. having a highly trained and skilled team.
[+] [-] cletus|14 years ago|reply
Agile is like anything else: some well-meaning (and arguably useful) principles that get warped by bad managers and bad companies. The natural evolution for any such idea is to turn it into an industry and there are any number of people who are willing to sell you training, lectures, books and programs for Agile (with a capital-A). You need to separate the industry from the idea.
[1]: http://steve-yegge.blogspot.com/2006/09/good-agile-bad-agile...
[+] [-] davesims|14 years ago|reply
[+] [-] mseebach|14 years ago|reply
Big-A Agile is a management buzzword, something you can become certified in and certainly a scam.
Small-a agile is a number of mostly common sense principles on how to approach process. It is emphatically not the process itself. While it cannot be meaningfully certified, it can be taught and learned.
Someone else linked to the agile manifesto. I'm just gonna go out on a limb and paste the punchline:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
[+] [-] jonnathanson|14 years ago|reply
Furthermore, I think it's best to consider Agile in its proper historical perspective. When it first emerged, its principles -- as you've enumerated from the manifesto -- were uncommon enough to be novel and insightful. In this context, the Agile philosophy was a legitimate reaction to the problems of its day. Whether or not it's been an effective remedy to those problems is a matter of hotly contested argument. But one is, perhaps, inclined to be more charitable to Agile when fixing it into historical place.
In principle, I don't think it's fair to call Agile -- the core, original theory -- a "sham." Rather, the "sham" is all the rigidity, trappings, and liturgy that have grown up around Agile since it reached its saturation point. At some point, Agile started to ossify into a shadow-image of everything it was intended to fix. But I think that failing reflects the nature of its practitioners more than it does the core philosophy.
[+] [-] MrKurtHaeusler|14 years ago|reply
For me, big-A Agile refers to the Agile Manifesto for Software Development, and is the Agile that people are talking about in posts like this. It may be a software development buzzword, and yes there are certifications and they are scams, but I find the values and principles in the Agile Manifesto to be fairly sound and relevant within the context they were first produced in, as basically a reaction to waterfall in larger companies developing business software with average developers.
Small a agile is an English word meaning quick or flexible or something.
I am not saying I am right and you are wrong, just that is how I have usually thought about it.
[+] [-] hpaavola|14 years ago|reply
I work as a quality assurance consultant. Usually companies buy my services when everything is messed up. Now if I try to solve their problems by saying "hire better engineers", nothing gets fixed. Nothing gets fixed because there is only so many good engineers available and the company usually don't have enough money to hire him/her.
But if I teach them to follow Scrum, it is really easy to add code reviews, testing (unit and functional), planned releases, etc.
It could be argued that one does not need Scrum to get those done or that it does not matter since team of better engineers will at some point do better job. But have problems in our hands right now and those must be fixed yesterday. So until some other methodology than Scrum get popular enough, we'll use that.
So in real life Scrum makes getting the best out of normal team so much easier. Sure there are always rockstars who don't need any process, but in reality you, me and most of us, are all pretty dumb and just have to live with the fact.
[+] [-] brazzy|14 years ago|reply
[+] [-] S_A_P|14 years ago|reply
I know that isnt Agile, but the problem is that many managers(and apparently consultants) think that is the way to do it. In my opinion, work getting done is not because you implement a process or methodology. Work gets done when you have a good team in place and trust them to do their job. Many companies seem to think that they can promote a non technical person to manage a development team. The problem with this is that they have no idea how software is built so implementing a methodology that promises consistent results no matter what the inputs are seems reasonable to them.
I am by no means representative of anyone other than myself, but I find I am most productive when a) I know the problem domain inside and out b) I am given some leeway with architecture and design c) I am not bogged down in process.
As projects get larger, its not as easy to allow for those conditions, so getting smart people on board is imperative. Agile should allow for managers to get some transparency and a view into the process, but little more...
[+] [-] sambeau|14 years ago|reply
They teach developers that building things is always an iterative process. A well designed product will still require incremental on-the-fly improvements to get it right just as code does. Sometimes a design will require a refactor just as code does. Needing a 'complete' design doc before building a product is a fallacy.
They teach project managers that if they just let the designers and developers get on with it they can usually self-organise and manage their time better than if done top-down by a non-technical outsider.
They teach producers and 'product owners' that constant interference can be detrimental to a production process. Developers should be allowed to develop.
Best of all if done right they allow everyone scope to make mistakes yet still fix them and good mistakes that they can try out and keep.
However, there are downsides: scrum has no role for designers in the day-to-day production. Either they are pushed to the role of product manager or they have to work independently a sprint ahead. An ideal system would put the designers into the heart of the scrum team.
Top-down scrum is where it all goes badly wrong: producers and managers insisting that designs are complete before a line of code is created, managers taking the role of scrum-master, sprints being nothing more than waterfall milestones etc.
[+] [-] creigh|14 years ago|reply
[+] [-] rbanffy|14 years ago|reply
[+] [-] tbsdy|14 years ago|reply
I think it takes a special sort of programmer to run a project to be honest. They are out there, but they are hard to find!
[+] [-] peteretep|14 years ago|reply
[+] [-] zedshaw|14 years ago|reply
[+] [-] rickmb|14 years ago|reply
This kind of attitude will show up in other matters, most importantly understanding what actually needs to be developed, what the priorities are and why they are important.
I'm surprised how many people here seem to be ignorant of Agile. Take for instance the certification scam accusation that is liberally thrown about: only Scrum has certification, and even that has always been controversial. As far as I know, no other Agile flavor tries to sell certification. But even so, Red Hat sells certification, does that make Red Hat Linux a scam?
There are scammers and greedy consultants in every area of IT. None of that has fuck all to do with Agile in particular. So why are people so hell bent on using this against Agile?
[+] [-] roguecoder|14 years ago|reply
In my experience 90% of software problems are social problems. He seems to care only about technical problems, and assumes those are solved by the magic of intelligence. I believe that if you can not explain to someone else how to do what you do, you aren't actually a master of your craft. Appeals to hire smarter coders sound incredibly hollow unless they are accompanied by techniques to make the average coder smarter.
There are much better critiques of Agile out there, mostly having to do with how it has been sold. I'm not sure what he thinks he is contributing to the discussion.
Any process can be harmful. It can also be incredibly useful, and the lack of process is at least as harmful as process applied badly. I recommend the book "The Checklist Manifestos" for examples. It proposes that the goal of process is to handle routine complexity and make cooperation routine, leaving human attention and effort free to focus on the actual hard problems.
[+] [-] bitwize|14 years ago|reply
The other prong to this problem is you can't remember what you don't record. Well, you may have an eidetic memory, but unless the company generates deliverables besides code that explain what the code does or is supposed to do, a change in team X years down the line may mean the company forgets why Joe wrote the widget wrangler in the way that he did, and accordingly the widget wrangling module becomes an unmaintainable black box. Generating these deliverables is a part of the software process, whether Agile or otherwise.
And there will always be a process. This arises simply as a consequence of the fact that management needs to know how well you're doing, and if you're performing in a cost-effective manner, to many decimal places of precision. And if the process isn't agile, it could be something far less pleasant.
Agile Processes (big A) may sound scammy to you, like their proponents are trying to sell back to you shit you already know. But you only know that shit because you're a software developer. Management can't do what you do, and they're the target audience of Agile Processes like Scrum and XP. It gives them a ready-made Industry Best Practice that they can decide with confidence to adopt company-wide, with little perceived risk because it's so proven and widespread. Compare and contrast with the success of the "open source" meme in convincing companies to adopt, and participate in, free software.
[+] [-] super_mario|14 years ago|reply
You want to measure LOC, programmers WILL write more lines. Want to measure and reward less defects, programmers WILL create less defects etc. But will your software be sexy, appealing to users, creative, innovative, trend setting solution to old/new problem?
[+] [-] georgemcbay|14 years ago|reply
I'd love to see some citations in the form of "Product XYZ that you know and love is developed using Agile" as opposed to the usual "My cousin's friend's brother's girlfriend used Agile for an internal CRUD tool and it went totally great".
In the real world, the few times I've worked at places that attempted Agile (Scrum both times) I've only seen Agile fail miserably.
[+] [-] rickmb|14 years ago|reply
This is where people tend to wrong at the very start. Any attempt to implement Agile (or any other method) with the illusion that process can solve the problem will always go horrible wrong.
[+] [-] vannevar|14 years ago|reply
Discipline is just a tax. If you need to structure and test your code, then you're a mediocre coder at best, and so is your work and project. Just write whatever you feel like, it'll turn out ok. You're awesome, how could you possibly code anything less than exactly what the client wants?
Nonsense. Agile is a discipline, just like properly structuring your code and testing it. It's discipline at a macro scale, on the team, rather than the individual programmer. You might argue over whether its specific practices are better or worse than other methods, but arguing against any development process at all is absurd.
[+] [-] lmkg|14 years ago|reply
Agile was supposed to help developers escape the obstacles of poor management and poor managers. It's really about developers owning the development of the software, and being given more creative authority. Non-developers play a support role, if they're present at all. That part is all fine and dandy, and it's The Good Part® of agile. Let the guys who make software be responsible for making software. Brilliant!
Managers, of course, don't want to get marginalized. If they see a movement towards Agile, they would rather bring it in themselves, so that they can control how it's implemented. And they implement it in a way that a) fits their existing biases about software development b) doesn't marginalize themselves[2]. Both of those goals are met by taking the agile process, and turning into The Agile Process (engraved on stone tablets, up on a pedestal).
Agile should be less process, but when the transition is implemented by process guys, it just ends up being different process rather than less. And naturally, the one role in agile that ex-managers can step into (aforementioned support role) is more important in this set-up, because it's about owning and managing the process. So the revolution happens, and nothing changes. Instead of developers having more freedom, the old managers just have a new title. That title still comes with the authority to make developers fall in line, except that "in line" now refers to a different set-in-stone collection of steps and rules.
tl;dr Meet the new boss, same as the old boss.
[1] I'd rather not derail this thread into history and politics so I'm avoiding details.
[2] b) is actually a subset of a). One of management's existing biases is that management and process is an important part of software development.
This isn't a knock of managers; everyone thinks the same about themselves. Hell, Agile itself basically originates from developers having the same bias. They just happen to be more correct ;).
[+] [-] benohear|14 years ago|reply
But regular communication, short, well defined sprints and a prioritized backlog available to all can do wonders in terms of getting a small amount of stuff done rather than a large amount half done.
[+] [-] crudolph|14 years ago|reply
[+] [-] PaulHoule|14 years ago|reply
(1) If you're building simple web apps for small town clients in a framework like RoR, you can break things into little tasks and estimate with laser-like accuracy. This fits in great with an agile methodology
(2) If you're writing security-sensitive string parsing code or any algorithms with tricky components, TDD is a big win. When I was in grad school I converted a very slow program for solving a quantum system (worked for N=5) into a very fast program (worked for N=64) by building very detailed test scaffolding. I don't know if I could have built the fast but complicated app without the tests.
Now, I've got another app where I almost want to use TDD but I'd wind up building a whole Potempkin village of mock objects and I just can't bear the line count I'd need to first write it all, find bugs in, and then maintain.
[+] [-] Xylakant|14 years ago|reply
(1) Being able to estimate with laser-like accuracy is not part of what's agile. Estimation is not part of the agile manifesto at all - Kanban for example can be done without a single estimate. It just limits the number of tasks that you have in parallel. Scrum on the other hand does deal with estimates, but it mainly postulates that you can't estimate large chunks of work at all and small chunks not necessarily correct. So there are all kinds of observed correction metrics built in that help you to get a better estimate - no one vouches for a correct one though.
(2) If you can't use TDD because you have to build a whole set of mock object you might have a tightly coupled system. Writing a test is not dead line count, it helps to formulate boundary conditions and expected behavior. It's certainly not useful for all kinds of project but it's certainly not limited to security sensitive or tricky algorithms. If the behavior is simple, then the test is simple as well. If the behavior is complicated, then the test will be as well - but at least you'll think about how it is supposed to be.
[+] [-] ilaksh|14 years ago|reply
Also I think that process can very easily get in the way. I was actually thinking maybe things would work better for small teams if you just handled everything in a group chat room with a history like campfire.
But I still have hope that someday I'm actually going to use TDD for a project and then have way fewer regressions to deal with. Still haven't had the discipline I guess to really learn and apply TDD after all these years although I have sort of done it a little a few times.
And also a few other things like short iterations and getting the simplest useful software going which I always thought were part of agile, those things help. Although it has always been a battle for me to get managers or even users to stop adding features and do an initial release so I haven't been very successful in that aspect.
I don't know if the quality the individuals on the team is everything but it is a good point that it is probably more important than anything.
I also would really like to believe that having a real QA team as part of the process would improve things, although I have never had that luxury either so it may be a false hope. But that would be something in the process category.
[+] [-] elmomalmo|14 years ago|reply
In my experience, customers rarely know exactly what they want out of a software project, large or small. Complicated documents, produced up front get ignored because of TL;DR and projects start on faulty specifications that describe a solution to illusory requirements. So, inevitably, there will be a disparity between documented requirements and the desired outcome.
Iterative delivery - a key feature of agile as I have experienced it - gives the customer multiple chances to try-out and feedback on working software along the way. Furthermore, by making the customer part of the solution early they are as instrumental as the implementers in ensuring the validity of the software and - therefore - the success of the project.
Incidentally, I think this is why many customers (internal and external) are suspicious of and hesitant to engage in a truly agile process. That is, they would become equally liable for the success of the project because of the decisions they are required to make. They are part of the solution and therefore potentially party to the blame for any failures. It's much safer for them to be more likely to fail and avoid the blame than it is to risk complicity in a failure, however less likely that failure might be as a result of the process.
What agile does that the author missed (or at least declined to mention) is that it gives a name to and formalises an approach that attempts to manage the customer as well as the implementers. It compensates for the fact that customers can't always be expected to fully understand their own requirements and for the inevitability that they change their minds.
[+] [-] DanielBMarkham|14 years ago|reply
Just differentiate between what Agile is and how people are pushing Agile on you. Different things entirely.
Agile is best practices around iterative and incremental development. Period. Yes, there's a manifesto and there's Scrum and all sorts of other things, but at the end of the day Agile is a marketing term. A place to go find out what people are trying in order to get better.
Two secrets here. One, team success is about 90% dependent on who is on the team. Good teams do well. Bad teams do poorly. But if you're going to have more than one team, you need some way to measure and talk about what they are doing, so you have to have something.
Agile -- when done correctly -- is just the minimum amount of something you need to get your work done. It is the minimum amount of process. After all, it's not like you can have no process at all. Whatever you're doing already is a process.
I've seen hundreds of teams struggle with Agile, and to me the problem is that we do a really bad job of balancing the difference between "here's a best practice that worked awesome for about 80% of the teams that tried it" and "These are the rules. You must do this." In many shops, Agile is just another way of micro-managing teams, sadly.
I can't help that. I also can't help the fact that lots of folks are out to make a buck on certifications and such. I don't think that makes Agile bad. Heck, I'm not even against certifications, although I'd never get one. I just think we take things too far.
I like the idea of having a marketing blurb "Agile" where I can go to find out what kinds of new stuff is being done. It helps me pick better reading material.
The second secret is that most teams, frankly, are not that good. So you need some kind of way to demonstrate that as well. Making things incrementally and in small iterations lets you see how bad teams are early on. You fail early and often. Then at least you have a bit of a shot at trying to help.
But believe me, I feel your pain. Sounds to me like you are a lot more upset at modern marketing and management attitudes than Agile. Remember that we technical folks have a way of over-doing whatever we get into, as I was writing in my blog before your post appeared! (It's still very strange to me watching HN how the same topic comes from multiple writers at the same time) http://tiny-giant-books.com/blog/agile-means-stop-focusing-o...
[+] [-] wpietri|14 years ago|reply
I got involved with this stuff before the term "Agile" existed. At the beginning, it was a bunch of professionals (mostly developers) sincerely trying to find better ways of working. Extreme Programming, for example, came to be because the developers were really interested to experiment with how their team got stuff done.
It breaks my heart that in the ensuing decade it has turned into exactly the kind of bullshit, top-down, PHB-fluffing idiocy that early agilists were trying to get away from. If you look at the Agile Manifesto, the focus is supposed to be on a) people, b) shipping working software, c) collaboration, and d) being adaptable. That is sure not what it has become.
In my view, we made a crucial mistake: we didn't think about money and power enough. Now the Agile industry is 98% selling idiotic certifications and homeopathic doses of process improvement to organizations that don't really want to change anything at all.
Mad. It makes me mad. Sorry we screwed it up, everybody.
[+] [-] _delirium|14 years ago|reply
I think this is a big source of the complaints, yeah. If I had to narrow it to one specific mis-implementation of agile, it'd be having daily standup meetings turn into daily mini-performance-reviews with the boss. Iirc the Official Scrum Rules try to avoid that by decreeing that the scrum-master should be just another team member, and not a project lead or other kind of supervisor/boss, but afaict that recommendation isn't often followed.
[+] [-] rodolphoarruda|14 years ago|reply
Agree. Let's not forget the HR challenge most organizations have today. It's hard to find, hire, develop and keep talented people in the company. I heard the other day: "every job seeker is a potential low performer". The basis of that is that most talented, highly qualified people is either managing teams or freelancing/consulting, and inevitably making interesting amounts of cash either way. So the chances of finding this profile on every Agile team is low.
In this scenario, Agile has its intrinsic value of providing teams members of various competence levels with some minimum rules of conduct, processes and tools. Maybe good teams will think they are all about bureaucracy, or they'll think it's something the management layers of the company can look and understand, like a burnout chart.
That's why I cut the second sentence of the quote above in the middle. Sometimes, as a manager, you need a "way", like the Japanese word for "Do", to keep discipline and make things moving forward.
[+] [-] pnathan|14 years ago|reply
That is,
Statement: No Agile Team would do X.
Response: An Agile Team did do X.
Statement: Well, no True Agile Team would do X.
(http://en.wikipedia.org/wiki/No_true_Scotsman)
[+] [-] timbre|14 years ago|reply
It's so important to remember this, as well as the corollary: I'm not that good myself. The article included this line:
> If you need to follow a prescribed process in order to be in any way an effective coder then you are mediocre at best and so is your work and your project.
I'm not sure if I agree with the statement itself, although I certainly think -- and know no one who doesn't think -- that the quality of your staff is more important than your process. But I'm sure I disagree with the way this statement is used to dismiss the idea of a prescribed process. One of the main goals of such a process is to get as good work as possible out of mediocre staff. Because there aren't enough high quality staff to go around. You won't get great work out of mediocre workers, but if you can get pretty bad work instead of total garbage, in many environments that's a big win. (In the startup environment that is hn's focus, pretty bad might be just as bad as total garbage.)
[+] [-] stcredzero|14 years ago|reply
Agile could be deleted, and replaced with a variable. Sturgeon's Law at work.
The second secret is that most teams, frankly, are not that good.
Again, Sturgeon's Law at work.
[+] [-] MartinCron|14 years ago|reply
It breaks my heart to see something that emerged from technical people to make their lives better and make them more effective be co-opted to the point where it's scorned by the same technical people who have the most to gain.
[+] [-] itsnotme|14 years ago|reply
You sell process for a living. You claim, "After all, it's not like you can have no process at all. Whatever you're doing already is a process." When you said that, you accidentally got something right.
Programming is a process. It's the only one that fucking matters if you're a shop that sells software. All the other process comes from snake oil salesmen as yourself, or pointy haired bosses who don't know a fucking thing about programming.
Programming. Either learn and do it, or get the fuck out of its way.
[+] [-] kevinpet|14 years ago|reply
If you're a lone cowboy doing it all alone, then good for you, but please state that upfront in your blog posts about how the software world is doing it wrong so we know you are evaluating things from a very unusual position.
If you aren't a sole programmer, then you've got a process. Maybe it's better than agile processes. If so, please, tell us what that process it.
This whole article reads like a racecar driver dismissing automotive technology because the only thing that matters is the skill of the driver.
[+] [-] mattdeboard|14 years ago|reply
Ergo, since mediocre programmers exist, agile isn't a sham, and is necessary. QED
[+] [-] fredwu|14 years ago|reply
I personally find the author's view on processes to be very naive - and a bit offensive, it's almost like saying if you employ processes, then you are stupid.
EDIT:
My thoughts in a separate entry: http://news.ycombinator.com/item?id=3765693
[+] [-] hack_edu|14 years ago|reply
Sure, some are better than others. But to those who somehow believe that Great Programmers can do anything, get over yourselves. They (read: you) probably aren't nearly as good as you think.