Agreeing to Agree at London Geek Night
Conflict is a natural part of your every day life, whether it is at work or home. A certain amount of conflict is healthy as long as you work out how to resolve it.
Liv Wild and I will look at a number of conversation models we’ve found healthy teams use, in agreeing to agree. We’re holding it at the Thoughtworks UK office from 7pm this Tuesday (9 Feb). More details can be found here.
Retrospecting Resources
I was really pleased to stumble across a new site for Retrospectives dubbed the “Agile Retrospectives Resource Wiki“. I can’t find who put it together but thank you for putting it to the public. Some other resources that I know about and is worth making more linkable on the internet include:
- Retrospective Facilitator’s Gathering – Wiki website detailing the yearly gathering of people passionate about facilitating retrospectives
- Retrospectives – The first website Kerth put up describing the practice of Project Retrospectives.
- Links to retrospective resources – A good collection of links to blogs, articles, etc that are related to retrospectives
I’m really pleased to fin
XP2009 Day 3
The keynote
Bjarte Bogsnes gave, in my opinion, the best keynote out of the three speakers, where he discussed his experiences applying the concepts discussed in Beyond Budgeting in Statoil. He talks about why do you want a system that is based on assuming you cannot trust everyone? Instead you want a system where the default position is that you trust everyone, and that you manage those that you can’t by exception (and not the other way around).
He talked about how the trigger for Statoil was two fold – internal and external. External pressures included the fluctuating nature of the sale price for barrels of oil, and internally it was the social pressures of actually having systems that encouraged all the good things that they said they did, yet didn’t neccessarily encourage, where policies were largely authority based (sign off) compared to those of trust and respect.
The key question they asked was, “How do we create the conditions that let people make good decisions and execute them well?” Compare this to, “How do we make people make good decisions and execute them well?”.
Interesting their solution laid in removing the “traditional” budgeting scheme, asking people to “do the right thing”. Resources were available but not yet preallocated. I remembered most his metaphor, describing most businesses operating like a bank that is open for four weeks out of the week. Customers need to predict exactly what their year is going to be like, and ask exactly for the right amount.
They identified that budgets typically have three overloaded (and often opposing goals), representing performance targets, forecasts and resource allocation. They implemented a system splitting each of these different aspects into different systems to achieve better visibilty and improve the quality of conversations around each of these topics. They created a system to ensure there was alignment at all different levels, directly creating KPIs out of the strategy, generating actions out of the KPIs and then individual goals out of the actions.
Industrial Logic’s eLearning Tool
I had a great chat with Joshua Kerievsky, founder of Industrial Logic and he asked if I wanted to see their “eLearning” tool. I’m glad I did as well because I think it’s an amazing environment for all developers who want to be professional. I don’t think calling it an “eLearning” tool does it justice. In a nutshell:
Imagine gathering some of the world’s best experts in different programming disciplines such as refactoring, automated testing, design patterns and imagine working with them on the same team. You get to watch over their shoulder as they explain what they’re thinking as they execute, you get to practise an exercise with them and receive immediate feedback, and you get to interact with the most engaging pieces of training I’ve ever seen (including many of the hands on training classes). All of this just happens to be online.
They’ve put a tremendous amount of effort responding to student’s feedback and its narrow focus on (currently) developer related material means they can give some surprisingly detailed feedback including comparisions and alternatives as a result. The tool itself only happens to help deliver the message and, more importantly, he’s managed to capture so much knowledge in the “albums” they’ve already put together.
Go check it out. Take the tour and then have a look at some of the albums.
Telling Your Stories: Why Stories Are Important for Your Team
Fellow retrospective facilitators Diana Larsen and Johanna Hunt ran a fun session that was particularly engaging considering, managing to have the busiest session on the last slot of the last day. The title of the workshop didn’t describe the session as accurately as it panned out as it was extremely creative workshop where we looked a number of a card games often used for story telling in other areas, and then brainstormed ways in which we could create cards and a process to help use stories in an agile environment. The group had some fantastic ideas and even heard a few people walk away saying, “I need to get some of those cards made!” to take back to their teams.
Conclusion
I’m pleased that this year’s conference seemed to have returned to what roots it was for me four years ago. I appreciate the fact that there are still so many people passionate about “doing the right thing”, about helping each other out, and that the main motivator is still to “grow, learn and get better” first, instead of “making money” prioritised as number one. Thanks to all the wonderful people I met at this conference (for the first time and again), and the great memories I took away.
XP2009 Day 1
General impressions about the conference
I really enjoyed this year’s conference with the combination of a remote island in Italy and the small numbers (100+) giving many great opportunities for chatting with our experienced practitioners, and a handful of academics about lots of different topics. I found it refreshing that there seemed to be significantly more experienced practitioners and thus, I found it extremely nice to be able to chat about similar experiences rather than simply unidirectional advice I find when present with a higher proportion of beginners.
Who wouldn’t want to gather around this place for some great conversations?
The quality of sesions was better than the last two conferences, once again focused less on the introductory nature and more focused on specific aspects. Of course, I had recommendations about how to improve, particularly the organisational aspects, of the conference and I’ve at least had an opportunity to give that feedback having shared a return train with one of the organisers for next year’s conference.
Thoughts about the first day
The first part of this day was a keynote delivered by lean evangelist, Mary Poppendieck. Titled, “The Cultural Assumptions behind Agile Software Development”, Mary proposed that there are several (American-style) cultural assumptions behind many of the agile practices that make it all the more difficult to implement. She referenced heavily the work discussed by Geert Hofsted in his book, Cultural Dimensions.
I didn’t find the keynote particularly inspiring, nor particularly challenging. Country-based cultural dimensions are just one of the factors that permeate the way that people behave. As an agile consultant, you end up fighting corporate culture, and the systems that encourage and maintain that corporate culture and I see country-based cultural dimensions yet another contributing systemic effect. This does not mean that just because a country has a high degree of individualism, working in pairs or working collaboratively in a team will be impossible (perhaps just all the more difficult). As much as I enjoy hearing Mary speak, I also found her presentation a little bit too heavy in the whole powerpoint presentation with far too much text and outdated clipart.
I also ran my workshop in the morning, titled “Climbing the Dreyfus Ladder of Agile Practices” and want to thank all the experienced people that attended as it resulted in some really rich discussions. We managed to discuss seven different agile practices in detail, brainstormed a large set of behaviours for each, classifying them and classifying them into the different levels described the the Dreyfus Model of Skills Acquisition. The results from the workshop can be found here (photos to be updated).
In the afternoon, I helped out Emily Bache’s coding dojo, focused on Test Driven Development. We saw four different pairs tackling four different coding problems using different tools and languages. I learned about the tool JDave (it’s still a little bit too verbose for my liking), and saw different styles in the way that people executed the code kata. For me, I was hoping to demonstrate more on the pair programming side of test driven development as a pair, and I had a lot of fun even though I felt a little bit out of my depth with the tools. Thanks to Danilo for complementing my lack of experience with tools like Cucumber. 
More to come…
Why ORID matters?
Last time I wrote about the ORID (Objective, Reflective, Interpretive, Decisional) model for conversations. Software development is hard because not only do you have to deal with technical challenges, but there are so many opportunities for poor communication. Detecting when poor communication occurs is important, as it lets you ask questions and steer conversations back into a much more productive result. Here’s a classic conversation I hear on software teams all the time:
Person A: We’re going to use <tool/framework/library>
Person B: No! <tool/framework/library> sucks. We’re going to use <alternative tool/framework/library>
Note that both of these people have jumped to the Decisional stage of the conversation (i.e. What to do). I’m sure that individually, both people went through the model, yet didn’t attempt to step through together (or as a team) each of those stages. I’ve learned that it’s easy to jump to different conclusions (D) if you don’t share the same background.
Using the ORID model as a guide, here’s a much more effective way the people could have had that conversation:
Person A: I’ve noticed we write a lot of code that deals with files. (O)
Person B: I’ve noticed that as well. (O)
Person A: It makes me feel frustrated (R) because we spend less time doing interesting stuff (I)
Person B: I didn’t realise you were frustrated about it! I also notice we tend to have a lot of bugs in that area as well (I)
Person A: I’d like to use some <tool/framework/library> so that we can improve our productivity (D)
Person B: I definitely would like to as well.
Person A: I think <tool/framework/library> would work well
Person B: I’ve had bad experiences with <tool/framework/library> because it also has lots of bugs (I). I think <alternative tool/framework/library> might still do the job, and help you feel less frustrated. What do you think? (D)
Person A: Let’s give it a go.
The conversation may not still go in the same direction of agreement, however there is much more opportunity to discuss why one particular solution will fit the issues both parties are feeling. Without making those items explicit, the discussion becomes an argument about choosing one solution over another. With a shared understanding of how both people are feeling, there are many more opportunities to clarify what problems the solutions are trying to fix. In fact, the solution each party originally thought of may change as a result.
Comments(2)Facilitation Tool – ORID
Last year, Esther Derby and Jean Tabaka shared a model at the 2008 Retrospective Facilitator’s Gathering that I now think about all the time. Esther Derby and Diana Larsen used it as the base model to describe how to run retrospectives. It also got me thinking how it mirrored different models described by other facilitation approaches, negotiations strategies and advice on how to give effective feedback. Apparently this originated in the book, The Art of Focused Conversation.
The base model starts with the acronym ORID that means:
- Objective – Focus on the facts, hard evidence data
- Reflective – Focus on how that made people feel or other associations
- Interpretive – Focus on the impact and significance
- Decisive – Focus on next steps.
I thought it’d be useful to share this model with a wider audience, and I keep forgetting what the “I” specifically stood for, so I’m putting here so I can find it later.
More on how to apply this later.