So you're 'agile', huh? I do not think it means what you think it means

What if I were to tell you that we knew all the best practices for software development? That they've been proven by actual industry use over the past 25 years? But that, oddly, these practices are not widely done? Well, if you read these pages, you'd probably say: "Sound about right." Agile is much spoken of, but not as …

[Zog_but_not_the_first]

Look to history...

At various points in history we "gave" the bean counters the keys to the car, and the keys to just about everything else. In the current cycle this occurred about 35 years ago. Until this imbalance is, er, rebalanced, such counter-productive nonsense will continue.

[Valeyard]

wagile

Wagilefall

Even when development teams have nailed agile, pumping out builds weekly gleefully (or, monthly for the languid), as Oti points out above, they often are not able to actually deploy their code to production.

yep! everything's agile after management pushed for it. After great effort we now pump out regular code... management themselves however weren't prepared for it to actually work* and the code ships with the same schedule as when it was waterfall

*3 years and counting

[Anonymous Coward]

Re: wagile

There can be good reasons for this

Ac obv..

Some customers of ours are happy to always have the "latest & greatest" new release

Others (lets call them type C, for cautious) have a rigorous deploy to a test environment, try that for many weeks / months to check OK, then deploy it to live

The Type C customers explicitly do not want to receive every release (as releases can come more frequently than their slow test acceptance process can cope with - no point them having weekly builds when their testing takes months).

The Type C customers usually only want to try a new release if It has new / improved functionality they specifically requested or it deals with a critical security bug, as the test process is a PITA and cost for them

Thus we have customers on a wide variety of releases, depending on their internal acceptance processes, so there can be cases when infrequent releases make sense for a particular subset of customers.

[EarthDog]

Re: wagile

I find type C is often with true mission critical needs, as opposed to "mission critical" needs, and so want reaffirmation of the software quality. If (collective ) you haven't done so show them the stage by stage testing from unit test levels to acceptance level. That might help.

[Anonymous Coward]

Re: Type C customers

Oh yes.

And further... when they come across a bug 4 months down the line, they want *only* that fix on top of the code line they are currently on. Not all the stuff that has been added since, in 4 different releases.

[Missing Semicolon]

Re: Type C customers

Well, yeah! I want *this* bug fixed. I don't want all the process changes, missing functionality and new bugs in your latest cruft!

I bought the product you sold me. Now make it work properly then go away.

[Andy 73]

Re: wagile

"their slow test acceptance process"

The argument is to move their test acceptance process into your continuous deployment process. Easier said than done, but what you're describing is the usual impedance mismatch that comes from a product being used in a situation that itself is not agile.

