Lesson #11: Review the project.

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.

Lesson #12: Update your process.

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.

Lesson #13: Share what you learned.

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.

Lesson #14: Enjoy the results.

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.

In our seven-day process the first day is spent with the customer in a start shop. The next five days are dedicated to development, and the last day is reserved for the demo shop where the prototype is handed over to the customer. During the five-day development sprint we develop, test and deploy the prototype in iterations. Let’s go through the lessons we have learned in this process.

Lesson #6: Spend time on design.

Rapid prototyping is a combination of craftsmanship and cowboy coding. Usually cowboys take over when the deadline is closing in. To keep things professional throughout the project you should spend time on design. It has a few benefits:

• Working out challenging use cases and problems in the beginning will reduce chances of failing.
• When there are more developers involved in the project, the design helps to divide the work.
• The product owner can verify the key requirements against the design.

In our projects, we have drawn the initial data model and layout designs on the whiteboard. The design usually changes during the development, so we rather spend our time developing than updating design documents.
Make it quick and keep it simple. The purpose of design is just to keep all the cowboys riding in the same direction.

Lesson #7: Deploy early and often.

Applications tend to work differently in production than they do in the developer’s computer. Verify that your prototype is working on the target device or in the production server as early as possible. Once the first deployment is made, you can start testing the prototype.

Deploying often is possible with automated deployment tools. Capistrano works great on Rails projects. Mobile applications can be installed from the IDE (e.g. Carbide, Aptana Studio) with a few clicks. When the deadline approaches and the going gets tough, automated deployment will save you from errors.

Lesson #8: Prioritize and estimate the task backlog continuously.

The task backlog is for managing the development tasks. It states which tasks are the most important ones and how long they will approximately take to implement. The backlog visualizes the remaining work and it helps us decide which tasks we should focus on.

We use a shared spreadsheet as task backlog. Everybody can add a task: the product owner, developers and testers. Every task that requires at least 15 minutes is listed in the backlog. Tasks longer than 4 hours are divided into smaller tasks to keep the estimates as accurate as possible. The developers give their estimates and the product owner decides the prioritization. With this information and a pinch of common sense we decide what to do next.

The beauty of the task backlog is the continuous evaluation. If a task requires more time or a new feature arises, we estimate it and we see immediately how it affects our schedule. Then we drop some unimportant items or simplify the implementation. So rather than sticking to a plan we continuously evaluate our situation and make new plans. Quoting Eisenhower: plans are nothing; planning is everything.

Lesson #9: Delegate tasks.

Prototyping team consists of different roles. In a short project it’s recommended that people concentrate on the things they do best. The developers should be busy coding. The test staff should be busy testing the application.

When we first started prototyping, developers were responsible for content creation. Then the product owner got more involved in the process since he has the vision how the prototype should look like. Finally we moved the whole content creation to the product owner. This solution resulted in more appealing content and gave us more time for development.

Lesson #10: Talk, talk, talk.

Instant feedback, quick decisions and information sharing require good communication. During development we have everybody working in the same space, so we can speak and hold ad hoc meetings (5-10 minutes) as needed. By talking a lot with the product owner we avoid a lot of misunderstandings and save development time by doing the right things the right way.

On the other hand, we also reserve time for silence. When we need to concentrate on our work we use the 45-15 rule. It means that for 45 minutes speaking is prohibited and then we take 15 minutes to discuss about the issues or problems we encountered.

Free breakfast and rapid prototyping

The last post of this series focuses on process improvement issues and the post will be published next week.

On Thursday Feb 18 Leonidas and Codento are organising a breakfast event on rapid prototyping and cloud services. The event begins at 8:00 in Scandic Tampere. Participation is free of charge but please register online (registering also available through Facebook). Welcome!

But what if we change the rules a little bit. What if you have to deliver in seven days within a budget, the prototype must work and you need to do this every two weeks. Can prototyping still be fun?

Since spring 2009 we have been working with mobile and web prototypes here in Leonidas. In our case rapid prototyping means a fixed price seven day software project. Two days are reserved for understanding the customer’s needs, designing the prototype and holding the start/demo shops. Five days are dedicated for development.

