My professional background is all rooted in Banks. Back in 1988 I started my own software firm, FastWrite, still working at the Generale Bank for about 9 months. Not surprisingly, the first client of FastWrite was the bank. Why is that?

Mostly because the bank was unable to deliver in a timely manner what the Business expected. For 9 months, FastWrite had delivered more software to the bank than what a team of 5 had delivered in 3 years time within the precinct of the bank.

What, for FastWrite, made the difference with the bank?

What was different at FastWrite is how the communication flowed between the members of the Team and how needs/requirements were captured, elaborated and turned to evolutionary working software, little by little, using our own tools (The Builder, a screen generator, and DoIt! a general purpose library of about 2000 routines), constantly in use by our Dev Team and always checked by our Business: even our developer tools were sold as by-products and therefore grabbed the interest of our Business. That's how we knew it was working software.

FastWrite didn’t work only for banks. Between 1989 and 1993, FastWrite released 3 software collections to the market: “I Manage…”, “I Wish…” and “I Learn…” selling about 300000 copies on 3 continents only for the “I Manage…” stuff. All software was created in "Agile" mode, despite the fact that the term was completely unknown to us. What was the common denominator then was how close we were to our Business (mostly our sales persons, clients and beta testers), how often we released new versions to them (every 2 days or so), how we listened to them when they said “Stop, it's good enough for us. We can already sell this!”, which is by the way the perfect incarnation of “Good Enough” and “Release On Demand”.

When things got a bit hard to program or to debug, we often paired to see what the problem was and it was often resolved by simply explaining what we faced to fresh eyes and ears: our chap was coming to our desk because we had no network at that time! Seriously! That's why we were kinda forced to pair!

On top of that, we were testing our material constantly. You know why? Because I speak of a time when the Internet was not prevailing as it is today and, for us, “Going LIVE” was something we did with extra caution because it was costly: we speak here of a physical release implying the creation of a real packaging, duplication of our master copy, assembling all parts together (the jacket, the registration card, putting the labels on the floppies, …, packing everything in boxes, delivery to the points of sales, etc.). This is not an operation you want to mess up! Too costly! Didn’t I tell you?

All of this leads to Extreme Programming even though it was a long time before Extreme Programming led the march of the Agile methods. How many of you recognize some of the very practices of Extreme Programming here:

• Pair Programming
• Test Driven Development
• Continuous Integration
• Small Releases
• Close Relationship with the Business
• …

We also invented a new testing method that we called Chaotic Testing: testing at large with no plan! That’s how we came across the concept of AMIS, Anomalies, Misses, Inadequacies and Suggestions. Later on, I have learned from a friend working at Microsoft that they basically did the same kind of thing when releasing a product like MS-Word for example. For the ones interested in that, chaotic testing is a method that has 3 prerequisites and 12 rules. It bases itself on the fact that if you test long enough with enough people, you will have tested your entire system better than any formal testing method can do (More about that in our article: Chaotic Testing).

By the same token we tend to think we have invented, at least, the ancestor of the Wiki. It was known as Dynamic Help in the “I Manage…” collection: Shift-F1 simply triggered the possibility for the user to enter, at the place the user was, his or her own help. By sharing the same PC (a situation that was not uncommon at that time), users were capable of “leave” messages (or guidelines) for the others. That was our way to invent a sort of feedback loop between the users.

I became aware of Extreme Programming only in 2002, when I worked for Viveo Cognitive Systems. Viveo was a company that marketed a specific range of banking products all aimed at providing Swift messages solutions (somewhat expert systems or basic artificial intelligence). I remember a period where Viveo entered an RFP for UBS with competitors such as IBM, Tibco, Mercator and SeeBeyond.

At that time the technical challenge for our team was to be able to treat 1.6 million Swift messages per day to program a compliance filter (right after September 11). IBM reached ±800.000 messages/day, SeeBeyond reached ±600.000 messages/day, Tibco reached ±450.000 messages/day, Mercator … I can't remember, and Viveo roughly 1.000.000 messages/day. We beat the competition but we were still far away from the target!

