Agile a load of crap?

Tim Robbins

Does any think there is way too much hype about Agile? People talk about it as if it some ground breaking concept that if you don't know well then you are not with the program. Non-technical managers love sh*tting on about it because talking about anything technical can scare them.

Some people use Agile to mean "we don't do documentation" which is actually an anti pattern in Agile if they actually read the literature.
And to some people it means you have great software. My hairy hole.

Some of the ideas from Agile are great if applied correctly. When mis-applied they are awful. They don't work.

And then some other wannabe's think the biggest question is are you agile or waterfall? That is probably as stupid a question as how many lines of code can you right in a day. Other wannabe will sh*t on about how agile they are but then when you probe you will see they have their own version of agile just like everyone else.

Would you like to share you cynicism about the way some people sh*t on about Agile?

Please, I'd love to hear it.

Ballyv24

I am not a big fan of any specific methodology. I do not agree with the approach that one methodology can work for an entire company. Most project are different and a lot of time and effort can be saved on a project if time is spent at the start identifying the most suitable methodology or hybrid of methodologies.

I hate when a Senior Manager returning from a conference after discovering the new buzz term and sending a company wide email "We are now all going to use the Agile methodology so drop everything and attend the training courses". Enforcing such a change can cause a lot of wasted time, where people have to add steps and create extra documents that are only needed so they can show that they are following the company's guidelines.

Back to your original point, "Agile a load of crap". No, I don't think so. Agile can work really well, but not for every project.

jester77

I've worked in Agile Teams for over 10 years, XP, scrum & kanban. When done correctly it works. But I've seen inexperienced scrum teams thinking that kanban is a better option (more freedom) and it nearly always turns into a disaster.

For an experienced team that are very focused then kanban is a winner and the customer is also a winner due to continuous deployment and rapid releases/bug fixes.

Does waterfall still exist? I've not come across it in any business since I left college nearly 15 years ago.

Boskowski

Agile basically means don't bother with specs or requirements and make up stuff as you go along. And pass on the overhead that results from it in terms of pressure and extra hours onto your developers - preferably unpaid.
And of course micromanage in daily meetings to make sure everyone stays in line.

stevenmu

I always think it's funny how many people see Agile as being a rigid formal development process. Like when people decide that they absolutely can not document anything because they are "Agile" or they must have a stand up meeting every morning when there's only 2 developers and so on.

Having Agile as a mindset can be a very useful thing, and at it's core level it basically just means that you adjust your process to suit your project. That means that if documentation will help, you create those documents, if it gets in the way and wastes time then you don't.

That can be very useful if you are working on different projects with different levels of scale and complexity and different levels of team involvement. It's unworkable to have one process which covers all of the eventualities, you either end up with an overcomplicated process for small projects, or an overly-simplistic process for large complex projects.

If you are working permanently on one project it doesn't matter so much, because you can have one process that covers everything and refine that as needed.



Also, pair programming is the worst idea in the history of computing and I refuse to do it under any circumstances.

ChRoMe

robbiezero

Did a bit of Agile for a few years a while ago.
Sprints of 3/4 weeks with a demo to the product owner and other interested parties at the end of the sprint.
What I found was that this demo put huge pressure on the visual aspect of the product. It was very important to have some new visual features to show at the end of the sprint.
This was to the detriment of the code base.

GreeBo

Boskowski wrote: »

Agile basically means don't bother with specs or requirements and make up stuff as you go along. And pass on the overhead that results from it in terms of pressure and extra hours onto your developers - preferably unpaid.
And of course micromanage in daily meetings to make sure everyone stays in line.

You are doing it wrong then.

jimmycrackcorm

If you've worked in a mature agile team then you'd know it's hard to beat as a methodology. One problem is that a lot of people think that if they do daily stand-ups, a planning meeting and a retrospective then they are doing agile when there is a lot more required to make it work.

stevenmu wrote: »

Also, pair programming is the worst idea in the history of computing and I refuse to do it under any circumstances.

