Every time you hear that a new process is about to be implemented at your company to increase productivity or software quality or creativity you should open wide your eyes and look around. Chances are that the problems are not processe related in the first place.
Let me start with a true story about bolts, washers, and nuts. I was in the 5th or 6th grade when all the boys from my class had the privilege to understand the working class: once a week we were taken to a factory and given the task to put together a bolt, two washers (split and flat), and a nut (these Kafkaesque tasks were common during the communist regime). In front of us on huge steel tables was a pile and we had a quota. After a while we realised that if we split in teams and each person does only one task we will finish the job faster. A simple change in the process increased our productivity while the people working on were the same.
Later I learned about Mr. Ford and his innovation (assembly line) and nodded wisely – I knew first-hand what it was all about.
During my software engineering time I learned another lesson about productivity: if you use the right tools (IDEs, programming languages, libraries, or frameworks) the same person can achieve more with the same input (at least once she or he understands the new tool). Simple example: suppose you have to plot data in some nice looking charts. There are two ways: write the code from scratch or use one of the countless libraries available for your programming language.
So far so good and probably nothing to argue against. So where issues start to creep out? On short: when you try to implement a process at the company level (or even team’s level) process that you hope to yields better results then what you already get (more creativity, faster time to market, better software).
I’ve seen teams doing great using some kind of waterfall approach and then switching to Scrum and doing also great (hard to tell if it was better or not). And the opposite: teams struggling in waterfall setups weren’t necessary better when switching to agile.
Trying to implement agile methods (like Lean Startup) at big companies is a painful process to observe and probably even more painful if you are part of the teams.
So why’s that? I think the main problem has to do with the homogeneity (or lack of) at big companies or big teams. In theory you take the new process and lay down on the company the same way you’d lay a blanket on bed: it will fit neatly and cover everything evenly.
The reality is that the blanket has to cover not a flat surface but a rough terrain that has lots of mountains, valleys, hills, and plains. Executives and senior management are the mountains, while the engineering teams are the hills or plains. And the valleys are the disconnect between the executive management and the engineering teams. Each party will take only what it makes sense and discard the rest of it. The end result hardly can be the one you hoped for.
Many of these cool processes were designed by startups. At startups the homogeneity is almost perfect – founders/executives are core part of the engineering team. All people pull in the same direction and have the same picture of the environment.
So why try in the first place? I think the assembly line from manufacturing industry and the developer tools are part of the problem – we think that surely it can be as easily to change the dynamic of a company or teams using the process X or Y.
In my humble opinion it is less about the process and probably 90% about having the right people with the right attitude in your team or company. Starting with the executives and finishing with the engineering teams. And because it is always harder to recruit and keep the right people we go out and hunt for the hottest methodology and try to make it fit at our company.
If you think I am wrong then explain me why a company like Samsung can’t beat a company like Apple when it comes to mobile devices? Do you really think that it is the process they are using or the people who work at these two companies?
Credits: “Bolt-with-nut” by Pavel Krok – Own work. Licensed under CC BY-SA 2.5 via Wikimedia Commons – http://commons.wikimedia.org/wiki/File:Bolt-with-nut.jpg#/media/File:Bolt-with-nut.jpg