So last week, we finally got together around a whiteboard, decided that we did want to hold it in June (like last year, and as we planned), but we didn’t have a location etc. and didn’t want to spend as much time as last year in sending out invoices, dealing with exceptions etc.

So, we decided to go with an affordable conference location and leave things like hotel, dinner out of the basic package. That means we can send out just one type of invoice - you come two days, or you don’t, and  beside diet preferences there are no options. Well, you can of course volunteer (we got spontaneous offers for that. ) or sponsor.  We also decided to cap the conference at just thirty participants, so we could go with the venue. One of the reasons being, we thought we can’t get that many participants in a month anyway… Surprise, surprise, sending out the invite to a couple of mailinglists, and we’ve already passed the twenty participants mark. And we have some sponsors as well (we didn’t expect many in this timeframe, so we’re pleasantly surprised. Now we have to make sponsor packages and facilitate the other volunteers so we can self-organize )

So, without much further ado, I’m proud to announce the next

Agile Open Europe 2008

will take place in Utrecht, NL on June 5th and 6th. A vibrant place to push the envelope and do business together. And yes, we will find Belgian Beer - one participant listed that as a dietary requirement ;)  Looks like its’ going to be good fun again. See you there!

And if you ’still’ haven’t registered - there’s a handful of places left…

This was the only ‘red’ card in the retrospective we held today at the end of another eXperience Agile

Further there was one looking ahead (’Drink & book’ -meaning looking forward to drinks in the bar and receiving the book at the end of the course).

Personally I also loved ‘no more questions’ (I guess there will be more after a night of sleep). One thing we experimented with was shortening the iterations in Day 3’s exercises, so we would have time for a bit of questions and answers ‘open space’ style (or XP style - questions on post-its prioritized by the participants).

We had quite a number of ‘puzzles’ on Wednesday and Thursday, mainly open questions… And some red cards. Most related to traffic jams. Other cards we resolved quickly (not enough overview on the agend for the course - easily done with an extra flipchart, another one was that we had two pairs working off the same repository by accident, we still have some manual steps in installing workspaces that we do not yet know how to automate well due to the environment we are using. ).

Seeing the green cards, and the happy, exhausted faces, there probably was quite a bit of accelerated learning going on - and that is not a coincidence.

I ‘m especially pleased to see green cards where we used to have red and yellow - dilligent work, and keep on trying to improve a few things each and every course. I don’t know what we’re going to change in the next one (we have some ideas around acceptance testing and have been experimenting), but I’m sure we are going to change some things. We, the ‘instructors’ are also part of the learning community, and I strongly believe our own learnings accelerates that of the other participants.

Therefore we hold retrospectives after every course day. Sometimes in the afternoon, sometimes the next day. Where it makes sense we ’stop the production line’ and fix problems immediately, e.g. answer questions and gather questions for further discussion in a separate block or over lunch. In other courses this also helped us streamline exercises, the build environment etc.

As you might see in the green and yellow cards, much fun (green cards) and puzzles (yellow cards) come from the open source tools and games generously donated to the world. This includes the xp game, ruby, rspec, test/unit (included in ruby), firewatir, and of course techniques like XP, Refactoring and TDD that you can (amongst many sources) still read about on the C2 wiki and the XP mailinglist. And of course retrospectives.

I hope these happy colourful photos inspire you to experiment with retrospectives. A word of warning… besides focusing on what you can do better, don’t forget to celebrate the green cards (I have that tendency - still a bit of a perfectionist) and relax before the next round of improvments. Have a nice weekend

As with our courses, the brochure is also developed in eat-your-own-dogfood style. Work iteratetively, use small batches and feedback, for example. I’m still a bit weak on formal acceptance tests, but the main goal seems to be happening - sell more courses in more places - and have fun teaching them.

