ArtsAutosBooksBusinessEducationEntertainmentFamilyFashionFoodGamesGenderHealthHolidaysHomeHubPagesPersonal FinancePetsPoliticsReligionSportsTechnologyTravel

Agile as a corporate strategy to breed mediocrity and commoditise software developers

Updated on November 6, 2015

Agile is a methodology of flexible incremental change with rapid feedback and a good way to tackle wicked problems, those problems that resists solution by revealing new facets every time an interim solution is formulated. It does this by breaking a task into smaller tasks, eating the elephant one bite at a time and responding to change and new information in a flexible manner.

Agile has been criticised on a number of grounds [1,2] but most of these criticisms are related not to the problem solving methodology above but to the management process associated with it, for example that involving Atlassian's JIRA, and the way company cultures or even individual managers implement the process.

Here “Agile” will refer to the way it is implemented rather than the sensible problem solving process above.

Agile can be implemented to foster creativity, and develop developers or to destroy creativity, stifle innovation, breed conformity, foster mediocrity and prevent developers from developing anything more than their knowledge of the technologies used by their organisation.

In most companies Agile is applied only to Software development teams: not Architecture, not Operations, not Sales and Marketing, not business analysts, not individuals and definitely not Management, just Development and is used by managers to speed up delivery and track performance.

When implemented in ( perhaps subtly) dysfunctional organisations, then by an obvious extension of Conway's law it reflects and amplifies both the dysfunctionality and the company culture. One such dysfunction is the worship of “The Team” and the resultant commoditisation of workers especially developers.

Agile can trap capable and senior engineers in an endless treadmill of user stories, digital paperwork, email tsunamis, scrum meetings and a position of endless juniority, even if they are tasked with planning work for the rest of the team. And the better the seniors plan the longer other team members remain junior. Architecture, R&D, perhaps the most frustrating exciting and fulfilling aspect of working in IT (or any other field), Sales, Marketing, product development and Management in General do not lend themselves to the standard Jira focused atomisation of work and baby talk description of tasks that developers experience.

Poor Agile can result from poor management, poorer company culture, negative factors in the software industry and a militaristic top down control culture of business in general.

Finally Agile can give developers extra reasons to consider themselves an elite. Just as 80% of drivers consider themselves better than average, though statistically truly elite developers will be rare and many teams will be composed entirely of mediocre developers. When mediocre people believe themselves to be experts they become dangerously dogmatic. When others believe them experts risky and dangerous ideas can take root and damage a company badly. When true experts consider themselves mediocre ( and the more you know the more you realise how little you know) ideas are considered in depth before implementation and the major risk is overthinking a problem.

Computing for the individual
Computing for the individual

The historical trend towards teams

Throughout history there has been a trend away from individual expertise to a team based mode of operation from the Iliad with its hero warriors to the Greek phalanx, from the individual craftsman to the factory and from the recognition that workers are people to their current characterisation as Human Resources. This emphasis on the Team tends to commoditise developers who are ideally, from the management view point, interchangeable with none having any specific expertise and all being able to handle any task, Jacks of All Trades and masters of none. Teams can do a lot more than individuals but have dangers for society, enterprise and the team itself: The herd instinct, groupthink and dominant individuals (alpha males and females) being the most obvious.

Homer writes of heroes: Achilles and Hector, who fought like demons in the scrum of battle mowing down enemies like grass. Later the Greeks invented the phalanx, a shield wall with spears sticking out of it that depended on teamwork and the age of heroes was over. The Romans later converted the phalanx into the Testudo or Tortoise and teams of soldiers led to the gradual obsolescence of the medieval knight once firearms came to dominate the battle field.

Later in the 18th and 19th centuries when Mercantile Capitalism gave way to Industrialism corporations were formed with hierarchies that mirrored those of the military. Factories where each worker, like a well honed Java class, had a single well defined responsibility with a few coordinators to ensure the work was done properly replaced guild workshops where multi skilled craftsmen assembled products on their own. Similar specialisation overtook the white collar areas of industry as separate departments and typing pools arose.

Eventually the Wild West frontiers of the Computer Industry succumbed to the same forces as tasks were simplified and automated with complexity swept under the hood. The Lone Programmer, like the Lone Ranger, became a figure of historical fantasy, at least in the corporate world though they continue to hang on outside, masterless Ronins eking out a living and perhaps envied by those inside the gilded creativity destroying fur lined mousetrap [6] that the modern corporation offers to Information Technologists.

