I’ve previously written down the system development process for students to use from the high level. This post will break things down into each section of the four sections of cycle (discover, define, develop, and deliver) with some ideas of what should be proposed for each of them.

Discover

Starting with ‘discover’ is where the team meet the client and discuss the percieved issues of the client. The purpose here is to explore the issues raised by the client and the context of the situation in order to establish the parameters of the application. In addition to interviews, probing with Five Whys (training example and TDD example and ‘how to run exercise‘) can be useful here to ensure the problem is being addressed correctly and its full context taken into account. At this stage it is important to not consider solutions, but rather gather ideas, and defer any judgement on possible solutions. In general we are diverging from the original idea and expanding possibilities.

A suitable service design template might be useful at this point. This would help ensure that appropriate partners are brought into the process and that nothing is forgotten along the way. You may also want to use the customer journey canvas from the This is Service Design Thinking book, which is a useful guide to the processes involved and the tools, which can be used for these four stages. The other suitable canvas, which might be useful in some cases is the business model canvas from the Business Model Generation book (where you can download a useful extract too).

Define

In the ‘define’ phase potential solutions are explored. The goal is to expand possible solutions and then to start focusing on viable ones, which can be carried forward to the ‘develop’ phase. This is the phase of brainstorming and ideating possible solutions. A creative problem solving process can overlap between the ‘discover’ and ‘define’ phases to help determine suitable boundaries of the problem, while also generating possible solutions. Many general brainstorming game sessions are detailed in GameStorming and Innovation Games. Chosing which game to use is a matter of determing the type of scenario for the appropriate people involved and the desired goal. Following the session the ideas can be compared using something like Impact Estimation Charts (further example and template), or maybe develop something more out of the CPS process and in particular step 5 suggested by CPS to see which will provide ‘the biggest bang for the buck’.

If the capability is a available, then a facilitated StrategicPlay session using Lego Serious Play may be suitable to help understand the issues of the problem and possible solutions. A StrategicPlay LSP session can help build a shared vision of the problem, or possible solution, as well as to possibly strategize future scenarios, or to understand the context of the problem and the intricacies of behaviours between actors.

During this phase the team should also determine the minimum viable product that is to be developed. You can find MVP discussed with reference to wikipedia, startups, and software. This is the simplest, most basic solution which can be released. The goal is to produce something for the end users sooner rather than later, so that feedback from actual usage can be used to tailor a better version. The goal of MVP is to keep adding parts of the product to the customers, instead of all of it at once. Start earning business value sooner, rather than later.

From the ‘define’ idea solution possible interfaces can be rapidly prototyped on paper, or some other simple method used to create a mock up, which can be shown to real users for feedback. Based on trials, the prototype can be refined again and shown to others for more feedback. When enough of the minimum viable product is ready as a prototype, then this is moved onto the next phase. You’ll notice that we started this phase with many possibilities and have narrowed them down via a number of processes to the bare minimum required. We have converged our ideas down based on usable feedback from users.

Develop

In the ‘develop’ phase a working prototype is developed and refined based upon ideas generated in the ‘define’ phase. This should be done using an agile process (wikipedia, scrum & XP) that incorporates incremental week, or two week long, timeboxed iterations based upon the client selecting the most suitable features to build in that increment. In order to keep the quality of the codebase high the team should be using appropriate agile practices such as pair programming based around test/behaviour driven development (TDD/BDD) so that the team only build what is needed. As the completed iterations are shown to the client these should be confirming hypothesis about which features are required, and other issues such as which user interface works better. Successful features should then be pushed onto the ‘deliver’ phase.

When the team is unfamiliar with agile practices, then games such as the Lego XP Game, or the Lego Scrum Game should be used to introduce the ideas. Activities such as CodeRetreats, or CodingDojos should also be used to introduce pair programming and TDD/BDD practices and bring people together too. The book to read for this phase would be something like Agile Estimating and Planning, which covers the basics clearly.

During this phase the process might be diverging out again as ideas explored in ‘define’ are refined and new possibilities explored while building a solution with the client. As the team and the client are also testing hypotheses, other options will also be explored. There might be lots of going back and forth between the ‘define’ and ‘develop’ phases. The key to successfully doing this will be that the team and client base decisions on some notion of ‘biggest bang for buck’, and using a ‘build, measure, learn’, or PDCA cycle, so that validated understanding is being used to make the decisions about what to include and push onto the ‘deliver’ phase. This is all greatly explained in the Lean Startup book, and illustrated in the Toyota Kata blog post using PDCA.

In order to keep the workloads manageable, the team need to institute a sort of ‘work in progress’ kanban system (scrum & kanban book) so that work is focused and delivered quickly. The clients and users only see ideas that are implemented and tested, so it is important not to have too much work ‘in progress’, because that would slow down the feedback cycle. Looking at Henrik Kniberg’s thoughts on Metrics would help here. Using a kanban board to limit the work will make this easier to achieve. There are a number of games that can illustrate these benefits such as the Kanban Pizza Game, or the Frog Factory Kanban Game.

Deliver

The purpose of the ‘deliver’ phase is to make the application go live for the client and their users. During the ‘develop’ phase limited users should have been trialing the application so that lessons could be learned, and from that knowledge final features should be pushed to the release version of the application. A continuous integration system should be used to ensure that all of the code is properly tested for smooth integration and any errors quickly caught and fixed. This is mainly to catch situtaions where multiple developers are pushing code to the version control system and one misses a change that someone else made and a test fails. It provides a useful safety net, which is not too hard to add to the process. The line between the ‘develop’ and ‘deliver’ phases can be permeable and the only difference might be that some features being used are temporary as part of an ‘a/b test’, or some other means to measure what is needed by the users, and thus might disappear if not deemed useful.

Together each of these phases should be a part of each project and while the team might spend more time in the ‘develop’ phase, they should also be sure to spend suitable amounts of time in ‘discovery’ and ‘define’ so that they ensure that they ‘develop’ the right application because they took the time to ask the right questions in the ‘discover’ phase and tested out prototypes in the ‘define’ phase to see if their ideas had merit.

Further resources

Further resources can be found to cover each of these phases. Some will be obviously applicable, while others will be less so, but will provide background suggestions for context. The focus here is on the service design aspects, which I’m assuming are new, and that the agile and other software aspects are familiar enough already.

d’school bootcamp bootleg with the basic process (they use five phases to the four here).

Service design tools has a wealth of material that can be used across the project.

Gamestorming site with games and suggestions, which can help with the ‘define’ phase.

Innovation Games has a lot of games, which can be used in the ‘define’ phase.

Conclusion

So there you have the basis of a process to co-create software bringing together service design and agile approaches. This is still not quite ‘right’ but pulls together most of the details I want to see covered. As with the post on ‘the process’ this is still a starting point, which I’m sure will change over time. Any thoughts and comments greatly appreciated.