Sometimes that's a technical problem (how do you test against a client's third party tools), but just as much is a cultural problem (they're just not ready to re-build their test processes). Of course, without solving those problems, 50% of the benefit of agile is immediately lost - which is a cost to them, albeit a hidden one.

[yoganmahew]

Re: wagile

@Andy 73

So not only are developers resistant to change, but customers are too? Well, if they don't want to adopt our agile framework, I think we should tell them to take their business elsewhere.

[Andy 73]

Re: wagile

@yoganmahew I'll take that as tongue in cheek :)

It is worth questioning some of the value of agile if your client wants one thoroughly tested release per year and the nature of the testing is not open to change. That doesn't mean you can't adopt it internally, but some of the reassurance of continuously tested increments are lost. That means ultimately your product still suffers from some of the biggest issues with waterfall, regardless of how agile you are.

That impedance mismatch can lead to developers and project managers coming away from a project thinking agile is a failure because it failed to deliver in hostile conditions. I've worked with people who claimed to be working in a 'post agile' way, because they'd tried and failed to get agile to work for them. It took them over two years to deliver a six month product change, but they'd never under any circumstances 'go back to agile'.

[JohnFen]

Re: wagile

"That doesn't mean you can't adopt it internally, but some of the reassurance of continuously tested increments are lost."

How so? A customer wanting fewer releases doesn't mean you can't develop in continuously tested increments. Why does the release schedule impact that?

[TJ930]

Re: wagile

In my experience, about 5% of Agile-Adoption problems are with Developers (most of whom just want to type code) and about 95% are with Management...

Management often likes to think the rules, practices and beliefs somehow don't apply to them, just the serfs beneath... Management sets the culture.

[EarthDog]

Re: wagile

like the SAFe garbage see this diagram and see what you think it says.http://www.scaledagileframework.com/

[TJ930]

Re: SAFe is uglyyyyyyy

Mate, I appreciate that everybody's first response to SAFe might, "WTF?!" But once you understand it, things make sense. A bit like x8086 Assembler, or .NET Intermediate Language, or Swedish, or whatever...

If you understand how to do Scrum, then you understand how to Scale Scrum (i.e. multiple Teams working from the same Product Backlog), and then you start to realize that the rest of the organization needs to get in step with this Lean-Agile think, Jemba (walk those 'value streams', etc).. It all checks out.

Or you could just rejoice in your ignorance and hope that this Agile Alligator eats you and your company last?...

[JohnFen]

Re: wagile

" the code ships with the same schedule as when it was waterfall"

That's a good thing. This "continuous release" thing that too many software shops are into has caused me nothing but pain and trouble. I long for the day when I didn't have to engage in the hassle of upgrades more often than once or twice a year.

[Locky]

Agile

Project Management shister-speak for "Make it up as you go along"

[Phil O'Sophical]

Re: Agile

Indeed, I've seen maybe 2 or 3 projects that really do Agile correctly. They don't actually seem to turn out code that's any better, or any cheaper to do, than waterfall. Much of what I see described as "Agile" translates to "Don't do specifications or design docs, just hack up a prototype and let the end users do the testing. Look at all the money we can save", with predictable results.

[zebthecat]

Re: Agile

That is not Agile at all, just laziness

[JohnFen]

Re: Agile

It seems that every time someone mentions their negative experiences with Agile (I have experienced it five times on five different projects with three different companies, and my experience has been uniformly negative), the response is "they're doing Agile wrong".

That may or may not be true, but if it is, it points to a critical flaw with Agile: it's apparently so complex or difficult to understand as to be essentially impossible to "do right". Even the most ideal system in the world is effectively worthless if it's too hard to implement "properly".

[Anonymous Coward]

Re: Agile

'it points to a critical flaw with Agile: it's apparently so complex or difficult to understand as to be essentially impossible to "do right"'

Like homeopathy or dowsing, or seeing the emperor's new clothes?

[TJ930]

Re: Agile

Nope. Not at all.

I can send you a simple 'Scrum checklist' from Henrik Kniberg, or a James Shore 'XP Radar Chart checklist', if you'd like.

Should be more than apposite for somebody at your level.

Cheers

[TJ930]

Re: Agile

And the alternative is?,,,,

Bearing in mind that, like an ON-OFF switch, an alternative has only one other state. (Poor English speakers tend to confuse "options" with "alternatives".)

[pcgeorge45]

Re: Agile

Too hard or complex, no. It just has some assumptions or prerequisites that aren't often seen in the wild, so ends up being a buzz word meaning 'good' or 'modern'. E.g. A 5-10 person development team with full control of the product requirements, development, testing, and releases. No external certification or qualification testing. Works well for small web-apps, but doesn't scale well and runs into issues with customer, saftey, or health critical systems. There are attempts to make it work in such things as SAFe, but in practice the focus on a program office or portfolio level backlog development process.

DevOps runs into similar issues since it depends upon real test or behavior driven development and automated testing. Deploying garbage fast is easy.

[Zippy's Sausage Factory]

Re: Agile

Indeed, I've seen maybe 2 or 3 projects that really do Agile correctly.

I came here to say mainly that, actually. Most of the development methodologies out there actually work if you follow them - some better than others, and most only in particular kinds of projects.

I've seen so many people who say "we use x metholodology" and then they don't. They say "ah well yes we improved it to match our corporate culture". No, no you didn't. You just decided to cherry pick the bits you like instead of using it. Kind of a bit like putting a racing car engine into a Lada. It'll work, but the results you get will be, shall we say, sub-optimal?

[John Lilburne]

Re: Agile

See none of the Agile twonks can actually say what is optimal. It is all hand waving and bluster. They didn't even know what issues we had with our old system, waxed on about no late nights or weekend working, when the 200 devies haven't done late nights or weekend working for over 20 years.

All the issues that we have Agile doesn't solve, it just gives us a bunch of extra shite. So instead of having 1 person work on something for 12 weeks we now have 4 people working on the same thing for 6 weeks. each of them finding the same issues and coding up a separate solution, each of them making changes which are incompatible with some other changes, all running about fixing up the fallout.

Then we have multiple teams finding an issue and solving it for their specific use case. Code gets copied from one place modified and siloed into another place, and all because they are running about with some false deadline being the end of sprint and the subsequent review.

And according to the Agile trainers we are meant to be fecking awesome, TWATS.

[TJ930]

Re: Agile

How many miles on that odometer, Johnny Boy? I don't want to say that "you aren't doing it properly", but "you sure as hell ain't doing it right." And that is your problem.

XP bods would have an apoplectic fit if you talked about code duplication as if it were passe or 'business as usual.'

You seem to be complaining about the symptoms without first understanding the underlying problems.

[John Lilburne]

Re: Agile

I have 30+ developers working on an 25yo legacy app, split into 4 scrum teams, then there another 15-20 teams reusing part of our apps codebase. Now I know for certain that chunks of the code, written over the last 25 years, wasn't written to be used outside of the app. So if some outside team is reusing they will have had to refactor it, removing some of the dependencies on the app. That refactored code aint going back into the app's repository, they've cloned and modified it for their own purposes.

If I go and look at what other teams are putting back I see methods with comments that don't reflect what the code does, I see code that is redundant in its new form, that was necessary in its old form. With a bunch of teams self-organising to sling code into the their particular silo of the app in order to meet a sprint deadline the process of cargo cult programming takes on a life of its own.

I wrote some code a year ago and a couple of weeks later found a bug in it. Meanwhile I'd attended a sprint review of some other team that had reused the code. The demo should have triggered the bug, but it didn't they'd copied the code found the bug and fixed it in their specific app.

C'est la vie

[TJ930]

25yo legacy app

Hmmm.. Michael Feathers’ famous definition of Legacy Code: “Code without tests.”

Seriously, I mean to help.

So are you Scaling with ‘Scrum of Scrums’? Or something a little more structured like Nexus, LeSS or SAFe, etc.? (Or is it rather more like ‘The Wild West’?)

But why are the Teams under a lot of time pressure? They are meant to be able to maintain this pace indefinitely – are they very poor at estimation? Are they doing sufficient Backlog Refinement? Which technique do they use to estimate – Relative Sizing or Capacity Planning (i.e. Time)? Or is somebody else from outside just “pushing” the work onto them?

Why not take a look at Henrik Kniberg’s checklist and – be honest – count how many your aren’t ticking? https://www.crisp.se/wp-content/uploads/2012/05/Scrum-checklist.pdf

Scrum should be bringing Transparency through its Principles, Practises, Events and Artefacts:

Potentially Shippable Increment = Fully merged, fully tested.

Continuous Integration = Merge to trunk (i.e. no branching).

Sustainable Pace.

Definition of Done. (Basic one that all the Teams agree to, with more exacting and tighter definitions for the better Teams, once they have started the Continuous Improvement process).

Continuous Improvement of processes, tools and techniques.

Who is the Teams' Scrum Master? The phrase, “Where Scrum isn’t fully adopted and fully understood,” is used as a caveat to give Scrum Master’s a bit of elbow room to correct errant behavior… Maybe time to have a word with the SM?

25 years ago = circa 1992 code, and so I’m guessing primarily C/C++? (If not Pascal or COBOL or something?)

Now I’ve used .NET static-analysis tools before to help identify redundant, legacy code. (But I'm sure there’s C++ stuff out there - have you checked into this?)

Does sounds like you’re already aware of your problem – a lack of Technical Excellence and Discipline (probably brought about by a lack of Transparency) – what can you do to hold them to account? (Are they Pairing?) Maybe you could work on their Teams for a Sprint and check that each Story has a Code Review Task? Or how about Martin Fowler’s “StranglerVine”? (Pay down that Technical Debt?)

[EarthDog]

Re: Agile

You forgot "QA, We don't need no stinkin' QA. We have Agile."

[bombastic bob]

Re: Agile

"I've seen maybe 2 or 3 projects that really do Agile correctly. They don't actually seem to turn out code that's any better, or any cheaper to do, than waterfall"

that would be my prediction just from reading ABOUT 'Agile', and not actually participating in it.

Although, at a used-to-company, I developed a prototype in 3 weeks for a potential product, doing it by myself [it involved a linux netfilter kernel module]. I spent another week (or so) tweeking it over a short period of time, because my proof of concept code was being used to DEMONSTRATE IT FOR POTENTIAL CUSTOMERS. Meawhile, 3 people (one manager, one senior guy, one junior guy) proceeded to 'start from scratch' using Agile-style principles for managing the project. A YEAR LATER [they were still demo-ing with my prototype] I'm brought back in to "help finish up" in a couple of weeks of 3-way programming effort (and then the junior guy was laid off) followed by nearly a MONTH of paired-up programming effort.

That's right, fixing the "Agile" code took LONGER than WRITING! THE! PROTOTYPE! FROM! THE! BEGINNING!!!

At that point, I had some cash stowed away, and I saw the writing on the wall, and left [after the project was 'working", that is]. Back to business for myself [no more commuting+wageslave].

Needless to say, I have a very *LOW* opinion of "Agile" and things like it. BUZZ-WORD of the day, market-speak and manager-incompetent-speak [manager hears a new word, MUST implement!].

Let's just call "waterfall" something else, in case the term has been POISONED too much by Agile-fanbois, and get people to go back to determining what the specs are FIRST, like is SUPPOSED to be done. Build a prototype, work out the bugs, and then SPEC UP THE PRODUCT, like is SUPPOSED to be done, and make it work according to the spec, as is SUPPOSED to be done.

We could call it: "Common Sense"®©™

[Andy 73]

Re: Agile

I've seen agile work, and in those situations it has delivered truly remarkable results - projects delivered faster, to spec with minimal staff and a team that overcame technical and personal issues along the way.

In those cases, the project manager has been the key. Not only have they managed the huge information flow that comes with a team running at full chat, but they have acted as the customer for continuous testing and validation (it's rare indeed that a customer actually looks at software until two weeks after they were meant to go into production with it).

Agile isn't complex. It isn't rocket science. But people baulk at some of the implications of what it asks of a team and decide to skip the 'difficult bits', as though only doing the easy work is going to get the whole job done. As often as not, the difficult bits are the social and managerial stuff that goes around producing code, and in a project under pressure to deliver, they're the first to go.

Paying lip service to parts that you don't see the value of means they'll never have any value - yet Agile does all it can to reduce the requirements down to *the bits that matter*. So if you've killed one of those parts, you've already broken the process.

[Anonymous Coward]

Re: Agile

In those cases, the project manager has been the key.

To me this is perhaps the biggest flaw with Agile, it only works when you have really good people. Good PMs to manage it, good developers who can be trusted to turn out good quality code under pressure, etc. Unsurprisingly, the people who champion Agile tend to be those sort of people.

Realistically, though, most companies only have a few of them, and they can sometimes be prima donnas that no-one wants to work with, which also encourages them to work in a little antisocial bubble. Companies are more likely to have a large group of competent plodders who get a decent job done when well managed in a structured framework. Agile does not work for such people, but the prima donnas tend to "go Torvalds" when faced with them, instead of accepting them as necessary components of a team.

[TJ930]

Re: Agile

Have you ever watched a group of 6-year-olds play Football? All chasing after the ball, all getting in each other's way?.. Have you ever watched a well-disciplined, lower-league, FA Cup 'Team' destroy a 'Group' of galactico, individualists on an 'off day'?

In short, it's the Team ethic...

There are various techniques for forming Agile Teams, but the very best - perhaps unsurprisingly - is to allow Self-Organizing, Cross-Functional Teams to pick themselves.

[Anonymous Coward]

Re: Agile

allow Self-Organizing, Cross-Functional Teams to pick themselves.

And then how do you use the remaining 90% of the developers?

[TJ930]

And then how do you use the remaining 90% of the developers?

Although "compost" might be a glib reply, I'll try to give you a serious answer. Let's say we have a department with 100 Developers and the company's decision is to use the most popular 'de facto' Agile Framework, Scrum.

The 3 Approaches are:

1) ALL AT ONCE - i.e. Spell out to the Developers what a successful Scrum Team looks like:

i) 3-9 Members.

ii) Optimum of around 5 Developers. (No split-Team membership.)

iii) Cross-Functional (i.e. all the necessary skills required to produce a working Product from a Product Backlog Item)

iv) Self-Organizing

Then allow the Developers to choose their friends, however they want, provided their Teams meet these acceptance criteria. (This may take several goes - i.e. iterations - and expect a lot of girlie whining for the first couple of weeks.)

2) CULTIVATE FROM EXCELLENCE - i.e. "one volunteer is worth 10 pressed men", as the saying goes. So start small with a Team of Volunteers, then once this Team starts trouncing the White-Water-Rafting and Big-Bang Boys - which will happen (these Teams are easily x4 times quicker) - create an air of mystique for this Team based upon Great Results and well-earned bigger bonuses, etc. Then 'take clippings' and form a new Team around each of these individual winners, who've done it before and now know what it takes to succeed. Keep spreading the love.

3) BUILD A SHINY NEW BUILDING with security on the door to keep out the riff raff / rotting vegetation. Recruitment Policy: Only competent people who know how to do Agile.

Then start winding down the old place, giving the less skilled less and less to do, hoping that they get bored and leave of their own volition... Saving on the number of redundancies when 'push ultimately comes to shove.'

[Andy 73]

Re: Agile

> To me this is perhaps the biggest flaw with Agile, it only works when you have really good people.

I've yet to discover a methodology that protects you against dumb shmucks. Sure, the dumb can come out in different ways, but it will always come out.

Waterfall tends to mean that you only find out somewhere around the end of the project, rather than near the beginning. Of course, with Agile, the temptation when dumb starts dribbling out is to 'bend the process' rather than fix the problem. Yes, I've joined a daily stand up which had 120 people in it. We were each restricted to three words so it wouldn't take up too much time.

[JohnFen]

Re: Agile

"As often as not, the difficult bits are the social and managerial stuff that goes around producing code"

Which is precisely the same if you're doing waterfall. Agile isn't unique in terms of the requirement for communication. If a team can't communicate adequately doing waterfall, they can't communicate adequately doing agile. I don't think the development methodology impacts this that much.

[TJ930]

Re: Agile

You're a nice guy. I can see that. But this is "scary unknown" speaking, isn't it?

Imagine if you had much greater visibility of what you were doing; imagine if your assumptions got tested in the real world much more frequently; imagine if you could replace vague guess-work with knowledge...

Communication in Agile is 'bolted in' - I don't want to sound like the "No True Scotsman fallacy" - but the number of people who claim to have done some form of Agile, Software Development but don't have the first clue about what they're doing... Well we've got to use binary and everybody in the room to count it on our 10 fingers!...

[TJ930]

If a team can't communicate adequately doing waterfall, they can't communicate doing agile.

No, you're just showing your ignorance off again, aren't you?

What size is the average Waterfall team?.. What size is the average Scrum, XP or Kanban Team?

