At work we had lots of meetings recently where the higher-up managers passed down next year’s plans for R&D (the Research and Development department — or, as I like to call it, “Research and Destroy!”).
It’s always interesting to see how different speakers address their audiences: Some prepare slides with wordy bullet points, while other pull out raw sales numbers; some have no slides at all, and yet others just draw on the whiteboard when necessary.
When we assembled again to listen to the last one of the managers (there were several over two weeks), we had grown tired of slides and buzz words and registered with some amusement that this manager announced, he would make certain that we would recall the last meeting as the best of them all. “Yeeah, right… ;-)”
But to my surprise, he kept what he promised. This was the first of those “high-level” meetings that was interesting enough for me to take notes. Clearly this manager has started his career in electrical engineering, and his way of presentation immediately connected with the software engineers (and computational linguist) present. Instead of a projector, he had requested two flip charts, and his way of presentation reminded me a bit of university.
The first thing he drew was an input-output triangle, basically an amplifier like an op-amp in a circuit diagram. In our case, the input is the software spec, and the output is the finished software product. The software engineers are doing the work inside the triangle. However, he said, there is a huge difference between manufacturing of electronic parts, and development of software. The manufacturing process has predictable start and end points (he doodles an x/y graph with a continuously decreasing curve); development, on the other hand, goes through many iterations until the process results in a working product (he draws another x/y graph with a very wavy curve that levels out towards the end).
Basically, he compared development to an oscillating wave: An electric engineer repeatedly takes samples to keep it under control. Mathematically, the minimum number is 2 samples per period, but experience teaches the engineer that 10 samples produce a higher quality outcome in “curve control”. In his software engineering career, he mentions, they did the “sampling” wrong for the first 15 years, and spent the next 15 improving the process.
Taking two samples per period corresponds to the “waterfall” paradigm of development, where you start with a plan, and a year later you look at the result: Then you realize that each team is only half finished and the pieces don’t fit together… Nobody expected that and you miss the targeted deadline. Instead of a decreasing curve towards the end of the year, you get a steep increase of workload: People are stressed out, panic, and make bad design decisions. A low-quality product is cobbled together hastily and released too late, resulting in disappointed customers.
If the engineers had instead taken 10 samples over the year (e.g. one review per month) the discrepancy between plan and reality would have become obvious much earlier. They would not only be prepared, but even able to correct the course of events. This approach is what we now call Agile Development. Each “sample of the curve” corresponds to a sprint review meeting at the end of an “Agile sprint” (which typically lasts around 4 weeks).
At each sprint review, the whole team gets feedback about the current status, and can re-evaluate the tasks together. He draws a feedback line into the amplifier symbol — an arrow that branches off from the output arrow and loops back to the input arrow. This important feedback line is what is being neglected in “Waterfall”-style development. Regular feedback gives you control over the fluctuating development process, so we can approach the goal over several iterations.
(He casually mentioned that he thinks about these things because, at home, he builds little robots as a hobby. Somehow I couldn’t shake the feeling that he saw us, too, as his little pet robots: His employees need calibration, a new set of configuration values, so he can control our oscillations!) :-)
Next he drew another triangle: In the three corners he wrote “time, resources, functionality”, and in the center “= quality”. The more “time, resources, functionality”, the higher the overall quality of the product. Assuming that you cannot afford to reduce quality, where can you save? Time and resources (man power and money) are typically fixed — that only leaves dropping functionality to save a project.
(As an aside, a similar model can also be applied to resource managing in RPG games: Low-quality newbie skills are quick and cheap to learn, but have only limited power. Investing more time into training, or spending more gold on equipment, results in more powerful skills, and the level (quality) of your game character increases. Game developers have to keep this balance in mind when designing quest items: More powerful skills must be more expensive and time-intensive to acquire (i.e. either rare, or slow to recharge), or your game will suffer from inflation.)
What happens if you increase or reduce quality? He doodled a rough satisfaction-vs-needs graph with the three curves of the Kano Model: If you fulfil more than the expected needs, your product is extraordinary and expensive (you used more resources), and only few customers will buy it. If you undershoot the target and do not even fulfil the basic needs (his example was selling a car without wheels and motor), you will lose customers so fast that they will not even bother to give you negative feedback… Most companies aim for the middle curve of customer satisfaction, and keep the balance between fulfilling the minimum needs within a medium time period for an acceptable price.
Quite an inspiring and well-targeted presentation, especially if you expected PowerPoint slides with sales figures! :-)