Blog

How To Deliver Software In 7 Days, Part II

My previous post was about preparing for a rapid prototyping project in which we create working software in seven days. This second post reveals how to keep the project on schedule, avoid technical risks, and delegate work during the development phase.

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!