I was working at a company that was less than united, to put it mildly, thanks to an owner who liked to buy up companies, then pit these units against each other in the name of "development."
[ Take a walk on tech's lighter side with America's funniest IT stories. | Get your weekly dose of workplace shenanigans by following Off the Record on Twitter and subscribing to the Off the Record newsletter. ]
Though these units offered products and services for the same overall type of business, they serviced different clientele. For example, one unit might target large corporations, while another worked with mom and pop shops -- but neither was used to collaborating with the other.
The owner further emphasized these silos when developing new products: He had the units face off against each other to see which would get it done the fastest. Redundancy ran rampant, with two or more teams often writing essentially the same product in the race to be the first to market.
When the dust settled, the losing units could either meet with the winner to find out how to make the product work for them or go with their own system and disregard everyone else. They usually chose the latter path. As can be expected, a lot of waste and expense came out of this competitive climate, and it became ingrained in the culture.
New boss, meet old attitudes
A new owner took over the company many years later, which happened to be right around the time I started working there. Despite the new owner's best efforts to streamline the organization and make a single company out of all the competing units, the old mind-set persisted: Getting something done fast was still more important than doing it right.
Under the new owner, one project focused on simplifying internal processes, particularly the numerous accounting and billing systems. We had several people doing the same job but with different software, which made creating companywide reports a real pain, as someone would have to aggregate the data over multiple systems. A back-office team was put together to create a single system to replace the existing setup.
I was on the development team for a business unit that was one of the first to integrate with the new system. The back-office team leader and one developer initially sat down and asked us what we needed for the switch.
We detailed the login and purchase flows that would need to be changed. We drilled down in our code and found about six methods that required replacement. We gave them the method signature and a rough idea of what had to be done. We were told that they'd have this for us in two weeks.
About a month later, we still hadn't seen anything from them. Then one afternoon, the team leader stopped by my cube to discuss the project. He asked me if I had "ever done agile development before? Because that's what we do. You know, no requirements. The developers just code what they think."