Check the error messages

The new ‘learn by doing’ MSc has gained approval and will start this September with a second group starting in January. While the degree idea I’ve been pursuing for a while didn’t end up being one where teams would work on projects for other businesses, which is what I thought would be most useful, this didn’t get approval higher up the university. However, a colleague suggested a change, which did make it more acceptable, and indeed possibly more exciting too: instaed of working for others, why not have the students start their own businesses while doing their degree? This makes it a ’startup degree’, which builds on top of other things we do already, and in some ways is even more suitable for learning by doing. This will not be the traditional entrepreneurship degree where you study other people’s startups. This is you working on your own startup and applying what you learn to your own customer development process. This is you living, breathing, learning and bootstrapping your startup.

We’ll have space set up for the students to work in, and mentor them throughout their year. We’ll also remove the need for exams on almost all courses, and gather their coursework for assessment instead so that we use the artefacts generated by the startup team instead. The coursework could be based on business model canvases, customer journey maps, business plans, prototypes, results and analysis of ‘build-measure-learn’ cycles, and minimum viable product source code too. The choice of what to submit is up to the students, who will also need to keep a journal of their own reflections on the year too, and how they see their team(s) working, or not, and what they learn from the experience. This self-reflection is important so that students demonstrate they are learning suitable habits to help them after graduation, and also to ensure that every course is based as much on individual work as much as group work.

The approach used on the programme will be ‘learn by doing’ so most of the time the students will be working on two applications/products each term. This is so that they all have a good exposure to different types of teams, and also so that they are developing a varliety of different products. The development ideas will be a mixture of ‘lean startup’ and agile informed by service design to provide for the co-creation of the early prototypes so that ideas are validated early. The teaching will be delivered through workshops and seminars most of the time.

This programme should develop students experienced in entrepreneurship with a good understanding of why they use different approaches, and know when to give up on an idea and to learn from failure. Most of their ideas will presumably fail, but that’s ok as they’ll be able to start another idea the next day, and they’ll learn how to build their creativity using a variety of techniques so that they always have many ideas to draw on for possible startups. For them it will just be another ‘learning opportunity on the way to graduation. Graduates will be valuable additions to establised as well as startup firms, who know how to develop, confirm, and grow ideas worth pursuing. If this sounds like someting you might want to do, then find out more and apply here, and if you have questions, then don’t hesitate to get in touch with me.

Oh, and in case you’re wondering, no the university won’t own your business. You will.

I was at Play4Agile the unconference for games and playing to help teams better perform again this year. This is full of about 80 agile coaches and others interested in using games to learn. I shared a room with @sven_kr, which was nice as I’d not seen him since last year. It was also good fun meeting up with @eegrove and @gwww plus @kurt_haeusler in Frankfurt the night before, and hanging out with @eegrove again on the way home. Lots of time to talk and discuss ideas.

As with last year, I took home a lot of ideas, and had a good time with friends old and new, as we took over the sprawling seminar centre where the event is held in the hills some 30 minutes south of Frankfurt. I should also point out that ‘games’ are not video games, but rather card and dice games, paper and scissors games, and of course games using Lego.

The pre-conference session was a mini-jam run by @adamstjohn and @markusedgar where participants developed ideas to make the conference more interesting for those who couldn’t make it, and also ways for those who didn’t go to one session able to better understand what happened in other sessions. This resulted in a number of brilliant ideas such as the tumbler blog of photos with the #p4a13 hashtag, the ’speed dating/meeting’ sessions at lunch and dinner (sit at appointed table and ask prepared questions from the deck on the table as a way to meet new people), the podcasts, the puzzle boards for putting ‘thank you’ notes, and comments about the conference that were scattered around. This mini-jam session was a great introduction for me of the Global Service Jam the following weekend, which Markus and Adam organise, and as a host for the Aberdeen one, was very useful to see how they work their jams. Helping to make the opening credits video for their event was also fun, as was the birthday party and midnight feast for @julezwitschert.

