Agile will fail

No Agile hereWhat quite some Agile consultants tend to do, is implement Agile/Scrum by the book without looking at the actual context. Most of these consultants define an approach that will need to have all layers of an organisation involved. On all these layers, a change process is needed to make a good transition to Agile. Guidance, for the large changes that are needed, is usually only supplied at the team level. This leaves middle and upper management, after a couple of awareness sessions, unable to efficiently deal with Agile/Scrum. After the Agile Consultants have left (most of the time they are too expensive to stay for a long period of time), the company has to carry on working with the mess that is left behind: a process with little Agility due to the remains of the “old process”.

Teams know what they should do, but cannot act since backlog items are not provided in the correct manner or upper management still has a very strict release calendar. Freedom of choice is not present and the team members are forced back into functions instead of roles. Management still thinks in these functions too and will judge people based on their functions instead of based on their performance and value added as a team. People who are not able to work in an Agile setting are kept on board for their “critical knowledge”, but they hinder the Agility of the process and the team by not sharing their knowledge.

Another mistake often made by companies is removing management (project management, test management, …). Especially for larger projects, management and a senior architect are still needed. Successful projects need people that keep a “helicopter view” to make sure that all the parts will work together. You need to know all the connections with other (parts of the) systems to incorporate the risks involved. Large parts of risk mitigation need to happen at this level and will fail without proper management.

Yet another strange phenomenon is not adapting the organisation to the Agile manifesto. The four rules are so clear, but in the transition to Agile the required documentation by various parts of the organisation is usually not re-evaluated. Most maintenance departments still demand exhaustive documentation. Yes, of course there needs to be some documentation, but in most cases the amount of documentation can be much lower while still delivering the essential knowledge.

For Agile to succeed properly, test automation should be an essential part of every sprint. An often heard claim about test automation: “We don’t do it, because it is too difficult in our setting.” This usually proves to be false… The teams do not realise that the changed context has impact on previous decisions on test automation. People often just do not want to invest in test automation, since the benefits are not made clear enough. On short term the business will only see costs without the benefits. If you want test automation to be supported, define a business case! Describe when test automation will start to pay off and what the initial costs will be. Above all make a plan on how to introduce test automation. It is not just using a tool, but a selection process on what to automate and which tool will be most suitable in your context.

Of course I don’t think that Agile will fail, but this is merely a reflection of what I see happening in many companies: a rigid, by the book, implementation with no room for context or Agility. Luckily I have also seen quite some good implementations of Agile/Scrum.

Do you recognize these problems or have problems to add?

Advertisements

