A few days later you feel the flow again. You’ve tweaked your OS and apps to best fit your workflow.
In the last decade of my career, I’ve been extremely fortunate to have worked with some of the best people I’ve ever known. A big contributing factor to this is the tech-savvy, expatriate culture that exists here in Munich as well as the type of people you typically find abroad who have left their home countries to pursue their dreams. It’s a dynamic that provides an immediate and powerful bond: we have to learn an a lot of things in a short timeframe and sometimes we’re terribly homesick, but we’re not alone. When we combine our strengths and help each other, we achieve something great.
For as many teams as I’ve had the privilege of leading, I’ve often been asked how I did it? How did I take six or seven individuals from different countries and turn them into a team? The question always catches me a bit off-guard because I don’t consciously do this – and I think that’s key. You can’t force anyone to work together as a real team and the harder you try the faster you’ll push them apart. Plus, it’s currently a developers’ market. They can work wherever they want to and they know it! How do you walk this tight-rope and successfully lead a team of rockstar developers?
Test a developer’s software and you’ll find bugs.
Teach a developer to test and they can release their software.
A bit of a twist on the old fish and eating maxim, but the same idea: teaching a skill enables self-reliance and self-confidence. And, while it’s harder than quickly doing someone a big favor, teaching is scaleable in a way that quickly refutes another old adage: we have so many bugs because we don’t have enough testers!
“But our customers don’t want 10 new versions a year. The last release alone had over 600 bugs!” retorts the hotline manager.
“How about a small update with just a handful of bugs?”
Your big-bang release is scary. It’s full of issues and weird, new features that nobody understands. It requires documentation and training and who the hell has time for all that?
Monthly, bite-size updates will have fewer features requiring less support (pro-tip: less code == less bugs). Speeding up your release cycle also allows quicker response to customers’ feedback. You’ll finally feel your company moving in the right direction again.
Of course, it’s easy to say. But how can you actually achieve this positive flow? Follow these key points and you’ll be well on your way.
Investing into code improvement is a dual edged sword: on the one hand you know that if you don’t improve your code you’ll get slower over time. On the other hand improving your code does not deliver tangible value to your users. So how do you know whether you’re on track?
A couple of years ago, I showed you how to Visualize Small Batch Sizes with Git by plotting day-to-day the amount of changed source code lines that hadn’t yet been released to production. While this graph gave immediate feedback about the “drift” of development from operations (live), it’s not something easily digested by upper management. What do these guys really care about? It’s all about the releases silly!
For those that have to deal with release management, release train is a well-understood term. It refers to a software development schedule where multiple products are released as a part of a single ‘train’ on a regular, pre-planned schedule.
But just as a train can be late thanks to leaves on the line, a fatality or engineering trouble, so release trains can be delayed by both internal and external problems. In order to solve this, it’s time to get off the train and look upward for inspiration.