It was not a French Riviera but it had all the exotic elements in it to make it seem like one. Each floor of the vast expanse above the Atrium had a refrigerator full of juices, beverages and chocolates. Every weekend, popcorn would pop in the huge dining room of the company with a fun filled activity in the Atrium adding color to the environment, with a swimming pool glittering in the background.
Sometimes, beer would flow with the music and the dancing spirits was believed to ensure that creativity, too, would keep flowing through the company, until the next week!
The designers — the UI team — were thrilled; the conservative QA would reverentially regard the boisterous celebrations the way the grand dames must have looked on at the changed clothing of women players at the Wimbledon; the developers found it something out of a dream and the heads of departments felt assured that the next fat pay check would reach them like the breeze sans the anxiety!
Into this “All is well that ends well” setting, crept in a stranger, armed with new techniques, practices and rules.
The year was 2005, just around Christmas when folks in the US would relax that the team in India would carry the work forward.
We received an email in the morning that the core product team would be coming over from Denver to present the product road map for the next budget year and, on a new development method called Scrum.
I was the lone technical trainer for all matters related to technology. My responsibility, aside from chalking out the yearly conferences and industrial trips for the employees, was to plan monthly technical training calendars and to devise training on this new methodology being introduced into our product development process.
The presentation began in a packed training room.
The Product Management team introduced the concepts of Scrum.
Scrum was fairly new in those days. The role of Scrum Master was donned by fewer than half a dozen persons in the world and none were in India. To compound the problem, we also had to figure out how to train thousands of employees!
The organization had been following an iterative development model, as was popular in those days, called ‘Agile’.
Our India Development Center housed some 2000+ engineers — developers, architects, testers, SCMs and the support staff.
The product was Mac based and the OS was the Mac OS X with the new Intel-based iMac, that was replacing the Power PC, just around the corner.
The SCM (Software Configuration Management) was a busy team as it had to figure out its deployments (the word was not deployments then but packages, bundles…) and other matters related to the shift in architecture as were the architects and the R & D team on the implications of shifting the code base or making it compatible with the change from Big Endian to Little!
Come to think of it, Jonathan Swift must have influenced quite a lot of brains in the computer world of those days because not only has the egg story of Gulliver’s Travels made its way into the software industry in the form of the Big and Little Endian system, even a programming language got the name Swift!
Anyway, back to the Manderley Scrum story.
The code base was in C++ but the growing needs of an enterprise working on Windows machines and designers and publishers using the Mac had created a need for an enterprise solution of the desktop software (that the product predominantly was) that would be web-based and this need introduced other technologies like Corba — IDLs, Java, .Net and web services into the ecosystem and so, I, too, was busy devising trainings on C#, Java, C++, IDLs.
Technical prowess was high in the organization; agility (there was no such word in the software development lingo then) was not!
Fortunately, there was no community, either, hollering around that this was Scrum and that not so, we had it fairly easy in terms of nobody questioning us on how well Scrum was being used within the organization!
Test-Driven Development (TDD) was just heard about and something that nobody used yet and anyway, agility was not even known in the software development context, as we know it today, in relation to TDD!
The best form of demonstrated agility that I can recall is in how one of the software architects of the core product team would take pride in wheeling the large and bulky Power-PC-based Mac OS on her chair into the lift and through the corridors into the training room! But agility definitely did not even appear in the horizon of an organization’s concern, all that mattered then was the team (s) to have the necessary technical acumen and skills to get the product delivered to market, on time and within budget!
The Chicken and Pig analogy/story was the most popular thing about Scrum in those days and although I, personally, found it childish (Good that the story got banished from the Scrum world), the product teams found it quite interesting and would lap it up like children do upon hearing the Aesop fables for the first time!
This was maximum Scrum for everyone in the organization! Stand-ups conducted and updates exchanged over the email or through audio conferencing!
The QA team was as large as the R & D team but nobody, then, really questioned the size of a team because testing was as integral a part of the SDLC then as was ‘development’ and the time box concept had not yet sunk in as very relevant because the empirical evidence or knowledge was not yet there to be used so team size did not matter because planning was done in the traditional form, over a long period of time and not in terms of time-boxed Sprints despite the newly introduced product road map done the Scrum way because there were no takers for the Scrum way yet!
Even the SCM team was big and they, too, had to shift to the Scrum way.
Scrum was becoming more mysterious, as each day went by, and as suspense filled as an Alfred Hitchcock movie, but interesting!
The IT team was also substantial in size and as such had a large say in many matters!
This meant that even if the SCM team did decide to release bundles by the month, it still had the IT department, that was traditionally oriented, to reckon with.
Another factor was that the IT department also housed the technical and customer support executives, who were then becoming the darlings of the senior executives as India was being projected as a huge base for call centers and so, whatever new methodology was to be used, was not priority!
And since the blueprint of the product roadmap and the Scrum adoption was being driven by the core Product Management team, the implementation strategy was external to the executing organization so it didn’t matter or so it was perceived!
This was a flaw that, like all flaws, was not visible then — a new element introduced but without dispelling the strong influence of the predecessor.
The scope for chaos about to go on a rampage was already there, all that was needed was a push in the right direction for the wrong thing to happen and unwittingly (for the organization, that is), it happened — through the solution.
Chaos elbowed its way in because of Scrum rather than being dispelled by Scrum! Because all the disparate elements that was natural in any organic software development process got grouped together to be labeled as chaos!
Lesson — An organization is a complex structure made of disparate elements contributing to its growth and existence but if the disparate elements are misinterpreted as ‘chaos’ then the consequence can make a new solution to become a problem or aggravate an organic, organizational state to make it seem like a problem!
Cliché (often used to describe such scenarios) — Blind men trying to figure out what the Elephant was, each with his own interpretation!
I, somehow, chanced upon the remarkable likeness, symbolically, between the novel of Daphne du Maurier’s “Rebecca” in which the new Mrs. de Winter gets introduced into Manderley, the estate of the de Winters and how Scrum was introduced to a large organization in this story — ie. both introductions done without removing the influence of the predecessor.
Scrum, by now, had become as intriguing as Rebecca (the dead wife of Maxim de Winter) was for the new Mrs. de Winter, when she enters Manderley only to encounter stories and images of her on the walls of the Manderley and on everything.
The organizational mindset was like Mrs. Danvers’ (not meant to cast any likeness to Denver, the city and the organization’s headquarters) — still besotted with the past mistress with no time for the new one!
Into such a setup, entered the new CEO, much like how Rebecca’s alleged lover Jack Favell skulks through the window into the new Mrs. de Winter’s life!
For Mr. de Winter, engrossed in the business of making money, the new Mrs. de Winter was a child but for Jack Favell, a child that could easily be silenced and cast aside!
Just like the crime associated with Rebecca, there existed an episode of intellectual theft in the organization’s history — an important functionality code base had been stolen and sold (or had made its way) to the competitor.
This not only made the case for Agile values and principles but it also created a need for a new Agile framework like Scrum.
Coming fully armed with what Scrum was all about and with just the right amount of bluster around the size of the organization to make the heads of departments mutter under their breath, the new CEO was all set to cause some burns around.
Blisters there were to be.
The CEO launched himself into his job like a Great White would on a school of Sardines.
The School keeps forming new shapes but the Great White never sees the large shape when it is near, it sees only the fishes.
The celebrations turned into Town Hall meetings; the Atrium filled with anxious faces instead of the dancing, jubilant ones; the audio had changed from music into announcements; heads rolled, beginning from the top, instead of glasses of beer!
Each email invitation for the weekend town hall meeting spread apprehension on which level would get down-sized that week, each week saw a sizeable decrease in different departments.
But as happens, there was the relief that drama always introduces, all on its own.
Mrs. Danvers had decked up the new Mrs. de Winter in Rebecca’s dress but Mr. de Winter had never liked Rebecca, unlike what the new Mrs. de Winter believed and so, the charade did not work as expected.
The clouds cleared and the new CEO got sacked as unceremoniously as the others he had given the pink slip to!
Chaos, created out of nothing, proved to be a bigger shark for even the Great White!
But the damage done to the organization was more.
Scrum now probably haunts the company like Rebecca did the Manderley but now, the size of the development center matches Scrum team requirements!
Lesson — Leadership should work only with empirical knowledge to be able to recognize change initiatives and not with assumed data given to it. Business vision should always be in sync with change initiatives for better alignment with strategic goals of the organization/stakeholders.
Cliché— Leadership must commit to new initiatives of change or manipulators would change the change initiative itself!
The hugeness of the shapes created by the school of fish is never visible to the Great White, it is just an illusion that is without, creating another illusion for possibly some non-existent enemy while the actual enemy feeds each fish it can get hold of to satisfy its hunger.
Shadows are not real and therefore, should not even be allowed to cast a shadow of doubt over the real.
There is no substitute for empirical knowledge for an organization that wishes to adopt Scrum otherwise, only the ghost of Scrum will remain as testimony.