11 comments on “Agile will fail

  1. I agree. Converting from a legacy software development approach like plain waterfall or the old Rational Unified Process is hard…very hard. A one week training class or a few weeks of coaching is not enough. At a minimum, there should be a pilot project with ongoing training/coaching as needed.

    And…the management team needs to be trained/coached also, not just the software team.

  2. ” a process with little Agility due to the remains of the “old process”. ”

    This is why by-the-book scrum is so powerful. Too many agile consultants try to fit agile into the existing org structure and processes, thereby allowing existing dysfunction to remain, or worse, covering it up. They try to modify everything right out of the gate, instead of just choosing scrum.

    If you were learning to play chess, would you learn the rules and start practicing or would you immediately change the rules to suit your organization’s current culture?

    • Hi Erik,

      Thank you for your reply. In my opinion, a “by the book” approach will rarely work. You always need to adapt to the context of the organisation. The difference with learning chess is that you don’t have an existing context. The rules of chess aren’t flexible, where Agile is meant to be flexible. I see Agile/Scrum as a set of good practices and you need to pick the ones that apply in your context.

    • What do you mean exactly by “just choosing scrum” and “by-the-book” ?
      If that implies what I fear, doing exactly what is written down in a book about Scrum, I fully agree with Jeroen, that is bound to fail.
      The concept of an Agile work process is oriented towards the flexible (hence agile) attitude, being able to quickly, efficiently and effectively respond to changes coming from either outside or within the team. That to me indicates you need to take “the book” as a guidline, try to make those things that work for you work effectively for you. Those items that do not work, you adjust to make it work for you, your team and your organization.

  3. Pingback: Five Blogs – 21 April 2012 « 5blogs

  4. As you said: It’s not that ‘agile’ fails, it’s the consultants who fail at introducing it and the companies at implementing it. (In other words: The communication seems to be broken.)
    One wonders what the reasons are, in the cases you describe.

    When you say “… they are too expensive to stay for a long period of time”, I wonder against what the expenses are compared (& the ‘too’ to me implies a comparison to … something).
    I think telling people how something is meant to work (even if demoed with agile games etc.) is not enough to actually make it work in the given context (of people, technology & techniques they use, existing management…).

    Last but not least: I often hear that there’s no time for test automation, so testing has to be done manually all the way. 
    I often react by stating that there’s a good chance that it could be the other way: With automated tests that cover the mechanical/checking there might be more time to do better testing overall, manual testing included.
    Whether it works that way or not depends on the circumstances of course: The team members, what they’re working on, the tools they have, in how far theyre allowed to use/change tools they use to create the software.

    • Hi Stephan,

      I share your wondering about the “too expensive”, but is a quote I hear in many companies. I think a great part has to do with the value add of these consultants. What often fails is the expectation management of these consultants. They promise the world, but “forget” to put it in a realistic time frame. I agree on your statement that telling how it’s supposed to work is not enough. There really is need for coaching!

      Your comment on automation is exactly the reasoning I mean when I talk about defining a business case. Thanks a lot for sharing your comments!

  5. The comments on this article in the Agile linkedin group :

    Steward Copper • I believe that Agile is the best approach for software development projects. But the problems described in the given article may really happen. Lack of documentation result in problems during the maintenance period… Lack of project management and test management in large projects may result in project fail… Bad processes and poor stakeholders involvement may be added to the list… Low flexibility of PM tool or no PM tool at all should be mentioned too… But all of that problems can be solved or mitigated if to plan then to solved – create proper processes including maintenance phase in a workflow, split large project into parts, use flexible tool (like Comindware or Redmine) and so on. I still vote for Agile to be the best!

    Jeroen Mengerink • I still believe that Agile is good too. The only problem is that the problems I described in the article appear more often than you would think. One of the points that I try to make is that Agile/Scrum just doesn’t fit in all contexts. So either change the context or don’t try Agile/Scrum.

    Richard Lessard • Good article. I thought the insights re “after the consultants leave” and test automation to be particularly salient. Many organizations cannot adapt wholesale to agile without at least going through a number of management and cultural paradigm shifts. I particularly would expect that the egalitarianism inherent in the agile-team-role concept is absolutely frightening to managers (and many workers) who are accustomed to orthodox hierachies of authority.

    Alan Hines • The most important point made in your article is what you called the “helicopter view”; the ongoing need for architects who understand the complex interactions between systems to maintain technical sovereignty over the integrated whole, lest the entire thing become radically destabilized as a result of the propensity of NON-technicians – the manufactured “product owners” $crum installs and puts in charge – to immediately come to think of “story points” as the conceptual equivalent of Legos: Singularly self-contained and isolated blocks of software, able to be moved around from any one release context to any other; assembled, broken out and reassembled at their whim, without impact or consequence – and solely in the service of the “burndown charts” by which they’re measured. No conception whatsoever of dependencies, or the immense effort incurred across multiple teams whenever anything about the context of the future-point-in-time they’re targeting with their development changes out from underneath them – which happens constantly. I’ve met several “product owners” who couldn’t even grasp that thisRelease is built atop theLastOne; they think everything’s developed from a blank slate, every time. And yet $crum promises they too can somehow not only become competently sovereign over even the most massively complex and large-scale software engineering projects, they can trivially bend them to their will. It’s a large part of the reason why $crum Sells, hand-over-fist (or used to, anyway, before the current long-awaited backlash [and resulting scramble-panic rush to try to productize Kanban]) – and it is absolutely ruinous.

  6. If you think it will fail, why take the trouble for being Agile or Doing Scrum.
    Let the expensive consultants go work somewhere or become jobless…
    Why don’t we create another framework that fits into all context and can be changed to cover up dysfunctions of all the context

    • I don’t think Agile will fail, as I stated at the end of the post. Just be aware of the context! When you find an approach that works in all contexts without the need for adapting it, please let me know. At the moment, I prefer the Agile way of working!

  7. Pingback: Why test “by the book” « Martijn de Vrieze

What do you think of this post?

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s