This is the last post in my rapid prototyping series. Previously, I wrote about preparation and the development process. Today’s topic is Kaizen, continuous improvement. We’ll go through a few steps that will help you be more productive, shorten the learning curve, and make your life easier.
Process is best improved by those who do the actual work. Our project team gathers for a retrospective the day after the prototype is delivered — while we still have the ideas and problems fresh on our minds. We discuss things that went well, things we could do better, and what actions we are going to take to improve the process.
For learning how to organize good retrospectives, I recommend the awesome book Agile Retrospectives by Esther Derby and Diana Larsen.
We keep our process documentation as light as possible. Currently, our entire process is described with a one-page how-to and a checklist. To inject our improving understanding into our process, we update these documents after each retrospective.
We also use how-tos that describe the most important technical tasks, such as setting up a new web application to our production server. These guides help us avoid stupid mistakes, and they save time when a team member does the task for the first time.
Rapid prototyping gives us feedback in seven days. When we get positive experiences, we share our findings with the rest of the company. We use wiki, Google Wave, and Leonidas hour to spread information within the company. To share our experience with the world, we write blog posts such as this.
Everybody loves getting feedback on their work. When our sales team returns from the demo shop, they share the customer reaction with us developers. Having worked hard for seven days, we find that it’s great to hear that the client said the results were awesome.
I hope that this journey in rapid prototyping gave you something to use in your own work. If you have any questions, please feel free to leave a comment.
If you’re interested in agile development, I gave a presentation last week in Demola; the material is available on SlideShare.
By the way, we have a post coming on software quality written by Edvard Majakari, who recently joined our company. Ed is a great guy, and he’s always there to help when it comes to making better software.