Micrognosis: A Pre-Agile, Agile Story

MICROGNOSIS (www.trademarkia.com/m-micrognosis-74145718.html)

I want to share a story from a galaxy far, far away.

It has been on my mind quite a bit of late, as I tell it in some of my agile classes. However, I am unsure whether the students believe me or glean the significance of the story. I usually share it to illustrate a key point around software requirements. I usually get LOTS of pushback in my classes surrounding the “goodness and need” for fully documented requirements in software projects.

And as I unfold the agile approach to requirements (user story based, conversational, acceptance-driven, intentionally incomplete, and, did I say, collaborative?) the class starts turning ashen-faced in disbelief. Particularly attendees who are business analysts, project managers, and testers struggle with the essence of agile requirements.

So, that being said, I thought I would try telling it here by writing it down.

From 1987–1996 I worked at a company called Micrognosis or “Micro” that was based out of Danbury, Connecticut. And no, it was not a medical or pharmaceutical company. The history of Micro was in the financial trading sector. In fact, mostly in the front office part of that business – providing complex trading stations for financial traders. And the company is no longer with us, but that is another story.

If you have ever worked with financial traders as customers, I would argue that they are some of the toughest customers—period! They were demanding to the point of obnoxiousness, and not just the New York based traders ;-). They had lots and lots of money to spend, but they expected to get the ‘world’ for their purchases and investments. They often operated 7×24 and expected their vendors to do the same. And the attitude and language – let’s just say, it would not be well received in my current location in the South.

Engagements

Our typical engagement at Micrognosis was to sell our clients a “trading floor”. That would include all of the desktops, displays, video sources, digital sources, and cabling and networking infrastructure to distribute trading information to their individual traders. For example, I remember we sold JP Morgan a +800-seat trading floor on 60 Wall St in the early 90s. It was one of the largest trading floors at the time and a real coup for us. I believe the price tag was a base of US$40 million, which was, for Micro, more than we had made in the entire previous year.

And the way we structured our deals was as fixed-scope, fixed-date engagements. The clients would often schedule their traders to move and be ready to begin trading on our go-live dates. Moving the dates was physically not an option, as people were coming into work AND they were expecting to be able to make money for their firms. Rarely was there a fallback or contingency plan. Risk had to be anticipated and contingency integrated in as part of the overall execution plan.

And failure was literally not an option.
The Bottom Line
The way we structured all of our deals was with heavy contractual penalty clauses if we “failed to deliver”. And, since most of our clients had oodles of money and attorneys, the penalty clauses were huge. If any one of them had triggered, it would have destroyed our company. And no, I am not exaggerating here. Because of the nature of our engagements and the industry, we had no choice but to compete in this:

  • Fixed date;
  • Fixed scope;
  • Fixed performance;
  • Be able to make the same amount of money on go-live date universe.

And not simply compete, but win.

The Reality

But the reality was different. Yes, we signed off on these contracts. But here is the interesting part of the story:

First, we never delivered on 100% of any contract’s scope requirements

And, second, we were never in violation of our contracts. Or, put another way, our customers never once sued us.

So, here is the question, how can that be?

Here we are dealing with some of the toughest, most demanding clients on planet Earth. And we had signed an ironclad performance contract. And we were clearly in violation of the “letter of the law” of that contract.

But nothing happened. And, even stranger, our customers were “happy” with every one of our deliveries. In other words – they made their money on their go-live dates.

So, how did we do it?

In hindsight, I think we were incredibly agile. Amongst a relatively wide variety of tactics, here are three key things we focused on:

  1. 1. We never simply followed the contract or the defined scope. Instead we would continuously interact with our clients and try to understand their needs for their go-live date. These were always different from what we had captured in the contracts. And we relentlessly pursued this understanding from contract signature through go-live.
    We never rested with the false belief that we understood exactly what they wanted. And these conversations were not solely done via email and document exchange. We put a real premium on face-to-face conversations. And sitting with our clients as they traded – so we understood exactly what each of them needed to be successful.
    We collaborated face-to-face with our customers in real time to clearly understand their specific needs to get their jobs done. And if the needs were different from the documents, we adjusted towards their actual needs.
  2. We had a strong team of developers and testers who fundamentally understood the financial trading market. Heck, some of our developers were part-time traders. And these teams had been doing this for quite awhile. We had a very solid understanding of our business and technical domains. We maintained low attrition and high energy with a servant leadership model and one where the teams were largely self-directed.
    We paired, worked in small groups, continuously iterated, and interacted with our clients and DevOps staging environments. We focused on high quality solutions that were resilient. Even to this day, I hear from former Micrognosis colleagues who found it to be the pinnacle of their technical teaming experience.
    We hired great people, we valued and retained them, and we empowered them to do what it took to deliver on the goals of our customers.
  3. We relentlessly tested. I cannot say it any other way than that. In fact, we would set up our client networks – not a simulation, but their exact infrastructure – in our Danbury facilities. We would test iteratively for functional and non-functional performance. We would set up individual trader positions and even test the data sets and applications that each would receive. By the time we shipped the systems to the client site, they were fully qualified. Dare I say it, the Engineering and DevOps teams worked side-by-side to deliver well-engineered systems that simply…worked.
    Were we perfect? No. But we collaborated fully across all teams and functional groups that were involved in delivering working systems to our clients. Think concept (client contract) to delivery (field operations) here as our value stream.
    We relentlessly simulated our customer environments (systems, applications, data, performance requirements, etc.) as we iteratively built customized systems for them.

Sometimes people challenge me and imply that this is not novel, nor does it sound very hard. I respectfully disagree with them. Micrognosis had to work very hard to be successful and our agile behaviors were key to our successes. It is just too bad that we did not have a sexy methodology to tie to our efforts at the time.

Wrapping up

I remember my time at Micro quite fondly. We had a great group of employees who worked their “tails off” to delight our clients. But, beyond that, we became intimate with the market and with our clients’ needs. That needed to be a relentless pursuit and we were incredibly good at it.

And, once we found out what they needed, truly needed, to solve their challenges, we were focused in our design of high-quality systems that we assured would exceed their expectations and needs. Every feature we delivered was designed, implemented, and tested with the client’s environment and direct needs in mind.

We did not implement something because a document said to. Instead, we asked, collaborated, iterated, and sought to understand what was truly needed.

I am incredibly proud to have played a part in it for as long as I did. Finally, to all remaining Micronaughts wherever you might be, I wish you peace and slightly “nicer clients”.

Stay agile my friends,
Bob.

Postscript

Micrognosis was initially independent, then acquired by CDC Corporation. CDC sold the company to CSK, a Japanese firm. They renamed it as CSK Software.

Along the way, the company acquired many small companies in this space, including Quay Financial Software out of Dublin and FD Consulting out of Staten Island.

Micrognosis ‘dissolved’ around 1998–2000 as a viable entity.

Bob Galen

Bob Galen is President & Certified Scrum Coach (CSC) at RGCG, LLC a technical consultancy focused towards increasing agility and pragmatism within software projects and teams. He has over 30 years of experience as a software developer, tester, project manager...
Read more about Bob Galen