Discussion on:

What employers want from developers? Agile, agile, agile

It would be nice if the interest were driven by a desire to produce better products. But alas, I feel it's being driven more by the perception of being able to do more with less. As in "If we implement Agile, then maybe I won't have to hire those seven new developers that IT says we need".

Based on my 25+ years of development experience, most upper level management won't understand it, and will constantly be complaining about having two (or more) people working on a task at the same time. I can see the emails now "Dave, why do you have two developers sitting side by side working on the same thing? Couldn't you get twice as much done if they each worked on something separate?".

is they can quickly move the goal posts at no cost. Scrum this, sprint that, stand up at stand ups, blah, blah, blah. All form, no function.

This article is confusing, agile is a management thing, developers just do what we are told, its the same under agile or waterfall.

I have no doubt "agile" is a trending requirement found in job posting for developers. Though as someone else pointed out, its more a management technique than a way of developing. And, I'll add to that in my experience "agile" is a management technique often abused to both put off decision making and to circumvent writing a fully fleshed out specification. When an employer says they want an agile developer what they really want 9 times out of 10 is a developer who won't complain when the direction of the project shifts every other day. Sadly, its usually the development team who turns around and takes the bad rap too when the project ends up late, over budget, and under delivered.

Agile, scrum, sprint, stand up meetings. These management methodologies have value if all other project management fundamentals are adhered to. The IT projects that succeed are well planned and researched and DOCUMENTED and then tested, tested, tested. Coding is a minor part of the effort - as long as the specs do not constantly change. Agile will not save a project that is ill-planned, badly managed, under manned, over reaching, unwanted by the users, under funded, and has a ridiculous target date.

Agile is a tool that can be very useful. But, like all tools, it only works in the hands of a skilled person.

As long as employers misunderstand Martin Fowler's Manifesto of Agile Software Development by taking short cuts, short cuts, and short cuts they will continue to ignore source code control management, controlled builds, testing baseline analysis, user acceptance testing and training, and documentation they will reap the wind(s) of disaster after disaster after disaster.

Employers really need to understand AGILE is a TOP-to-BOTTOM approach and not just the BOTTOM (developers/QA) to adopt and the TOP still expecting deliverables in a scheduled manner.
The requirements change and so would be the deliverables dates.
Which means even a calculated business risk that the TOP (Managment/Employers) need to take and not push it down to the Development?

Just quoting ecerpt from the blog
"Agile software development simplifies the planning stage and splits large projects up into iterations where workable products are delivered throughout, rather than at the end of the project. It also emphasises user feedback at every stage of the programme, not just at the beginning and the end"

Does the employer really understand Agile as defined above?
I have'nt seen yet?

Is there a way to educate the Employers to get this in practise in true sense?

Regards,
Shriram Pore