Bad Attitudes of Agile

Posted by Christopher Goldsbury on Sep 20, 2010 |


All software development professionals will find interest in this article, but managers, CIOs and software architects will find the greatest interest.  The topic may be controversial to many, but I offer this article as insight into what seems to be a growing problem in the Agile movement.

“Why are you here?  Agile doesn’t need managers.”

Ever hear this one before? Imagine how shocking it is to hear that the developers think your position shouldn’t exist……as if you as the manager had some contribution in creating that position.   It’s most commonly directed at project managers as they first meet the development team they’ll be working with.  To be sure the original Agile Manifesto makes absolutely no mention of project management and subsequent agile theorists go further and suggest adjusting the project manager role to be more of a coach or support role.

However, this view ignores reality.

Small non-integration dependent development projects, to be sure, probably require very little supervision of any kind as long as you have a competent, experienced and capable team.   However, the larger the project, the more integration dependent the project, and the less development centered the project…….the more a project manager is needed to coordinate, communicate and lead the overall effort.  A project in which the development portion is only 10% of the overall budget can allow a scrum master to lead the development while reporting to the project manager.

Furthermore the development team is almost never aware or good at managing a budget.  The amount of time required to develop software requires that little time be spent on anything else.  This creates a bit of a blind spot for some developers as they begin to believe that everything they are doing *IS* the project and that anyone else is just a peripheral annoyance.

The bad attitude here is the inability to recognize other roles and professions as having value and strictly adhering to a philosophical interpretation without recognizing the need for flexibility given the winds of reality.   If taken too far the attitude can come across as almost unionist or neo-communist in its presentation by extending the view to all management in all situations.  Surely the individual who adopts such an all-encompassing wholesale reduction of the corporate culture and organizational structure into one flat level is a radical.   His views are on the periphery, but if he’s the right person ( a leader ) his views can gain traction and worsen the relationship between the development team and management; turning the goal of project completion into a class warfare between management and workers.

“The team runs the project, not the managers…….We’ll decide what gets done.”

This view is often an outgrowth of the notion that management roles are no longer needed.  It flies in the face of the truth; that many decisions require collaboration among many elements of the company; not just the development team……..including the software design and architecture.

In other instances developers positing this notion are just unaware that there are other aspects to a project.  Or even worse a developer has been burned terribly by a bad experience and feels the need to “take control” of the project before some perceived breakdown occurs.

Regardless agile becomes the pre-text,  a foundation, for an attitude which suggests that most, if not all, the management structure above the development team has no contribution and should be summarily removed from contribution to the effort.  Letting this attitude take hold, in my experience, usually results in endless re-architecture sessions, severe budget-overruns,  no real end date, and a fractured emotional team that becomes disillusioned with its own mission.

“There are no due dates or schedules in Agile.”

Those of us with deep insight into capital budgets and corporate finance know how silly this is.  However, if you read Ken Schwaber’s Scrum book it does talk of abandoning the Gantt chart for a burn down chart.  In truth the burn down chart is a neat and well thought out innovation, but there are those who take this to mean that there is no schedule for delivery……i.e. the money never runs out.

This was a painful experience for myself. I watched as a team led by a strong, charismatic technical leader ,whom we all reported to, abandoned any time based goals in favor of just producing a “working product” for the customer. Without any time boundaries the team careened every which way. Work ethics declined or were non-existent. Those who wanted the product to succeed lost any motivation and drive. The customers became bewildered as to why so much emphasis was being placed on various technical architectures while features and product change requests became lost. The burndown charts further confused them. All they really wanted to know was; when will the product be complete? The team would only respond with; “We’re not on a schedule. We keep developing until we’re done.”

When attempts were made to set realistic goals by anyone; they would immediately get knocked down as “anti-agile”. When the team was informed that their project was hopelessly over budget; their eyes looked clouded, and confused. The connection between what they were doing, time and, ultimately, money had become lost in the abstract design patterns etched on their whiteboards.

Realistically…….there is always a due date and a schedule for delivery; explicit or implicit.  No one puts up money for a development project with the view that it will never complete.   Even more realistically, I’ve found that Gantt charts are still very useful for coordinating deep integration or non development aspects between non-agile teams and agile teams.

The no schedule attitude arises mostly because agile techniques put forth the notion that the project should continue to add new features until the money runs out.  This is ideal and ignores what happens when a development team hasn’t even completed the bare minimum of functionality within the budget; rendering the application useless.  The bad part of this attitude is taking a new technique for tracking team progress and accountability and twisting it into a reason for not being accountable for delivery.

“Agile code is self documenting.  There’s no need for requirements, architecture diagrams or technical specifications.”

If you are a software architect or technical manager this attitude is usually targeting you between the eyes.  The thinly veiled attack is meant to question your role, experience, and the need to have anyone coordinating the overall technical design of that 28 million line software program that generates 78% of the company’s revenues.

Certainly it is often put forth by ignorance.  Maybe the 2000 line web app that the developer built recently required very few artifacts beyond the source code, but scale matters.   You know that, your management knows that, but this bad agile attitude chalks up your role to not staying current on development techniques like Scrum.  Major software systems require that a few minds are overseeing the direction and coordination of the technical vision and the many hundreds of hands creating it.

