18
Feb
Micrognosis: A Pre-agile, Agile Story
No Comments Agile Project Management, On Agility agile requirements, customer collaboration, customer value, just enough, just-in-time, mitigating risk
I want to share a story from a Galaxy Far, Far Away.
It’s been on my mind quite a bit of late, as I tell it in some of my agile classes. However, I’m unsure whether the students believe me or they 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’d 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’s another story.
If you’ve ever worked with financial traders as customers, I’d 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; lets just say, it wouldn’t 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 & 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 90’s. 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 $40Mm 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 planned 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 triggered, it would have destroyed our company. And no, I’m 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’s the interesting part of the story:
First, we never delivered on 100% of any contracts scope requirements
And second, we were never in violation of our contracts. Or put another way, our customers never once sued us.
So, here’s the question, how can that be?
Here we are dealing with some of the toughest, most demanding clients on planet Earth. And we’ve signed an ironclad performance contract. And we are clearly in violation of the “letter of the law” of that contract.
But nothing happens. 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) 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 to 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 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 can’t say it any other way than that. In fact, we would setup 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 setup 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 isn’t 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’s just too bad that we didn’t 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 testing with the clients’ environment and direct needs in mind.
We didn’t implement something because a document said to. Instead, we asked, collaborated, iterated, and sought to understand what was truly needed.
I’m 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 to 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.
No Comments Agile Project Management, On Agility agile requirements, customer collaboration, customer value, just enough, just-in-time, mitigating risk