Agile is a Sham • Hacker News Board

Re: Agile is a Sham

#41

Post by elmomalmo » Wed, Mar 28, 2012, 1:14 PM UTC

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.

Re: Agile is a Sham

#42

Post by peteretep » Wed, Mar 28, 2012, 1:19 PM UTC

super_mario wrote: post #35

That should be clear to anyone that has even a little mathematical/computer science training. Anyone that says you can follow some process to ensure success is effectively telling you they have implemented artificial intelligence that simulates a production line designer and to be able to do it by using humans pushing bits of paper around as their computer.

> Anyone that says you can follow some process to ensure success

I'm going to argue this on both of its implications.

Firstly: Agile is not about ensuring success. It's about greatly increasing the chances of success, and minimizing failure from fallout. No amount of process will rescue you from truly dreadful technical team, but so what? Plenty of processes will almost guarantee failure with the best tech team and will in the world.

I'm going to go for the assumption that you knew that already, though, and are attacking the idea that a management-related solution can help in the solving of technical-related problems.

Take a look at a modern hospital, and you will see layer upon layer of 'management' solutions to support medical problems. Prescriptions are checked by the doctor, checked by the pharmacist, and then checked by the nurse. Do hospitals throw these rules away with sufficiently good doctors? No. Do hospitals do this because they think their doctors are shit? No.

Agile can be a highly effective management solution for supporting technical development. I know this because it has been for me, on many occasions, with many different teams, in many different settings. I've also seen it badly implemented to the point where it's an impediment to teams, but ... so what? That's a risk with any process.

Re: Agile is a Sham

#43

Post by super_mario » Wed, Mar 28, 2012, 1:27 PM UTC

peteretep wrote: post #42

super_mario wrote: post #35

That should be clear to anyone that has even a little mathematical/computer science training. Anyone that says you can follow some process to ensure success is effectively telling you they have implemented artificial intelligence that simulates a production line designer and to be able to do it by using humans pushing bits of paper around as their computer.

> Anyone that says you can follow some process to ensure success I'm going to argue this on both of its implications. Firstly: Agile is not about ensuring success. It's about greatly increasing the chances of success, and minimizing failure from fallout. No amount of process will rescue you from truly dreadful technical team, but so what? Plenty of processes will almost guarantee failure with the best tech team and w…

Agile and other processes go much much further than your contrived example of checks and balances in a typical hospital. It would be like hospital directly interfering into the daily doctor/patient interaction or say stipulating that no surgery can be longer than 2 hours. You want to do 9 hour heart transplant surgery. Sorry, can't do that. Break it up into 2 hour chunks and measure progress after each to make sure you are going in the right direction.

This is why agile is like religion. It is so vague and so thinly disguised into general meaningless correct sounding "principles" that it can be anything to anyone.

Re: Agile is a Sham

#44

Post by Xylakant » Wed, Mar 28, 2012, 1:28 PM UTC

PaulHoule wrote: post #7

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…

You're wrong on both accounts:

(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.

Re: Agile is a Sham

#45

Post by Xylakant » Wed, Mar 28, 2012, 1:35 PM UTC

super_mario wrote: post #43

peteretep wrote: post #42

Earlier quoted context omitted.

> Anyone that says you can follow some process to ensure success I'm going to argue this on both of its implications. Firstly: Agile is not about ensuring success. It's about greatly increasing the chances of success, and minimizing failure from fallout. No amount of process will rescue you from truly dreadful technical team, but so what? Plenty of processes will almost guarantee failure with the best tech team and w…

Agile and other processes go much much further than your contrived example of checks and balances in a typical hospital. It would be like hospital directly interfering into the daily doctor/patient interaction or say stipulating that no surgery can be longer than 2 hours. You want to do 9 hour heart transplant surgery. Sorry, can't do that. Break it up into 2 hour chunks and measure progress after each to make sure y…

You're messing up agile and Scrum. Scrum has the restriction that every task has to fit within a single iteration. And even with scrum, that limit is self-proscribed. If you regularly have tasks that dont fit in a single iteration and you can't cut those down to smaller tasks then you're free to choose longer iterations. Scrum just says "make iterations, measure progress during iterations to get an estimate how much you can fit in the next." It's like doctors measuring how long they usually need for heart transplant surgery and applying that knowledge to the operations plan for the next week. I'm sure they do. And I'm sure they limit the time they have in the operation room and won't schedule a non-critical long operation at the end of a packed day. (I actually dated a doctor for 6 years and they surely did - apart from working tons of overtime and other unsensible things)

Re: Agile is a Sham

#46

Post by super_mario » Wed, Mar 28, 2012, 1:36 PM UTC

bitwize wrote: post #25

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 h…

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?

Re: Agile is a Sham

#47

Post by drewolson » Wed, Mar 28, 2012, 1:49 PM UTC

A fun anecdote is to consider the belief the TDD crowd entertained that, by creating tests for a problem you couldn’t solve, you could somehow evolve a code that passed the tests and therefore solved the problem!

I'm all for a healthy debate of TDD, but the above statement seems ridiculous to me. For me, TDD helps with two main things:

- I specify the behavior I'm adding/changing before I implement it. This helps document the change I believe I'm making.

- I feel more confident when making changes to a large codebase.

TDD works for some and not for others. There are very interesting arguments to be had about the subject. However, can we please stop acting as though TDD advocates view their tests as having psuedo-mystical powers to solve problems automatically?

Re: Agile is a Sham

#48

Post by wr1472 » Wed, Mar 28, 2012, 1:51 PM UTC

papatron wrote: post #38

plinkplonk wrote: post #12

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…

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…

Don't confuse "what you should do", with "how you should do it".

For example the what is "do not get stressed", the how might be to plan your day better, keep your life simple, etc.

These small nuggets usually talk bout the how, but a lot of people either think they know better, or have resigned themselves to the fact that it really is that hard.

Re: Agile is a Sham

#49

Post by itsnotme » Wed, Mar 28, 2012, 1:54 PM UTC

DanielBMarkham wrote: post #24

[Obligatory plug and disclaimer: Agile professional who wrote an earlier rant "Agile Ruined my Life" http://www.whattofix.com/blog/archives/2010/09/agile-ruined-... Also I am writing some practical how-to Agile e-books trying to undo some of the damage: http://tiny-giant-books.com/scrummaster.htm ] Just differentiate between what Agile is and how people are pushing Agile on you. Different things entirely. Agile is be…

> [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.

Re: Agile is a Sham

#50

Post by marknutter » Wed, Mar 28, 2012, 2:00 PM UTC

I view Agile the same way I do P90X, which if you swapped one term for the other this post would probably be just as valid. Yet, I use P90X and get good results. Is it dependent on my motivation and physical abilities? Yes, of course. Will it help an unmotivated person become fit? No, of course not. But what it does give some people is a road map to follow and a process for following it. Much like Agile does.

My team is using Agile and it's effective. It's not a silver bullet, but it keeps us on the same page for the most part and it gives the business team goal posts for getting features designed and queued up. If us developers sucked, it probably wouldn't help that. But since we're all decent, motivated workers, it has been going pretty well.

So is Agile a sham? Sure, whatever. So is P90X. I'll keep using both, thanks.