There were lots of sessions that were very useful for me. ‘Useful’ insofar as I learn something I can take back to the classroom. In no particular order the ones that stuck with me were a session by @ralfhh re-introduced me to the Kanban Pizza Game, which I hadn’t played since Agile Lean Europe 2011 in Berlin when he was prototyping the game. Now that I’ve played it and worked through a ‘what happens next’ session on the game to see where it can go next, I’ve seen how it will balance the beer game played at the start of a course. The students had asked if they could play the beer game again, but I think the Kanban Pizza game might work better for them to see another way of managing a system.

A session by @sven_kr and @cuxdu on Lean Startup using Lego was brilliant in exemplifying what can be done with a bit of Lego and idea formation. This will be useful in the future.

A session by @cuxdu on creative problem solving, reminded me of a process that I’d forgotten about, which this time pointed out to me that I can bring more games into the classroom if I change the location of my class now that I know how many attend. There is still the four weeks after the Easter break where I can try out different games if we have tables instead of a lecture theatre.

A session by @olaflewitz and @zucherart on real options was great to remind me that this needs to be discussed more in classes, as plans change, and we have different choices at different junctures, until we commit to one specific action, and until then everything is ‘an option’.

A session by @IlIlIIlIlIlIlII where we played a lean workflow game developed by @vanschoo went well and is another one I’d like to bring into class too as it too shows how you need to change the system to improve results, and this means reflecting on what the system is currently.

The Lego StrategicPlay retrospective session by @p_roessler was a useful reminder of how these sessions are run by others, and to see what variations work, and what can be done to keep the session short, and how varied they can be with just a fiddle pack to use for Lego bricks.

The session by @jacquiello on minimalist games using what’s in your pockets was wonderful in reminding us that it’s not always about the equipment of the game, but what the players bring with them in attitude and openmindedness. This too could be an interesting game to try with students to see what happens with simple rules.

I didn’t get to the ‘5 minute games’ session, but was inspired by it to think of ways to use simple, ‘no equipment needed’ type of games in my lectures and found some to work with amongst the game books I have. I thought they went well, and the students liked them too I found out later, and understood the points the game made in the class.

Play in the classroom is good and should be in all classes if possible. Play can illustrate a point more effectively than a lecture on its own as students experience the issue themselves, and through their emotional involvement, plus physical activity during the play make a better bond with the concept too. All of this is to the good.

At this conference learning is happening all of the time and games are played ad-hoc in the bar until the small hours of the day, and even over meals too. The games in the bar were for fun (werewolf, flux, and fiasco), while other games were prototyped some more. Lots of talking and catching up with friends also happened, and it wasn’t just the young folks who staying in the bar all night either. For some of us, little sleep is a fine price to pay for talking with friends discussing ideas, and sharing stories and learning all of the time.

The beauty of Play4Agile is that it provides a wonderful space for the participants where they feel safe, and well looked after so that we can try new things and know that if we fail, it’s ok. It’s a ‘learning opportunity’ as was often said during the weekend. The organisers provided space ‘for the magic’ as shown in this drawing by @p_roessler in his session on gamifying.

where the magic happens

One of the most memorable and fun sessions that came out of the Friday pre-conference session from @teamfuture17 and ??? was the ‘blindfolded snowball fight‘ at Sunday lunchtime. This was fun to think about and to play. A good way to change pace for the weekend and take a break.

Yes, this is possibly the one conference I look forward to the most each year, and it is a lot of fun, but it is also the one I think I learn the most at. Maybe it’s because it’s full of wonderful people, who are great fun to be with, but also it’s because you never know what will happen, and what you’ll learn. It’s also over all too soon usually, and you then realise that you didn’t speak to this person, and that person, which you meant to do too. Bother. I guess that’s what Skype and Twitter is for and I’ll need to catch up with those people that way.

Last year, P4A for me was more about ‘what being agile’ means, and ‘what possibilities’ are there for each of us. This year my take away message seems to be, to remember what you’ve done before as a few sessions reminded me of what I had forgotten, while the other message was about ‘what can be done now, with what you have to hand’. I look forward to next year already. In the meantime, watch the blindfolded snowball fight we had.

