Triple Eight

List of methods / Design and innovation

Triple Eight is a method for designing innovative software through rapid prototyping and forced mutation.

The idea is for three groups to work on the same concept over a period of 24 hours, with each group taking turns to develop the concept for 8 hours. Ideally, the three groups are distributed around the world so that once one group has finished the next can pick up the work and then the next till 24 hours have elapsed. The first group is given the design brief but each subsequent group is only provided with the output, a rough prototype, of the previous group. The overall output of this method is a design for a software product. This design can ultimately take many forms, e.g. a backlog for a Scrum team.

Here, as with Constructor theory, variations on the theme can be explored allowing for a richer set of options and ideas.

Name and history

This method was originally developed as a part of the early DSDM consortium.

The name "triple eight" simply comes from the fact that the method involves three teams working eight hours each.

Preparation

Scope

Stakeholders should determine the scope of the concept to be explored. Generally, this method works best when the focus is neither too narrow nor too general. The scope is not required to be shared with the participating groups.

Participants

The method relies on three groups. The first group has a different role than the other two that follow.

The first group should be composed of:

• 1-3 prototypers
• a business analyst
• 3-4 users, or potential users
• a facilitator

The second and third groups should be composed of 3-5 prototypers. Diversity in each group improves the result.

• Prototypers are developers who are skillful at quickly producing a rough piece of software. Perfectionism and Test-Driven Design practices will likely be counter-productive when used in conjunction with this method. Not every developer wants to be a prototyper. Prototypers do not need prior knowledge of the scope of the concept that will be explored.
• The users, or potential users, are the people who will bring the concept, which will draw on their knowledge and experience. They do not need to have prepared anything for the occasion. Aspects of their daily routine that can be improved or that are frustrating are common sources of inspiration.
• The facilitator should be someone who has knowledge of the current software system(s) as a whole, and who can code at least a bit.

Each group should obviously have access to the development tools needed for prototyping. At least for the first group, this often includes a physical or virtual whiteboard. All prototypers should be skilled at using the same tools, and the output of these tools should be easily shared, run and modified by all. Originally, this method used 4GLs. Nowadays, low-code and no-code platforms can be a good choice.

Each group should ideally be in time zones that are roughly 8 hours apart. This is not required. Teams may be in the same time zone or even colocated, as long as there is no communication between teams beyond the handoff of the output of one team to the next.

Prior knowledge

• Prototypers should be familiar with one or more methods of rapid prototyping, e.g. Joint Application Design (JAD)

Workflow

STAGE INSTRUCTION	COMMENTARY & TIPS
The first group works for 8 hours on producing a rough prototype. The ideas for this prototype are initiated by conversations with the users present and are continuously fleshed out and revised. At the end of 8 hours, the prototype, its source code and any instructions for executing it, is available for sharing with the next group.	The session can be run like a JAD session, or use pair or mob programming techniques. Activities can switch fluidly between conversations at a whiteboard, coding and testing.
The second group receives the prototype from the first group, but does not receive any other details or artifacts that were produced. This group works for 8 hours on improving the prototype in any way that they see fit. At the end of 8 hours, again the prototype in its modified version is available for sharing with the final group.
The third group receives the prototype from the second group, and similarly, works for 8 hours on improving it. At the end of 8 hours, the prototype is sent to back the first group for demonstration to the original users.
The original users test-drive the output of the third group. Feedback is gathered about the aspects of the prototype that are desirable. These aspects are documented and can subsequently form the basis of a product design specification and/or product backlog. The prototype, including its intermediate versions, is thrown away.

Do's and Don'ts

• Do use appropriate tools. If setting up a Spring Boot web service that responds "Hello, World" for deployment on a Kubernetes cluster on the cloud will take anything more than five minutes, then these tools are inappropriate.
• Don't break the constraints on communication between groups. Each group should only share the bare minimum required for running and modifying the latest version of the prototype. If a version control system is used, the history should be erased before the handoff or later groups should neither look at its history nor check out previous versions. Preferably, groups do not know who the other groups are or how to contact them directly.

Virtual running

This method can be run virtually with little to no modification.

Obviously, the norm is for each group to be in different locations and to not communicate with each other.

Members of a group may be working at remote locations. This can require using visual conferencing tools, virtual whiteboarding, and an IDE or a low-code/no-code environment that offers collaborative coding features.

References

Link to other articles on this wiki if they are relevant.

Articles

• Why Dawkins is wrong, Denis Noble - there are some similarities to the hypermutating that the immune system does when it faces a novel infection (first segment). It basically goes to the nucleus and asks it to 'stop the error correction' and then uses the mutations to see if they have any effect on the infection.

Blog posts

Link with commentary

Cases

Link to case articles here or third party material

Related methods and approaches

Similar principles can be found in the Toyota design practice which Alan Ward referred to as Set-Based Concurrent Engineering (SCBE). The practice does not look at efficiency but tries to ensure as many design options are explored in parallel. The practice was discussed in SMR paper titled 'The Second Toyota Paradox: How Delaying Decisions Can Make Better Cars Faster'. The Toyota practice uses a series integrating events when the options are reviewed and the non-viable options are culled. This goes on till there is one option which is then developed.