By Ofer Dangoor, VP of R&D
One of the tasks of an R&D manager is to make sure your teams are efficient. At the same time, we all have stressed deadlines, and we are always understaffed. Given these conditions, the question is, do you really believe you are maximizing your resources, both human and not?
The first principle of “lean software development (LSD)” is simply “eliminate waste”. If some activity within the development process could be bypassed or the result could be achieved without it, it is waste. Basically, do whatever you can to increase efficiently. Sounds quite simple, but waste is not always that obvious to recognize.
There are many reading materials that discuss lean development, based on the “Toyota Production System”, and more specifically, the different types of waste you can find in the development process. Since many of them are quite theoretical, I would like to point out three of the most significant types of waste we’ve recognized at TeleMessage and have managed to eliminate:
Unclear Requirements
Your developer’s time is precious. Let them do what they know best, develop. If you’ll give them unclear requirements, they will spend their time going back and forth to the project/product managers, and in many cases, end up redoing their work. I have found that eliminating unclear requirements to have one of the greatest impacts on reducing development time. Heads up, you’ll need the cooperation of the stakeholders, since it might create more work for them and slow the response time on your part. However, the “bureaucracy” in this case is worth it.
Unnecessary Code and Functionality
Focus, focus, and focus again. Nobody likes to throw away a good piece of code. But keeping it has its costs. You need to maintain it, test it, and make sure your new code will play along nicely with the old one. Don’t hesitate to retire unneeded features, and do not keep methods “just in case”. You will be able to get anything back from Github or SVN when (and if) you’ll need it.
I especially like the agile principle of “simplicity,” the art of maximizing the amount of work not done. Achieving a certain goal is important, but there are many ways to get there. A nice example is the myth about NASA spending millions of dollars developing an “astronaut pen” which would work in outer space while the Soviets solved the same problem by simply using pencils.
Incomplete Projects and Task Switching
At the end of the day, it’s all about what you can deliver and not how many tasks you started. Half-baked tasks of partial projects means you invested a lot of time and have nothing to show for it. You do not get more customers by being “almost done“. By not completing projects, you end up needing to keep the different versions, and halting and switching the developers tasks (a big no-no!), and resulting in chaos.
Making improvements is not a one-time effort. You’ll need to create a process of continuous improvement. Having an iterative process and implementing the retrospective practice will enable your company to make small improvements regularly, and tackle changes in manageable way.