Dancing Peacock by Hamed Saber

Here’s why:

As a writer, I want photos to go with my blog entry, so that it looks appealing for readers and inspires me to write more.

Brickpit Ring Walk Bicentenial Park by Louise Docker

As a presenter, I want photos to go with my slide, so the slides have metaphors that make people think, and my presentations look well prepared.

For these two stories we might not have bothered writing a web application – we could use the regular flickr search. However:

As a writer or presenter, I want to easily credit the photographer so that I can fulfill the obligations that go with the license and give viewers the opportunity to see more of their work.

I used to have Super Human Powers by Esparta Palma

We found that finding photos to go with a presentation was easy enough, but collecting the credits and then adding an attribution to the photo in a blog entry or the end of a presentation) often turned out to be a lot of clicks, which meant that we would not add photos to presentations as often as we like…

How does it work?

Photo Suggest queries Flickr and searches for photos with a liberal license (see the about page for a short list) sorted by interestingness. If you click on the link below an image, it takes you to the details page that shows the full credits, license and description together with the image. The reason we called it ’suggest’ is that when you type a keyword, the results are often not what you’d expect, but can more often than not make an interesting contribution to your text.

How did we get here?

With QWAN we try to apply lean and agile principles to everything we do, so we reflect at our ways of working continuously, identify things that add value, and do more of them, as well as things that are wasteful and eliminate them. We started to give more and more presentations to get the word out – we love experiential sessions over anything else, but they do not get us into more traditional conferences. Styles like Presentation Zen led us to do more with images.

Presentations with attractive imagery inspire me more when I do a presentation and they seem to energize the audience as well, so it becomes easier to add experiential elements (small exercises, questions) to a presentation.

Marc Evers and I have been thinking about how to improve our presentations as well as the way we produce them for a while. This led to a bunch of wild ideas, which we used as stories for the new new new! product development game – participants have to plan a ‘presentation 3.0′ project.

With Lasse Koskela I ran a Scrapheap Challenge at XP2009 – participants have to write a working application in half an hour. For that we needed exercises. Some stories from the game seemed well suited, so I did a small experiment – in half an hour I got quite far. Then I called Marc and asked him if he wanted to help me finish it into a working application. We had noticed we were losing some of our “superhuman powers” , so Marc suggested to “start from production”, which meant I talked him through the app while we brought it into version control and production, before adding more features & polish.

From experiment to production took half a day. After a day it was usable enough (but was missing the finish such as about page and stylesheet) for us for blog entries and presentations. When we demoed it during xp2009 a few participants jotted down the url, which encouraged us to polish and publish it.

What Can We Do With Flickr? by Alan Levine

We hope you enjoy it! Your feedback is welcome.

• “Traditional” linear backlog planning we know from Scrum and eXtreme Programming,
• User Story Mapping, popularized by Jeff Patton. This takes into account User goals and actions. It can help you build a working application soon, taking into account as many goals as feasible,
• Dimensional Planning, popularized by Koen Van Exem. Like User Story Mapping, it focuses on the medium to long term. It helps to develop a Minimal Marketable Feature Set, trying to deliver a broad application in the simplest form possible (also known as a ‘Dirt Road’ solution).
• Kanban, popularized by David Anderson and others. This can be combined with the approaches above, but in this game we let participants choose to develop one Minimal Marketable Feature (MMF) at a time, where they have to determine what the next MMF is after developing the previous MMF.

creating a Minimal Marketable Feature

We played two rounds, in each of the rounds participants chose an approach to plan and deliver features. For some reason nobody chose “traditional” backlog planning. With User Story Mapping and Dimensional Planning, three releases are planned and executed in sixty minutes. With Kanban as many MMF’s as possible, one MMF at a time, as fast as our fictitious developers can develop them. The groups that used Kanban got surprises after each MMF, both strategical (e.g. external customers change their mind) and technical (developers have higher or lower throughput). The other teams got such surprises after each release.

What implications that has I leave up to your imagination, alternatively you can come play the game some time .

Dimensional Planning

The game ran reasonably well for a first time. The participants had good fun and learning, especially in the first round. We got good suggestions to run the game differently the next time. Using the same set of stories for the two rounds acted a bit as a spoiler. The team that tried kanban in the second round finished very quickly; they had done dimensional planning in the first round, and were very quick to determine MMF’s and develop them.

