Agile vs corporate decisions
It’s been already awhile since the first time I had the chance to check how inefficient some so-called corporate decisions can be.I was working as a consultant for a well-known company, and giving some training on SCM to its main software development team. Well, at least this is what I was supposed to do. The first morning I arrived there I was introduced to a QA manager and a “quality expert” contractor, the ones who were going to actually receive both the training and “consultancy work”, because the team was “so busy to stop”. Shocking!
I started teaching them basic SCM concepts, then asking them about the way they were working and trying to figure out the best way to move away from their apparently “total chaos” situation. I have to admit that I wasn’t very motivated because I was trying to explain concepts like “branching”, “merging”, “baselines” and the like to people who didn’t seem to have ever managed nor participated in a software development effort. But, ok – I thought – they’re interested to enhance their current situation so let’s try it.
The “funny” thing happened only a few hours later. I was teaching them how to implement some of the concepts and ideas we were discussing using a certain version control package (the whole story happened before Plastic existed) when I unexpectedly discover a shelf full of boxes containing, at least, another two well-known software configuration management packages.
“I see you have licenses for product X and product Y, haven’t you? If so, why are the team still using Visual Source Safe and suffering all the pains you’ve told me?” – I asked.
“Well, you know, I’ve been here to help the team choosing the right SCM tool” – the external consultant (the contractor) answered me – “so I’ve tried first with product X. I’ve received the training myself and then helped the team implement the solution, but the team leader didn’t feel comfortable so I tried with product Y. The team was so busy that I decided to receive the training again and later on try to help them deploying it, but we couldn’t figure out the way to set up an effective working method either so...”
So I was the third one arriving there and trying to move the team away from VSS. But it would be actually impossible if I didn’t have contact (I wasn’t even introduced) with the “real” team. They were big enough to hire people to do the job of selecting the right tools, but they didn’t have the time to listen nor to get involved somehow. The managers didn’t trust the team to decide on which tools would be better for a “company wide solution”, so they hired an “external expert”, the contractor I’ve been talking to. And the team didn’t seem to trust the contractor, so they were in a locked situation.
Everyone seemed to be very busy doing nothing, and this was one of the first times I got in touch with “extreme corporate inability to make any decision”.
Months later I was sent to help starting a pilot project in another big company. They were trying to decide which tool would be the best to use it as “company wide solution”. I was scared (I’m always scared as soon as I hear something starting with “company wide”), and things got even worse as soon as I saw boxes of product X and product W abandoned on a desktop... “No! Not again!” – I thought.
But this time it was a little bit different. This time the problem was not the real team not getting involved, this time the huge problem was setting really unrealistic expectations.
I started with a demo of the product, to show the core functionality and later on moved to find out how to apply it to solve their problems (the demo was required as first step). Then the people there (about 5 different managers) started complaining about the lack of feature XX and feature YY. I was happy to see such an experienced audience (I’m not joking, they seemed very good to me at the moment) discussing about advanced branching patterns, merging topics, how to manage concurrent development, setting up some sort of “streaming” hierarchy to resemble their 3 different environments (development, pre-production and production), and how one of the most advanced tools on the market seemed to be in trouble to actually reach all these expectations.
They explained me how product X and product W failed to meet their needs. Both of them weren’t enough to actually “model” their development process.
They looked so professional and had so strong opinions that I wondered why they were trying to change their current tool. I mean, if they had such a strong development process in place... they should have a really strong SCM system behind!
So I asked them: “Ok, what are you currently using?”
“Er... well, the team is currently using Visual Source Safe” – one of them answered.
I was shocked! A bigger than 250 team using “good-ol” VSS? Unbelievable!
“And “ – I started – “do you actually have this process in place using VSS?”
NO! They weren’t. They had been telling me the way they would like to work, their “desired process” instead of their real one. The “real” one, constrained by VSS limitations, was in big trouble: they avoided merge like hell, suffering huge “blocking periods”, they weren’t able to actually identify which were the binaries in production (they were not managing releases at all, so they didn’t know which sources generated the binaries used by their customer), they didn’t have a good way to do bug fixing (no branch management at all) and they were doing some sort of micro releasing: instead of deploying whole tested released they “uploaded” binaries one by one, which introduced problems more often than not, when different incompatible versions refused to work together.
So they’ve been trying to find the “silver bullet” SCM system for months, discarding really good products, while the whole organization was affected by an important crisis.
Any of the other products they had evaluated was much better than the one they were using. Any!
But they were so busy (or interested, or whatever you call it) trying to find a “company wide solution” that they weren’t able to do any movement.
My advice was: “no matter which one you choose, just choose one! Whatever direction you move will be better than your current situation”.
They were setting so high expectations for the new solutions that no one seemed to fit, but in the meantime they were accepting all the limitations of an obviously suboptimal solution.
Years later I started designing, developing and nowadays deploying Plastic SCM. I have the opportunity to get in touch with a number of companies and see very different situations.
Small companies and some big ones have the ability to download, evaluate and start using Plastic within days or weeks. They make some questions, they make up their minds and then they choose whether Plastic fits or doesn’t fit in their environment. They’re fast. They’re agile decision makers.
But the common feature they have is they’re not too big: whether they’re small companies or teams inside big ones (but with a budget to make their own choices), doesn’t really matter. Size seems to be a key to make fast moves.
Sometimes a team on a corporation decides they’re interested on Plastic. Then they follow the regular process, and when they look like they’re going to buy someone has a bright idea: “what if we scale it to upper management so they can check if we can adopt it company-wide?” And then, more often than not, the situation follows the pattern I described before: someone starts dreaming on all the things an integrated, company-wide, solution should have, taking his time, asking questions, reevaluating already discarded alternatives... wasting precious time! If the team isn’t in a hurry it isn’t a problem, but frequently I see how the lack of agile decision making and searching for a gold-plated-integrated-fully-featured-silver-bulleted solution takes months while the team which had the original problem is still blocked. They can’t make any movement while someone waits for the perfect SCM, when any option (any) would be much better than their present situation.
Being so extremely afraid to make a mistake is a mistake itself. The lost opportunities, the continued deadlocked situation, the impact in the team’s motivation, will be much worse than all the supposed upcoming benefits.
So, each time I hear “company-wide”.... :-D
No offense to any readers, but rejecting all the products just because they aren't perfect sounds like living in the 19th century. There are no perfect products and there won't ever be. Teams with well-established products have their own to-do lists, computers still break... dammit, even water has calories!
ReplyDeleteOne can't stop just because there isn't an optimal solution. You pick the best of the options, and then try to survive without the lacking features; you either implement a replacement for them, or just adapt your workflow to the existing resources, but never, ever, stop your production!
Just some random rant, but I seriously ask myself why sometimes the "big bosses", (supposedly) financial sharks, doesn't realize that, in the end, they're just losing money.