I did an intro to test driven development (TDD) talk for TechMeetup Aberdeen last night and started with the ‘simple TDD game‘. I modified the game based on comments there, and made a few changes of my own. I used 2×4 Lego bricks as ‘rulers’ to be the ‘testing tool’ as this was easier than finding a large number of actual rulers. I also added the ’round zero’ as suggested to show ‘current state’.

I wanted to try this game as it was the only TDD game I could find that wasn’t also a coding exercise. I wanted a way to introduce TDD to an audience that held a mixture of developers and others. It also let me try the game to see how it might work with a larger group of students by way of introduction to TDD at a later stage.

My modified game ran as follows:

Three one minute rounds with variations:

The ‘dev’ folds the paper where  a fold should be, say 1.5cm, or 3cm in from an edge, or in our case use a 2×4 Lego brick (3cm long), but you could also use paperclips or something else that’s readily available to use as the ‘inspection tool’.

The ‘tester’ measures the fold to see if it meets ’spec’.

At the beginning of the round, have the team estimate how many accurately folded pieces of paper they can produce in the 1 minute iteration. Keep track of your score on a piece of paper.

Round 0 - Throw it over the wall simulation

There is no talking

Sit back to back, or maybe at different tables in the room if space allows. We were in a lecture theatre so side by side seemed to work ok. The dev should fold as many as possible and hand them to the tester, who should test as many as possible.

(You could discuss ‘queue’ wastage comments too about ’stack’ waiting to test, and feedback loop on ‘right/wrong’ during retrospective of round.)

Round 1 – Test After Development (TAD) simulation.

In this round, have the dev make the fold and the tester measure the placement of the fold. If it’s right, then good work! However if it’s not exact, then the paper is given back for a refold. At NO time can the dev person utilise the ruler, this is only to be used by the tester.

Once they ‘team’ get the fold right, the unit of work can be counted as complete.

Round 2 – Test Driven Development (TDD) simulation (almost pair programming)

Allow the dev to utilise the ruler, the ruler in this instance simulates the ‘test’ by having the dev use this the fold should be right first time. The tester can help in whichever way seems suitable.

At the beginning of the round, have the team estimate how many accurately folded pieces of paper they can produce in the 1 minute iteration.

Finish, review the scores, discuss the insights from the game and relax.

We did brief retrospectives after each round to see how many people completed successful and what the ratio of folded/correct was for the teams. We didn’t go into comparisons of team practices, but that would be something to consider for a longer session perhaps.

One team inadvertently tried batching the folds as pieces stuck together, which led to a brief discussion of whether this would be a good idea or not. After pointing out that when it worked, this was fine, but that ultimately you’d be letting through untested pieces as you’d only be sampling the output to some extent and feedback would be delayed. Batch size of one is the preferred process for this game.

Some discussion went on about how the game rounds related to programming, and tied into these questions which brought home the main issue of shortening the feedback loop between coding and finding out if there were errors, or bugs.

1) how many of you work with legacy code? (legacy == untested code from Michael Feather’s definition)

2) how do you know your code works?

3) how do you know the new code you just added didn’t break the old code?

4) when will you find out if something broke? (how long is the feedback loop?)

5) what would happen if you speeded up this feedback loop?

The game ran well with the usual fun and noise you get with a good game as people realise the changes they need to make, and cheers at results become known. The one minute rounds went by very quickly and teams that thought they might fold 25 or more pieces found they only managed 10 or so, of which maybe 3 or 4 were ‘to spec’.

In any case this is a game to try again with a larger class. I also want to find a way to do this with only Lego so that I don’t need to keep cutting/tearing up pieces of paper, which become a chore quite quickly. Still, nice game and maybe it’s fine as it is now.

Thanks to Hurricane Four for the game!

The agile classroom in the university should be a cohesive concept that forms a thread through the student’s degree. As the student learns more in the classroom through a mixture of lessons and exercises, there should also be opportunities to use this knowledge in the wider community of the university and its local community. After graduation the student should be able to find suitable work without too much trouble thanks to the mixed education of  lessons in the classroom as well as applied work in the community. This in turn should encourage more students to apply to study at the same place and form a virtuous circle.

