Tag Archives: process

The Four Process Phases

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.

The Development Process for Group Work

Discussions with a good friend this last week made me realise that I’d never put my thoughts down on how students should be building their applications before. Thanks friend, your prodding is greatly appreciated. Sure, I’d been thinking about it and determined what was needed from the software development process, but since moving more into the service design and design thinking camp, I’d not coalesced these ideas together. As always with these things, this is just a snapshot of where my thoughts are now. As I get a better understanding of this all myself, I’m sure my ideas will change. In any case, it is useful to document the starting point.

I’ll roll this idea out with the MSc students on group projects over the coming summer and then iterate it for other group work next academic year. These students have already done some of these things in isolation as part of other exercises, but other parts will be new to them. Where possible, I’ll pull in materials from elsewhere and use things they can run on their own. However, some parts will need to be facilited by myself or other suitable staff members. These group projects are always done with an external client across a variety of domains.

The process starts at the top and goes around clockwise with the red labels of ‘discover, define, develop and deliver’. This follows the British Design Council ‘double diamond‘ where discover and develop are divergent phases, and define and deliver are conceived as convegent ones. Putting this into a wheel is based on a DNA Wheel diagram from Sarah Drummond in her Embedding Design presentation.

The process also overlaps with the creative problem solving (CPS) stages used by Basadur, and thus also suggest phases and activities for each of the stages. While that breaks everything into eight phases of the circle, we can see them mapping onto these same four phases without too much trouble.

The orange labels suggest activities for each of the phases. I assume that each group will use all of these in the phase in co-creative work with the client. After fact finding and understanding the issues involved with the client, then they will brainstorm and ideate possible solutions. One or two of these will be rapidly prototyped according to whichever will provide the ‘biggest bang for the buck’, or some other logic about a return on the time/effort invested. The best of these ideas will be carried forward into the next phase where a more detailed prototype will be developed and refined based on user feedback. Accepted and validated ideas from the prototype will be moved into the deployed version that is released.

The blue labels suggest specific activities that will implement the orange activities. You can assume many more of these, and these are here only as typical versions of the activities I expect to use with the students. During the discovery phase this will include empathy maps and personas based on interviews. CPS can be used inbetween the discover nd define phase, while StrategicPlay sessions using Lego Serious Play can be used in the define phase. Needless to say many of the ideas in GameStorming could also be used here too.

The green labels are ways to help learn the blue labelled activities. They are there to provide another aspect of the process.

I see the Plan, Do, Check, Act (PDCA) from Deming, and the Build, Measure, Learn from the Lean Startup cycles sitting between teh ‘define’ and ‘develop’ cycles as ideas flow back and forth between them. Successful, ‘validated’ ideas move onwards to the ‘deliver’ phase.

The next step for me is to flesh this out some more with specific activities for the students in each phase along with more detailed notes and references for them. I’ll put in more references here too, for the rest of you too. In the meantime, please leave any comments about this you may have.