This topic gets more & more popular these days - many people on the internet discuss agile methods adoption on Enterprises, words Agile & Scrum finally got their buzzword rank - corporate people still don't understand what really stands behind those words, but they want to bring them on-board anyway. And that creates another, perfect niche for weaseling leeches, willing to sell even sand to bedouin.

Sadly, adopting Agile (or Scrum in particular) in Enterprises as I know them is not that easy. There are several constraints that prevent or at least impede such efforts. And my goal in this post is to list them down. To keep things as brief (& clear) as possible I'll focus on Scrum only - but by Scrum I mean real Scrum, not just enriching your ol' good waterfall with daily stand-ups ;P

Here we go:

App != App

There are many significant, practical differences between a typical Software House (let's call it SH) that produces an IT product offered as COTS (commercial off the shelf) or SaaS (software as a service) and an Entprise (let's abbreviate it as EN) from a different industry (like Insurance, Telecom or Banking) that has IT capabilities for its own purpose:

  • SH produces a somewhat generic product that is supposed to meet average client's needs, usually it doesn't integrate it at all; at most SH provides integration options -> impact on testability is obvious (integration is usually the most troublesome & expensive aspect of testing - the more of it, the biggest pain)

  • it's far easier to keep the SH's product portfolio withing reasonable limits than to control ever-growing IT landscape of EN: majority of SHs has just few products that are regurarly updated / improved or just replaced with new, better products; In EN, what gets in, stays in forever - mainly because:

    • it's not only codebase, but also data (that has its inertia to move)
    • the services provided by EN are usually spanned between IT products: removing something from the chain is hard, expensive, requires a lot of regression testing and in the end: business people rarely understand the reason of expense (IT maintenance costs? No my stuff).

  • SH knows its products far better than EN - in EN, there's usually a mixture of custom development, packaged development, system integration and hell knows what: some are outsourced, some developed locally; some are regularly upgraded and some smell that bad that no-one wants to touch them (sometimes no-one CAN, because of some contractual reasons) -> that's why tech debt grows far faster in EN and it's increasingly more expensive to keep in check.

Based on practical experience: EN has much more products than teams that develop & maintain them. They don't work on all of them in the same time, but change them ad-hoc, based on current needs: that doesn't help with ownership & impedes seriously the quality of changes (due to limited knowledge & time for tech debt reduction).

And how does it all impact potential Scrum adoption?

SH has a much better control over their products - it's far easier to keep the technology uniform & up-to-date, to introduce changes in-sync (because those do not span across 20 applications...) and to analyze the impact of change on the whole landscape (what do I have to re-test if I change that).

That's one of the reasons why SH can keep stable (releasable) versions of their products and many of EN have to perform extensive, wide-scale regression testing what seriously impacts their ability to release the functionality frequently.

Curse of the Pharaoh

Those above are big & serious problems, but big cannons are still about to appear:

The legacy in EN, I mean The REAL, PAIN-IN-THE-ASS LEGACY in EN. The heart of large EN is its core system(s). Absolutely business-critical, efficient, integrated with everything, rock-solid and stable as a glacier. But ... everything comes for a price: vast majority of these core systems have been produced decades ago, in ancient technologies (mainframe-based or similar crap). And what does it usually mean?

  • the legacy tech are absolutely outdated and they didn't adapt modern software development practices like unit testing or continuous integration
  • the resources for legacy tech are physically limited - a developer can't have his own, exclusive environment; some ops have to be performed by external resources (additional dependencies) and release process is far from being transparent
  • the agility of introducing a change on legacy system is laughable (due to ancient tech)

And how does it all impact potential Scrum adoption?

Legacy can't be tested in an automated way, legacy can't be put in CI loop - there's a long feedback loop for legacy code.

Legacy code can't be easily re-factored, it's module / component distribution (if any) is historical and frequently doesn't have much in common in current EN reality (or even worse, somehow impacts it in negative way). Dependencies are barely traceable - due to core system's typical size (and usually, a monolith-like structure), it's very hard to analyze the actual impact of the performed change: what has to be tested, what may stop to work?

What's even worse - as legacy is so tighly integrated and critical in any processing, other apps / systems can be barely tested without legacy. And if legacy is constrained with resource availability (for instance: developers have to share instances), it pretty much kills automated testability or error trackability of every considered app. If you're persistent, you can end up with mocking mayhem.

If the IT landscape is so complicated (there are so many apps based on different technologies), creating an cross-functional, independent, stable (rare person swaps) team is a myth as well.

Grey area of so-called ownership

ENs offer services.
Services are delivered by executing processes.
Processes utilize IT systems.

The problem of ENs is that:

  • usually it's far easier to find a business owner of service / process than a business owner of an IT system
  • when there's a change request or just a business idea that will be used to shape a change request, its origin is usually in service / process, not product

As a result - when there's a project to happen:

  • one product may be modified due to requirements / vision from owners of many services / processes
  • project may involve modification of several systems in a synchronized way

And how does it all impact potential Scrum adoption?

Product Owner (PO) role doesn't make much sense from business people perspective, because systems contribute to many processes for different business units - in practice, it means that in such case PO should be an IT person, not related to any of interested business units. And that kinda kills the PO role in ENs, because it takes all the decision power from them - they are being reduced to the role of mediators.

Projects that span between several systems create dependencies between teams and it's far, far harder to split them into short chunks that can be released alltogether. The scalability of Scrum is like a religious myth - some believe it and some not, but have anyone seen it really working in a non-trivial EN scenario before? :P

The Litany continues...

The list is much longer and there are other, complex factors that may prevent ENs from adopting Scrum:

  • synchronized programs (that involve several projects) require a high level of predictability and scope + time commitment
  • if core business of EN is about life&death matters (medical stuff), large flows of money (so it could impact the overal economical stability of other large ENs) or other highly criticial area (nuclear plants, pollution control) - test regimes required may not fit the Agile paradigm as well
  • and many more...

But many of these additional factors are just about higher effort and switching the mindset of people, while the main ones from the list above (huge and interconnected IT landscape, legacy arch, large process vs system discrepancy) can't be fixed in that way.

Does it mean that ENs are screwed?

Not really. Scrum just isn't for everyone: it requires deep, thourough, cross-unit EN-wide changes and brave architectural decisions that alltogether are:

  • very expensive
  • time-consuming
  • and risky (the avalanche effect, big bang transition, etc.)

In the end, there's no guarantee of success.

What then?

Instead of Agile, ENs can go Lean.
Instead of burning down and re-building on ashes, evolve.
Instead of introducing new processes, continuously improve existing ones.
Instead of forcing methodology that has been carved in stone, come up with your one - shaped up for your EN.

If you want to learn more about that - I highly advice you to look into David J. Anderson's work - he has written a lot about this particular topic.

Share this post