The fact there are far fewer people in Agile Teams and there is far more transparency means there is nowhere to hide. It's pretty obvious in a Daily Stand-Up when a Team Member isn't pulling their weight and needs a talking to! Or when somebody has a blocker, they can more easily ask for help.

The fact that we are dealing with smaller chunks of work means that the shared understanding of the work in progress improves.

Also the fact that the team wins and loses together, sets its own targets, improves its own processes, is its own boss, de-emphasises job titles, typically co-locates teams and communicates with each other face-to-face, rather than through hefty documents, phase gates and sign-offs.

The cross-functional nature of teams also improves communication, reduces bottlenecks and reduces delay.

Yeah, you don't know what you're talking about, do you?

[Robert D Bank]

Re: Agile

I think you have nailed this really well, the PM's are absolutely CRITICAL, but on their own are not enough. You still need Devs and supporting areas right through testing to implementation that are CAPABLE and willing. Reducing things to 'bits that matter' actually takes skill to identify, not just by the PM but from the techies right through to business. And this often (usually) requires a greater understanding that these 'bits that matter' may mean fuck all to someone else whose 'bits that matter', matter more to them, and then onward to the support or operations people who may or may not see either of these being 'bits that matter'. And then the management at multiple levels, and then the business at various levels then have another view of 'what matters'. It's a case of understanding connections and being able to prioritise, and make an entire organisation dynamically move behind that. Bringing all this into line is incredibly difficult in a large 'business' of whatever form (less so much with small business). So the underlying issue is it becomes what the business wants to deliver to meet a customer requirement, which the customer may not even know they require, if it's a new thing. Will it deliver value? It may in the case where some very specific customer gripes have been identified and these can be addressed. It may not if things have moved on (as they inevitably do) and some other company has come up with something even 'better' and taken fickle customers with them.

So thinking this through I can see the value of the Agile approach, with supporting DevOps. But, it needs to be kept in mind very strongly that this approach does NOT apply to everything an organisation does. Identifying where it does needs some real honesty and clear understanding by everyone in the delivery chain. And if that can be done you can build an Agile infrastructure and process around just that, in a properly focussed way without this nonsense of trying to make the whole organisation try and find Agile process where it might actually be dangerous and damaging and delivering nothing but a tick box for a managers bonus

[TJ930]

"Make it up as you go along"

Yes, far better that we make up a piece of fiction right before we start, plan everything in microscopic detail as to the precise way things are going to occur for the next 2 years... Then just deny observable reality, blame and scapegoat the poor souls tasked with achieving the impossible, and watch as the 'final deadlines' keep flying by like miles on the odometer of a speeding car, as the Bugs in the Bug Backlog start to number in the thousands, as the customers grow more and more disgruntled, and the £ notes burn right before your eyes...

Way better? Or maybe not?...

[TJ930]

Project Management shister-speak for "Make it up as you go along"

I thought that was "Big Bang" (or "Silent But Deadly", as it's also known)?

[Oengus]

Still more importantly...

More importantly: please, let the T-bone rest for a while before cooking it.

Please, Let the T-bone rest after cooking it.

Beer because it is an essential accompaniment to any good steak...

[Anonymous Coward]

Re: Still more importantly...

Actually, BOTH is needed.

Letting the meat come up to room temperature before cooking and resting it afterwards.

The same can be said for Software Development. Let the design sit for a while before starting development. When you come back to it you may find some glaring errors that were just not that visible beforehande. Then afterwards, and when all the testing is done go back to the spec and see if what you are about to deliver meets it.

Most of the time you will find that what you are delivering does not meet the approved and signed off spec.

"Don't worry," we are told.

"We are using Agile. The Spec will get corrected later..." as it is added to the Technical Debt.

The only problem is, that it never does get fixed (the spec or the software).

Sad fact of life.

In my last job, most of the 'Agile' team I was working with were away on 2-3 weeks holiday over Christmas. I was the only team member at work. I resolved most of the technical debt that we'd built up over the previous nine months. When the PM came back from holiday, I was heavily criticised for not 'doing new stuff'. Said it all really. Technical Debt seems to mean 'Do Not Fix' these days.

Yes, I'm cynical. 40 years writing code and much of it safety critical code at that has taught me to be very cynical.

Agile to me means always going onto the next thing and never going back.

My current employer went all Agile and actually saw a large drop in productivity of usable code/product.

Now they use bits of this and bits of that and you know, it all seems to work.

[Solmyr ibn Wali Barad]

Re: Still more importantly...

"Let the design sit for a while before starting development"

Indeed. As one seasoned developer told to younglings: "There's no need to rush. If a change request comes in, wait until tomorrow. There's probably going to be another request, either amending or even superseding the previous one.".

Then he had a sip of coffee and added with a diabolical grin: "But if you stall for several days, then there's a solid chance that the whole idea will be canned and you'll get a request to revert your code back to original."

[HmmmYes]

Agile fucks me off more than most stuff I have to deal at work.

The original Agile might have some merit, at least in the early stages of development where teams are struggling to work out what and how to do a project.

Its a fucking disaster for everything else. The term is so pointless that any piss poor products gets classified as Agile to overcome the vast number of shortcomings.

[Anonymous Coward]

The main issue are those who turned it into a sort of religion...

with the Scrum Certified High Priesthood and all the related dogmas. And like religions, pragmatism is banned, and reality must fit ideology, and not viceversa. And like religions, it became a source of revenues for preachers and churchesconsultants and training companies.

Take Scrum stubbornness a sprint must be shorter than a month. Sorry, for some complex projects where the team is not so large, and the code can't be easily broken in smaller pieces to be coded separately, it could take more, especially in the early phases of a project when you need to establish the foundations.

You can have a great developer who can write outstanding code, but may not be the quickest on the planet (maybe exactly because they think about what they write).

Being forced to release earlier, can lead to bad designs, and hurried code.

And because you don't always (re)code the same stuff, there are also often unknowns to be tackled - not everybody can perform extensive research and prototypes before starting a project.

Sure, if all you do is churning out the same websites with some customization, or essentially maintain some legacy project, it's all OK - when you work on more complex and innovative projects, being forced to abide to some strict rules just for the sake of them often just gets in the way.

[TJ930]

Re: The main issue are those who turned it into a sort of religion...

To be fair, I can understand why you would proffer such an opinion... By definition, a Belief is something that can't be proven - otherwise it's just a fact!

But, to understand your complaint, it's Lean-Agile Values and Beliefs that guide those Lean-Agile Principles, these Principles are then applied to form their own specific Practices (by the people doing the actual work - NOT top-down Management, far removed from "what's what"). So it's the Beliefs, Values and Principles that can make things seem quasi religious.

To explain why they're needed, a Practice which works very well for one Team / Department / Company / Organization / Hospital / whatever, might not work at all - due to local reasons - when attempts are made to apply the specific practices directly elsewhere. This is why an understanding of the basic Principles is required, because the Principles CAN ALWAYS be applied.

For example, the whole point of a "Daily Scrum" is NOT to answer 3 questions when standing up; the point is for the Team to gain a Shared Understanding of the current state, to formulate a Plan for the next 24 hours, to check things are on track, and make changes if they aren't... How you do this (the Practices you employ) is entirely up to you... So, if your processes aren't working, change them!

Given that "working software is the only real measure of progress.." and that Empiricism is based upon Feedback loops (i.e. checking your assumptions) ; if your Sprints last longer than 4 weeks, are you increasing or decreasing the number of Feedback opportunities you will have in a given year?

"Scrum is a framework for creating complex products in complex environments..." People always make excuses about complexity; why not try breaking the complexity down into smaller problems?

"Oh, no.. Couldn't possible do that!..."

Oh, yes, you can.

[Anonymous Coward]

"are you increasing or decreasing the number of Feedback opportunities"

Religions use a lot of capitals. Common people avoid them because the emphasis is useless.

That implies that "feedback" can come just at the end of a Sprint. and that need to come on something working because you have to show it to "stakeholders" outside the development team.

Actually, reality is different and "feedback" can come on unfinished artifacts not yet working. Sure, you may have nothing to show outside code to people who can't understand code, but sometimes all you need is the feedback from people who understand code and a debugger.

Forcing shortcuts may be just as bad when management press to have "something to show".

I'm not against the principles of Agile - actually most people followed agile principles well before it was documented, because very few software outside bit gov/mil projects could design everything in the beginning, set it into stone requirements, and expect code monkeys implement it without changes arising, and wait for the project final deadline to check if everything works.

What became wrong with Agile is when they exactly followed the same path - they put into stone the *P*rinciples, the *P*ractices, *E*tc. *E*tc. and invented *R*ituals to be folllowed, with *P*retentious *T*itles like *S*crum *M*aster.

People shared understanding and planned what to do even without formal stand up meetings. Sometimes you don't make plan for the next 24h, sometimes you make plans for some days because the task is much more complex than what you can accomplish in one day. Sure, you can break a complex problem in smaller one, but not always the "smallest" one are enough small you can do everything in little time.

And isn't one of the principles "Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done"? Giving to short targets and schedules just because a methodology says so could be the best way to achieve the opposite. When you have distributed teams, and varying skills, it's also more difficult.

[TJ930]

*P*rinciples, the *P*ractices, *E*tc. *E*tc

*A*d hominem *A*ssertion *A*d hominem *A*ssertion.

Okay, I'll "rip you a new one" on each of these points... Yes, don’t bother challenging the argument; challenge instead the style or character of the person who made the argument. Far easier ;) (Though those with even only a cursory understanding of logical fallacies might consider this tactic to be rather less effective.)

I was explaining to you the underlying need for principles, and why they can seem a little abstract.

Just read some of the other postings on here. In the same breath as accusing the concepts, principles, beliefs and values as being too abstract, hazy, opaque or imprecise, someone will seemingly then go on to describe the practises as too concrete, over-exacting, silly and/or unnecessary.

No, “put the Principles into Stone”, not the Practises. Here the principle of Self-Organisation is the one that’s important – the Team should have the power to override “pointless rituals.”

Ipso facto. I think you have rather proven my point.

[TJ930]

“That implies that ‘feedback’ can come just at the end of a Sprint[?]”

No. You imputed that. Now, where possible, I personally consider basic TDD/CI to be far superior to Debugging, but each to their own....

You’ve specifically used the word “Sprint”, rather than “Iteration”, so we’re talking Scrum – am I right?..

So what are the 5 Scrum Events?.. Do you know?.. No?.. Read on..

- The Sprint

- Sprint Planning

- Daily Scrum

- Sprint Retrospective

- Sprint Review

The first is a “time-boxed” container for the other 4, and each of those is an “inspect-and-adapt” (i.e. a “Feedback”) opportunity for each of the different aspects of the development processes. (NB: Feedback is not strictly limited to these Scrum Events!)

In my experience, whatever Sprint length the Team chooses, when Scrum Teams are very inexperienced, the Programmers (despite protestations from the QAs) typically pull in far too much work. (Usually ~150+% of what the Team can actually finish in the time-box: so a 2-week-Sprint Team will pull in 3 weeks’ worth of work; a 4-week pulls in 6 weeks’, etc.) This usually originates from “I’ve-done-MY-bit” and “quality-&-testing-are-someone-else’s-concern” thinking; the Sprint Time-Box and Sprint Review force errant, lazy programmers to ‘face the music.’

“Hardening Sprints” and “Bug-Fix Sprints” are not part of Scrum; they are a managerial dysfunction/anti-pattern caused by not finding and fixing bugs (i.e. inspecting & adapting) early enough in the Development. This reduces the transparency of how much work actually remains, destroying Scrum’s empiricism, and with it the ability to predict the finish date with any kind of accuracy…

I’m guessing that this sort of failure thing sounds quite familiar to you, right?

Now, splitting Stories is a skill to be acquired with practise. Yes, Product Owners and Developers need teaching, coaching and advising to that end. But look up “Walking Skeletons”, “MVP” and “Story Mapping” to help you understand the basics… In your Sprint Reviews, you’ll want to have a ‘working Prototype’ – so stub out/fake the bits that aren’t finished yet – but proudly show the bits that are, and then let the Customer glean whether what they requested is what they actually want (i.e. a “validation error”, as it’s known) – whilst we can still easily do something about it!

All of these Agile Methodologies are based upon transparency and feedback loops. So, yes, in summary: Feedback. Feedback. Feedback. Ad infinitum.

[TJ930]

"something to show"

"Exhibitionist"?

Scrum is a “pull” system. Back in the Sprint Planning, you were meant to have negotiated with the Product Owner what you were going to be working upon, and then pulled it into your Sprint Backlog; in the Backlog Refinement sessions, you were meant to have helped the Product Owner write those self, same Stories in that Product Backlog (from which you then went on to select your Sprint Backlog).

Hence, I’m now reminded of Douglas Adam’s famous quote – no, not the one about fish or the meaning of life – if you are an ingenious idiot, I can’t help you. Sorry. Scrum isn’t idiot proof.

That said, maybe your Product Owner and Scrum Master could do a better job as “Heat Shields”, protecting you from Management pressure? But if you’re frequently showing them good, working software in the Sprint Reviews, their trust should build and the pressure should subside.

Maybe you just aren’t doing your Sprint Reviews frequently enough?...

[TJ930]

*P*retentious *T*itles like *S*crum *M*aster.

Yep! I’ll give you that one… I personally might have chosen different names… But have a think what would happen if instead of “Product Owner”, we just used, “Business Analyst”? Or instead of “Scrum Master”, we continued along with the title, “Project Manager”?.. What would be the result? Would people appreciate that their roles had totally changed?

If you keep the name “Manager” in your job title, are you more or less likely to desist from telling people what and how to do their jobs?... Are you more or less likely to let the Team Self-Organise and make their own decisions?

One could even make the case that the very name they haven’t changed (just the definition), the “Developer”, is the one that causes the most issues in Scrum! In a Cross-Functional Team, “Developer” applies to anyone doing the development work (so QA, Architect, Programmer, DBA, Basket-Weaver, whatever). This change is intentional and absolutely essential, because it’s trying to knock down “over-the-wall” and “siloed” thinking, trying instead to create a Team ethic where “everybody in that small Team is responsible for ensuring the Team’s overall success..”

[TJ930]

People shared understanding and planned what to do even without formal stand up meetings.

If you were doing it anyway, why then the complaint about codifying these approaches and putting them in the public domain? Sounds rather like those who complained about the King James Bible being written in English (instead of Latin)? Sharing it with the “common people”, eh?

Perhaps it is because you want to keep this near-religious experience all to yourself, and continue to be treated like a deity? That Super Programmer who walks on water? ;)