UBS left us some time to reach the target because they envisaged gradual load of the system and 1.600.000 messages a day was not their primary objective. Our team of 5 rolled up the sleeves to attain this objective.

After multiple refactorings and multiple spikes we reached the incredible amount of 1.750.000 messages … per hour (for example, we completely rewrote an XML parser in C using the Boyer-Moore algorithm, which required a spike; other example: we programmed a viable alternative to the Base64 encoding method, which of course required spiking). Did we use Scrum? No, not so! We were a team of 5 working the XP way (Jean Bourdin, Edwin Cheront, Jean-François Noury, Greg Sovaridis and myself) always driven by Technical Excellence: we had “constant discussions”, some passionate and very emotional, we had a battery of more than 300.000 test cases that we injected in the system (we wrote two tools like “The Composer” and the “Reader” to do just this ―testing―, which by the way were sold as by-products), we created a “Cardio” application to constantly monitor the health of the global system (how is that for a feedback loop?), which also turned to be a by-product and which we developed further into an automatic testing station (the Cardio was capable to reconcile expected output and observed output), “on-the-spot-dry-runs”, etc. : the team will surely remember! After some time, it became common practice to have these runs on Fridays! It sounds like a weekly demo, doesn’t it? You bet!

In SAMBA — our own Scaled Agile Model — we try to reunite the practices of Extreme Programming and Scrum. Why? Because like Robert C. Martin expresses (and Martin Fowler also to a certain extent), what remains of Scrum today is simply Project Management stuff. The technical aspect of the Agile methods has been deserted in Scrum. This is what Martin calls “The Land that Scrum Forgot”.

One should not forget that the Agile Manifesto started from the will of Kent Beck (Extreme Programming) to reflect about the lightweight methods/processes and that many practices were rooted in some technicality such as refactoring, test-first approach, pair programming, and the likes.

It would be a very good idea to reclaim few of the agile values and principles: Extreme Programming Practices. By the same token, it's a nice opportunity for me to also point you in the direction of the Manifesto for Software Craftsmanship.

So, what is now the point with Scaled Agile, because that’s the point we’re at?

The point is that with Viveo, as a matter of fact, we have mostly worked cross-projects! Actually, our Team has created X-Stream, a financial EAI (Gold labelled by Swift in these years, up until 2005 if I recall correctly) that was needed in many projects of the company, in the clothes of a dumb dispatcher, or in the skin of a pretty smart message broker. Our Team had to respond to many changes coming all at once from different sources, typically 3 or 4 at the same time: these changes for bank A, those changes for bank B, etc. How do you manage to keep in synch? How was our team supposed to immerse itself in so many projects simultaneously?

Well, we actually worked in a Kanban mode, pulling things from our Wish List (pardon me, Product Backlog) in the order I have fixed the priorities (in my role of Core Technology Manager) (“Product Owner” in Scrum). There was nothing like iterations but we had weekly objectives and each week was punctuated by a Dry-Run (sorry … a demo). Each week we had a new version of X-Stream, a version that brought value, Business Value in the broad sense of the word, not only functionally but also technically (which we called our Harmony Degree). Each version that was produced was strictly compatible with the previous, something more difficult to do in C than it is nowadays with Object Oriented Languages. This topnotch compatibility was the very ground of the evolutionary design of X-Stream.

Because of this weekly delivery on a Help-Yourself Shelf (the projects that wanted to get the latest version of X-Stream simply needed to pull the thing right off the shelf), we could completely decouple ourselves from the own rhythm of the projects we were serving. The very same concept is what we defend in SAMBA, even though we can also accept to work in cadence like SAFe requests.

The point is exactly there: you must keep the DevOps Teams independent as much as you possibly can. Should you fail to achieve this, then you will catch yourself creating many handovers that need to have a lot of synchronization. Take my word for it.