Nowadays the corporate coder must demonstrate they are a team player and demonstrate, or at least fake, the passion of the Lone Programmer, manifesting as long hours, sacrificing personal time, relationships and even health “for the team”, “for the company” and the latest buzzword “To add customer value”.

The ideal corporate team
The ideal corporate team

Problems with teams

Development teams are, at least under Agile, supposed to be composed of individuals who can handle any task. This fulfils management's decades long wet dream of turning workers into commodities, something that started when “Personnel” became “Human Resources”. The idea that teams could comprise specialists who might flounder outside their comfort zone, or heaven forbid, might have expertise not relevant to the team but to the wider enterprise, is often taken as a dysfunction within the team and the team member.

Perhaps more importantly a team, like the Greek Phalanx, has no room for heroes. If anyone can tackle any task all are equal and statistics tells us they will all be close to average while the Dunning-Kroeger effect tells us they will all think they are geniuses. Even if they are a carefully hand picked elite (and the jury is still out on what defines an elite developer) they will all have to submerge their ego: and developers, having been treated as superior for decades, have a lot of ego. The solution to this is for each developer to have one or two areas of expertise, thus preserving their ego which goes against the idea that anyone in the team can pick up any task.

In practice some team members become local experts in a particular subset of the team's activities while tackling less demanding tasks outside their comfort zone. The best then leave in order to concentrate on their speciality leaving a team with somewhat less collective competence.

The business focus here hide problems with Agile
The business focus here hide problems with Agile

Agile specific problems

Agile as implemented tends to reinforce hierarchical structures in an organisation, with the developers at the bottom, outranked by an entire management structure and that amorphous if not protean entity known as “The Business” a mixture that includes Business analysts, project managers and customer relations managers. Agile increases the feedback frequency between developers and their customers and prevents them going astray – assuming the customers know what they want, which is never a safe assumption. In terms of Conway's laws expanded to take the communication structure of an organisation as including its management structure Agile mirrors an organisation that is dysfunctional, perhaps subtly so with the workers on whom it all depends at the bottom. They have to work faster but often have no formal power other than perhaps vetoing a suggestion by pointing out it is unworkable.

Agile often leaves developers capable of more trapped in a junior role with no easy way to move up either on a technical path, as architects, or on a managerial path where their technical skills might allow The Business to avoid asking for provably impossible features each faster than the other ot into architecture or (my dream job) research.

Church [1] claims there is no place for a senior engineer in a Scrum team. Some organisations use senior engineers as technical leads planning and coordinating work while remaining in a Scrum team. It is usually better for the senior people to be separate from the team, though free to contribute to development if they desire. This lets the senior people look a few months ahead, something generally left to management.

Church also claims Scrum and Agile should be short term tactics for emergency. In support of this I have worked in a number of companies where productivity was high and targets met but neither Agile nor Scrum were in place. Against this is the view that software development is a wicked problem and Agile is a good way to tackle such problems. If that is the case however an Agile like methodology should be employed in scientific research and in political decision making.

This could be Heaven or this could be Hell: It ain't no technological highway
This could be Heaven or this could be Hell: It ain't no technological highway

The Wrap

Agile is regarded as a good way to tackle the wicked problem of software development where planning an entire project in advance is impossible. Development has to switch between exploration and evaluation to straightforward development [4] in a process reminiscent of real scientific research (which however manages to avoid tickets and Scrum).

The Agile Manifesto is framed in terms of Software development and Business. It is thus embedded in corporate culture and the problems many attribute to Agile are actually problems of Company culture, the culture of the software industry and the dysfunctions in Business culture. When Agile meets Business red in tooth and claw it tends to be implemented in a way that destroys creativity, forces mediocrity on developers and prevents the more experienced moving up into areas such as architecture and research.

When the Agile manifesto is examined without the distorting lens of software development and business it shows a strong resemblance to academic research, though the need for funding has made riskier research less easy to pursue, just as Agile has made it harder to pursue risky development.


  1. Why “Agile” and especially Scrum are terrible

  2. Can agile destroy creativity?

  3. Software Development is Inherently Wicked

  4. The Agile Manifesto

  5. The Dunning-Kruger effect

  6. The Fur lined mousetrap : C. Northcote Parkinson, Law Book Co of Australasia; New edition edition (20 Sept. 1983), ISBN-10: 0863600077, ISBN-13: 978-0863600074