How did we do it? Marc found a printer that prints nice full-colour brochures in small batches, so we can apply feedback to each new batch. We started out by sending out the beta PDF to a handful of people, and feedback was so encouraging, that we made the first batch without all suggestions incorporated… We now have a small inventory of things to do, which we’ll process before the next print run.

I’ll bring some to the cultural patterns presentation in Houten tonight. I wasn’t sure at first whether making a brochure was worth the effort, having done some before with mixed results. So far it’s worked better than expected - the extensive descriptions and the wicked course-flow diagram Marc made come across well, and seem to make the courses much more tangible, which leads to better conversations. So all in all, making and distributing it is an enjoyable experience. Let us know what you think - your feedback is most welcome.

Tomorrow we plan to present the material in much the same way as at Qcon London, and spend the extra time we have on doing exercises with the participants, much like we did at XP Days Benelux and London last year, now with new and improved exercises . We’re getting better at presenting the patterns in a non-linear fashion and getting the idea across that one pattern is better than the other, but that they each have a context where they fit best.

After Beyond Agile in France, we took up the nice task of re-ordering most of the presentations, and drawing some of the choreographies you could see in the notes, so that we could tell stories more effectively, show the patterns in a context where they fit and explain why some choreographies are easier than others.

We start off with asking the audience questions about too much or too little process and whether they have been involved in some way in an agile transformation. At qcon, surprisingly little hands went in the air for any of the questions - so that might mean that agile is not that mainstream yet… We expect most people to have worked in either routine and/or variable cultures. Several people raised their hands on all questions . So that means it is a decent starting point - it is easy for most of the audience to picture what these cultures feel like from their own experience. Some of the others require a bit more explanation, as they are more uncommon or less easy to spot.

Routine and Variable can also help explain an endless source of conflicts within an organization. At Agile Open France there was a session on “Dev vs Prod” (Development versus Production - most of the participants worked in some kind of IT organisation where the Developers - people who program the programs - are not responsible for keeping the programs they make up and running - that is the responsibility of Production). Developers often prefer a variable way of working - being flexible, trying out new stuff and making the customer happy. When they hand their stuff over to Production, they are faced with forms and procedures - indicative of a Routine Culture.

Now, why would Production have these procedures?

Because (amongst other things), they have past experiences with Development handing in code that ‘Works On My Machine’, and even if the code does work, most software they have to use is Legacy Code. As Gildas noted at Agile Open France, most production software (e.g. mail servers, databases, some web servers) don’t give feedback until you restart it and go live. Some do some syntax checking (e.g. the apache web server), but even that is uncommon.

So any change to a production environment has a good chance of breaking it, which leads to the Production people getting complaints and working nights to get the whole thing back up and running. Wait, did I say working nights? That doesn’t sound very Routine, now does it…

Often when something goes wrong, a routine organization will temporarily go into a Variable state, in the hope that order will return soon. In the case of Production, going Variable is more unpleasant, because if you’ve been doing this for a while (I have, as a side project), you can feel in your gut that something might go wrong again, requiring even more heroic fixing… And this always happens when you least expect or want it (say, the day before you go on holiday…).

The two pictures with arrows already show two uses of the patterns:

• Predict and explain conflicts between parts of an organization
• Transitions from one pattern to another (and back) and why they happen.

And that ‘fixes’ one of the ‘defects’ we had in our presentation last year: explain early on in the presentation what we use these patterns for - we usually needed the Q&A round to explain the ‘why’… I hope to follow up with another post on another ‘why / how to’ : guide transitions from one cultural pattern to another, and explain why some transitions feel easier to me than others.

“[...]a small startup, should be working twice as hard as the bigger companies [...]“

Taken from tales from the WTF company, part II . If you work smart, read part I first…

Excercise for the reader: which cultural pattern does the WTF company exhibit? You get bonus points for identifying coping stances from the story as well ).

