Let there be no doubt, I truly believe that Agile software development is always and everywhere applicable. Ultimately Agile is built on the foundations of feedback, learning and change. Given this, the Agile principles can be applied in any environment because we try, learn, adjust and try again.
However, in the last year or so I have worked with a number of teams that are attempting Agile in non-traditional settings. The problems which these teams face is not that Agile principles are not applicable, nor that the feedback cycle is doomed to failure; but rather, outside of a certain Agile sweet-spot there are additional barriers and costs to applying Agile techniques. None of these obstacles prevents Agile in itself but each increases the cost of getting to Agile.
The teams I have been working with are a long way from actual customers - they are working in highly hierarchical organizations with non-OO languages.
Agile sweet-spot
The Agile sweet-spot is the place were the software industry as a whole has the most experience with using Agile methods. Normally it is a Java or C# environment, normally a web-based application, not embedded, normally fairly close to the eventual end-users or actual customers.
Team sizes are usually fairly small - under a dozen people all in - but experience with large teams is growing. While teams may include elements of distributed - or dispersed - workers the core of the teams are located fairly close to the end-users.
There are many who would claim greenfield projects are the Agile sweet-spot. I beg to differ, I have always found Agile easier to apply to existing systems. The important things is that today there is enough experience to do either type of development with Agile.
The sweet-spot is not the only place Agile has been seen to work, only that it is the place where there is the greatest knowledge. In this sweet-spot there is a virtuous circle, more experience creates more success which creates more opportunities to gain experience.
The further a team is from the sweet-spot the greater the additional investment required to become Agile and the greater the risk of making any changes.
Engineering practices
When asked where a team should begin with an Agile adoption my answer is always: quality. If a team cannot improve quality enough to ensure that at the end of an iteration a piece of work is completely done - golden seal, bug-free, ready for deployment - then sticking to a credible iteration schedule is going to be close to impossible.
For teams in the Agile sweet-spot there is a lot of accumulated knowledge, case studies and, most importantly, tools to do this. Take Java for example. We have JUnit, JMock and FIT for testing. Eclipse and IntelliJ provide powerful development environments with easy to use refactoring tools. There are many books, journal articles and blogs describing how to use these tools.
This situation does not prevail for teams using C, COBOL or SAP for example. Theoretically there is no reason why TDD and other practices cannot be undertaken in these languages. Ultimately all computer languages are Turing-compatible, and since we could imagine a testing framework for a Turing machine it is entirely possible to undertake TDD here.
But, these languages are outside the sweet-spot, and knowledge of how to do this is scarce. Yes there is a COBOLUnit and ABAP Unit (for SAP) but there are few examples of their use, there are few questions on forums about using these tools and there are no books or case studies available. In short, there is no shared community knowledge of how to use these tools effectively.
Each language provides its own set of challenges, some technical and some cultural. SAP developers for example, shun the idea that they program - SAP, they say, is "configured". True, a lot of SAP is configured through system options, tables and such but this is just programming in a different form.
Modern COBOL includes many features - like objects - that can provide for Java-style unit testing. But, almost by definition, the major COBOL systems that exist are legacy systems that pre-date these features, and have developers who have little experience of using them.
Traditional COBOL uses a dynamic linker that offers the tantalising prospect of automated TDD, but again the legacy codebases get in the way. Legacy code is not itself the block, the problem here is that much of the legacy was developed before ideas of data-hiding, cohesion and coupling because well established and widely used.
Nor is there an active Open Source community to provide tools like there is in Java and C#. Unlike Java and C# developers, COBOL and SAP developers are unlikely to have the development environments to create tools in their own time. And the organizations that do are unlikely to allow such work to be released as Open Source.
Further complicating matters, with older technology, vendor lock-in is still an issue on COBOL and SAP systems. Swapping, say, your source code control system for one with better CI support may not be easy.
Of these languages, C provides perhaps the most promising outlook because (a) C developers are active in the Open Source community and (b) it should be possible to borrow the unit testing tools from C++ - possibly the Cute or Aeryn testing frameworks. However again there is a lack of knowledge on how to do this.
The net effect is that while we could do many Agile practices in C, COBOL and SAP we lack the knowledge and experience. Any organization that wishes to take this road must pay a higher price to break new ground, build new tools and create new knowledge. They cannot download an existing toolset, or recruit consultants who have done this before.
Whether discussing Test Driven Development, Acceptance Test Driven Development, Continuous Integration, Refactoring or other engineering practices these same arguments apply. Legacy technology does not prevent Agile but it increases the cost and difficulty. While isolated cases can, and do, exist, so far most organizations have found the barriers too high.
Management practices
While the engineering practices present real limitations for Agile, the management practices don't look so negative a first glance. After all, stand-up meetings and short iterations don't need technology.
Without tool support it is hard to know when a piece of work is completely done. Unless work can be completely done, it is impossible to keep meaningful fixed-length iterations. Carrying work from iteration-to-iteration, again-and-again, reimplements the code-test-fix-test cycle and there is no certainty when work will actually be completed. This in turn leads to pressure to increase the iteration length, jeopardising the short cycles and frequent feedback.
Multi-disciplined, cross-functional, teams are another management practice in Agile. Having people work on what is required next rather than only in that area in which they specialise ensures the highest priority work is done and evens the workflow. Yet this too is difficult with many legacy systems.
While staff who have been with the system for a long time may well be keen to learn new techniques - or in some cases resurrect lost ones - the same is not true of younger staff who may be reluctant to work on old technology. Even when the technologies in question are close, like C and Java, I have seen staff refuse to work with the older language for fear of being drawn in.
The legacy nature of much COBOL and C doesn't help either. To be proficient in a large system may require months, even years, of experience. It may be unrealistic to expect an experienced COBOL developer to jump in and start making changes overnight to part of the system they don't know.
With SAP the situation is more complicated still. While SAP market their systems as common, the reality is that different SAP modules require different skills to implement them. SAP HR is different to SAP Financial, which is different to SAP Logistics, and all of these are different to ABAP, the underlying COBOL-like language. Asking a developer on a SAP module to work on a different one can be akin to asking a C# developer to work in Erlang.
Another complication with SAP is the business model operated by the eco-system. SAP implementation projects are not normally a core competency for a corporate IT department, so they bring in consultants from multiple consultancies to implement different parts of the system. The consultants and their employers expect them to work with their core, named, SAP skills and not venture into other modules.
Thus, for a collection of reasons multi-functional teams are more difficult to create than may be the case on a Java project were developers have grown up with SQL, HTML, Python and Unix too.
Phew you might say, at least stand-up meetings survive. Well, perhaps. In an effort to reduce wages many legacy shops have distributed their maintenance operations both geographically and organizationally. SAP consultants can be in short supply, with the result that they clock up lots of frequent flyer miles and regularly miss days or half days. Finding a convenient slot for a stand-up meeting can be hard, and when they do happen they may well be sitting-down with a telephone handset.
As if that weren't enough, the cost obsessed nature of many big organizations means the question "What have you achieved?" is most honestly answered with "Clocked another eight hours of billable time." Such cultures lead people to focus on inputs and costs, not output and achievements.
Another characteristic of large legacy system is the degree to which the teams are cut off from real customers. Mainframe system may well be hidden from end customers behind more modern front-end systems intended to shield users from the green screen.
With layers of technology insulating the legacy system, the team too is hidden from the business and the business hidden from the developers. It becomes very difficult to know where the value is, what the business wants and just what is the simplest thing that could possibly work.
Releases
Finally, there is one practise that falls into both engineering and management practices: frequent releases. In the Linux and Windows world releases have become cheaper, but performing a release on a mainframe or SAP system is still an expensive operation. Many of these systems are operationally critical to the organization, so every release carries extreme risk. This creates pressure to reduce release frequency, not increase it as in Agile.
Some server environments get around this problem with multiple systems. One is live while the second is readied for the next release. Switching to a new version of the software simply involves pointing at a different box and the cycle repeats. On a mainframe or large ERP/CRM systems hardware and license costs may well block this approach.
And other languages?
I have focused the discussion on C, COBOL and SAP but I have no reason to believe the situation is very different with other languages. In fact, I would expect in many cases the difficulties to be greater still because the likes of Pascal and PL/1 represent a smaller installed base than C and COBOL so the available knowledge is less.
The Oracle Applications suite is, to a much greater degree than SAP, the result of mergers and acquisitions. As a result, each application may need to be considered as its own case, and cross-skilling is even more difficult.
The boundary of current knowledge is represented by C++ and, perhaps, Visual Basic 6. There is just enough knowledge, and just enough tools, to do CI, TDD and refactoring in C++ but it isn't half as easy as in Java. Newer languages have more support, while older, non-OO languages have less.
Procedural languages are always going to be more complex to work with because they lack dynamic dispatch. It is easy to forget how much procedural code is of the “IF x THEN do Y” nature. OO and dynamic languages make it much easier to change the control flow for testing purposes.
Is it worth it?
None of these difficulties alone prevent Agile, but each raises the cost. Taken together they represent a significant, and expensive barrier. Naturally sooner or later someone should ask: does the cost outweigh the benefits?
It is impossible to give a clear-cut answer here, the only answer is: it depends. There are two factors that need to be understood before all others:
1. Is the system likely to be around for long enough to recognise the benefit?
Since new SAP systems are being built and installed every day the likely answer here is Yes, they will be around for some years. For legacy C and COBOL systems, organizations need to take a view on life expectancy. In some cases the answer will certainly be No. For all the hype and promise of Agile, if a system will be end-of-lifed in the next two to three years its probably not worth doing anything.
2. How well is the current process working?
Given that some of the system under consideration may well have existed for 20 or more years it is likely the development process and practices around them are - provided they have been allowed to grow organically - fit for purpose. If you have a legacy system and teams which delivers when required, why change?
That said, given changes in the business environment, corporate strategy or even technology, continuing with the status quo might not be a viable option. If an organization find that its mainframe development process cannot deliver the required changes in the necessary timeframe, then something needs to give.
Agile is not a cure-all. Agile may help improve a mainframe shop but its benefits are limited. There is a reason why few new system are created in C, COBOL or Pascal: newer languages offer more. Ultimately an organization will need to change its technology.
Conclusion
While Agile may always be applicable, it might not always be appropriate. That does not mean that the Waterfall is automatically the right solution. It could be, but personally I have never seen the Waterfall work the way it is supposed to and don't believe it ever does.
I am not saying you cannot do Agile in COBOL, or any other language or environment - I believe you can. But I am saying it won't be Agile as we know, and I am saying it will cost. You will in effect have to invent a new Agile based on new knowledge.
Readers of this article may know of cases were the obstacles I have talked about have been overcome - and I look forward to hearing about them - but one swallow does not a summer make. Taken together, and as a whole, there is a lack of knowledge and understanding about how to apply Agile in these environments. It is not enough to have one or two case studies, we need dozens; it is not enough to have one presentation on TDD in COBOL, we need mailing lists to debate the subject as well as training courses and books.
Some advice
More and more organizations will want to try Agile outside of the sweet-spot, so let me close with some recommendations.
If you go down this path, remember that you are blazing a trail, there is no predefined path to follow and you will take some wrong turns and go down some dead-ends. This will all add to the cost.
Don't expect Agile to work overnight. Just sprinkling Magic Agile Dust on your project isn't going to work; you need to put in some elbow grease and money.
Find and hire people who have developed the tools used in the sweet-spot. It is easier for a Java programmer to learn COBOL than it is for a COBOL programmer to learn TDD. While many developers have used nUnit, JMock or CruiseControl, few have the skills to create such tools. Such developers who can cross the modern-practices/old-technology divide will not come cheap so don't cut corners.
Open up, share your efforts and tools. Publish case studies on the internet, make the new tools available as Open Source and find others willing to share development with you - or even just find people willing to test your tools. Either way your own future recruitment will benefit; firstly because people will respect you, and secondly because some people will already know your tools.
Management practices like stand-up meetings and iterations are the easy bit. Don't call yourself Agile just because you have a few of these. Without the engineering practices to back them up, management practices have very limited value. So start with engineering practices, improve code and delivery quality before doing the easy bits. Only by embracing engineering practices will the management practices make a significant difference.
Finally, don't see this as a project or an initiative. It is a new way of living. Projects and initiatives end. Being Agile is to be always be changing and improving.