That is the short version of the Agile in the University Classroom talk I presented at ALE2012 in Barcelona on 29 August. Each of these components can be expanded further so that we have a better idea of the student, the courses and degrees on offer, the community and the people involved such as other students and staff.

The students are at different levels of ability, which need to be supported in different ways. These range for beginnings to compentent on a Dreyfus model scale (more specifically), or ’shu’ and ‘ha’ in the martial arts model of learning. In other words, the students are mostly following the rules for the subject they are studying, and some will start to understand the rules enough to know when they can be broken by the time they graduate. We can help to push them to these limits of their classroom abilities if we can also find ways to bring the student into situations where they can use this understanding developing applications for and with the wider community. This will energize the student when they return to the classroom and provide a better context for deepening future learning.

The courses taken by the student should cover the whole software development process in an agile manner. This should include the four process phases: define, design, develop and deliver stages, and not just focus on the obvious deliver stage where the software is built. Rather, the courses should include service design and design thinking in the define and design stages, as well as continuious integration understanding in the deliver stage. Therefore the student should be able to learn about all of the stages and understand how to work within each of them in an agile manner. Ideally, they should also be able to do this within the community too, so that their understanding is gained in context as part of their degree.

The community offers a number of opportunities for students to gain praxis with their classroom skills. There is athe local community of developers, designers and enterprenuers, who can come together and build up their skills in a mutually supporting fashion through coderetreats, hackday events, and sharing of experiences through workshops and talks. There is also the academic community with its research projects that will need applications developed. There is also the local business community that also needs applications developed. In both of these cases the students should be collaborating together to build applications, and not aiming to undercut the local market for software developers. Where possible the students should be able to attend placements (internships) with software houses to learn how their classroom skills translate into everyday skills at new levels of understanding.

This is the idealised situation of course, and not all of the pieces are in place. Resistance to them can be from a number of directions. These are new ideas that will disrupt old patterns of learning, and change some of the nature of work done by staff too, but also bring in a number of benefits in that their projects should be developed sooner with the help of students practicing their skills. Others will worry that some of these ideas will need some trialing to ensure that the idea is  implemented in a suitable manner, which means that mistakes will be made along the way, and that scares some people, who fear that this will reflect badly on them, and not that it merely means the implementation needs to be improved.

Students will also worry about this approach that sees them working on projects and not saving the project through their ‘hero programmer’ efforts of nightlong coding sessions. They will understand this better when it is seen in context of their work and discussions in the wider community.

An agile classroom at the university is possible and is being developed. It takes a community to build this and a community also benefits from this too.

These notes were used on a Windows 7 machine to create an Ubuntu Server and started with the notes created by http://notesofgreg.blogspot.co.uk/2012/04/slim-rails-environment-v2.html who started this after discovering my Vagrant notes didn’t quite get him where he wanted to be with Ruby and Rails development. I started with those and then added more parts as I was doing this behind the proxy and wanted any student to be able to copy what I’ve done to tweak their own version of a Linux box. I also referred to http://munkyonline.co.uk/articles/lamp-ubuntu-server-on-virtualbox for general creating vm and http://www.ubuntu.com/download/help/install-ubuntu-server for ubuntu server ISO.

We use a ’server’ and not a ‘desktop’ ISO so that this is a smaller installation. Hence we only use a lightweight ‘desktop’ like Fluxbox. We still can use our Windows desktop, so we only need lightweight tools for this virtuarl machine.

Start with ISO

Once you have an ISO you can start it up and install it into VirtualBox.  You will need to set the proxy if at the university so that you can download more software as needed in the box. Just follow the defaults for the most part and let it use the whole partition. Set yourself easy username and password. This is a virtual machine remember so you don’t need to be paranoid. You can also tell it to install Postgresql during this phase too.

When the installation is done and you’ve logged back in again with your new account you can start adding the software you want to use for the application.

I found you need to set the proxy again for the session with the command:
export https_proxy=http://proxy.abdn.ac.uk:8080

If you need to set the root password then look at https://help.ubuntu.com/community/RootSudo and at
http://ubuntuforums.org/showthread.php?t=1599832 at end of page for running as su with root