Also seems strange that you complain that time is being wasted, but then complain about a technique proven to reduce wasted time… You don’t actually have to stand for a Daily-Scrum if you don’t want to. (The standing-up part actually comes from XP!) But, if you’re struggling to keep to that 15-minute Time-box, why not try standing?.. The clock doesn’t lie.

As regards the frequency of the “inspection”, Daily Planning does not preclude longer-term Planning – or hadn’t you understood that? The fact is, if there is some serious impediment or some exciting opportunity/Emergent Design to exploit, would meeting less frequently help or hinder your progress?..

Remember also that a time-box is a MAXIMUM (not a MINIMUM). So, if you have nothing much to say today, you should be able to wrap up the Daily Scrum inside 2 minutes! (Almost no time wasted, and way less than the amount of re-work created by not talking to each other enough!)

[TJ930]

Giving to short targets and schedules

Yeah, I suspect that you understand how a Product Backlogs work. Look up the “Iceberg Model” (and Epics->Features->Stories). Sounds like your Backlog is a “Sea of User Stories”?

But really?!.. Rigid inflexibility is better, is it? Dogmatic adhesion to a bad plan? Blind obedience in the face of overwhelming evidence because our (religious) leader said so?

There are only 3 roles in Scrum… So, if the Product Backlog isn’t being prioritized to maximise business value, who is to blame?...

Hint: It isn’t going to be the Framework or Methodology.

Stronger hint: Neither is it going to be the Scrum Master or Developer (unless they are staying quiet when they know they should be saying something – see Principles of “Self-Organisation” and “Continuous Improvement”).

[TJ930]

Distributed teams, and varying skills, it's also more difficult.

I really don’t accept this assertion. Are you seriously suggesting that “Traditional” / old-fashioned approaches are completely impervious to the effects of those same complications?.. Seriously?.. Have you been drunk typing?..

[Mellipop]

Re: The main issue are those who turned it into a sort of religion...

Look how much your well meaning comment has been voted down.

The commentards here wouldn't know what team working is. They are, by their own proud admission, the loner in the corner. Not wishing to pair up with less experienced developers to help them with insights. Not wishing to participate in model storming sessions with customers. Refusing to refactor other people's code. Hoarding code until they have crafted an over-engineered monolithic lump that only they can maintain.

Agile is a way to classify a number of development frameworks or methodologies that mostly exhibit the principles of the agile manifesto. They are usually founded on the theory of constraints and software is development using XP techniques.

There is not one specific Agile methodology.

Just like there is not one specific Waterfall methodology. Just a set of specific, clearly defined phases.

Unlike the Agile haters here, I know when waterfall phases are needed and when Scrum will be ambushed.

[Deltics]

Re: The main issue are those who turned it into a sort of religion...

> Being forced to release earlier, can lead to bad designs, and hurried code.

Neither Scrum nor Agile dictate release schedules. This is one of the many misinterpretations/misapplications of Continuous Delivery and Agile.

The intent of CD/agile is to deliver incremental value in *potentially* shippable product. The keyword is "potentially". It means that the work you had delivered in that increment is correct (satisfies requirements/adds value) and valid (has complete test coverage and passes all tests).

That is, you _could_ ship if you (or the business/customer/user) wanted to, but you only actually _would_ if the value is useful. e.g. If your increment includes the abilities to create a bunch of stuff in your system but the rest of the changes around that "stuff" have yet to be delivered then you wouldn't ship. Or you might ship with a feature toggle set to disable that new valuable but currently useless capability. Or limit availability to a pilot group to field test the UX of that increment.

None of which alters the way you go about building that increment in the first place, i.e. the extent to which you do robust design, development and testing.

A sprint is not a release cycle.

[Robert D Bank]

Re: The main issue are those who turned it into a sort of religion...

I think the struggle is to understand how you meld all these 'potentialities' into something coherent that can safely go through Integration and QA testing before delivery. It's like having 10 balls in the air as you juggle your options. If you have many iterations of a given piece of code along with many other teams who have another 10 balls of 'potentialities' it just seems to create a huge amount of risk, especially if documentation is minimal. Sometimes you might get lucky and others you may not. I'm sure there are 'tools' around to assist with this, but even then they ultimately require competent people to manage them with honest input to them to make them work.

PS: I am not a developer. Just curious to understand this current phenomenon

[bombastic bob]

Re: The main issue are those who turned it into a sort of religion...

"with the Scrum Certified High Priesthood and all the related dogmas."

Ah, yes. "The Scrum". Let's cram everyone into a single room and let JUNIOR PEOPLE get THEIR ideas heard, too. Because, as we all know, JUNIOR PEOPLE *ALWAYS* have "the best ideas"®©™ that us SENIOR and GURU level people *NEVER* think of... [or reject outright, because they SO reflect the inexperience of the person who said it].

But, but, but, we HAVE to let the junior guys "share their ideas" because THAT way, they'll FEEL better!