I had a team work on two projects, one was completely paired and the second wasn't. I noticed no difference in productivity. However, the definition or Pairing that does work, is two people working and collaborating very closely on specific tasks. Each is able to work relatively in parallel while still getting the benefits of some aspect of the paring intention such as oversight.

Tim Robbins

GreeBo wrote: »

You are doing it wrong then.

You see this is the crux of problem. Everyone is doing agile but everyone is doing it wrong.

Put the software architect hat on and I'd say that abstraction is utterly failing.

c_man

How long are yer daily standups lasting? Ours is running over 45 minutes most days... There's not that many of us! What a waste of time.

rainbow kirby

c_man wrote: »

How long are yer daily standups lasting? Ours is running over 45 minutes most days... There's not that many of us! What a waste of time.

15 mins-ish, but the last one of a sprint is usually much longer.

Sparks

c_man wrote: »

How long are yer daily standups lasting? Ours is running over 45 minutes most days... There's not that many of us! What a waste of time.

Which one, the local one, the whole-team one or the written one?

Honestly, if done right, it can work well. But frankly, I think if you do any methodology right, it would probably work well too. I think we're at the stage (if not beyond it) where "Agile" is just another buzzword and the original idea is long since lost in most places where it's allegedly being used.

Ballyv24

Sparks wrote: »

I think we're at the stage (if not beyond it) where "Agile" is just another buzzword and the original idea is long since lost in most places where it's allegedly being used.

I was at a conference lately and Lean Projects were all the rage..

So Lean is the new Agile... until the project managers start to fatten up the Lean methodology

Tim Robbins

Ballyv24 wrote: »

I was at a conference lately and Lean Projects were all the rage..

So "Lean is the new agile"

The stand up recks my head in agile.

Why? Because some people can't abstract what they are doing to higher levels or are just not good at speaking and just end up with something that is painful to listen to. You would be better off spending 5 mins to look at their code / doc to see what they have done.

Other people can get competitive and always trying to make themselves a little bit better than the person beside them. This is tiring.

Too many conversations that should be taken offline are not.

And sometimes your stand ups run way over 5 mins and you are wonder why the f*ck is everyone standing up? If these warrants detailed discussion, make a meeting and let people sit down.

Project Mgrs love this as it is a way to keep them busy and a way to put pressure on everyone. It doesn't mean you get better architecture or better code.

The Corinthian

Methodologies, be they Agile, project management or analysis are typically complex, bloated monstrosities out of the box.

This is probably because those who designed the methodology wanted to do so in such a way that it can be, in theory, applied to anything between a small corner shop project, through to a massive multinational solution. That it also allows them to set up lucrative certification courses for the methodology in question, probably doesn't hurt either.

The problem is firstly that few people actually understand such methodologies. Some have some superficial understanding, from a conference or seminar they went to; often with disastrous effect. Others have more in depth knowledge, but then they take the methodology far too literally.

Of the latter, almost all methodologies need to be tailored to the project or programme, not the other way around. UML may be an excellent approach to analysis, but strictly following an UML approach is overkill for the vast majority of cases. Same goes for PRINCE2, with regards to managing a project. And where it comes to development, you will often find similar mis-implementations of Scrum in use. After all, the whole point to a methodology is to make things easier for yourself, not harder.

Understanding a methodology is important, but understanding how to tailor that methodology to what you're doing and not the other way round is what is often critical.

And in this regard, whether in terms of understanding or tailoring, many applications of Scrum are a disaster.

DublinWriter

The Corinthian wrote: »

Methodologies, be they Agile, project management or analysis are typically complex, bloated monstrosities out of the box.

You are indeed correct. However I would argue that Agile in its purest from even isn't a methodology, it's an approach, or even a mindset.

All you need to know about Agile is contained in the 12 principles of the original Agile manifesto.

Note that there's no mention of scrums or sprints in the original manifesto.

Most large organisations in a slavish approach to adapt the latest and greatest use Agile like it's a BPR exercise, which it isn't. Queue lots of consultancies and so-called industry experts tagging their own crapology onto Agile - i.e. scrums and sprints.