When Bob moved to the ABC Bank, he tried to repeat his recipe for success (weekly planning meetings and standups) and then later add stuff. This also would enable developers to deliver more value. Instead of being happy, they asked: “where are the documents, and procedures? How does my role/job description fit in a multi-disciplinary team? (’I like the security my role provides’) Where are the handoffs?”

This time Bob found himself in a place with a Routine cultural pattern - everyone follows the rules, questioning or evolving the rules is not expected behaviour. And when you introduce for instance bits of XP, Scrum or Kanban, people might complain there is not enough ceremony. We’ll explain why that is later. For now, Bob could not say more than “don’t worry” to the people who were worried about their job…

Bob learnt that a routine culture works well if the context is well known, and is characterized by:

• Feedforward control,
• There is a best way to develop software
• Silver bullets
  • Methodologies
  • We need a tool!
• Management by controlling
• Process oriented

We often find routine cultures in ‘Production environments’ (e.g. hosting of web-applications) and environments like banks and insurance companies where stability is more important than innovation. Organisations with a waterfall process (which I considered so far to be a red herring, as I didn’t encounter it much, but I’m getting more work in this area) can also be considered to be routine.

When Bob worked at XYZ Widgets Inc. , he wanted to introduce weekly planning meetings and daily standups to track progress and release products sooner with less overtime. He expected happy responses at the customer’s site. Instead, several of the programmers went : “oh no, not a one hour meeting every week! Just leave me alone to code. And those ’standup meetings’ every day, do I really have to be there? Can’t you do them without me?”

Later, Bob figured out he found himself in an instance of a ‘variable’ cultural pattern. Developers (usually a few) work very closely with a customer, and do whatever they feel like to give the customer what they want. Don’t bother to ask them when they can deliver - they won’t be able to give even a rough estimate. But, at some point they will deliver, because they like the customer.

Bob experienced that variable culture works well if the problem/challenge is small enough, and is characterized by:

• Close cooperation between customers and developers
• Craftsmanship
• Hands-off management
• Performance and quality totally dependent on individuals
• Heroes

Come to think of it, a variable culture goes pretty well with the values of the agile manifesto… So is it any wonder that co-workers in a routine culture are afraid when you mention the manifesto? They see heroism, variation in quality and they don’t dare to care about innovation, because their environment traditionally thrives on providing stability… And there is no reason to risk sacrificing stability (unless there is a crisis of course…).

Marc and I presented another iteration of “Beyond Agile - People versus Process” at qcon. This transcript was inspired by the re-done introduction. I plan to write some more soon… We had an article in production that we’re going to rewrite based on last weeks Agile Open France. The choreographies, the random order and the questions you saw at the top of this post worked well, so we are going to do more with that.

Notes of Beyond Agile. Click the image for the full-size scan.

I decided to propose a run of “beyond agile”, so I could try a different way of presenting the cultural patterns before qcon London this wednesday. The runs at xp days last year (then dubbed ‘people vs process’) were well received, and gave us ideas for improvement:

• we needed the question and answer time to get across why we believe these patterns are useful in our work (they help us determine where we are, and decide on a strategy on where / how to go next),
• attendees got the idea that one goes from one pattern to the next in a linear fashion. We then presented it in a linear fashion then, so surprise,surprise…

In this instance, I ditched the slides and presented from flipchart. After presenting the ‘why’, the participants did a round of experiences on the questions:

• ‘did you ever experience people telling you that your mix of ‘agile’ practices is too much process? ‘
• ‘did you ever experience people telling you that your mix of ‘agile’ practices is too little process? ‘

We then gradually constructed the circle, starting with the cultural pattern (’routine’) suggested in the story told by the last participant. Meanwhile, I explained some common choreographies (the arrows), each with their advantages and difficulties through stories:

We discussed more choreographies than could sensibly make the notes, and further discussions over dinner gave me some more inspiration. Even this ‘circular’ drawing follows the same linearity as in Gerald Weinbergs’ books. In wednesdays’ presentation we’re also going to talk about some other choreographies (e.g. going from routine, or routine to oblivious).

