This day and age all the organizations are under pressure to increase their velocity to create more value faster and with ever increasing quality. This trend is not stopping, but ever increasing with the commoditization of the infrastructure (clouds), operational processes (on-demand) and free tooling (open source and free tiers). Today a couple of college graduates in a Starbucks shop can disrupt a whole industry with $100 of initial capital.
The companies that are not paying attention to this trend are dying very quickly. The companies that become comfortable with their current business models can easily miss the point when it’ll be very late to react. Market leaders, without competition, have their competitive muscles atrophied and a high-velocity innovation newcomers over-innovate, over-iterate and out-maneuver the leaders into oblivion.
So it is becoming “trendy” to talk about how to increase the velocity of innovation and product development.
Most of the times I notice the companies are starting with “agile”. They hire coaches and impose mandatory cross-organizational training for development teams to adopt an agile practice (usually “SCRUM”) and claim the victory: “from now on we’re AGILE and we will kill the competition!” A couple of year later without seeing any benefits, these companies either claim that Agile doesn’t work in their specific case or try again to retrain the developers on Agile. This cycle may continue or dies at some point when the organization settles on “their own” flavor of AgileSafeScrumBanFall.
At some point, sooner or later, organizations do a further attempt to improve developers’ productivity by finger pointing at a range of problems from bad talent, lack of training, accumulated bugs, lack of testing automation, unclear requirements from business or slow IT/Ops, etc… While business trying to coerce development organization to increase velocity, new features are prioritized higher than the bug fixes, automation is ignored as a non-business critical, resources are cut due to decrease in funding, IT/Ops outsourced to reduce OpEx budgets. Business incentives to keep current customers happy and to increase the opportunities to bring new customers are improperly translated into “how can we make lazy developers to work faster and harder”.
Can you, please, tell me how can you make a racing horse to win a Kentucky Derby by starving it (no new talent), not providing time and abilities for training, putting it into a dark box that is 10 times smaller than it’s body (tight time/budget boundaries), cutting it’s legs (budget cuts), outsourcing it’s head to another horse and putting carriage with granite boulders (technical debt) behind? Will a smiling jokey with a whip (management) can make this horse to perform and run happy in front of the newcomers that don’t have these limitations?
I apologize for this analogy in front of the animal lovers, but I feel that it closely describes the current situation in most of the organizations. People in such organizations feel burned out, cynical and discouraged.
So juggling things around, like moving the carriage in front of the horse or outsourcing legs instead of the head (i.e. fixing bugs first and then features or moving contractors from one place into another) are not going to change the situation.
In these situations any discussions about working out of this situation are shut down very quickly by a lack of resources, tight schedules or other excuses. Process changes and rearrangement of the priorities will keep the situation unchanged.
The good news are that there is way out of this situation. The bad news is that it’s not magic and it’s not coming for free. Organizations can make fast improvement but such drastic shifts require sacrifice and drastic measures. On the other hand they can slowly iterate out of this problem but it’ll take forever and may be “too little too late”.
To get started with the improvement of organizational velocity you need to ask yourself and your organization a very fundamental question – what is your current velocity and what is your definition of the velocity/performance?
There are so many different definitions of the velocity as well as there are so many different ways to measure it. But, if you’re honestly looking to improve, you MUST have your definition and your measurement. Without this you can’t claim that improvements, in fact, have happened. On the other hand, be careful – incorrect measurement and incentives can drive to a totally unpredictable and disastrous results (check a story behind Cobra Effect).
Productivity (put your definition in your organization here…), can be different based on the definitions and the measurements you put in place. For me, the productivity is the factor of how easy it is to produce business value (ex: features).
Before you get started, observe the high-velocity innovation companies. You can see the main common thread – they constantly invest into their own velocity.
There is a story (7th habit by Stephen Covey) that talks about 2 identical lumberjacks that worked in the forest where one of them was substantially more efficient than the other. So when the laggard asked the performer how did he achieve this improvement, the performer said that he spends each morning 1hr to sharpen his saw. The laggard said that he has no time to sharpen the saw because he needs to cut the trees despite the fact that sharp saw can help him in a long run.
The moral of this story is that when you’re investing into your own velocity you getting more time and resources to do even more, but if you’re rearranging the same thing and hope to get a different result – that is, according to Einstein, pure definition of insanity.
Now if you’ll ask what can be used to invest into the velocity – the answer will be: pick whatever is most painful, lengthy or resource intensive and fix that first and then take the next item on the list and repeat. Demming teachings and the following Goldrat’s Theory of Constraints have been known for quite a while, but, unfortunately not widely adopted throughout the industry. They teach continuous improvement and the need to iterate on the bottlenecks.
Bottom line it’s a journey and there will always be a lot of work, but slowly the teams will start feeling more relaxed and engaged because the painful and tedious items will start disappearing and the life will get better.
The items for improvement are vast. Here a couple that you may consider, but, please, do not be limited by this small list:
Fixing disabling and paralyzing bugs (paying off technical debt)
Moving work to computers instead of people – they are built for repeatable processes that do not require human ingenuity (automating tedious and error-prone processes)
Automating build/release/QA processes (be very careful to not over engineer and introduce more technical debt with brittle scripts)
Changing the sitting arrangements (saves a lot of time on the unproductive mail threads and empowers people to make fast in-place decisions)
Bringing more training on new technologies and practices (follow the trends and behaviors of the leaders in your and adjacent fields)
Consider changing teams composition (better composed teams become more autonomous, self-sufficient and scalable)
Killing unnecessary overhead processes (lengthy approvals, all-hands design meetings, etc…)
Moving responsibility and accountability down the chain (empower people to make right decisions at the right time/place)
Firing “bad” customers (painful, needy and high-maintenance customers sometimes more expensive than the money they pay – sometimes it’s not worth the effort)
Decommissioning unused/rarely used features (reduces size and complexity of the code making it easy to innovate faster and reduces technical debt)
As you can see – the improvements can come from any direction and in many different forms. Use your imagination and prime feedback from your teams.
Q: Which one from the improvements to choose?
A: The one that will bring the most benefit (biggest bang for the buck) for your velocity
Q: How do I know if it works?
A: Measure everything – before and after
Q: What do I do if it doesn’t work?
A: Use Lean approach – Keep what works, Ditch what doesn’t, Pivot to new direction using the learning you just acquired
A lot of good ideas and useful patterns on how to introduce change into the organizations are discussed in the book Fearless Change by Lynda Rising and in her latest interview to Software Engineering Radio on Agile Brain.
What do you do in your organizations to measure velocity of innovation and what do you do to improve it?