This setup uses fluxbox as a lightweight desktop (right-click) for any options. You start the ‘desktop’ from the command line with ’startx’ command and can right-click for menu options. When you’re done you drop out of the desktop with ‘right-click->exit’.
You can stop the virtual machine with ‘machine->Close and select ’send Shutdown signal’ ’so that pick up where left off before.

Installing the system

#System
sudo apt-get install xinit
sudo apt-get install fluxbox
sudo apt-get install build-essential
#Node.js Rails will not run without a Javascript Engine
sudo apt-get install python-software-properties

#might not need next two steps, try setting proxy first, but may need to also run this as su and thus set password for root. Try to avoid that though.
#set password for su
#switch to su and add proxy details so that su knows them.
export http_proxy=http://proxy.abdn.ac.uk:8080

sudo add-apt-repository ppa:chris-lea/node.js
sudo apt-get update
sudo apt-get install nodejs

#imagemagick so that we can manipulate images on the server
http://www.imagemagick.org/discourse-server/viewtopic.php?f=1&t=20814
sudo apt-get install imagemagick libmagick++-dev

#Sqlite3
sudo apt-get install sqlite3 libsqlite3-dev

#Postgres <<– you need this for working with Heroku
sudo apt-get install libpq-dev (you may get some errors and also need to run sudo apt-get update to fix things, persist, it should all work)

#Rails
sudo apt-get install ruby1.9.1-dev

sudo apt-get install libxml2-dev libxslt-dev (cucumber/nokogiri)
sudo gem install rails –http-proxy http://proxy.abdn.ac.uk:8080
sudo gem install sqlite3 –http-proxy http://proxy.abdn.ac.uk:8080
sudo gem install heroku –http-proxy http://proxy.abdn.ac.uk:8080

sudo gem install rspec –http-proxy http://proxy.abdn.ac.uk:8080
sudo gem install rspec-rails –http-proxy http://proxy.abdn.ac.uk:8080

sudo gem install cucumber –http-proxy http://proxy.abdn.ac.uk:8080
sudo gem install cucumber-rails –http-proxy http://proxy.abdn.ac.uk:8080

sudo gem install rmagick –http-proxy http://proxy.abdn.ac.uk:8080
sudo gem install heroku –http-proxy http://proxy.abdn.ac.uk:8080

#rails new cookbook -T (t flag keeps tests out)
#cd cookbook
#bundle install will get the rest of the gems

##Other Programs
#Terminator (Better terminal)
sudo apt-get install terminator
#scite for editing files
sudo apt-get install scite

#Google Chrome (web Browser) - that is a capital ‘oh’ NOT a zero in command and each ’sudo’ is a new command
sudo wget -q -O - https://dl-ssl.google.com/linux/linux_signing_key.pub | sudo apt-key add -
sudo sh -c ‘echo “deb http://dl.google.com/linux/chrome/deb/ stable main” >> /etc/apt/sources.list.d/google.list’
sudo apt-get update
sudo apt-get install google-chrome-stable

#sqlitebrowser (SQLite3 browser)
sudo apt-get install sqlitebrowser

#git
sudo apt-get install git

#enable shared folders on machine
http://www.sysprobs.com/maverick-meerkat-ubuntu-1010-virtualbox-328-ubuntu-1010-guest-additions-fix

#change permissions on shared folder so default user can use this folder and edit files (edit in Windows on Komodo and run commands in Linux)
http://manpages.ubuntu.com/manpages/intrepid/man8/usermod.8.html
http://www.ubuntuka.com/add-user-to-existing-group-ubuntu/ but group is now vboxsf
#need to log out and back in again for this to take effect

Winding up

You’re now done and should be able to do all that you need to do in a Linux box on a Windows machine. This should take lots of the pain of Ruby running on Windows away. So that you have a better idea of what you’re doing you should also look to these links for more help:

https://help.ubuntu.com/community/UsingTheTerminal for more on commands

http://fluxbox.org/ for details about the windowing manager installed

you can edit the menu for fluxbox so that Terminator and Scite are included by opening .fluxbox/menu from your home directory and adding in the three lines starting with [exec]. The result just adds them to the end of your menu, so if you want them grouped in another location then follow the instructions at the top of the full menu which is included there under the ‘etc’ directory.