And once the 'F' word "FEEL' gets injected into the process, the INCOMPETENCE, INEFFICIENCY, and SLOPPY MANAGEMENT PRACTICES are predictable.

I have an idea: Let's get some SENIOR PEOPLE and MANAGERS in on PLANNING a project before you start working on it, with a prototype to work out most of the problems, and then SPEC IT OUT, and if you go halfway through and realize that you need to CHANGE THE SPEC, you just *DO* it. But you won't be changing it every day, and probably NOT without approval of the design team (i.e. the managers and senior people).

You know, like WATERFALL!!! Except waterfall doesn't have "a cool name" like Agile. Or blackjack. Or hookers.

[TJ930]

King Knut and the JUNIOR PEOPLE

The tide is coming in, Knut. (Did I spell that right?)

Yep, I have a cool, new name for the old, dead horse: "W**k**fail" :)

[John Lilburne]

Re: The main issue are those who turned it into a sort of religion...

One always suspects that they'll turn up with Thetan meters

[Dagg]

Re: The main issue are those who turned it into a sort of religion...

We lost our last preacher (scrum master) and things actually improved. We actually got things done instead of death by standup / sprint planning meeting etc. All BS, protocol and process no work.

We ended up calling him the scum master...

[TJ930]

We ended up calling him the scum master...

Hilarious! :)) Yeah, the guy doesn't sound like he was living up to his education job description, so deserved to get the 'chop of the sword'

Yes, we've all mistyped stuff in our time; Did you know that incompetent Developers get called "Divs"?

[Anonymous Coward]

Re: We ended up calling him the scum master...

Did you know that incompetent Developers get called "Divs"?

Very useful. Round here they just get training.

[TJ930]

Re: The main issue are those who turned it into a sort of religion...

Tom Cruise thinks otherwise... Dzzzzt

;)

[John Brown (no body)]

Re: The main issue are those who turned it into a sort of religion...

"being forced to abide to some strict rules just for the sake of them often just gets in the way."

Exactly correct. Agile, by definition, also mean flexible :-)

[Dagg]

Re: The main issue are those who turned it into a sort of religion...

Agile, by definition, also mean flexible :-)

So how does this work when you have fixed 2 week sprints?

[Madness Creator]

Asshat programmers who want to go back to the good old days of taking 7 months to create a steaming pile of crap code that cant pass a basic unit test are what pisses off Scrum Masters and every single business partner.

We are all sick and god damn tired of you ass hat programmers who want to sit around months not working on shite. Yea Agile pisses you off as you have to work. It's transparent so you cant sit around for a week with your crank in your hand watching monkey porn.

But oh yea it's Agile that's the problem not you. Avoid that retrospective at all costs as you just might see what a POS you really are. Can't have any introspection YOU are a GOD YOU are a Java/Lunux/Ruby/Looser Programmer. Oh let is bow down and suck your ass you are so great. That goddamn methodology is the issue! I have to WORK? Screw you! do you know who I am!

Screw all you prima donnas and you holier than thou attitudes. Turn in some unit tested code for a change that is not so bug ridden that it takes 4X the time to fix. What do you say you pay attention for a change when we ask what else you need in planning? What do you say you quit lying your ass off when you have no clue what was asked of you.

In the meantime please keep screaming how bad Agile is.

[TJ930]

Its a F******g disaster for everything else.

In the "early stages" - you mean before the Monkeys touch the keyboard? Right... Here's an idea - get rid of the Monkeys! Problem solved! :)

No, Agile - e.g. Scrum - can be applied to anything from Software Development, to house refurbishing, to self-educating Dutch School Children, to planning weddings, to refurbishing old-classic-Sports Cars...

But we wouldn't expect you to know about all that. You're only spouting..

:)

[Teiwaz]

Sounds like..

Attending a Tai Chi class for a few weeks before slowly realising the entire class is just being taught the moves for some of the less impossibly athletic slow-mo scenes from the Matrix movies (or seems like it).

[Lysenko]

Something's off with this article ... I can't quite...

Michael Cote will be speaking at our Continuous Lifecycle London 2018 event. Full details, including early bird tickets, right here.

... and there it is. Perhaps you could post a link to the author's GitHub repository so we can verify his credentials to lecture about coding? Or how about an overview of the last development project he personally managed to successful completion (preferably in an environment with compliance/regulatory/safety aspects)?

I must re-emphasise the personally managed bit because we're all familiar with George Bernard Shaw's insightful dictum ("Those who can - do. Those who cannot - consult") and I wouldn't want to write someone off as a PowerPoint jockey unfairly.

[K]

'When does your user ever see your code?'

Speaks for it self, and it's saying "i'm bollocks".

Call my me a cynic, but anybody who is experienced enough to understand their users, will know they will simple ask "is that Chinese?"..

This shite is clearly aimed at PFY's who are desperate for a mentor and guidance on how to gain experience and progress their skillset.

[Teiwaz]

Call my me a cynic, but anybody who is experienced enough to understand their users, will know they will simple ask "is that Chinese?"..

An actual walkthrough meeting might actually end in a re-enactment of the famous scene from 'Scanners'.*

* If they paid attention, which they wouldn't, I generally notice a sad look in their eyes, with a handl carefully and slowly going to a phone to call psychiatric services (or a cleric).

[TJ930]

"Code"

Feel I ought to help you out here: "Code" means that executable stuff your computer likes; not "Source Code."

Two clues comes from the Agile manifesto:

i) "Working Software over comprehensive documentation."

ii) Principle 7: "Working software is the primary measure of progress."

Two more clues come from the Scrum Guide (if we're talking Scrum)

i) "Potentially shippable increment" [i.e. fully merged, fully tested Code at the end of each Sprint.]

ii) The Scrum Event 'inspect-and-adapt opportunity' known as the "Sprint Review" [aka "Sprint Demo"]

Two more clues from SAFe Principles (if we're talking of scaling with something like SAFe)

i) Principle 4: "Build incrementally with fast, integrated learning cycles."

ii) Principle 5: "Base milestones upon objective evaluation of working software."

[Robert D Bank]

Re: "Code"

sorry, but I think 'RTFM' (or the Agile fucking bible) should not apply to you at all because you've obviously OD'd on them and should keep your hands on the table. Original thought please, backed by practical experience and use cases that are quotable and proven.

[Cederic]

re: Call my me a cynic

You may be a cynic, but you're also a realist. This article is a lovely confirmation that I'd be wasting my time at Contiuous Lifecycle; If I want to know more about agile development I'll read Fowler, Beck, Gamma and their peers.

[markbick1306]

I took it as the author meaning get functionality (code) delivered to users, not literally show them code line-by-line.

[Dan 55]

No true agile developer...

- Is agile development not working for you?

- No, it´s not.

- It's not really agile then.

[Anonymous Coward]

Re: No true agile developer...

It's not really agile then.

Just like socialism/communism. Never been implemented 'properly' yet :-)

[TJ930]

Re: No true agile developer...

To give it its proper name, it's known as the "no true Scotsman fallacy."

The thing that separates, for example, Scrum from the No-True-Scotsman fallacy is what's called the "End Note" in the 2016 Scrum Guide.

"Scrum is free and offered in this Guide. Scrum’s roles, artifacts, events, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices."

So I rather suspect that the "twits with an 'A' " who claim to have done Scrum but it didn't work, actually haven't done Scrum at all..

If you wan't help, see either Erik Kniberg or me... I'lll be able to diagnose your malignancy in seconds.

[TJ930]

socialism/communism. Never been implemented 'properly' yet

I’d absolutely with you agree about the Socialism/Communism, and taking these sorts of people “for the helicopter ride.” However, the weakness in your argument is that this quip could far more easily and more accurately be applied to Waterfall! The idea that you always get it exactly right first time is rocking-horse manure…

I’ve heard it said that Waterfall is actually an iterative, adaptive approach – it’s just that the iteration lengths are muuuuuuch longer and slower. (Typically 6 months to 2+ years.)

So you guys send out v1.0 on (or somewhat after the deadline), it’s full of bugs, and doesn’t work how the customer wanted or expected; then – rapidly as you can (another year later) – you send out v1.1… And shortly after that, v1.2, v1.3 etc. etc. etc. to fix (some of) the bugs in the previous versions…

So you see, proper Agile is just a better way of doing it. Less time. Less waste. Fewer pages of unread documentation… Bit like Capitalism? (Just pay for what you need, rather than being taxed to extinction, paying for ‘non-jobs’.)

[Anonymous Coward]

One size does not fit all and it is not all about code.

I'm sure most organisations would love to have the sorts of systems that can tolerate an agile approach.

But they don't.

Also, agile is incredibly difficult to implement with an IT organisation that's majority outsourced. Even if you can do agile, your suppliers probably can't. And besides, they need a PO before getting going, which means detailed analysis of requirements