I can categorically (and very subjectively) say that 50% of people who work in I.T. are incompetent numpties of the highest order and only in their current positions by dent of either Buggin's Turn or either an innate ability to blag their way into positions for which they are seriously unsuitable.

True Agile is a glorious thing, however it's become another I.T. fashion behind which many of the incompetent hide.

The Corinthian

DublinWriter wrote: »

You are indeed correct. However I would argue that Agile in its purest from even isn't a methodology, it's an approach, or even a mindset.

Agreed. All of these things are essentially a set of common sense principles with an overarching structure and set of processes crafted on top of them - you mention the 12 Agile principles, for example, PRINCE2 has 7 such principles.

Once you've built said structure and processes, then it becomes a 'methodology'.

DublinWriter

The Corinthian wrote: »

you mention the 12 Agile principles, for example, PRINCE2 has 7 such principles.

True, but you're comparing apples and oranges.

The seven principles of PRINCE2 make me open a vein with a rusty Gillette, yet PRINCE2 is quite good when you use it for project governance, especially with larger projects.

Again, I'll say that it all boils back down to the general incompetence of most who work in the IT Sector. They need a methodology to hide behind. Suggest anything to them that's not ITIL/ISO9660/SixSigma to them and observe the look of pure panic.

A seasoned IT practitioner will cherry-pick the best from all that's available.

The Corinthian

DublinWriter wrote: »

True, but you're comparing apples and oranges.

Not really. As you pointed out, all you need to know about Agile is contained in the 12 principles of the original Agile manifesto; the same is explicitly taught of PRINCE2 - as long as you adhere to its 7 principles, it's a valid PRINCE2 implementation.

Again, I'll say that it all boils back down to the general incompetence of most who work in the IT Sector.

I'd agree. Most, if not all, of these methodologies are typically common sense dressed in an intentionally complex series of processes and buzzwords. Often those who decide that these are important (HR departments looking at CV's, managers seeking to adopt better practices or clients who take comfort in a supplier being ISO X,000 compliant) will have a superficial understanding at best and not realize that it is the underlying principles behind the methodology rather than the processes (or buzzwords) are what are important.

As a result, half-arsed implementations will be employed - ironically often contravening the very principles on which the methodology was based on - which end up making things worse, rather than better.

TBH, all of these approaches should probably include the KISS principle in big red letters - some actually do, but tend to be written in language too subtle to be noticed.

Tim Robbins

Looking at the 12 principles number 9 states:

"Continuous attention to technical excellence and good design enhances agility."

That's hardly something that even deserves a special word.

gargargar

I love agile software development. When you look at the basic values of agile it is hard to argue with them:

1) Individuals and interactions over processes and tools
2) Working software over comprehensive documentation
3) Customer collaboration over contract negotiation
4) Responding to change over following a plan

A constant focus of delivering working software, when combined with on going customer collaboration, pays great dividends. There is no divergence between what is being built with stakeholder's expectations.

Sparks

(1) implies that nobody's ever going to quit the company or move on in their career;
(2) is usually used as an excuse to never document anything and typically results in chaos;
(3) is a really fast way to be screwed over by a customer not acting in good faith;
(4) implies an inability to focus on long-term goals.


Agile's great for one specific kind of problem. And components of Agile work well in other contexts too, but those tend to be the components that everyone thinks of as best practice anyway.

But outside that context, and in the majority of the deployments of "Agile" that I've had the misfortune to encounter, "Agile" is just another buzzword that has six tons of unnecessary paperwork and hassle riding on its coattails...

gargargar

Sparks wrote: »

(1) implies that nobody's ever going to quit the company or move on in their career;

No it doesn't. A team can have members swapped without breaking down. Especially if the code is written to a high standard (tests implied), one of the core principles.

Sparks wrote: »

(2) is usually used as an excuse to never document anything and typically results in chaos;

Not in my experience. Agile doesn't mean no documentation. A focus on working software is actually the opposite of the point you are making. For software to work it means there must be communication and integration, not people working in silos on a piece of functionality.