Over the next few weeks I will be writing a series of posts of the lessons we have learned. This first post is about preparation. The difference between rapid prototyping and a traditional software project is the very strict deadline. Rapid prototyping is like the Cooper test: run as far as possible within 12 minutes. Those runners who have prepared well run the longest. For developers good preparation equals more features done.

Lesson #1: Understand the project goal

The customer has ordered the prototype for a reason. Usually they need a prototype to show to their organization or to their own customers. Or their developers are busy working and they need somebody to build them a walking skeleton for the next project.

Understanding the customer’s needs helps us develop the prototype. If the prototype is used for demos, the visual stuff is more important than the robust form validation we could spend hours working on. So instead of coding everything, you can describe functionality with pictures and enhance the user experience with AJAX.

If the customer needs a walking skeleton, you can spend more time on making your code readable and documenting how the prototype can be developed further.

As the bottom line, understanding the goal helps you to decide where to focus your efforts.

Lesson #2: Prepare yourself for the technical challenges.

Time is our most important asset and we need to spend it carefully. During the development phase it’s better to spend time on customer’s needs rather than learning Rails’ nested forms.

Try to get as much details as possible about the project before it begins. We usually get some information from our customer before the start shop, so there’s time to think about the implementation. If there’s an unfamiliar technical area, there’s still time to study it before the project.

Lesson #3: Check your development environment.

Installing the SDK, configuring the demo server or matching your tools with your co-worker’s environment are issues that require only a little time if everything goes smoothly. If something goes wrong and you use more hours to solve the problem, you have spent a part of your most valuable asset.

It’s better to be ready before the project starts. Create the code repository, create user groups, configure the demo server, prepare the project wiki. Doing these beforehand can save you a half day’s work.

Lesson #4: Have your project management tools ready.

In our prototyping projects we need to handle requirements and test results. The concept designers have an ongoing discussion with the developers how the prototype should work. These requirements are written to the task backlog with priority and developer’s time estimation. Whenever testers find bugs they also write down their findings to the backlog. Developers pick tasks based on the priorization and mark them done when finished.

We use a shared spreadsheet as our task backlog. It’s fast, easy to use and developed for our needs. After trying some online project management tools and a task board we decided to stick with the spreadsheet since it worked best for us. The backlog spreadsheet is improved between projects and that would be quite impossible if we used a commercial tool.

The lesson here is to have the backlog or any other tools you are using ready before the project starts. Make sure the tool is really helping your team.

Lesson #5: Find reusable code.

If you make a list of the common functionality web applications have, you would list things like authentication, authorization and lost password mailers. From prototyping view these are nice-to-have items (see Lesson #1), so you shouldn’t waste time on them. But on the other hand, you would impress your customer by delivering these features.

One solution is to have these features available in your project skeleton (check out Ryan Bates’ excellent Railscast). Knowing the features are tested and ready to go, you can concentrate on the items your customer really needs. In Rails projects you can also use gems and plugins to get a flying start. To avoid risks, try the gems/plugins before the project.

Hope you enjoyed this post. Next week I’ll be posting about the lessons we’ve learned in the development phase.

The answer: prototype to validate the idea as early as possible.

Even a harsh, simple, ugly and defective prototype is better than no prototype at all. It clarifies the concept in three important aspects:

1) Do the product champion and the implementors share a common vision?

2) Does the product address a real customer need?

3) Can the concept be realized using current technology?

Expensive – and unfortunately common – mishaps occur if these concerns are not addressed properly.

First of all, if the product champion is not able to clearly communicate his/her vision to the implementing party, the direction of the development might be wrong from the start. The earlier this is noticed, the cheaper it is to fix.

Secondly, even the best visionaries get it wrong most times.

It is important to get feedback from the potential customers/users as early as possible. A good prototype is something you can show to the customer and ask “would this solve your problem?”

And thirdly, as the implementors get to inspect, evaluate and execute the concept, they form a better understanding of its technical requirements. For example, they may find out that implementing the project would be extremely expensive. ROI on this kind of insight will naturally be substantial.

So, when you’re pondering upon the Next Big Thing, actualize it as fast as possible. You will be greatly enhancing the time you can use on the right ideas.