Colliding Worlds
Posted by swlc on February 18, 2009
I work for a Fortune 500 company, which recently bought the company I worked for, which in turn had recently bought the company I worked for. Just before these couple of acquisitions, I was part of the team managing the acquisition of another company.
I’ll keep the names of the companies out of this to protect the guilty and the innocent …
So in the classic fish swallowing fish picture, I worked for the second fish from the right!
Each of these companies had a different software development process, at various stages of maturity.
The big company had a lot of divisions which had never been integrated, so there wasn’t any company-wide process. Their processes ranged from some pretty respectable agile shops to totally ad hoc.
The medium company had traditionally been a mainframe shop, and traditionally had followed a waterfall process (I hesitate to call it planned – more passive-aggressive, really). They started the roll-out of their flavor of the Rational Unified Process, complete with a squad of IBM consultants and a bunch of IBM tools.
Now, I like a lot of things about RUP. And for this company, rolling out RUP and getting it adopted was an important step in their evolution as an organization. Going directly to agile might very well have been ‘a bridge too far’. I do however view RUP as incorporating ideas that were current when Philippe Kruchten wrote his book “The Rational Unified Process” – still a great book by the way – but ideas which might not be the best anymore for many organizations.
The world has moved on, and there is a half-life to all ideas in software development, as Philippe notes.
The small company that I worked for had been pretty darn productive. We had followed process ideas that evolved from my work at HP and some from Intel, and we were doing a flavor of agile before there was a name for it. As the company grew, and different folks joined as managers, our process decayed.
Then about 2004 we adopted XP and then Scrum, as the whole agile movement became formalized and there were books to which we could refer the managers and developers. After several years and many projects, we were improving continuously and had a pretty fair process in place. Nothing to write books about, mind you.
So, to cut a long story short, we get bought, the acquiring company rolls out their new process, which is really about 15 years old, and requires us to go backwards.
We lost several key developers as a result, and I feel that our product delivery was slowed to a crawl for several years. This was only one of many factors, of course. I’ll write about some of the others over time.
I see the company viewpoint as well – some groups within the company had a strong and current SDLC, others had a weak and old SDLC. We also had others with a current SDLC, like agile, but weakly followed, or with an old SDLC, well-executed. We were all over the map.
They didn’t single us out. It was important for integrating the acquisitions to have a standard process so different organizations could collaborate on projects, and so that we had a common model for planning and reporting within the company.
But, you bought the company because they were successful at delivering products. Why kill off what they were doing right, whatever it was? IMO, the real value in a software company is the culture, the ideas, the management team and the developers, in roughly that order.
What would I do differently, having lived this, and if I was in charge of the do-over?
I believe that corporations, like governments and schools, should set minimal standards and then govern to bring any groups that lag up to that standard. Groups who already exceed the standards, and who are able and willing to collaborate with the other groups, should be allowed to continue to develop and innovate, and identified as the process leaders “out in front”. I see this failing to occur in our schools, in our government, and in our companies.
The greatest under-achievers are not those who fail to meet the standard, but those who are not allowed to exceed the standard.
