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.

Maybe because of the delay (we skipped May eventually) we not only have more items, they are also longer. We try to keep the newsletter short, but the things we discussed at conferences and while making the product development training gave us some inspiration to explain some topics in more detail. If the topics pique your interest, you can read it online or subscribe.

• “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.

I’ll process and post the rest of the photos when time permits – I decided not to do everything in a big batch this time (which sometimes means the batch never gets executed and photos are not published). Tomorrow Marc and I depart to Luzern, Switzerland for the first instance of our Agile Product Development training, so there is not much time left.

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…

It’s back in Sardinia, in the beautiful town of Pula so the place itself is worth a visit – I was in Sardinia once for XP2001 – it is stunning.

looking to the Sea from Pula fourtress by Alistair Young

Temple of Augustus, Pula by yellow book ltd

Haskell

This years’ conference had many sessions on a hitherto rather obscure programming language: Haskell. I knew the guys from the Paris CodingDojo (at the very least EmmanuelGaillot, ChristopheThibaut and ArnaudBailly ) have been jamming on Haskell for a while, I was surprised to learn Ivan Moore and Mike Hill, this years’ programme chairs also have taken an interest in it.

I am not exactly sure why. Maybe it is because Haskell is the ultimate MindFuck where it comes to programming languages that you could use in theory (and sometimes in practice) to do interesting stuff. Maybe it is because, if you do not work in really, really small steps, you are going to shoot yourself in the foot very quickly, so Haskell, TDD and a dojo (where in the randori form you have only 5 minutes at the keyboard before you have to rotate out) seem like a natural fit.

Ivan told me they thought it would be interestingly different to let Simon Peyton-Jones, one of the stewards of Haskell, do a keynote. SPA has a tradition of keynotes that are inspiring and different from what you would expect – Kent Beck did early presentations on eXtreme Programming at this conference (then named OT) 10 years ago.

Simon Peyton-Jones presenting the keynote on Haskell

The keynote was fun and interesting, explaining the kind of problems Haskell intends to solve, with some examples. You could say haskell is kind of a spreadsheet on steroids, although it lacks the graphics . The presentation was laced with code on slides, explaining important features in Haskell. About halfway through, unique for a keynote, Simon did some live coding, showing how the haskell program quicktest can be used to test new features. Quicktest exercises code with random testdata for cases specified in haskell, and when a test fails reasons backwards to find the simplest possible failure.

Apparently Arnaud Bailly and Christophe Thibaut used quicktest in their workshop on wednesday to test a java program, I would have loved to see it, but had to be at our Consulting Without Secrets workshop, which was good fun in itself and very useful for running our businesses; you can read through the outputs on the conference wiki.

Back to Haskell.  Sunday saw the RealWorldHaskell tutorial hosted by Peter Marks, Nicholas Simons and Ben Moseley. Christophe Thibaut paired with me, so we could work test-first. Unit testing was not part of the tutorial, but Christophe already knew how to do it. This helped us to getting reasonably far with the exercises.  If you do not work in small steps, I find the error messages sometimes difficult to understand.

Several Bird of a Feather sessions were scheduled to do more Haskell in the form of coding dojos. There was also a discussion BoF on why Haskell? which was packed – more people attended that than the hands-on sessions, which I found a bit puzzling. The dojos consisted of a Kata performed by Christophe and Arnaud, and a Randori hosted by Rob Westgeest. That meant I got to practice a little Haskell with switched-on colleagues every day. Pair programming and learning helped a lot.

Therefore, next Tuesday, April 28th, Mike Hill and I will be co-hosting an amateur Haskell coders’ dojo at the eXtreme Tuesday Club (in London of course).

Beatboxing

The SPA conference always has interesting ‘diversions’ in the evenings. Before the whiskey tasting there was a beatboxing tutorial, hosted by UK beatboxing championship Mc Zani. That was wicked.

Here you can see him in action for a ’slightly’ larger audience. Mc Zani knows his stuff and his facilitation style resulted in a relaxed workshop with surprising performances by some of the participants . Definetely worth it to attend one of his workshops if you get the chance.

Some of the remarks Mc Zani made about beatboxing made me think of programming, and the agile movement. Beatboxing is more than a party trick, but after it suddenly became popular again, the media are overflowing with mediocre beatboxers – people who see it as a party trick and are not willing to put in the effort required for greatness. Great beatboxers are still out there of course, but you have to go look for them.

Which brings us to the next topic:

Anarchy Agility in the UK

The other diversion was a Panel Discussion about 10 years of agility in the UK and bar night, with drinks sponsored by the eXtreme Tuesday Club . David Harvey hosted a panel discussion between early eXtreme Programmers Paul Dyson, Tim Mackinnon, Rachael Davies and Ivan Moore. Paul Dyson wrote about his optimism already:

Perhaps the Agile community has become a bit too focussed on certification rather than learning, on easy rather than effective methods, and on being recognised as ‘being Agile’ rather than achieving agility. But I believe that the world is changing in a way that will force the Agile community to adapt or die and I’m optimistic that we will achieve the former.