A supplier who knows their onions won't sign up to something (especially with a new customer) unless it's carefully detailed (otherwise you get sued when the business isn't happy with the results) and procurement don't sign up to just handing out money to a new supplier without a detailed view of what they're getting in return.

So agile is good at developing code, but that's only one part of how IT works in organisations.

[EarthDog]

So the solution might be more in-house IT and less outhouse IT.

[Mike Shepherd]

Pay no attention to that consultant behind the curtain!

We must always consider new ideas. (Whether there's anything new about Agile is moot). But, 2,500 years on, real progress still comes more often from persistence and hard work.

[EarthDog]

Re: Pay no attention to that consultant behind the curtain!

That reminded me of this:

https://despair.com/products/achievement

[Wulfhaven]

Developmestruction

The waterfall devcycle is largely a straw man argument recycled over and over again to push more expensive talks and consultancy hours of how to avoid doing the strawman dev cycle.

The important thing is to generate something end users like and use. What dev cycle you use to attain this entirely, and wholly irrelevant.

[Anonymous Coward]

Someonr is getting to the reality

And indeed the "wall" from operational teams is also more complex in some instances.

Software put live is often under some sort of "warranty" which expires regardless of the next sprint or sprints regardless of issues arising. Financial frameworks damage this relationship regardless.

Worries about, can I back out or fix issues arising quickly turn into issues of, I cant fix it till next week as the developers are working on the next sprint (or will escalate into arguments about what to drop from sprint) - also take a worrying turn for the brave ops manager.

Delivering half baked sprints into customer facing systems where failure or poor user experience puts your brand on the line, while the project is trying to churn out tiny parts of large complex changes with lots of clever concurrent development.... For Agile to truly work you need to TRUST your developers to do the right thing - this is often not easy, and operational people are not always considered as a key stakeholder, particularly as their needs are often boring and not based on shiny new stuff for developers or marketing to show off with.

Trust is a key issue, and with the usual case of transient outsourced code shops, entirely disconnected from your business, with endless cycles of change it is no wonder that larger organisations struggle, possibly justifiably, with being fully agile.

[Dagg]

Re: Someonr is getting to the reality

For Agile to truly work you need to TRUST your developers to do the right thing

It is not only the developers. The problem with agile is you can't trust the BAs, they just come up with something fuzzy, throw it over the fence and then blame the development team when the whole thing fails as what they specified wasn't want was wanted.

Note to BAs if you specify a gold plated turd then that is exactly what you will get. Be proper BA and actually do some real work. Find out what the business pain points are don't define requirements as a set of solutions spend some time on the non functionals. THEN and only then get the client to sign it off so what gets built has a chance of working.

It aint rocket science, the earlier you find the problem/issue/gap the less it costs to fix and the quicker it gets fixed.

[Anonymous Coward]

I would have thought that the 'Agile' bit should be about how fast the developers fix the bugs and cockups in their code so it can go into production as bug free as possible as well as fulfilling the specifications.

[Naselus]

Just the inverse; it's mostly about how quickly they can introduce new bugs and cockups. Agile allows a whole plethora of new problems to be brought in weekly.

[Anonymous Coward]

Bugs and cockups

all get lumped together with the mantra FINS (Fixed in next sprint) only there is never enough time to do what is planned for that sprint let alone fixing all the crap that is left in from previous sprints.

So what about the 'Fix all the crap' sprint?

Dream on, that does not meet the right productivity metrics and as one commentator has put it, Technical Debt never gets repaid.

I am so glad that I'm retiring at the end of next month.

All this pissing about with (fr)agile and DevOps and whatever... All the jobs are either going abroad or will be done by A.I./Robots. Software development as a profession in this country will be dead and burried by 2019, 2020 at the latest.

[Chairman of the Bored]

I cannot believe I'm going to defend...

...some of the stuff I saw when I was is Gov't service but here goes:

For agile to work, one needs and intelligent and engaged customer. A hint of this is found in the question, 'has your customer seen source code?' In a govt to govt context if you show source code, your PM will s#can you immediately. Why? The customer would have absolutely no clue what to do with it. I've seen projects (looking at you DHS) where turnover at the mid-level management to decision maker level was so high that teams could not get on the calendar to brief the wunderkind of the moment before he shoved off for greener pa$ture$. For years straight.

So what do you do when your customer cannot find their own ass with both hands, a flashlight, and a radar set? Make your own best estimate of what they need... somehow get the yes-men, sycophants, and sociopaths above you to agree to a course of action.... maintain laser-like focus on those requirements so you dont piss away resources chasing buzzwords or shiny... and execute. Sounds a lot like the much-maligned waterfall, no?

If you try to go agile you are brought into constant contact with the same yes-men, sycophants, and sociopaths. They've got no insight into whats needed - no technical ability - and are only going to demand more buzzwords and shiby.

The actual users? Nowhere at the table in the bureaucracy. In the "as built" govt waterfall-ish process they get at least some representation because the developers usually hire some to serve as requirements leads early on.

I'm not claiming the as-built process builds products that are optimal, cheap, or necessarily effective. What I'm saying is that its the best you can do in a Byzantine bureaucracy populated by sinecures. Going agile without having a decent customer seems like cruel and unusual punishment, and thats unconstitutional.

That's reality. And that's why I drink and my liver shall be buried with full honors.

[Lysenko]

Re: I cannot believe I'm going to defend...

...some of the stuff I saw when I was is Gov't service but here goes:

On a related note, I remember one govt project about twenty years ago that had failed twice (the immediate predecessor attempt being canned after burning £11M) using an early "agile" approach that revolved around rapid releases and continuous user feedback. The problem was the users weren't entirely stupid. They knew the new IT system was an integral part of a wider programme of "rightsizing" (aka "Redundancies") so they weren't exactly motivated to see it succeed.

We did succeed though. By performing time in motion studies of what the users did, performing top-down systems analysis and then implementing the system to do the job as it needed to be done (not how the users thought it should be done). Forty percent of users redundant inside 12 months. Result. Just not the result the users would ever have signed off on.

[Snorlax]

By Bullshitters, For Bullshitters

Here's my 'user-story': I had to the recent misfortune to take a couple of agile modules as part of an honours degree. Is agile what happens when you let the lunatics run the asylum? It sure looks that way...

I have never before wanted to stab my eyeballs with a sharpened pencil.

Instead of just doing a project in stages like any sane person, the whole thing is in a constant state of flux because some arsehole thinks that "testing starts at day one" and that risk is reduced because the customer, sorry 'product owner'/'stakeholder', is constantly providing feedback.

Buzzword Bingo needs to make a comeback in these agile times...

[Solmyr ibn Wali Barad]

Re: By Bullshitters, For Bullshitters

"Buzzword Bingo needs to make a comeback"

It never went away. And of course there's an app for that. Actually few dozens.

[bombastic bob]

Re: By Bullshitters, For Bullshitters

some arsehole thinks that "testing starts at day one"

and even the TRIVIAL things, like 1+1=2, MUST have a test function to verify it STILL works!!!

if I developed test functions for EVERYTHING I wrote, the test suite would probably be LARGER than the actual code. AND, there would be no value added. Because, when testing is needed, I do that separately, then put the function in place ONE TIME, shelve the "test the algorithm" console mode program [in case I ever need to look at it, which I never seem to] and document how the function works in case someone ELSE has to work with it. No need to re-re-re-test it EVERY! STINKING! TIME! because it WORKS.

And, if all functions (that aren't trivial) are tested in this manner, are well documented, and guaranteed to do what's on the tin, then you're fine.

[and also assuming that the project isn't shotgunned across way too many files with way too many trivial functions calling even more trivial functions ad infinitum so you can't even see the code flow any more without having 67 files open at the same time, JUST so you can do "unit tests" on EVERYTHING]

icon, because, facepalm

[Snorlax]

Re: By Bullshitters, For Bullshitters

@bombastic bob:"if I developed test functions for EVERYTHING...

...No need to re-re-re-test it EVERY! STINKING! TIME! because it WORKS."

bob, nobody give a toss about how YOU do things.

You are quite a bullshitter, so in a way you'd be a perfect evangelist for agile.

[Crumble]

Re: By Bullshitters, For Bullshitters

Careful, you're only one step away from "I don't need to test it, I coded it correctly"!

To put it another way, yes you do need to re-test it every single time. If you constructed the test right the first time, it's trivial to prove it again. Then you can spend the rest of the afternoon working out why it didn't pass this time even though you DIDN'T CHANGE THAT BIT.

[Snorlax]

Re: By Bullshitters, For Bullshitters

@Crumble:"Careful, you're only one step away from "I don't need to test it, I coded it correctly"!"

I'm not saying you don't need to test your work.

I'm saying that these agile bullshitters pretend to be in a constant cycle of testing, when in reality they're just spouting buzzwords...

[Anonymous Coward]

Ahh, (fr)Agile

AKA a bunch of people who don't understand process running around in circles until something looks vaguely right? There's a GCSE in the subject - students get unlimited retakes.

[BrentRBrian]

Agile is an oxymoron - for morons

If you live off consulting fees, agile is great.

But for developers, AGILE gives the least productive members of the group yet another way to kill time in meetings and demand a two week sprint for 5 minutes of work.

B

[Anonymous Coward]

The means have become the goal

I'm a pretty big advocate for modeling languages and certain software development / project management methodologies and/or frameworks. Agile can be a part of that, but the emphasis for me lies on UML / SysML and BPMN.

If there's one thing I've learned over the years its that the means to reach a certain goal have become the main goal in itself for some people and companies and that's also exactly where your problem lies I think: people who fail to grasp the basic concept of the whole methodology. Which is that the process (modeling, project management, etc.) should help you make things easier on you. As soon as it interferes with that then you're doing something horribly wrong.

And that interference can manifest itself in multiple ways. From smaller issues (like a data analyst being more worried about having applied the correct standards than the validity of his research material) to bigger issues (managing a team with Agile and ending up with most of your team members who would prefer to see the whole thing get canned so that they can get back to work).

Or to make this easier to understand: it shouldn't be about "doing something Agile", it should be about "doing something efficiently". If Agile can help with that, awesome! But that doesn't mean you'd have to follow the process to the letter to make that work.

[Anonymous Coward]

Successful implementations?

Please list truly successful large scale agile projects here.

[Swarthy]

Re: Successful implementations?

I wish I could up-vote the non-existent responses to your post.

[el_oscuro]

Re: Successful implementations?

**** Crickets ****

[TJ930]

Re: Successful implementations?

Well let's just list a few company names, shall we?...

Amazon.

Google.

Adobe.

Right, where's your list of successful Waterfall implementations?..

Nokia (*long gone* They couldn't react quickly enough to the iPhone)

etc.

etc.

Yours are as rare as rocking-horse manure, boys...

Whereas Lean Companies (such as Toyota, Harley Davidson and Porsche) trounce the opposition in terms of efficiency, time-to-market, customer choice, etc...

You're a dying breed, boys. "Bye bye!"

[Anonymous Coward]

Re: Successful implementations?

OK, Three companies out of thousands on the market. Is that all you've got?

Harleys are vintage designs masquerading as modern motorbikes with bling. Toyota and the rest are pretty cool.

[Anonymous Bullard]

Yes, I've done quite a few waterfall projects - that is, constantly getting pissed on from those above.

And Agile is just an excuse for micromanagement. Which is fine for juniors, I guess. But really, if I'm blocked or need something clarifying, I wont wait until the next "scrum".

[EarthDog]

Which is what you are supposed to do. If you can solve it, don't wait. If it is a defect, fix it then document. If you need more information don't wait for scrum; read documentation, go online, nudge the developer next to you etc. If necessary, ask for forgiveness.

[bombastic bob]

"Which is what you are supposed to do"

(etc. - snip rest of nauseating touchy-feely motivational phrases)

You forgot "work smarter, not harder". And all of the rest of them.

/me reaching for pink liquid now

icon, because, nausea

[Robert Forsyth]

"And Agile is just an excuse for micromanagement." no it's not. It is supposed to be a process of continuously improving the development process (and product) - making it more efficient, reducing rework, allowing people at the coal face to spot and communicate improvements early, so they can be implemented early and act for the greater amount of time.

Waterfall (and Agile) can suffer from flash-in-the-pan requirements from marketing, that will not go away until it is seen implemented.

[Anonymous Coward]

Windows 2000 - Waterfall.

Windows 10 - Agile.

That is all.

[Anonymous Coward]

What if I were to tell you that we knew all the best practices for software development?

I'd call bullshit, that's what. Especially looking at how every major software package and OS I use has got steadily worse over the years.

[Ken 16]

Agile is Medieval

If you want to build a house then you get together everyone in the village and say where you want it and which house it should look like and everyone gets together and fills in the posts and adds some wattle and daub and you do the same when you want to add some new bits or when the chimney falls down.

Then you scale that up a bit and you try to build a really big cathedral and you realise it's falling down more often than it stays up and the serfs are back ploughing the fields before it's anywhere near finished. You decide you need someone who's studied ancient buildings (the one's that didn't fall down) and who can instruct scribes to draw some patterns for others to follow and a team of masons who can follow instructions and let you know when they are going to need more stone in time for it to arrive by cart.

I haven't seen agile scale well.

[TJ930]

Re: Windows user is Medieval

Yeah, you don't know what you're talking about.

The maximum size of a Scrum Team is.... No, not the size of a whole village *sigh*

You haven't seen Agile.

[Paul Smith]

New trend?

30 comments or more, and not even one that actually defends agile as a way of working. It has been around for 25 years and mainstream for 10 to 15 years, and yet the most supportive comments here still damn agile with faint praise.

Is it time to finally admit that the fad has past? That agile is merely a tool to be used when appropriate.

[EarthDog]

Re: New trend?

I think it is a conversation on "Agile", as practiced by the clueless.

[Anonymous Coward]

Re: New trend?

Seems like I'm the only person here with a confirmed, 3-digit IQ!

Using binary is cheating.

[TJ930]

30 comments or more, and not even one that actually defends agile as a way of working.

FYI: This logical fallacy is known as "argumentum ad populum" (i.e. "argument to the people" or "appeal to the majority"), e.g. lots of people say "the Earth is flat", so the Earth is flat; lots of Creationists say that "Darwin's Theory of Evolution is wrong..." etc. etc. etc.

So, back to the topic at hand, there are really only 3 choices:

1) Do all your planning up front.

2) Do no planning.

3) Use an Agile (adaptive) approach...

For anything other than the trivially simplest of projects, I don't think the first two are not sensible options. But if you don't want to be sensible, do feel free...

Oh and I have been defending Agile, and doing a rather good job of it. You can't knock down my arguments; instead, I just get name-calling ("argumentum ad hominem"). How very grown up. Not.

[Shaha Alam]

agile does not mean doing stuff quickly.

if you're finding its quicker its probably because you previously had an obstacle that was slowing things down.

or worse, someone on your team is no longer doing their job properly.

[colinb]

agile with a lowercase a

I consider myself an agile developer but have to laugh at the folks who strictly follow their flavour of Agile.

Its not rocket science to create a system and agile gets to the crux of most of the problems.

1. Talk to the users. Listen more than you talk

2. Basic assumption: management are clueless about the on the ground business process.

3. Ask questions, a lot of questions, really stupid questions, it draws out lots of assumptions.

4 Talk to users singly first, then as a group, lost track of discussions where people realise they don't know their own process and/or don't want to take ownership, software won't fix this.

5. Mock-ups - i create quick HML mockups and get users involved early, really early.

6. Treat with distain any manager who say they represent users and won't let you talk to them. Walk away if you can. Was once told emphatically not to do multi-currency by a 20 year veteran as 'it is a dollar based industry'. They didn't know or forgot about all those euro invoices they receive and settle.

7. Know your tools. If you don't POC the hard stuff first.

8. If there is a chain of more than 5 people between users and developers, you project will most likely fail. Large consultancies have got rich on this business model.

8 Back to point 1

[EarthDog]

Re: agile with a lowercase a

I've done and and used all except number 5 and it works really well, though constrained to smaller and usually in-house rather than outhouse projects. I would add in good timeboxing, one of my favorite projects forced us to work due to regulatory requirements at maximum for two months with "mini releases" along the way. We also had direct access to the users. This was in the early 2000's before I bumped into Agile as a concept. So I immediately "got it" when I saw it.

The only of thing I would add in is gathering information, *not* metrics but real information, and adjusting using a Scientific process to adjust methodologies and tools as you go.

[JohnFen]

Re: agile with a lowercase a

These are all bedrock principles for software engineering from before Agile was even beginning to be a thing.

[TJ930]

Re: agile with a lowercase a

Right. So everybody knew it already?.... So why the backlash, if everybody knew it already?...

[TJ930]

These are all bedrock principles

..Which are all far too complicated and totally unnecessary for anybody to bother following? So should be mocked and ridiculed in direct proportion to their effectiveness?

You don't see a contradiction here?..

[Jonathan Schwatrz]

Re: colinb Re: agile with a lowercase a

Yeah, but you do realise points 1 trhough 7 you mentioned are what is called requirements analysis, and work just fine in classic waterfall?

[colinb]

Re: colinb agile with a lowercase a

That is true, in theory.

In practice i find Waterfall shops have been at it so long things are stratified and the above list doesn't happen. Also the fixed feature, fixed deadline, fixed price is very common. That is insanity, unless you are rewriting a system you have just written. People generate reams of documents long before any code is written and all the old mistakes are made, prototype only shown to managers etc..., offshore developers yada yada.

Agile is good way to change the system and bypass the old structures and get to quicker iterations. It may well become stratified and need to be shook-up itself.

[JohnFen]

Re: colinb agile with a lowercase a

"In practice i find Waterfall shops have been at it so long things are stratified and the above list doesn't happen."

But that has nothing at all to do with waterfall. Agile (or any other methodology) is equally susceptible to the exact same problem.

I do agree that it is necessary to shake things up from time to time to fix the problem, but I don't agree that moving to Agile is a necessary (or necessarily desirable, depending on circumstances) way to do it.

[TJ930]

1 trhough 7 you mentioned are what is called requirements analysis.. in classic waterfall

I think the simple analogy that counters this weak line of argumentation is that of driving a car.

So, when you're driving a car, which is the "Looking-out-of-the-windscreen phase"?...

"Let's do all our looking out the window before we set off. That'll work!"

Not.

[bombastic bob]

Re: agile with a lowercase a

"Its not rocket science to create a system and agile gets to the BECOMES the crux of most of the problems."

fixed it.

[TJ930]

Re: agile with a lowercase a

Agile Frameworks make your pre-existing organisational problems visible for all to see..

"Shoot the messenger", eh?

[Jonathan 27]

The region I live in is currently very enamored with Scrum, so almost every organization claims to use it, until you start talking to them. Then they'll say something like "modified Scrum" or "incorporating agile methodologies" and when you get right down to it you're looking at something like waterfall with continuous deployment. As such I never trust surveys as to who is using agile methodologies, because in my experience a great number of organizations claim they are, but aren't.

I've only really experienced one organization (it's a large one) that really uses Scrum and it's fairly debatable if it's a benefit or not. Communication between the team and product owner is the primary advantage of Scrum and in the case of boxed software, the product owner is often pretty detached from the end user and may not really understand what they want.

