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.
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.
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.
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.
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
- Code Quality
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.
We have been running coding dojos once a week after work for the last couple of months. They have proved a valuable learning resource and people have been attending even though we run them after work. They focus on one aspect of technology and past topics include implementing UML class diagrams, Ruby on Rails 101 and OO Principles.
One technique I have found valuable for running a session is to prepare a set of failing tests beforehand. I recently ran a dojo on LINQ and Lambdas. I started with a test for the simplest possible LINQ expression I could think of. I made the test pass [using the standard red, green, re-factor]. I then removed the code and stored it inside a Visual Studio Snippet for quick retrieval during the dojo. At dojo time, I gave a brief intro to LINQ and the project structure I provided. And then one by one talked through the tests and got the attendees to implement the code to make the test pass. This keeps people focused on a single problem and keeps scope down to the knowledge you wish to get across. The feedback I received post dojo was positive. I call this approach Test Driven Teaching [TDT] and I would definitely encourage you to try it if you are thinking of running your own dojo.