Why Agile In The Enterprise Generally Doesn’t Work

13 commentsWritten on August 29th, 2010 by
Categories: Opinions, work/career

I just came across the Manifesto for Half-Arsed Agile Software Development thanks to the wonderful world of Twitter. I'm gonna shamefully copy the text of the manifesto from the original website:

Manifesto for Half-Arsed Agile Software Development

We have heard about new ways of developing software by paying consultants and reading Gartner reports. Through this we have been told to value:

Individuals and interactions over processes and tools and we have mandatory processes and tools to control how those individuals (we prefer the term ‘resources’) interact

Working software over comprehensive documentation as long as that software is comprehensively documented

Customer collaboration over contract negotiation within the boundaries of strict contracts, of course, and subject to rigorous change control

Responding to change over following a plan provided a detailed plan is in place to respond to the change, and it is followed precisely

That is, while the items on the left sound nice in theory, we’re an enterprise company, and there’s no way we’re letting go of the items on the right.

As funny as this is, it's really quite sad as well. I don't think i'm going out on a limb here if i say that the large majority of us have seen and experienced this with a striking similarity. And i think i know why. I've only spent time in two 'enterprise' companies but from what i've heard from a variety of people, it's pretty much the same deal in most of them. Simply put: the typical enterprise culture leads to widespread incompetence, the majority of which is hidden from higher levels of management which eventually results in an environment where it is virtually impossible to work in an efficient manner. Whoa, i kinda dropped a bomb there didn't i? Allow me to explain why i believe the above statement to be true.

I believe the root cause of all of the typical problems in the enterprise world to be the Peter Principle. In the enterprise world, a large group of employees is typically interested in climbing the corporate ladder. Some of them will get promoted because they did a great job. If they do a great job in their new position, they might be promoted again. Eventually, most people will end up in positions at which they perform at a level that is no longer good enough to ever be promoted again. Quite (very?) frequently, those people produced more overall value for the company in their previous position than they do in their current position. Unfortunately, none of them (save the occasional exception) will ever go back to that previous position. As good as those people were in their previous positions, they are simply incompetent for the job they're currently doing.

Not only is it bad enough that you've got a lot of people who are too incompetent to do their job to a satisfactory level, you have to keep their superiors in mind as well. After all, they are the ones who promoted them. And they have superiors too. And you can safely assume that very few of them will be willing to own up their mistake in judgment to their superiors. That is, if they even realize that they made a mistake. Either way, either the incompetence is not noticed (which only points to more incompetence one level up) or it is actively hidden. Brushed under the carpet for nobody to notice. Obviously, that can't be good for the quality of the work that is supposed to be done at every level of the hierarchy below this one. Problems will show up in pretty much everything that gets done by the lower levels. Rules, policies and guidelines are put in place to combat these problems and to try to keep the situation under control.

This in turn leads to decreased motivation, which is especially deadly for those who do have the skills and talent to right a lot of wrongs. You're either losing time and efficiency because of people who no longer care, or because of people who simply can't do what they're supposed to do. Some will persevere, only to be promoted until they too are part of the problem. And the others will leave and prefer to work for smaller companies where everything seems to go "a lot smoother and easier".