I know this is a long post, but the point I'm trying to make here is that Scrum has a lot of advantages, but it's not a one size fits all solution. Right now Scrum and to a lesser extent Agile methods in general are the current fad. I think it's going to take at least 10 years before we can look back at this and evaluate what does and doesn't work about agile and either develop the next big software development fad or improve knowledge of agile techniques to the point where claiming to be "agile" and then not actually doing so will yield a lot of negative backlash, unlike today.

[Anonymous Coward]

Too soon?

Can we refer to the guy who tried to bomb the subway in NYC this morning as an agile bomber?

Certainly had all the characteristics of most "agile" delivery I've seen - blew up too soon, and incompletely.

[Afernie]

Re: Too soon?

"Certainly had all the characteristics of most "agile" delivery I've seen - blew up too soon, and incompletely."

Very agile - he was "testing from day one."

[Solmyr ibn Wali Barad]

Re: blew up too soon

It's OK, we can just cuddle.

[TJ930]

Re: Too soon?

Was the customer feedback positive?...

[Kevin McMurtrie]

Consultant says you need a consultant

It really comes down to making a functional team that's trying to work with the customer to produce good solutions. It requires careful planning and open communications. Giving names to methodologies that don't have a single form of solution is just for the Agile Preacher's sales pitch.

PS: Copy-pasta in the article's URL.

