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.
Last year, I ran a workshop at XP2009 and Agile 2009, helping people map behaviours to the different levels in the Dreyfus Model. Being a workshop for only 90 minutes, we only had time to introduce the model, generate a set of behaviours mapping them to each level in the model and only a small fraction of time thinking about where this might be useful in a coach’s toolbox.
I tend to use it as a way of encouraging people to self-assess their own behaviours, and as a way of seeing concrete, specific sets of behaviours that people in more advanced stages might find themselves.
We didn’t really get an opportunity to discuss the limitations of using the model in this way (remembering that all models are inherently limited in some manner).
Most useful for Novices
Ironically enough, this set of behaviours mapped in this way is only most useful to those who still remain Novices and less so, the Advanced Beginner. Novices need concrete rules, and directions. Advanced Beginners start to see context, yet it’s often helpful being specific about what sets of behaviours you might see at different stages.
Ironically, as you progress, using the Dreyfus Model in this way becomes less useful as you progress. I like to introduce this set of behaviours after people have had some experience with a certain practice. It helps people answer the question, “What does good look like?”
It’s not an exhaustive list
When I’ve run these workshops with other coaches, I find it interesting to see how they notice different sets of behaviours from what I would observe. Even when looking at a single practice, you have a multitude of behaviours at lots of different levels. It’s preciseness at describing specific sets of behaviour also has the risk of people only focusing on the prescribed behaviours instead of thinking about the sorts of behaviour that sits at this level.
I can’t imagine trying to list every single set of behaviour. As interesting as that might be, I think it would be impossible to capture, and difficult to communicate succinctly.
Best for personal development, not as performance evaluation criteria
It’s easy for managers to see a list of different levels, and then attempt of fit people into a box for performance evaluation. As much as their intention might be good good (professional growth) I think it’s easy to game.
I like to emphasise that this model is best used as a way for coach’s to help people self-assess, and for people to set their own goals about where they want to be.
Not the only tool to use
I like using this tool as a transitional tool, helping people jump the gap from Novice to Advanced Beginner and from Advanced Beginner to Competent. Beyond that, I would use less of this tool and look at other tools that help people self discover their information.
Update: Posted this so early my brain wasn’t awake and I hadn’t linked to the feedback links as promised. I’ve updated it so that it’s correct now.
A few people have arrived at this blog looking for the terms, “Giving feedback to defensive people.” Before focusing on the fact that the recipient may be “defensive”, I’ll refer to you to several different posts outlining some principles of giving effective feedback. Read them before continuing on.
Firstly, if you’re giving feedback to a person, ensure that you follow the principles of effective feedback.
Many times I’ve heard several people give feedback and it is not in the spirit of either of these. Often, they give feedback with the intent of improving their own effectiveness, not necessarily the recipient. For a variety of different reasons, it’s easy for me to improve my own effectiveness by asking people what to do – something that is both selfishly easy. It takes more courage and effort, putting yourself in the recipient’s shoes to help them out.
If someone comes across as “defensive”, I’d ask yourself what circumstances they could possibly under that make them so. Perhaps they have other things on their mind, and are preoccupied in a manner that makes it difficult to listen to feedback. The solution? Ask them if now is a good time to give them feedback.
Maybe the recipient associates “feedback” with “criticism” due to others “giving them feedback” ineffectively, fuelling a cycle of defensiveness. The solution? I find it easy to spend a quick minute or two describing the basic principles of feedback, and help them understand you are here wtih the true intent of either strengthening their confidence or improving their effectiveness. I like to emphasis it should be a conversation and that I will try to be a specific as possible, but encourage questioning if the recipient needs clarity.
Another reason the recipient may be defensive is for fear of being judged as a person. The solution? Focus on behaviours and impact, rather than attempting to describe what you think their motives are. This doesn’t mean you cannot have an opinion, however it should be clearly stated about how you interpret the impact, not on how you interpret them as a person.
They may truly believe that whatever situation you describe, they disagree with. The solution? Start with the model I describe here, seeking agreement for observations, then impact, before thinking about recommendations. Any disagreement on the early stages will inevitably lead to disagreements on future stages.
Finally, as a person giving feedback, you need to accept the recipient may choose to acknowledge, disagree with or do nothing with the feedback you gift to them. I remember one incident, quite recently, where a colleague gave me feedback with recommendations. We talked about it, both understanding the variety of forces unbeknownst to each other. At the end of the conversation, I concluded I would have repeated the same behaviour in the same circumstances, however that’s when the feedback donor got frustrated. My lesson, if you’re giving feedback to someone, be prepared to say, “I respect that we disagree on something, and thank you for being prepared to listen.”
Andy wrote a great blog post trying to relate Shu Ha Ri to the Dreyfus Model of Skills Acquisition. When I posted my thoughts, he suggested I blog about my story, so here it is.
In it’s simplest form, Shu -> Ha -> Ri roughly translates to Follow -> Detach -> Transcend. When I think back to the days when I studied Aikido (where I believe these concepts originate), I considered Shu Ha Ri as the flow of energy, or where you focus the majority of your efforts.
Photo of energy taken from HocusFocusClick’s Flickr stream under the creative commons licence
A Shu person, for example, focuses their energy on simply executing a very basic move. They repeat the kata, over and over, with the weight of their conscious mostly on thinking, “I move my arm up to block”.
The Ha person, no longer follows the rote kata, “detaching” from the original conscious thought, now focused on its application. They spend their time thinking, “An arm is coming my way, I better block”.
The Ri person is certainly spectacular to witness with energy flowing from move to move, something the dojo sensei demonstrated during a yearly open house. During this event, lasting a good twenty minutes, five black belt students attacked the sensei from all sides. They attacked with their hands and a small assortment of weapons. The sensei defended by turning, locking and throwing each student back in return. What I still remember vividly was comparing the black belts, completely drenched to the skin in sweat, to the sensei, who barely showed any signs of sweat.
I see this same flow of energy and focus of effort when watching people learn development skills. At one end of the spectrum, the Shu developer spends an enormous effort thinking about how to execute a particular practice. At the other end of the spectrum, the right practices occur and great quality code (and tests) appear.
Thanks to all the people that came along to the BSC London presentation I gave last Wednesday. Despite the threat of weather potentially cancelling our, previously snow-canned, presentation, it went ahead much to my delight. I hope that you all got something out of it. I’ve uploaded the slides here if you’d like it.
As I gather more experience (i.e. get older) I’ve discovered every model has a breaking point. What does that mean and why should you care? Accepting that models break is the first step to understanding and identifying their limitations. More importantly, because models have a breaking point, you should be actively discovering other models that help you better communicate and grasp new concepts.
Sounds easy right? Unfortunately my experience in life proves the opposite with most people wanting to only hold a single “valid” model that manages to explain and justify everything. I see this as a consequence of western education guided by Socratic thought and a Platonic ideal but that is a post for another time. In real life, this desire to hold onto “one valid model” translates to arguments over the merits of a particular model and often the basis for justifying a position. Note that I have no problems arguing for the sake of testing and discovering the boundaries of a particular model.
What do you do about it?
Accept that models are simplifications of sometimes complicated, sometimes complex systems. Be open to exploring the boundaries of a particular model, uncovering where one model excels at explaining certain characteristics of a system. Seek out and invent new models that provide a different point of view, or that emphasise and highlight different aspects for that system.
One of the biggest differentiators between the users who prefer IntelliJ over Eclipse is often their dedication to learning keyboard shortcuts. The user-conscious designers of IntelliJ make as much as they can consistent, something much more difficult for Eclipse, who is dependent on a community for plugin development without any process for reviewing how well they all fit together.
On my very first ThoughtWorks project, I remember my pair commenting about how I should learn all the keyboard shortcuts for IntelliJ. Learning keyboard shortcuts is less about churning out great amounts of code, and much more about avoiding interrupting your flow. Simple actions, such as reaching for mouse have potential to break your flow. Jetbrains make it easy to learn the keyboard shortcuts, even providing a printable cheat sheet so you can put them around your workspace as you learn them.
Having said all of this, here are some of the keyboard shortcuts I find myself using all the time for iPhone development:
I’ve also found application-wide standard keyboard shortcuts really helpful as well
Of course there are many more keyboard shortcuts. These are simply the ones that I’ve found I’m getting the most productivity. I wouldn’t say all of development can driven through the keyboard alone, but it’s a pretty good start for now. What are your favourite ones?
I’m a huge believer in accepting multiple models as different ways of looking at the same set of data. It’s just simply different glasses to see different things through. One of the glasses I’ve been putting on more consciously is that of David Kolb and his model on experience learning. Read more about it here.
It follows a simple cycle: Experiencing -> Reflecting -> Generalising -> Applying -> (Back to Beginning)
Here’s how I go about applying it. I follow one of the wonderful tutorials from Apple on their iPhone development, focused on simply trying to step through the cycle and get some visible success (Experiencing). I then spend some time thinking about what new tidbit of information I’ve learned (Reflecting) and trying to come up with some way of fitting it my general mental model of how it works (Generalising). I then try it out on my prototype application to see if I truly understood it (Applying).
Having read about the model a while ago, I think there are a few key things to focus on when using this model:
Interesting it is these two aspects, incrementing and iterating that is at the heart of working in an agile manner. Notice how it’s all about learning then?
I’m a big fan of XP’s practice of spiking solutions. Although I’m not currently doing TDD because I barely know enough about iPhone development to make myself dangerous, I haven’t quite dropped all practices. I still use source control (just a local SVN repository) against the root of my spikes directory.
Here’s how I’ve been structuring myself:
The benefits of this let’s me quickly create new projects to learn a single lesson given the numerous tutorials out there, and then put that under source control for reference code at a later stage. I then spend some time integrating it into the MyPrototypeProject, making small incremental commits as I make progress. The best part is that if I make a mistake along the way, all I have to do is a svn revert -R . to get back to a working state if I get too frustrated or lost.
Late last week, Andy Yates got me onto the whole Hello World application for the iPhone. Since then, I’ve been dabbling around a bit more trying to get my head around it. After having studied how people learn things using models such as Shu Ha Ri, the Dreyfus Model of Skills Acquisition, and Kolb’s learning cycle, it’s fascinating to try to understand how best to pick it up.
Here are some observations that I’ve made so far:
Comments(3)