begin] (fluxbox)
[include] (/etc/X11/fluxbox/fluxbox-menu)

[exec] (editor) {scite}
[exec] (console) {terminator}
[exec] (google chrome with proxy) {google-chrome –proxy-server=http://proxy.abdn.ac.uk:8080}
[end]

Look at http://www.makeuseof.com/tag/8-great-alternative-desktop-managers-for-linux/ for alternatives to Fluxbox if it’s too minimalist for you.

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.

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.

Steven Milne and I ran the first CodeRetreat in Aberdeen on 21 April and a little under twenty people turned up on the day. Adrian Mowat from EdgeCaseUK facilitated the event for us and kept everythign moving along smoothly.

Adrian ran the traditional CodeRetreat format and had everyone coding in pairs to develop Conways’ Game of Life in 40 minute blocks using test driven development (TDD) followed by a short retrospective and then a switching of partners. After the first two sessions everyone had laptops all sorted for running TDD and they focused clearly on coding tests and having fun.

Thanks to sponsorship from Codify, Fifth Ring, the Aberdeen Software Factory at the University of Aberdeen, and EdgeCaseUK we had food from ItsyWorld, which was wonderful as always.

By the end of the day after six sessions of pairing one pair had the game running in Javascript and everyone had a much better understanding of the value TDD brings to coding sessions. Thanks to all who came along, or sponsored us on the day.

In case you’re wondering. Don’t. We will run another CodeRetreat later in the year.

I’m trying to find out if there would be any interest in a degree where you mainly ‘do the work’ and learn through discussion with fellow students and mentoring staff, who can guide you to what you need to know. There would be no exams on this degree and it would all be done via coursework as groups and individuals over a year. So read the following and put something in the comments please, or email me your comments if you prefer.

The basic idea

My idea is that the ‘clients’ would be local businesses, who might need some prototype work done to prove/disprove an idea, but also maybe a research group which works with local groups to explore issues and problems, or maybe charities too. Even more exciting would be if a student had an idea for a start up, which we could develop over the year. I know from other work done with the Aberdeen Software Factory that we can find lots of projects on which to work, so that’s not a problem. I think this idea would work, but I need to sanity check it with the public. So, I’m asking, does this sound like the sort of thing you’d be interested in?

As a student

Would an MSc where you only did group work with real clients for two terms appeal? You still do an individual project in the summer. The goal is for students to learn to successfully develop software solutions while helping to solve local and global problems so that they have a portfolio of external client examples by the end of the degree. Does this sound like it would appeal? What more would you want to know before you signed up for such a degree?

As an employer

Would you want to hire people who had a track record of workinig on four or five projects the previous year with a variety of clients be ideal? What would you want to know they’d done over the year, or just have them be able to point you to websites, or applications in which they’d made a contribution?

As a potential client

What would you want to get out of this sort of arrangement? Assume that all of the IP can be sorted, as I’m told it can be based on current types of projects underway at the university. What else would you want to know before you committed to such a collaboration?
Like I said, I think this is the way to go: learn by doing and then do it some more to develop good habits. This is also what is suggested as good practice by any number of reports on employability and learning and of course, the big universities do similar project based work too. Sheffield does its MSc work with Genesys at the MSc level, which is what inspired the Aberdeen Software Factory in the first place. We should aim to do what we can at our level and find our level and then get better.

Now that you’ve had a read email me something, or put something in the comments. Thanks.

As some of you know I’m into the whole Lego for teaching thing and have used it for a few years in some games with students, and that you can find some of the bricks in my office. Some of you may have also noticed that since last September my laptop has a ‘Play Changes! StrategicPlay’ logo wtih Lego minifigs looking over the edge of a wall. (Ok, a plate if you know your colloquial German expressions, if you must).

Anyways, I just finished my StrategicPlay® facilitation training in the process and it was the best training session I’ve ever had. It was awesome. Yes, really. Now that I’m at the Play4Agile conference (twitter stream of #p4a12 hashtag), it seems the right time to write this up before I’m back at work.

If you need to help your clients discover their strategic change options in business, or how different changes in their business environment might impact their business, then StrategicPlay® (website) Lego Serious Play (LSP) facilitation training is what you too should have. This will help you more than you think as described in the StrategicPlay® prezi presentation and the case studies on the Canadian site. You can also find LSP case studies on the Australian MCI site who collaborates with the other two sites.

Lego Serious Play is not what kids use

Yes, you’re probably thinking Lego, kids toys and what’s that going to do for my business clients? I can’t go to them and suggest this sort of thing as they’ll laugh me out of the office. However, this is different, as I’ve mentioned before in an earlier post on LSP.

As noted in the earlier article, I’ve been reading up on this subject for a while and thanks to chats with Katrin Elster at StrategicPlay® (Twitter) , I had some understanding of the process and its benefits. After getting some Starter Kits thanks to a grant, in late January I ran a session with students and their group project clients, which went well and I discovered this really worked well as a group kick off for projects. The team members all had a common understanding of the ideas and goals of the project. Real cool! It also helped bring the teams together.

Three Days in Hamburg at StrategicPlay®

Come February I ended up in Hamburg at the StategicPlayground in the StrategicPlay® (Facebook) headquarters with my five fellow classmates and wow! We learned a lot in our three days.

I learned that brain work, which is what we’re doing from 9-6 each day with an hour for lunch, is hungry work. This is made easier by the great food of endless coffees, juices, fruit and cakes, provided by the staff and the fabulous lunches in a nearby restaurant. There are also celebratory drinks in the evening when you discuss how the day went and what issues might still need clarifying.

I learned that I could trust the process of using the Lego models built by workshop participants to illustrate metaphors. This is how Katrin teaches the facilitation training: you run through the process three times; once each day. The first and second days you are the participant, while on the third day you and your classmates each take a section of the process and Katrin is a participant too. The workshop sessions are balanced by theory sessions in another room, which on the third day is also where you have the debrief sessions of the workshop stages you ran with your team members.

I learned that what I thought I knew was the tip of the iceberg. There is so much more that I had to learn and that reading and running a few sessions is not the same as the full facilitation training. They are so much different, and I suspect it would’ve taken me years to learn on my own the lessons I gathered during three days in Hamburg. The third day is what makes the difference. After two days you may know all that you need to know to run a session on your own, but the ‘graduation’ session you run with your team members and the accompanying debrief show you what you need to know and put all of pieces together for a real day-long workshop. Yes, it will still take me a while to sort out the first one I do, but now I know what’s involved and what questions to clarify with a client before I do it in order to make it run to its maximum potential. Sure I’ll be nervous, but I’ll also know that as I did it once with friends, that this time on my own it’ll be ok. I’ve already made the beginner mistakes in a safe environment so I’ll be fine when it counts.

I learned that the StrategicPlay® Lego Serious Play process is everything I thought it would be and more. It builds upon the process discussed in the LSP open source document. This document only scratches the surface though, and you learn more with Katrin at StrategicPlay® about how to develop this tool of creative problem solving.

In the coming months and years I know that this new part of my toolkit will help develop my career and change my teaching forever. I’m not the same person who waked through the door in Hamburg on Monday. I’m better prepared for challenges ahead thanks to Katrin and the new friends I made at StrategicPlay®. Yes, it was hard work, but it was great fun too. We had lot of that: plus laughter too.

What others say about StrategicPlay®

But you don’t have to take my word for it. You can see what others say too:

Michael Sahota videos on StrategicPlay - he was trained through the Canada office

Michael’s description of the StrategicPlay® training process

Olaf Lewitz did his StrategicPlay® training with Katrin too and wrote about that training. He also wrote another piece on her awesome facilitation skills too.

Thorsten Kalnin did his StrategicPlay® training with Katrin too and wrote about his introduction to the StrategicPlay® process as a means to envision the Play4Agile conference, how he became a trainer and what the session was like for him too. He also wrote how he co-facilitated the strategy session that launched the Agile Lean Europe network.

Pete Roessler did his StrategicPlay® training with Katrin too and wrote about how easy it is to use Lego Serious Play for solving complex problems.