[Jonathan Schwatrz]

So many misunderstandings.

This article - like many developers - completely fails to understand the business outside the development team.

".....Project managers, previously beset with putting together complex status reports that no one seems to ever actually read, find much more meaning in their work....." You fail to understand on of the big reasons all those reports are required - because if something goes seriously (as in "we're getting sued/criminally-charged") wrong it is those reports that will help apportion blame. And I'm not talking about "how we fix the problem", it's usually long past that in real projects (one's that are not Apple/Google Store geegaws), we're talking about where a company's reputation gets trashed, who will pay the fine, or who will go to prison.

Secondly, the Ops "wall" is there for a very good reason - it is a last line of defence that protects the business from unwanted operational failures THAT COST THE COMPANY MONEY. Even after decades in the IT industry I still cannot understand why so many supposedly smart developers just simply cannot grasp the fact that the majority of businesses do not write code as a business. Most businesses are usually selling a product or a service, and a failure of code in production will often mean they lose money directly, and probably more money in the long-term through bad publicity and upset customers going elsewhere. The checks put in place by proper change management and Ops are vital as they stop the risk that the business will grind to a halt just because a developer thinks the greeting page to an app will look better after a (botched) re-write in the latest language-du-jour.

IMHO, Agile is great for tiny projects (the geegaw apps mentioned) but is not suited to anything bigger without a proper waterfall process wrapped around it.

[TJ930]

Re: So many misunderstandings. "Customer Collaboration over Contract Negotiation."

In relation to your concerns about being sued, suggest a couple of intro books for you, like Tom De Marco's "Peopleware" and "Slack."

But, yes, as I think mentioned in "The Phoenix Project", 99.9% reoccurring of companies, whether they realize it or not, are IT Companies that sell plane tickets, energy, products, finance, services or whatever... But their business is entirely based upon IT.

No, they don't have to form a Waterfall-Agile-Waterfall Sandwich. Read one of Mary Poppendieck's books, learn about Lean companies (like Toyota, Harley Davidson, or Porsche), or look into Dean Leffingwell's SAFe... When you get a little more advanced, learn about 'Lean-Startup' to truly liberate your mind. Eric Ries has a couple books on that.

[Anonymous Coward]

Agile Project Manager

If you see this job title, walk away! It confirms that either the organisation doesn't understand Agile ways of working. Or it means that they using wagile or Iterfall or Wateragilefall.

[TJ930]

Re: Agile Project Manager

Yes. Quite so!

It's a true oxymoron... God, I can read a job spec and with 99+% accuracy predict all the problems the organisation is currently experiencing..

Doesn't mean that i can necessarily fix them, because people with lots of power might have other ideas...

[[e-mail]]

In 1998, I went to the first talk at OOPLSA about eXtreme Programming. It had been all the rave on the original W2 Wiki. I spent the next 5 years really getting into the movement, experimenting with it, and participating in the larger movement being labeled as Agile. One of my favorite books was Beck's original eXtreme Programming eXplained. It was pretty simple, pragmatic, and it didn point out that the practices kind of supported each other. I found it made a positive difference in the product I was working on at the time. Whether that was a placebo effect that really boiled down to "let the developers think they're doing a new cool thing and managing their own destiny and they'll actually increase their productivity" or not, is something I guess I'll never know.

What I have watched over the last 20 years has been like an accelerated variant of the last 2000 years of Christianity. The amount of pressure to be "doing agile" was huge, but people mixed and mashed it with their own ideas. Which had a variety of mixed results. The "introspection" principle (the idea that you should sit down at the end of every week or so and decide what was working and what wasn't and adjust as necessary). Like the term "Christian", when diluted to the point it has been, it becomes pretty undescriptive to use "agile" as a term to try and communicate what it is your team actually does do (or fails to do).

[Carstairs]

"Scrum" and "Agile"

AFAIK, the word "scrum" is only used in two contexts. Rugby, and "agile" programming. Rugby came first by many years (100 or more).

As anyone who has played, or watched, rugby will know - a rugby scrum is very definitely *not* agile. Heavy, powerful, whatever - but *not* agile. So what bright spark choose to miss-reuse "scrum" for meetings in an "agile" context?

And if you're going to appropriate the word "scrum", why not also the related words like "scrum-half", and "hooker", etc?

[TJ930]

Re: "Scrum" and "Agile" / Rugby

Tedious and predictable.

Web-Ellis would not be proud of you.

[Anonymous Coward]

Re: "Scrum" and "Agile" / Rugby

All the best fouls and illegal play took place in Scrums and Rucks.

[Teiwaz]

Agile is a marketing bikini-clad booth-babe.

Incidentally course bookings are now open on my new methodology.

Basically agile ('cause its a dynamic name that catches the eye), it's been under the waterfall for three straight days and is purified and steeped in eastern stoicism.

Now, stepping out, it's skin all glisitening, ready to revolutionise your development strategy.

Meet the 'Nubile' Method - Agile but more sexy....

[Vanir]

Agile: the new

'fake' software engineering.

Much like the hype surrounding the 'new' paradigm of Object Oriented code with the sales pitch on 'code reuse' to stakeholders responsible for budgets.

The only software engineering methodolgy I know that works is software engineering.

Someone please inform me where this methodology is practiced.

[TJ930]

Software Engineering

Software-Engineering practices will not prevent you from building the wrong thing.

[Potemkine!]

Plaster on a wooden leg

As I see it, Agile methodologies are an answer to the wrong question.

The problem does not lie in development methods, but in the inability of the client to express his/her needs, and in the inability of the project manager to understand and translate them. It's all about communication and psychology. Learning to listen, to understand, to be open minded would help, alas IT people are most of the time antisocial psychopaths (count me in).

[stephanh]

How to write non-buggy software

* Do lots of testing.

* Do code reviews.

That's mostly it. In addition, automatic checking tools (linters, static type systems, more advanced tools like Coverity) help but not nearly as much as testing and code reviews. (See also https://sixty-north.com/blog/top-four-javazone-2013-talk-the-unreasonable-effectiveness-of-dynamic-typing.html for discussion of static type systems vs. testing).

I have a strong suspicion that a lot of "Agile" methods are a bit like the Atkins diet. The Atkins diet consists of a lot of complicated "rules" which end up making you eat less sugar. You could also cut the crap and just eat less sugar. Similarly, you can do "Agile" or you can just do more testing and code reviews.

[TJ930]

Not just how to write software with fewer defects

Sympathetic to your viewpoint. However, I feel you’re missing the bigger picture - but first off, some QA definitions:

Verification error - The code doesn’t do what the spec says it should.

Validation error - The spec was wrong.

(The latter is usually far worse, because it often results in large portions of the code base being binned, due to building totally the wrong thing!)

So rather than Documentation, Sequencing and Phase-Gating, Agile Frameworks are based on the principle of Empiricism, and Empiricism rests upon the 3 Pillars of Transparency, Inspection and Adaptation.

To help you understand this purer form, let me ask you why you are running tests against your source/executable code? You’re inspecting it, that’s why. But why are you doing that? To gain transparency of your code’s quality and suitability. But why? So that you can make corrective changes (adaptations) if there are problems. In short, it’s all about Feedback.

So will your coding practices help you if the Business Analyst totally misunderstood what the customer wanted? (Or, more truthfully, if the customer didn’t really know?) No, of course not, and so your approach will not prevent Validation Errors.

You may then retort, “They would have found it in UAT!” But a typical Scrum Team gets feedback after just 2 weeks; your Waterfall approach is going to have to wait until the whole thing is finished (typically 6 months to 2 years later). So how much extra code is going to get binned? How much more rework is going to be necessary? (And let’s not forget that the Scrum Team didn’t waste 3-6months writing this useless specification in the first place!)

So this, amongst many other reasons, is why Agile is upwards of x4-to-x10 faster because it removes so much unnecessary waste from the processes. (It’s not just about fewer bugs!)

I see that you’ve used the words “a strong suspicion” – this sounds rather like you’ve never experienced Agile for yourself? Am I right? Psychologically, I think the behaviours of yourself and other commenters on here can be explained as not wishing to feel stupid again, having to learn something new, and so your egos are preventing you from seeing the truth.

The thing is, reality doesn’t care about your feelings.

[Phukov Andigh]

so, say you have gone "full Agile"

are you really doing anything "better" for your company, your customers both internal and external? Or did you simply give more MBA's stuff to do?

you can redesign a shovel every month but aside from advertising something new in Tacticool Gear Monthly, you and the other shovel manufacturers haven't really changed how well anyone digs.

[Robert Forsyth]

Re: so, say you have gone "full Agile"

You could make the shovel more cheaply.

Make it the right size for your newly identified customers.

Make it more comfortable to use.

In asking the customers and listening to them, they become invested in the product, they know about the new "smoothy grip" before it is available, you do not have to explain it to them.

[Paul Smith]

Re: so, say you have gone "full Agile"

When was the last time that the person paying for a hundred shovels actually used a one of them?

The 'customer' is the person signing the check and has a correspondingly loud voice. The user is almost always a completely different person with completely different needs and requirements and, in my experience at least, is a person without a voice.

[TJ930]

Customers and shovels

So you haven't heard of "Personas" and "User Stories", then?..

Or you have and haven't understood them, but this hasn't prevented you from offering up an opinion?

[BiffoTheBorg]

In my experience some folk are much better, one or two orders of magnitude better, at software development than others. Nowadays they get promoted to some role where they don't actually do anything useful. I can't remember now why the IBM Chief Programmer Team system was discarded, I'm sure someone will remind me. However, it seems to me that one good developer with a strong support group can be much more productive than a group following a set of rules, Agifail or whatever, designed primarily to check up on the performance of generally poor team members.