Continuous Open Space

At BBC Worldwide I run a weekly meeting primarily aimed at engaging the development community in a number of ways such as organising dojo’s, presentations, study groups and the like. This changed recently to alternating sessions focusing on the needs of developers and testers. With the success of the meetings other groups such as Analysts and PM’s were expressing an interest in discussing topics pertinent to them.

Whilst attending the Agile Coaches Gathering [twitter tag – #acguk] I attended a session on running continuous open space meetings. This sounded like an effective, open and inclusive approach to getting things done and raising awareness within the weekly meeting above.

The first meeting was limited to planning the agenda for the next session. The group was given time to write titles of topics they wanted to address on sticky notes. People were asked to include their name and informed that if they proposed a topic that they should be prepared to referee.

Each person was then invited to come up, announce their most important topic and place it on the board. The group then voted and the top three proposals made the agenda for the next session. The meeting also served a couple of other purposes. It acted as a useful introduction to the concept of open space meetings. My impression was that people felt comfortable with the style of the meeting; this was backed up by the fact that all attendees raised topics and were involved. It also emphasised the importance of a feedback mechanism. People started talking about the challenges and ways in which the meeting could be improved. This was completely unprompted. As a result the improvement suggestions were captured and prioritised in the same way as the session proposals.

The next meeting was split into two parts. The first ten minutes was used to raise session proposals and vote on the most important. The remainder of the hour was used to host the three sessions. The sessions were held in meeting rooms adjacent to each other to encourage footfall.  Each session is responsible for collecting output which is circulated to the whole group.

After the agenda has been set for the next meeting all other suggestions are simply ignored for that week. By getting people to think about what is important each week from fresh allows people to concentrate on what is important now and reduces the effect of distraction from an existing backlog. By proposing sessions at the start of each meeting people have some time to prepare and some time to change the topic. Sessions have already merged and changed in the first two weeks. This structure has given us a very flexible and engaging way of addressing the most pressing issues we face.

Why do we coach?

At the Agile Coaches Gathering I proposed a session exploring the reasons why we coach. Managing to gather a few people on the sunny lawn at Bletchley Park to explore this topic, we created a mind map looking at the positive and negative reasons for coaching.

The outcome can be summarised by the following three categories:

• Negative personal reasons
• Positve personal reasons
• The greater good

Negative Personal Reasons

Coaching to boost your ego was thought to be the primary thing to be avoided. Being seen as clever, important or the person with the answers should not be your goal. Closely related is hubris – overconfidence or arrogance. These items are represented in green in the diagram above.

Deferring decisions for too long can have a detrimental effect. Another area where a negative impact can be introduced is through lacking the courage to make decisions. We had quite a long chat about this in regard to when it is acceptable to help people improve versus when it is best to let them discover improvements. Most people agreed that making this call comes down to your experience of similar situations. Too much hand holding and you can become a crutch on which a team depends, too little and the team doesn’t see the benefit of you coaching them.

Positive Personal Reasons

Some of the positive experiences coaches have experienced include self development, learning, enjoyment and achievement. Some also expressed the feeling of coaching being what you are best at, or your vocation in life. We also coach because we enjoy the challenge of adapting, solving people problems, meta-problems and a better understanding of psychology.

Greater Good

Some of the reasons for coaching the group came up with are related to providing benefit for the ‘greater good’.  These reasons include:

• Fulfilling peoples potential – Giving is better than receiving; people are amazing; everyone can excel.
• Social responsibility – People should be treated with dignity, helping avoid misery and frustration. Many of the people present mentioned that they felt a responsibility to change things that are broken or do not work.
• By teaching that accountability is good, people can start to own problems and therefore do something about them.
• People are genetically programmed to coach, especially children. Most people present had a parent or close relation who was involved in teaching. As a result there was a feeling that we coach because we ourselves have been coached well.
• Coaching can help bring about change. Change requires courage, patience and confidence.

Summary

I found this a very useful session and learnt a lot about what motivates people to coach others. We had a very free, open and honest discussion. Many thanks to those who contributed. An extra special thankyou to Rachel Davies and Mike Sutton for organising.

Agile Coaches Gathering

I attended the Agile Coaches Gathering last weekend at Bletchley Park. All in all, it was a great day andI  learned a lot.

Bletchley Park was home to thousands of people intent on breaking military codes during the Second World War. It is in danger of falling into disrepair. This wasn’t helped with the announcement from the House of Lords rejecting calls for more funding. The IEEE plaque sums up why Bletchley Park is so important; “on this site during the 1939-45 World War, 12,000  men and women broke the German Lorenz and Enigma ciphers, as well as the Japanese and Italian codes and ciphers. They used innovative mathematical analysis and were assisted by two computing machines deleveloped here by teams led by Alan Turing: the electro-mechanical Bombe developed with Gordon Welchman, and the electronic Colossus designed by Tommy Flowers. These acievements greatly shortened the war, thereby saving countless lives.”

You can make a difference and donate here.

I facilitated two sessions at the gathering. The first session was on the theme of “Does smaller and more often have a limit?”. We discussed whether the trend from larger, longer pieces of work to smaller pieces of work delivered more often had a limit and where we are currently with regard to this.

Liz Keogh captured the thoughts of the group here.

The second session I ran was titled “Why do we coach?”. We explored what motivates people to coach by repeatedly asking why? I captured a mindmap below. Sorry for the quality, hopefully somebody will post a better quality image on the ACG website. Thanks to Xavier Quesada Allue  for the images.

Design Patterns Study Group

We’ve been running a weekly lunchtime session for interested developers on design patterns. I suggest that you do the same, as we have found it very valuable in coming to a common understanding of what each pattern is about, when you might use it and real world examples in our current code.

Somebody made the point today that we seem to have the most debate about what we perceive to be the mostly widely used and understood [particularly creational] patterns. This for me highlights the importance of running these sessions. We use something like the approach outlined here, but announce which pattern/s we will be looking at next week based on what is related / of interest / controversial.

Software Craftsmanship

I’m helping to organise the Software Craftmanship 2009 conference to be held at the BBC Worldwide offices in West London on the 26th Feb 2009.

I’m a member of the selection panel and requests for proposals are now open. If you would like to do an interactive session with a bunch of passionate developers may I suggest that you propose a session as soon as you can. Jason has done a great job in assembling the selection panel which contains many leading lights in the world of software.

Registration for the conference opens on the 1st December.

SPA 2009 – Proposal Deadline

Proposals to present a session at SPA 2009 close at 18:00 BST on Monday 15th September. Being the orgainsed chap I am I’ve submitted my proposal with oodles of time to spare. Now I just need to wait and see whether it gets accepted.

MiniSPA Roundup

I attended the miniSPA conference yesterday at the BCS offices near Covent Garden in London. SPA stands for Software Practice Advancement and “is where IT practitioners gather to reflect, exchange ideas and learn.”

miniSPA is billed as a free taster for the full event, where you can experience the most popular sessions. The real thing lasts for three days [and nights!] rather than just the one.

After the usual intro, there was a choice of two streams for the three sessions run during the day.

My first choice was deciding between Best Practices for Finding your way into new Projects – quickly… and Getting To ‘No’. I plumped for finding your way into new projects. After Marina had set the scene and everyone had introduced themselves, we brainstormed ideas for practices we thought would be useful if starting on a new project. Everybody stuck their post-its on the wall under one of the five categories. The categories were Team / Culture, Me and Myself, Me and Others, Me and My Computer and another that I cant recall right now. Unfortunately due to the time constraints we were unable to review the output. However I think Marina is going to post the output somewhere which will be worth examining. Lastly each table carried out a metaphorical exercise where we had to pick a scenario outside of the IT world and map the activities back onto an IT project. Our table came up with a prison break. The effect of selecting a topic completely outside the normal domain was interesting. As everybody was essentially a novice the fear of making a mistake was eliminated. This allowed the participants to brainstorm in a very uninhibited way, and to have some fun. It was actually surprisingly easy to map most activities back on to the world of the IT project. It turns out escaping from gaol lends itself to an agile approach!

Next up was Awsome Acceptance Testing or Storyboarding the Domain Model. I went for the Awesome Acceptance Testing. Unfortunately Dan North couldn’t make it which was a shame. He was replaced by Simon, one of Joe’s colleagues from Google. The session was an introduction level talk describing acceptance testing. Not so much interaction in this one, even though a few times people did ask questions that led to some interesting diversions. I didn’t learn a whole lot from the session, but it did give me the confidence we are doing the right thing and are probably ahead of the curve where I work.

The last choice of the day was a toss-up between Domain-Specific Modelling for Full Code Generation and Effective Pairing. Not having any strong feelings about code generation I chose the Effective Pairing session. Normally the practice of pair working is described in terms of programmers [pair programming]. This session looked to see how effective a practice pairing is in other domains. Everybody lined up in order of how much they liked or practiced pairing. Teams were split up into groups of 5, with each team having somebody from the front, middle and back of the line to ensure some balance. Being teams of five, one person from the team worked alone to give adversarial feedback. Pairs and singles swapped after each exercise. There were four pairing exercises that were allocated among the teams, but again being constrained by time each team only got to try two of them. The four themes for the pairing exercises were creative, analytic, visual / spatial / physical and people centric. I did the creative and analytic exercises. The creative exercise consisted of describing a painting to a blind person in at least 200 words. Working in a pair I found that more detail was picked up than I would have done individually. There was almost an analysis / brainstorming phase at first where we discussed various aspects of the painting. This was very effective in a pair. However, actually writing the prose was less so. For the analytic exercise I was working alone. Whilst I was able to direct what I did, I certainly missed some speed and accuracy that the pairs reported back. I found this session interesting, in that it informed me of the feeling when the payoff line for pairing was crossed. In general pairing is a great practice and this certainly helped encourage me to use it where possible and to know at what point to stop pairing.

Overall miniSPA was a well organised, enjoyable and interactive conference. I definitely recommend attending the real thing next year.

Upcoming Events

See the events page for a list of upcoming events, conferences and that sort of thing.

miniSPA 2008

I’ll be attending this years miniSPA conference. It’s billed as a free sampler of the best sessions from the full on SPA held earlier this year. In case you are wondering SPA stands for Software Practice Advancement.

BBC Hackday – Mashed 08

This weekend the BBC have arranged a follow up event to last years hackday. Mashed 08 is taking place at Alexandra Palace in North London and looks like it will be great fun. Have a look at the schedule and here for a quick overview.

It is now all over. Have a look here to see how it all went.