This website uses cookies

As a user in the EEA, your approval is needed on a few things. To provide a better website experience, uses cookies (and other similar technologies) and may collect, process, and share personal data. Please choose which areas of our service you consent to our doing so.

For more information on managing or withdrawing consents and how we handle data, visit our Privacy Policy at:

Show Details
HubPages Device IDThis is used to identify particular browsers or devices when the access the service, and is used for security reasons.
LoginThis is necessary to sign in to the HubPages Service.
Google RecaptchaThis is used to prevent bots and spam. (Privacy Policy)
AkismetThis is used to detect comment spam. (Privacy Policy)
HubPages Google AnalyticsThis is used to provide data on traffic to our website, all personally identifyable data is anonymized. (Privacy Policy)
HubPages Traffic PixelThis is used to collect data on traffic to articles and other pages on our site. Unless you are signed in to a HubPages account, all personally identifiable information is anonymized.
Amazon Web ServicesThis is a cloud services platform that we used to host our service. (Privacy Policy)
CloudflareThis is a cloud CDN service that we use to efficiently deliver files required for our service to operate such as javascript, cascading style sheets, images, and videos. (Privacy Policy)
Google Hosted LibrariesJavascript software libraries such as jQuery are loaded at endpoints on the or domains, for performance and efficiency reasons. (Privacy Policy)
Google Custom SearchThis is feature allows you to search the site. (Privacy Policy)
Google MapsSome articles have Google Maps embedded in them. (Privacy Policy)
Google ChartsThis is used to display charts and graphs on articles and the author center. (Privacy Policy)
Google AdSense Host APIThis service allows you to sign up for or associate a Google AdSense account with HubPages, so that you can earn money from ads on your articles. No data is shared unless you engage with this feature. (Privacy Policy)
Google YouTubeSome articles have YouTube videos embedded in them. (Privacy Policy)
VimeoSome articles have Vimeo videos embedded in them. (Privacy Policy)
PaypalThis is used for a registered author who enrolls in the HubPages Earnings program and requests to be paid via PayPal. No data is shared with Paypal unless you engage with this feature. (Privacy Policy)
Facebook LoginYou can use this to streamline signing up for, or signing in to your Hubpages account. No data is shared with Facebook unless you engage with this feature. (Privacy Policy)
MavenThis supports the Maven widget and search functionality. (Privacy Policy)
Google AdSenseThis is an ad network. (Privacy Policy)
Google DoubleClickGoogle provides ad serving technology and runs an ad network. (Privacy Policy)
Index ExchangeThis is an ad network. (Privacy Policy)
SovrnThis is an ad network. (Privacy Policy)
Facebook AdsThis is an ad network. (Privacy Policy)
Amazon Unified Ad MarketplaceThis is an ad network. (Privacy Policy)
AppNexusThis is an ad network. (Privacy Policy)
OpenxThis is an ad network. (Privacy Policy)
Rubicon ProjectThis is an ad network. (Privacy Policy)
TripleLiftThis is an ad network. (Privacy Policy)
Say MediaWe partner with Say Media to deliver ad campaigns on our sites. (Privacy Policy)
Remarketing PixelsWe may use remarketing pixels from advertising networks such as Google AdWords, Bing Ads, and Facebook in order to advertise the HubPages Service to people that have visited our sites.
Conversion Tracking PixelsWe may use conversion tracking pixels from advertising networks such as Google AdWords, Bing Ads, and Facebook in order to identify when an advertisement has successfully resulted in the desired action, such as signing up for the HubPages Service or publishing an article on the HubPages Service.
Author Google AnalyticsThis is used to provide traffic data and reports to the authors of articles on the HubPages Service. (Privacy Policy)
ComscoreComScore is a media measurement and analytics company providing marketing data and analytics to enterprises, media and advertising agencies, and publishers. Non-consent will result in ComScore only processing obfuscated personal data. (Privacy Policy)
Amazon Tracking PixelSome articles display amazon products as part of the Amazon Affiliate program, this pixel provides traffic statistics for those products (Privacy Policy)
ClickscoThis is a data management platform studying reader behavior (Privacy Policy)