Bad Attitudes of Agile

Congratulations, you probably just wrote the first true Agile-reactionary article ever. Well, there had to be one. I read it through, and I have to admit it is brilliantly argued. All your points are valid if you take for granted that the statements in bold are real-life quotes.

The problem is, if people who think and speak that way exist (I personally haven't met any), they're probably closer to dangerous fundamentalists than Agile practitioners. As you said, nothing in the Agile manifesto or in any Agile methodology says that there should be no schedule or deadlines (actually, iterations are all about deadlines), no position dedicated to the financial aspect of a project, or no requirements at all (read Mike Cohn's User Stories Applied).

If your intent was to issue a warning to developers no to push Agile bigotry to the absurd, we got it. Unfortunately, exaggerating like you do is too often a devious way of refusing any measured, balanced point of view and throwing out the baby with the bathwater. I hope it is not the case.

If your intent was to issue a warning to developers no to push Agile bigotry to the absurd, we got it. Unfortunately, exaggerating like you do is too often a devious way of refusing any measured, balanced point of view and throwing out the baby with the bathwater. I hope it is not the case.

I can mostly agree at your statements, too.

Though, your examples to me are showing a typical problem for a lack of responsibility on the developers side. I want to show that on 4 of your points.

"Agile uses generalists only" - is that science or esoteric? Generalists are important, yes. But why won't I have a mathematician in my image editing team? A QA expert in the team with a QA manager to report to - very useful. But why a special QA group? Give QA goals to the team as well. Give them the QA responsibility.

"Agile embraces (massive) change" - that is very extreme. Agile works with smallish increments on working software. Technical evolutions should be as small as functional increments. If they are not, you have nothing new to show to the customer. The team needs to take over the responsibility to deliver. And they will not deliver anything if they redesign everything every other month.

"No documentation" - If there is more then one team give them the responsibility to share an architecture with the others. How that can be done is a different story and belongs to those responsible. Let architects be part of some teams (usually you do not have enough) and support team architecture efforts. I am a software architect at quite a big web portal architecture (a million LOC) and it just works - with a lot of evangelizing. Agile has made architecture management lots easier - especially since the teams took over responsibility having our support - with much less documents.

"The team decides what's done" - hardly. An agile team does what the product people prioritize for them to do. That is nearer to the business and the customer needs than in any bigger (big for me is half a million dollar) project I experienced (and managed). And I never want to manage the detailed work items of 10 to 20 grown-up people for half a year again.
That, again, is a responsibility issue. The agile team does not have the product responsibility. And if they do, they have to explain the ROI to their customers. Product people should do that job (in the team or "not"), if ever possible without any communication relays (other managers) between them. Better to have them coordinate the schedules and results with owners of the product (e.g. release management). Because product people WILL care, because they are responsible.

My 4 cents :-)

James, I agree with you. However, it drives me to despair that someone chooses to emphasize on the presumed "bad agile" or, let's face it, "too agile" behavior of a part of the community when they should rather leverage the shared interests that exist between customer, leader and developers in Agile to come up with new answers to the many question marks that remain in the field of Agile adoption.

Unfortunately what transpires from the article (but maybe I'm wrong) is that the recommended solution would be to keep Agile "in its place", enclosed in its tiny perimeter and prevent it from changing too many things in the surrounding organization on the pretext that it could be dynamite in the hands of dangerous extremists - to me that sounds particularly un-agile.

Certainly this is not an agile bashing piece. That is evident from the wrap up - 'Agile has a great message; simplify, engage the customer during the product development, take ownership, and stay connected.'

But for me it raises a salient point, that some of the core philosophies of agile play naturally to and *reinforces* many software developer's natural prejudices (management is superfluous, I can replace a QA team with JUnit and a couple of Ant scripts, architects are just managers in disguise and are stopping me from getting work done, documentation is a waste of time) and are therefore open to abuse through interpretation, just like any other philosophy, political stance or, dare I say it, religion. Human nature and all that.

The article put forward these examples of behaviour and asked if others had experienced them and if so, how do you deal with them.

The comments about 'agile doesn't work if you don't have responsibility' whilst valid, are equally valid for any other development methodology you can think of - this is not a new insight.

I have heard variations of every statement here as much from managers as from developers. There is a lot of pressure in most IT organizations from above to be more agile (IOW 'get it done sooner!'), and from below because it is currently the 'cool' thing to do. My experience is that this reflects a great confusion about what is necessary to achieve agility. I think it is more than mere internal project techniques, though those are obviously necessary.
I really do wish that the 'agilisti' would bring more attention to the organizational prerequisites for agile working, ala 'Peopleware'. There needs to be some clear requirements specifying the 'host' organization's responsibilities that must be fulfilled prior to attempting any particular agile technique. Otherwise it is just fashionspeak.

This article might simply be repeating a number of fundamentalist positions, but ultimately provides an unsatisfactory account of agile. As others have noted, this account appears to suggest that agile should be contained to a development team and should not be allowed to pollute the organisation at large. This approach leads directly to precisely the pathologies the author complains about:

* management entirely disconnected from development priorities (often management keeps itself at arm's length from technology decision-making, using agile as an excuse for its own indecision and inaction)

* no timelines or deadlines (these obviously need to be set by someone with business insight and control of budgets, who is invariably outside of the dev team)

* no/inadequate test processes (maintaining an external QA group is a sure-fire recipe for the bad old days, when all the bugs in a project are discovered at the last minute and there's no time to avoid a blowout. Why not bring QA expertise into the team itself, where it can iterate along with development?)

I had a completely different reaction to this article than the other commenters I read. I resonated quite strongly with the views of the author and feel he gave a very balanced account of how Agile is percieved and misinterpertted by both Developers and those who manage them.

All to often I have witnessed a team that proclaims it has gone "AGILE" when in effect it has embraced "CHAOS". Some of the most common mistakes made by "Agile" adopters, is they do take the Self Managing and organising aspect of the Agile Methodology too literally. They often percieve the management hierarchy as external to the team, when in fact the opposite is true, management is still very much a part of the team, it is just a much more flatter structure. Management should be alot more ingrained into the team and seen more as a team member, working with and for the benefit of the team. There is a common perception by developers that they are focus and they should be steering the project, this is wrong they are a vital component of the project but they do not own the project.

The points on change are also very relevant. The leading factor to success of Agile is managing the expectations of the project. Yes a team can adapt to change, but there is a cost and this needs to be contiuously emphasized. The cost is both Financial and Timescales. IF the client wants x widget to do Y, then Impact is Z. This needs to be communicated and understood not just embraced. IF client the client has higher priority features for an Interation, then which features need to descoped from the iteration to accomodate.

The documentation point is also a very common mistake. The code is the documenttation is completely wrong. The code is a component of the documenation and in many cases plays a role in compiling the documentation. There is still a need for documenation in Agile albeit lighter in weight but higher in importance.

An Agile team could contains specialists which collaboratively make a team of generalists, but there strengths in the team are there specialisms. In my opinion a successful agile team should at least contain ; Developers, Testers, Business Analysts, Architect, Product Manager, Build Master, Integrator. It may be possible for 1 person to do more than 1 role, but his main priority is his main role. For instance the Build Master may preform secondary developer duties, but his sole purpose on the team is that of ensuring the build is sacred. The build master should never be assigned a critical work item.

Well that is my 2 cents it's probably about time I focus on my core repsonsibility in the team :-)

It appears as if we have had near identical experiences with developers and team leads. All talented, just misguided by a belief that Agile can cure cancer. And if you aren't wearing green Agile bracelets you must be anti-innovation. I'm sorry that reality gets in the way of doing whatever you want as a developer. Darn it!

I find that the best project managers are those who used to be software engineers that adhered to agile best practices i.e. test driven development, re-factoring etc etc

These managers know the trade-off between short term and long term productivity - getting stuff done fast vs doing stuff well.

They use apply their understanding of the business needs to decisions about what sections of functionality should be well tested and well written vs what should be written throw-away style.

The best managers usually those who have spent many years in the software development trenches, then go on to do an MBA or something, and have expert knowledge of the domain. On top of all that a good dose of humility helps too. Regrettably most managers do not have a clue. Some should have their heads checked for narcissistic personality disorder. Fortunately I am one of the lucky few who have a good manager, but I have had some pretty awful ones along the way.

Hi,

The poor level of abstraction used in your article shows that the company that you work for have deep trouble. So deep, that they decide that Agile will save them. Any Agile practitioner knows that Agile don't solve the problems. Instead, aggressively put them in front. As managers are incapable to create a proper environment, that degenerates into something worse than Agile - chaos, or anarchy. You can call it whatever you want, even Agile if you really need to blame something.
Agile is not a silver bullet, even through, managers keep looking for something like that to manage creative working teams. In Agile philosophy people are self-directed and self-organized into some boundaries. If the manager doesn't understand that and poorly perform in managing that boundaries then it's not such a big surprise that the team point the finger on him.
Agile works in environments lead by Agile managers, that can step over the "command and control" style, that doesn't see people like some numbers on a sheet, mixed into stupid complicated formulas. That kind of managers needs to have well balanced art, craft and science of management.
Agile implementation it's a tough job for large companies, so skilled Agile people are needed to ensure a good and real transition. Again, Agile dosen't have bad attitudes, people have! I agree that bad people are easily exploited through a command and control management style, but that have nothing to do with Agile. On the other hand, good people deliver in any project management style but you get most of them by using Agile.
Agile is not a mass market product, it's a maximiser for good teams. Start asking if you have a great team that deserves a great environment around them that will stimulate them, and after that, carefully implement Agile.

In my mind the best way to look at this is through the eyes of comparative religion studies: after all, methodology does in many ways resemble religion. In my experience, the believers in Agile are much more likely to hold fundamentalist views and resort to extremism than followers of other major IT religions – have you ever seen a species of RUP extremist or Waterfall fundamentalist? And the moment fundamentalism and orthodoxy (meaning literally "having the right opinion") enter the room common sense and reason flee in panic through the back doors. Which is exactly why Christopher’s article is so timely and relevant. And why it has generated such a firestorm.
Extending the parallel with real religions, extremism can be found in every single one of them which is bigger than a sect, but it is fairly clear which ones are more prone to develop extremist views. It also doesn’t seem to be directly related to the belief systems or canonical texts but to the age since the first revelation: I can think of a few religions that used to be pretty out there and have mellowed out after the first couple of millennia. Another interesting analogy between IT methodologies and religions lies in the attempts of reconciliation: the endeavors to bridge the differences between the methodologies that I have been a witness to closely resembled the interfaith disputes in both the style and futility.
I hope you realize that all of the above was written about software development and not any other, more controversial, subject.
Coming back to the Agile – I sincerely hope that it will sometime in a not too distant future come of age, stop fighting for its place under the Sun and seeking new converts by the edge of the sword and start doing what religions should: giving the sense of direction to those who are lost, sense of righteousness to those who feel insecure and inspiring great works of art.

...in fact frequently over a 20+ year career writing code. To start: I acknowledge the problems that brought about Agile. I've worked with many large non-functional teams delivering product that was poorly executed and created at tremendous time and expense. Project management certainly didn't seem to do anything (which, by the way was the problem -- no guts in the PMs to say no *ever* to *anything* from dreaded Senior Management or the Customer).

The problem with Agile is its wish-fulfillment basis. The fact is that many people (not all people) are not particularly interested in spending all of their life Delighting Their Customers. Agile works well when the team does feel so inclined (as Chris points out). Larger teams, much more complex interrelationships -- that's a different problem. As for "Change qua change is good?" When did any adult start to buy into that? One sysadmin I read years ago put it best: "We fear change." (That's why he was still on apache 1.3 -- he trusted it.) A decision to make a change always has an element of risk with it, and accepting risk is always a cost-benefit analysis -- certainly not an emotional one.

Now Government and Agile is a real problem. Government has a fiduciary responsibility not to bind the next Congress with the current Congress' decisions. (That's why we can't do multi-year budgets.) So you gotta have a good understanding up front of what you're going to do, why you're doing it, when change occurs how it was managed and who approved it so it can be budgeted and paid for without just being "Gee, we'll go till, um, whenever we think!" Other than a natural (but infantile) human wish that a particular person may use the word "Agile" to mean "I want things to be built faster and better -- but still with my project plan and budget amortized over the next 4 years for presentation to Senator Muck-a-muck, right?" You tell me how this can work with Scrum meetings and a burndown chart? Puh-leaze!

Students of history who read Marx will find much to appreciate in Agile -- less Division of Labour, less scalability -- in fact, Agile's closest economic model would be the medieval guild in its purest form (master artisans working together where each had a vast knowledge of the entire process). But after reading _Capital_ (esp. Volume III, not just I), one should then read _Reminiscences of Lenin_ and discover that, actually, the first thing that happened during the Russian 5-year plans was the elimination of worker autonomy and non-specialization -- because things didn't get done in a large-scale environment. Also, please to check the Wall Street Journal for that famous "No Code" ad that SalesForce used to run. Newsflash: Nobody wants to pay expert software developers except when absolutely they have to. They want to pay component integrators as little as possible. Sorry to be the bearer of bad news.

So I've read the Agile Manifesto and did my best over the past year to run my projects using Agile methods. Did they work? Not particularly well, and the customer was really confused by my inability to produce status reports (well, I had to produce those anyway -- but that's not Agile so please keep it hush-hush). The good news? A few years and Agile will fade away with other silly ideas.