This supports of course the theory that combining those things can be valuable, but makes playing the second round less fun. The team that tried kanban in the first round had no previous knowledge of the features and needed a lot more time – basically they went through the product vision again for every MMF, which was quite time consuming.

The Kanban part of the simulation needs a bit more work. We are probably going to develop a different set of cards that visualize throughput and one piece flow better. Due to the developerless nature of the game, an MMF completes at once in the simulation, which feels strange.

This week we will play the next iteration, as part of our Agile Product Development training. Probably only one round, with User Story Mapping and Dimensional Planning. The audience here is mostly non-technical people (C*O, business analysists, testers and some developers) and we focus on effective and efficient ways of release planning and story writing. We might introduce Kanban and dimensional pull on the side, with comments and ’show don’t tell’. I was inspired by seeing how Wim van de Goor and Stefan van den Oord used a task board during their Scrum Board Game to track and show progress of the workshop itself.

Thanks to the participants for giving us critical and constructive feedback, and Marc Evers for editing drafts of this post.

Willem and Marc introduce cultural patterns that can be found in software organizations. By understanding the cultural patterns then you can better adapt your practices.

The presentation starts off a bit slow, but picks up after the introduction. At the time we were incorporating some feedback about our presentations, most notably that we said too little about ourselves, so that the audience had difficulty understanding where we are coming from, and why we had to say something about the subject.

The videographer and editor did a good job at choosing the shots – shooting a pair presentation with one camera is challenging, especially since Marc and I are on opposite sides of the projected slide. The last part of the presentation was helped a lot by questions from the back of the room, I remember Keith Braithwaite and David Anderson (you can hear them faintly in the background) and there were one or two others. Next time I guess we could repeat more of the questions so they are more audible on the video.

A surprising thing we ran into was that Agile was not as mainstream as we thought – a surprising small number of participants put up their hands when we asked whether they were using (at least some) practices connected to Agile Software Development. Luckily, the patterns are independent of this, so we hope those who were/are doing something else get value from seeing various ways to organize development. It’s all about choosing an approach that fits and makes you more effective.

In hindsight the presentation became more graphical and less textual with each iteration. We’ve left the presentation alone for some time, and now have new ideas on presenting the material, as well as some new ideas on how to place various approaches to organize development. We’d love to hear from you about opportunities to perform new iterations…

Getting everyone to ‘crawl in the skin of’ their users creates simple to use products that do what they must and no more. Sometimes with amazing, simply beautiful interfaces.

There were presentations by:

• the BBC – Effective product ownership within a multi-component project by Mike Lowery and Marcus Evans,
• Yahoo – Less, Never more; Launching a product with critical features, and no more by Gabrielle Benefield and Scott Gatz, and
• Oxygen Ript (TM): Innovation and Collective Product Ownership by Ken H. Judy and Ilio Krumins-Beens.

The BBC story was on using the time of product owners wisely, I hope to write about that in a separate post.Yahoo’s and Oxygen’s stories are both about strong product ownership, focus on essentials, and last but not least: crawling under the skin of users. In the case of yahoo those were college students, in the case of oxygen women who are planning something, e.g. a home (re-)decoration or a wedding.

Both stories reminded me of ‘The Knowledge Creating Company’ by takeuchi and nonaka (1995). There is a chapter on how Panasonic created the first bread-baking machine. The chief engineer on that project had tried to understand bread baking from reading a book, and failed. Then he went to take lessons with a master baker in an Osaka hotel. He then tried to explain the bread-making and -baking process to his colleagues, and failed. Eventually groups of engineers would do internships with the master baker to get a ‘gut feel’ for breadmaking – this eventually helped them to resolve the myriad of constraints on a breadmaking machine.

Looking through the agile2007 proceedings, the written version of oxygen’s experience report actually mentions the knowledge creating company, I did not see that in the presentation.

If you are interested in product development, and haven’t read the knowledge creating company yet, I strongly recommend you do so. It is not an easy read (quite thorough), but you’ll come back with a more thorough understanding of product development.

The book also has good tips on how to collect knowledge and share it from one project to the next (or at the same time) – collecting and condensing knowledge takes time and concentrated effort – this gives project managers something to do with the spare time they get once their teams start to self-organise…