In my own experience this attitude came from a developer who, ironically, wanted to be one of the architecture staff. He felt by critiquing and arguing with the technical leaders and introducing his knowledge of agile techniques they would respect him more and give him the coveted position he craved. Instead, they found him to be annoying and a troublemaker. Furthermore his lack of tact in introducing agile concepts left the senior technical leaders with a bad taste in their mouths for anything agile.

“Agile rapidly embraces change; all change.”

My experience with this attitude came from a manager instead of a developer.   It turned out he read “rapidly embrace change” to mean all kinds of changes……not just business requirements as was intended by the original agile creators.  So, fundamental architectural changes became commonplace and shifting between different open source technologies was seen as ‘good’  even though this meant taking the team completely away from their skill sets and setting project delivery back by months.  Organizational experimentation and rapidly dropping people in and out of roles also became part of  ’rapidly embracing change’.   The end result was a mess.

Clearly accepting change presented by customers is important, but without a system for managing that change; you’re asking for trouble.  One needs to keep track of all requirements and changes and their impact to project delivery so that this can be communicated to customers.  This is necessary to make effective project decisions.  If you don’t then the customers get the unrealistic notion that anything they ask for will be included……we know where this leads.

So the bad attitude here is accepting change without managing it.  An unmitigated free for all will only lead to dashed hopes and unmet expectations.  Change is good, but violent change is chaos.

“Agile uses generalists; we test our own software.  There’s no need for a QA group.”

Again this view is accurate in philosophical interpretation but my experience with this on, especially large, software development projects is…….you need a 2nd set of eyes looking at what the developers created and how well it works.  Pride of workmanship is great and should be fostered, but sometimes pride can turn into blind acceptance and defensiveness.  It takes a strong and deeply honest person to recognize their limitations and find ways to mitigate them.

Using generalists puts emphasis on making sure you’re staffed with a nimble group of multi-skilled individuals.  In reflection this recognizes software development as mostly craft and less production assembly.  However, as software development leaders we can’t assume perfection in human resources and ignore the facts.  It’s better to see the risks and plan for them and history has proven that developers don’t find all their own mistakes.

In my own experience the individuals holding this view disliked anyone testing their code and were prickly to any constructive criticism. In one case in particular we found the underlying reason was because the developer really wasn’t that good at coding. He was given training and mentoring and after many months of struggle it became clear that he was on the wrong career path.

So using generalists is fine, but the attitude becomes stale if the hard truths of decades past are ignored in favor of philosophical purity.


In conclusion these problems could be found in the pre-agile world as well.  But in my experience these bad attitudes are finding refuge and justification in a new technique that in isolation probably never intended to present such a soapbox.  As software development leaders it’s critical that we address these viewpoints before they take hold of the agile methodology and potentially darken a good movement.   Agile has a great message; simplify, engage the customer during the product development, take ownership, and stay connected.  It would be a great disappointment to see this message lost.  So what do you think?  Are these attitudes in your shop?  How do you address them?  I’d like to hear from you.

About the Author

Christopher R. Goldsbury is a software development professional who has played the roles of developer, architect, scrum master, development manager, project manager and quality assurance manager  throughout his career.  Chris writes on his experiences and ideas at his blog.

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

So what now ? Should we throw out Agile with the bathwater ? by Guillaume L

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.

Re: So what now ? Should we throw out Agile with the bathwater ? by James Watson

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 think it's pretty reasonable. I didn't get that the article was bashing Agile. Generally, most of the 'big ideas' in software have at least some value to them. The problems start when people take these ideas to ideas to the extreme.

Often this happens not as a result of the idea but because people come in with their own biases. If a person dislikes managers and management (I can throw a rock and hit a dozen such people), I'm likely to find Agile more appealing than a command and control structure. If I'm really anti-management, I can probably use some of the ideas of Agile as shell to push my agenda.

In other words, I don't think many people believe that Agile is creating anti-management sentiment. If someone does, they might also believe that listening to Black Sabbath turns people into Satanists. In other words, they aren't too bright. But there is a danger of a idea being hijacked and twisted into something different that initially envisioned.

Agile without responsibility does not work by Stefan Schubert

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 :-)

Re: So what now ? Should we throw out Agile with the bathwater ? by Guillaume L

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.

Goo article by Michael Burke

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.

Culture & Attitudes by Paul Korney

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.

Re: So what now ? Should we throw out Agile with the bathwater ? by Bo Daley

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?)

Completely different reaction by gary woodfine

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 :-)

Who's been reading my diary? by Keith Kmett

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!

Project managers are great if they have agile programming experience by Thomas Fitzpatrick

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.

The problems are not with Agile - maybe with Agile implementation by Radu Davidescu


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.

A religious matter… by Alex Maclinovsky

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.

I've run into these attitudes... by Andrew Bruce 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.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

13 Discuss

Educational Content

General Feedback
Editorial and all content copyright © 2006-2013 C4Media Inc. hosted at Contegix, the best ISP we've ever worked with.
Privacy policy