As you might guess from the notes, we ran the entire session in french. I needed to ask for some words, and probably my grammar is not up to par, but overall it went much smoother than I expected. The other participants were extremely helpful in letting me and Barry Evans speak as much french as we could, providing us with words when needed, and allowing us to switch back to english when we couldn’t manage in french - less and less frequently needed as the days passed .

So now it’s time to re-order the slides in a quasi-random order - some order that allows us to string stories together in a way that makes sense to the audience, add choreography slides and practice a bit more. I hope to see you at qcon on wednesday.

Agile Open Northwest, an alliance of agile practitioners in the US Pacific Northwest region, presents Agile Open Northwest 2008.

Our first agile open event, Agile Open Northwest 2007, was held last year and was a great success. This year, we once again invite 100 experienced, collaborative, committed agile practitioners from the Northwest and beyond to join us in tackling the issues around the theme of agile development in the real world.

The Northwest has a wealth of practitioners with years of real-world experience with agile methods and self-organizing teams. Agile Open Northwest offers an opportunity to strengthen our community of practice and co-create the future for agile development. Your commitment to arriving at the beginning and staying until the end both days will ensure we build on conversation after conversation as we engage important questions like:

• Who practices Agile in the Northwest and what is its impact?
• What is “Agile” anyway? What does it look like in organizations?
• What are the technical challenges facing Agile?
• How does Agile co-exist with project management, process control and other governance structures?
• Can we adapt agile practices to our organizations without diluting them?
• Can agile methods work in big, risky projects?
• Can distributed teams use agile approaches?

This event is designed to allow agile practitioners to meet in self-organizing groups where they can share their latest ideas, challenges, hopes, experiences and experiments. We follow an Open Space format to foster collaboration and allow the conference to take its direction from the participants themselves.

• What: An Open Space event discussing agile practices and techniques.
• Where: Seattle Center, in several of the Northwest Rooms.
• When: March 18 and 19, 2008
• Who: Anyone with some degree of experience in agile methods
• Cost: $100 per person, including lunch both days

So far we had a good response on  Belofte maakt schuld, overpromising and underdelivering seems to be even more common than we thought.

Writing papers in two languages is an experiment for me, usually I write in English, and I used to write in Dutch when I was writing articles for Dutch IT magazines. Writing and editing a translation gives me a fresh perspective on the text, and in the meantime I’ve had some more discussions on the topic. In the end, I came to the conclusion that if you really want accurate estimates, and stop overpromising, you have to foster a culture where saying no is ok.

The session was organised by Kevin Rutherford and chaired by Clarke Ching

Presentations:
* Servant Leaders — Nancy van Schooenderwoert
* wevouchfor.org — Laurent Bossavit
* Fit4Data — Adrian Mowat
* Shared data for unit tests — Paul Wilson
* Let them Eat Cake — Brian Marick

You can find out more information - including slides - at  http://www.nakedagilists.com/jan-08.

It was interesting to see how some technology rots over time… Last year’s naked agilists used a skypecast, where the presenters and an audience of about 60 people could participate. This year, we could not get the skypecast to function even for a test run with only a handful of people. In the end, the event ran as a regular skype conference call with the presenters, Kevin, Clarke and yours truly, so we lost the direct participation of the audience unfortunately.

This was the first time I was involved in a ‘talk’ podcast. I have podcasted some of my music, that is ‘just’ a matter of playing, synthesizing and then rendering the result… Things I learnt :

• Have tested options, so you can switch easily, even at the last moment
• Test the connection with all presenters. The connection to Nancy was bad at some points, which made it difficult (but not impossible) to get all of it.
• Using slides does not have to be complicated. Put up a presentation, or a collection of images on a webpage, and as a presenter say ‘next slide’.
• Not having a visual of the presenter takes more concentration
• Many interesting presentations can fit in the space of an hour, so go download the audio