With that in mind, go over the manifesto again and ask yourself the following question: how could it possibly work in such an environment?

  • http://ackenpacken.blogspot.com/ ackenpacken

    A lot of this is true though I don’t think this is all about incompetence. I see a lot of superiors being afraid of letting go of control. Which ends up with companies doing that whole “resource sandboxing” thing. Ending up with the illusion that R&D is a production department and not a creative and innovative department. Dan Pink pinpoints it perfectly in this video

  • http://davybrion.com Davy Brion

    @Ackenpacken

    “I see a lot of superiors being afraid of letting go of control.”

    agreed, though i’d argue that that is a manifestation of the incompetence ;)

  • Fizz

    Large organisations do not reward technical ability, only the position in the pymarid:
    “You can only have a pay rise if you are managing a team.”
    “You can only have a pay rise if you are managing a division.”

  • http://braincells2ixels.com Rams

    Very well said and I agree. I expressed similar sentiments in my blog post http://braincells2pixels.wordpress.com/2010/03/29/it-takes-guts-to-do-agile-scrum/

    You have identified the potential causes for agile to fail in an enterprise and I am currently seeing this happen in real time. It takes guts to do the right thing and as long as everyone works like it’s not their money, things will continue to be swept under the carpet and one can always say “You don’t get agile. You are just complaining”

  • Mark

    The worst part is that some of the people pushing a lot of the ‘agile’ stuff do not understand it and prescribe it as some sort of rigid process (which totally misses the point).

    In my last job, only a handful of teams truly understood what it meant to be agile. For the best part of 3 years, the majority of the teams did a half-arsed version that had little value because they were forced into it by management. Neither the management or the team leads understood how to make it work. Management insisted the whole project was “agile”, while the teams basically didn’t care and just wanted to write code.

    Worse still, our company actually had a dedicated “scrum coach”. Unfortunately, the scrum coach did no development and wasn’t in a team. He didn’t understand scrum or agile practices or how to tailor them to a team. Hilariously, back when he was in charge of a team, he fundamentally fucked up the basics, too! (I heard tales of unstructured standups that would last for over 30 minutes, huge backlogs of work planned out for years, no improvements after retrospectives etc.) You couldn’t make it up. If there’s anything worse than a half-arsed “we’re agile” management culture, it’s having an irrelevance with a scrum badge foisted upon you. Sigh.

    The only teams that made it work for them were the ones who had their heads screwed on right in the first place — they took control, shut out the management meddling and put team/software engineering practices in place to get things done. Agile/Lean/Whatever else all have some excellent parts, but the moment out of touch managers get their hands on it, it’s as useless as anything else.

  • http://elegantcode.com Jan Van Ryswyck

    Incompetent developers are highly valued in the enterprise (even more than being competent) simply because these so-called ‘code-monkey’s’ don’t stir up things, they only care about going home at 5 o’clock. They don’t give upper management and other co-workers a hard time about continuous improvement, quality and software craftsmanship. Those who want to improve their craft and really care about their profession are generally considered as troublemakers who need to be silenced as quickly as possible by more procedures and ‘company standards’ composed by those people who don’t know how to program themselves out of a paper bag, let alone know how to fire up an editor. The first category are the enterprise heroes, the second the enterprise zeros.

    Being one of these worker bees in an enterprise I have to say that incompetence is only a part of the problem. The other big problem in any kind of enterprise corporation can be summed up in one word: bonus! Bonuses and incentives are meant to increase motiviation of employees but they usually have the opposite effect. I’ve seen some very smart people make mistakes on purpose just so they can meet their targets and get their bonus. Those who have witnessed such a thing know that it’s not a pretty sight.

  • http://awkwardcoder.blogspot.com/2009/03/no-one-owns-domain-model.html Awkward Coder

    Mark +1, Jan +1

    IMO if you want to make agile work in an enterprise environment you have to take their rules, regulations & policies as nothing more than guidance, and when they get in your way just ignore them and carry on. Okay it does help if your manager believes in the same ethos.

    My current client follows the MS ‘golden’ path and has a ‘tech menu’ which doesn’t mention VS 2010, NHibernate, StructureMap, AutoMapper, OpenRasta but that doesn’t stop the team using them. Remember being pragmatic is big part of the job.

  • Mark

    Jan:

    “Incompetent developers are highly valued in the enterprise (even more than being competent) simply because these so-called ‘code-monkey’s’ don’t stir up things, they only care about going home at 5 o’clock. They don’t give upper management and other co-workers a hard time about continuous improvement, quality and software craftsmanship.”

    I agree with this statement 100 percent; I’ve seen the results first-hand. We had a lot of passengers who coasted without causing a fuss along with some egotistical dinosaurs, yet management focussed on the ‘troublemakers’ who were actually drastically improving the way things worked day to day.

    After a while, you have a few options:
    1. Hit them head-on and challenge their authority (not really possible in some organisations)
    2. Fall in line and become one of the coasters (not an option)
    3. Stealthily do the work and show them that it’s better (or just convince your fellow developers so you can get a bit of momentum going, with a view to reaching critical mass)

    It’s not a good place to be when you have to work extra hard to make things better and then you’re fought every step of the way to block the improvements…

  • http://myopendraft.blogspot.com/ Alireza Haghighatkhah

    Going to Agile is not mean killing principles and organization culture. It means “just enough” principle and you should consider & balance agility and principle in large scale teams.

  • Marthinus

    The one problem with improving software is the “Who moved my cheese” problem. Most if not all team members, developers, testers, managers do not like it when their cheese gets moved. You are just making their lives difficult.

    The positive side of the coin is what I call poop scooping. You work as a consultant, do the stuff you like and enterprises pay big money so you can just clean the mess the other nine to fivers made. Now this is not always fun, but depending on your attitude, it can be.

  • Frank

    Computerisation of (at least) Western organisations took place over the last 30 years, which was accompanied by the rise of neoliberalism and reaganomics, a shift of capital and production to the East, globalisation, and the convertion of Western workforces to service providers, particularly in the service sector.

    In a highly automated society that does not produce much of what it consumes, as long as we ration our inputs using ‘money’, the outcome can only be increasing redundancy. The core problem is the set of typical incentive structures that result: the West must employ millions of office workers somehow. There is no case for lean, agile, safe or efficient production if the prime goal is protecting your and your allies’ jobs.

  • Frank

    service sector should read finance sector above

  • Pingback: A Roundup of Popular Agile Articles - WebsitesMadeRight.com