Paul was was a bit surprised about the agreement on failing agile projects in the room – since it was filled with agile coaches, developers etc. who have a ‘vested interest’ in agile. I have a vested interest (I am not retired by a long shot , coaching and training agile teams, and being test-infected I have to find places of work where I can at least write tests  (and preferably talk to the customers as well) . The agreement does not surprise me.

I still encounter shops (or rather, shops encounter me) that want to kick ass, but as ‘agile’ becomes mainstream we find more and more shops that are content to go throug the motions, or believe that by following some book ‘to the letter’ they will be somewhat more successful. I guess the room was filled with people who got addicted to high performance teams through the early days of eXtreme Programming. Stepping back from there into environments that lack the desire for excellence is hard.

Another thing that struck me from the panel discussion, was a remark by Tim or Paul about the early days of XTC. If something new came along, you would try it out just for fun and see if it would work for you. These days there seems to be more of a ‘not invented here’ syndrome hanging around, even in agile circles.

Paul’s optimism stems from the trend of mash-ups – applications that are made from other applications that already exist. Turn-around time of mash-ups can be a lot faster than ‘traditional’ applications, which will force the agile community to adapt or die (or perhaps ‘adapt or dye’   ).  In that context the postmodern programming conference organized by Ivan Moore and others a few years ago was also mentioned.

Lasse Koskela and yours truly already decided to adapt (embrace and extend ) – we will be hosting a Scrapheap Challenge, which is a shorter version of the exercises of the postmodern programming conference, during XP2009. We see the internet as a giant Scrapheap, and Challenge the participants to complete a mash-up instead of an application, from Scap instead of Scratch, in less than no-time.

In the meantime, I hope the photos convey a bit of the buzz that was SPA2009…

Tomorrow, April 15, Rob Westgeest, Marc Evers and I will represent QWAN with Giving your code some love at jspring in Bussum, NL. This  session is heavily inspired by Ivan Moore and Mike Hills’ performance at the Software Craftsmanship Conference. After the first line you write, your code is in maintenance. After that, the devil is in the details. We will show that even code that looks fairly decent can benefit from some more love and care.

Next up, on May 11 is Mini XP Days Benelux, where we will do a re-vamped version of Executable story specifications with RSpec with Marc Evers. Mini XP Days sees the most popular sessions of XP Days re-run. We got, ehm, sufficient ideas for improvement at XP Days last year, so even the title might change. What will not change is that it will be a practical session with live ‘coding’ on ’specification’ by example.

With XP2009 we had a happy accident. Quite a number of sessions got in. I was asked to organize the Open Space together with Lasse Koskela, and then decided if we were going anyway, it would be fun to do some workshops and maybe tutorials as well.

Marc and I had been ruminating for a long time, we wanted to develop some a simulation game for product development. This has finally resulted in The New New NEW! Product Development Game. Participants will compare several ‘new’ ways of planning (e.g. User Story Mapping, Dimensional Planning / Dimensional Pull, and Kanban) by doing. We will provide a sample project with user stories etc, they will make plannings in groups and then we will compare notes.

We thought it would be a fun change – since last year we have developed a lot of new technical material, which we continue to do. The New New NEW! Product Development Game will also feature as part of a (non-technical) Product Development course we are developing.

Lasse suggested we do a Scrapheap Challenge, since we both enjoyed the PostModern Programming conference Ivan Moore organized a couple of years ago a lot. This workshop will use the Internet as a giant Scrapheap, providing interesting bits and pieces to create an application in no-time. May the best team win!

Last, but not least, Marc and I will run the hands-on tutorial version of Promise is Debt – System Dynamics of Technical Debt. In which we introduce diagrams of effect as a way to understand how technical debt is created, and participants get to work on their own solutions.

I will probably add some more dates to the calendar (for instance the Open Space Code Day in June) as the quarter progresses. I hope to meet you during at least one of these events!

And even that is not enough. Systems thinking for me is one of the tricks we can use to get people to create a whole systems perspective -together- . And then the people present also have to be able to carry out the interventions they find.

Sitting in a room and inventing interventions for others to carry out is not my cup of tea.  I have done some management consultancy in the past, with and without systems thinking. It was difficult to make change stick, even when we interviewed a representative number of people to create a broad enough perspective. I guess it was because it was us, internal and external consultants, who made the final picture, collected data and suggestions, and then make some of our own. That meant not all suggestions and systems pictures were ‘owned’ by the people who were supposed to try them out… These days I would do something like that differently; for instance by organising an open space and targeted workshops, where all of the results are created in the room. Reports, if any, are made by the participants and/or are merely a textual summary of what was said during the workshop, with diagrams that were created on the spot.

Jurgen writes:

“With his book Complexity and Management Ralph Stacey convinced me that top-down systems thinking is a management fad. Weinberg’s diagrams may be useful to understand communication problems in an organization, but managers shouldn’t think these diagrams can help them solve those problems. Managers cannot directly control a social system by adding or removing relationships, nor by enabling or disabling communication. Managers are part of the system themselves, and communication simply happens. They can draw circles and lines until their fingers turn blue, but diagrams will never properly represent what happens on and off the work floor.”

Diagrams of Effect and other systems thinking tools have helped me most when I applied them with my peers on things that we had influence over. Note that influence is not control – the quality of ‘improvements’ we imagine have to be judged by their effect. So how do you get to properly represent what happens on the work floor?

Invite the “work floor” with their managers to tell stories and create diagrams plus possible improvements together.  We have been experimenting with systems thinking in technical training. In an object-oriented design training last week the developers invited a senior manager to the systems thinking part of workshop. In a short time many stories were told, diagrams were drawn -together- and possible improvements were identified.

We are busy articulating why we believe this approach works. I hope to post soon on how this seems to work, and how we arrived here. In the meantime, we’ve published our first technical training that includes participants doing systems thinking (managers are invited too, of course ) besides programming and design excercises.  We have incorporated forms of systems thinking in our explanation. It seemed to help in and now we are taking the next step.

We have good hopes the improvements everyone found in last weeks’ training will stick: the people who have to do most of the work to make it happen were present. That includes the manager. Developers can also draw circles and lines until their hands are blue – it is easy for developers to forget the hard work that goes into seemingly effortless management.

Finally, managers can make things happen that developers’ can’t.  For instance freeing up budget for training, build servers, deciding how new developers are hired and getting customers to talk to each other and to developers. So get everyone in a room, and don’t let them out until they found stuff that could possibly work