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.

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.

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.

All programmers tend to agree that repeating yourself [in code] should be avoided. This is commonly known by the acronym DRY.

After looking at some demos of a search engine today a light bulb lit up in my head [not an energy effecient one I'm afraid]. The interface to the search allowed you to select from different categories and the result was dynamically updated. Nothing remarkable in that but wouldn’t it be great if we could search our code this way? And I’m not talking about the ability to find something in just your project. What if you could search the entire enterprise code based on filters for method names, return types etc right within the IDE. Every time you write a new method or class you could quickly find similar pieces of code within the enterprise. Now this may lead to some time pressured / lesser experienced developers to copy and paste more, but for me it would identify areas where it makes sense to provide libraries / services based on the actual coding needs of the developers. It would also help target problem areas across different projects. I may try and knock up a proof of concept in .NET using something like Lucene as the search engine. Not sure how this might work just yet, but it would either examine the source itself or use static analysis, something like cecil and the approach I’ve talked about before. Does anybody else think this is a good idea? What should the filters be?

Now I’m back on the blogwagon, I though I’d let you know about one of the things I’ve been doing over the last couple of months.

As useful as standards and guidelines are they are very much based in the here and now. What is missing is a statement of the goals for your development practices over the next year or two. Where do you and your organisation want to be over this time frame? To that end I created a mulitple choice survey with each question having 4 answers. The questions used the following scoring system

• 0 = The practice, tool or what-not mentioned in the question is not used / followed
• 1 = It is used / followed, but in an obsolete manner
• 2 = It is used / followed according to current standards
• 3 = It is used / followed according to our future goals

The questions fitted into five broad categories

• Configuration Management
• Tools
• Practices
• Code Quality
• Testing

If you take the averages across all of your development teams you can chart it like so:

At a glance you can tell whether standards are being meet, software quality aspirations are being achieved or that certain aspects of your development practices are below par. The more of the circle that is filled, the better you are at acheiving your goals. When you get scores mainly falling between two and three it is time to raise the bar.

This information is useful in a couple of ways. If you plot the scores in ascending order you can tell what thinds need to improve and spend your effort on them, based on their priority. You can group this info into categories to ascertain if you have any problem categories.

You can also plot individual teams against the average. This enables you to hightlight to all devs what a particular team is good at. It also lets teams know where to get help from other teams who have a higher score for that particular practice.

If you re-run every quarter or so, you can evaluate how the organisation has changed, identifying what worked and what didn’t. It’s basically a retrospective at a higher organisational level.

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.

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.

I fully expected myself to get out of the habit of blogging at least once a week. I’ve been on holiday [twice] and it only takes a few weeks away from the world of software development to let something slip.

Anyway, I’m back. Honest.

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.

We have been producing code quality dashboards at work. They are produced by our CI server whnever a successful build is produced. This allows developers to get quick feedback on the quality of code they have just commited. We can compare projects and raise their quality over time. This is all very well and good but wouldn’t it be nice to see how we are doing compared to the outside world?

So without further aso I present to you 4 code quality dashboards for a selection of .NET open source projects [and one MS one!]

As you can see quality is variable with nmock and ASP.NET MVC doing well. Fifty percent unit test coverage for nunit is a bit shocking however!