Sparks wrote: »

(3) is a really fast way to be screwed over by a customer not acting in good faith;

That can occur. It can be mitigated if properly policed.

Sparks wrote: »

(4) implies an inability to focus on long-term goals.

No it doesn't. You can have a product roadmap with agile. What it means that if a change is required you can react to it rather than plow on with plan regardless.

Sparks

gargargar wrote: »

No it doesn't. A team can have members swapped without breaking down. Especially if the code is written to a high standard (tests implied), one of the core principles.

I've heard this before, and I still don't believe it. This isn't the Renaissance - I can't take someone with fourteen years of experience writing network code from the wire to the top of the stack and replace them with someone who's spent fourteen years writing UI code. We might all be small cogs in a large machine, but that doesn't mean we all have the same number of teeth

Not in my experience. Agile doesn't mean no documentation.

It's not meant to, which I think is where our impedence mismatch is coming from...

That can occur. It can be mitigated if properly policed.

Yes, but that's what we invented contracts for, a few hundred years ago...

No it doesn't. You can have a product roadmap with agile. What it means that if a change is required you can react to it rather than plow on with plan regardless.

Waterfall aside (which is a special case in itself given its original purpose), I can't think of any methodology that can't react to change; but that aside, again, I think you're talking about what Agile is meant to be and I'm talking about what I've seen being called agile...

RoryMurphyJnr

you should try it when both your dev and qa teams are in India, your program man team are in the us and you're in Dublin

Sparks

RoryMurphyJnr wrote: »

you should try it when both your dev and qa teams are in India, your program man team are in the us and you're in Dublin

I would, but you left China, Canada and Israel out of that sentence so I can't

DublinWriter

Sparks wrote: »

(1) implies that nobody's ever going to quit the company or move on in their career;
(2) is usually used as an excuse to never document anything and typically results in chaos;

True, but come on, admit it...when did you ever read a manual?...or even a handover document?

Good object orientated design and abstraction should negate these problems. My motto is well-structured code should document itself.

Sparks wrote: »

(3) is a really fast way to be screwed over by a customer not acting in good faith;
(4) implies an inability to focus on long-term goals.

This is really where you need to bring in the governance processes of ITIL and PRINCE2 into the overall mix - basically client sign-off at the right points.

As I said, a seasoned IT practitioner will know what to take and dismiss from all the dominant methodologies.

Sparks

DublinWriter wrote: »

True, but come on, admit it...when did you ever read a manual?...or even a handover document?

I work in a 30MLOC codebase -- I spend half my day reading docs and the other half wishing I had more docs

My motto is well-structured code should document itself.

My motto is that "should" isn't "does".
Well, that or the one about finding the guy who wrote this piece of... and force-feeding him a printout of it, starting with the printer...

As I said, a seasoned IT practitioner will know what to take and dismiss from all the dominant methodologies.

Yup.



Assuming, of course, that that seasoned IT practitioner has a seasoned IT boss who will permit it....

ChRoMe

Sparks wrote: »

I work in a 30MLOC codebase -- I spend half my day reading docs and the other half wishing I had more docs

:eek:

Any clues to what it is?

Sparks

DB2.

gargargar

Sparks wrote: »

I've heard this before, and I still don't believe it. This isn't the Renaissance - I can't take someone with fourteen years of experience writing network code from the wire to the top of the stack and replace them with someone who's spent fourteen years writing UI code. We might all be small cogs in a large machine, but that doesn't mean we all have the same number of teeth

That's demonstrably ridiculous. People leave teams all the time. If your 14 year guy is the lead developer on the project, and hands in his notice, you have to deal with it. You replace him with someone with the same abilities (or promo the next guy).

From you other replies I see you work on a large code base with many developers. I work for a consultancy working on mostly SAAS projects. Money is tight and requirements are loose. You can't chain them in to completely binding project contracts. They need some flexibility. Most will not pay for tech specs that need to be maintained on top of the code and the tests. Hell, it is hard enough to convince them on the case for writing tests