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.
Thoughts about the second day
Ivar Jacobson gave an equally uninspiring keynote, talking about “What they don’t teach you about software at school: Be Smart!” In it, he focuses on the fact that it’s not only enough to try to “Be Agile”, but you need to “Be Smart”. Unfortunately many of the items that he talked about didn’t really seem to be any different from “Being Agile” and that he had obviously targeted the wrong audience.
I’m glad the conference ran with an open space session, this year introduced by Willem Van Den Ende and Lasse Koskela. I suggested a topic titled, “The Kanban, Lean, Agile Divide” and I felt we had the best quality discussions during this open space. I wanted to answer a number of questions including:
Out of around the 12 people participating, probably only two or three hadn’t heard about the community, and only one or two people were active in participating (in the mailing list portions). We had lots of discussion as to what people considered as Kanban as well.
First page of notes from the open space session
We noted down the mailing list, available on Yahoo Groups: Kanban-Dev and several “published” resources including the paper, Kanban Vs Scrum, and the book, Scrumban.
When asked about what Kanban was the participants, here’s what we recorded:
I recorded that some people were still doing sprint/iteration planning whilst using Kanban though I don’t remember if we got into the details.
I also recorded two concerns, such as knowing, “When do we get stuff done?” and a very “Loose Terminology” leading to lots of confusion, particularly the overloaded associate with Kanban (as a practice) and Kanban (as a methodology).
When asking the question, “Is there a kanban divide?” some answers included, there is maybe a divide in a community sense, and when probing further, when interpreting Kanban as a practice, not a methodology there wasn’t however there was definitely a sense when treating Kanban as a methodology and not as the practice with a feeling that some people in the community wanted to make money.
Last page of notes from the open space session
We asked why the community divide and understandably, there was no real community around to openly discuss Kanban (as a practice) and felt similar to those that had been around during the XP early days. There didn’t seem to be any general list for “agile practices” with extremeprogramming and scrum-dev mailing lists. It’s also not the first time practices have had their own list, like the pairprogramming or the test-driven-development lists. We did note down that there were several potential ones the community could have joined including lean-agile, lean-dev instead of creating their own kanban-dev.
In the afternoon, I went along to the panel on Lean Software Development although I seemed to come away with the same questions and less answers. One of my questions about budgeting was answered by the next morning’s keynote, while another focusing around the lack of discussion around practices seemed to be dismissed by Mary Poppendieck as, “I don’t believe in practices”, maybe best surmised as, “I don’t know” (which I would have also been happy to take).
The evening was an impromptu beach BBQ held by the awesome folks at Agical. Whilst a small company, I’m glad to see them still as passionate and having grown year upon year with more enthusiasm about a huge variety of topics. The BBQ was amazing and I know that everyone had a great time.
More to come…
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…
One of the biggest divides you need to cross, even on agile teams, is the chasm between testers and developers. By the nature of their different roles there will always be tension with developers focusing on creation, change, and construction, and testers focusing on breaking, destructive, and exposing questionable system behaviours. It’s essential that both organisations and, in particular, individuals realise what they can do to ensure this tension doesn’t dissolve into an exclusively confrontational relationship.
Photo taken from Sephiroty’s Flickr stream under the Creative Commons licence
Recently, a new QA person highlighted this very issue for me. I’d finished some functionality with my pair and the QA had been testing it after we declared it ready to test. They came along to my desk and said, “I’ve found some defects with your code.” Internally I winced as I noticed myself wanting to say, “There’s nothing wrong with my code.” It got me thinking about why.
Evaluating people puts them on the defensive
Just as giving effective feedback should focus on behaviour, poor feedback makes a person feel criticised. When the QA said that there are some “defects”, it implied a broken state that you had to fix it. Made worse is the way that they said it made it feel like they were blaming you, and it’s very hard not to feel defensive in a situation like this. A very natural outcome is to pretty much deny the “evaluation” which I’m sure anyone in our industry would have witnessed at least once.
Avoid terms like “defect”, “broken”, “bugs”
One of the biggest differences working with agile testers versus testers who come from traditional backgrounds is the terms that they use. Traditional testers constantly use the words above. Agile testers focus on discussing the behaviour of the system and what expected behaviour they would see. They only use the words above once they have agreement on both of the both the current and expected behaviours. I definitely recommend you do not start a conversation with the words above as they all carry some connotation of “evaluation” and I’m yet to meet someone who truly feels comfortable being “evaluated”
Focus on Effective Feedback
Effective feedback follows a neat and simple pattern:
Testers should use a similar series of questions (in order):
Apply the guideline above and watch the collaboration improve!
On our current project, we haven’t run many retrospectives. Gasp! Anyone who knows me might be shocked to hear that.
I’ve pondered whether or not that this has been a bad thing for our project. I’m a huge advocate for using retrospectives to help encourage people to create change on their projects. I’m a huge advocate for using retrospectives to bring the team together and understand what’s going on. Fortunately I’m lucky that our team has some very strong people with probably 40% of them having true skin-in-the-game experience working on agile teams that things just get done and more importantly, things continuously improve.
I definitely believe that without all the experienced agile team members, we wouldn’t have overcome all the different and sometimes bizarre situations (ask me if you see me!) thrown our way. Do I think retrospectives still offer us some value? Yes, but probably not for the reasons that most people use it for.
It’s amazing what a bunch of energised, passionate and people with the “solve the right problem once” attitude can achieve. I’d only wish that more teams were made up of people like this more often!
One of the things most important to me when working with teams is to demonstrate constant humility. To me, you need humility in order to have courage and in order to learn. You need humility in order to have good collaboration and interactions with people.
During one of our last stand ups, I apologised in front of everyone for making the quick commit before rushing off (I had a taxi waiting). That small quick commit broke the build so I thanked the team members who fixed it for me. Everyone had a good little a laugh about it because I’m the biggest advocate for encouraging people to practice good habits (unlike what I did).
Of course I’m embarrassed for breaking the build but I’m delighted that I can say sorry in front of my team without being slapped over the wrists. It’s important to acknowledge that people make mistakes – even experienced people who have been working in this fashion for ages. It’s more important to ensure that we have a safe environment where people can make mistakes, and learn something from it, rather than being punished for it.
Steven List asks the question, Are Retrospectives an Anti-pattern? Of course, retrospectives are a topic close to my heart so I naturally wanted to share my view of them. The conversation apparently started on the Kanban Development mailing list and Steven’s post already captures some great discussion. I won’t repeat it here, but I find the dialogue echoing the same sentiments about other agile practices and whether or not they’re useful. For me, it’s too extremist and not particularly helpful. They make it sound like you need to choose from two positions: Either you run retrospectives, or you don’t.
I think the more interesting question is, “When are retrospectives most useful?” To help explain my thoughts, I’ve put together the following: A Model for understanding Retrospective Impact (click on it for a slightly bigger view).
What is a retrospective?
Being specific and clear about this term is important in the discussion about whether or not retrospectives are useful. Some people’s understanding of a retrospective can differ from other people’s depending on each of their experiences. The conversations on the Kanban list seem to imply retrospectives are solely an iteration focused ritual (and of course, there is no such concept of a Scrum or XP iteration in Kanban). Though I appreciate Kerth’s original definition, I think in the agile community, Derby and Larsen’s definition better captures its essence:
A special meeting where the team gathers after completing an increment of work to inspect and adapt their methods and teamwork.
I like this definition best because its ties the concept of improvement (inspect and adapt) based on a shared understanding (the team) according to some unstated time period (an increment of work, noting it’s not specifically tied to an iteration).
What is impact?
I think it’s also important to define the term impact. One of the definitions by the Oxford Dictionary seems most appropriate:
a marked effect or influence
I want to emphasis that you can have a high impact retrospective without necessarily taking a lot of time, and that the opposite is entirely possible too (a long retrospective with a low impact). Note that I’m not going to discuss how to run retrospectives that have the highest impact (a totally separate topic worth its own set of posts).
Effect of team dynamics
The state of the team has an enormous influence on the impact of retrospectives. A high performing team will naturally have better communication amongst its members, and are more likely to fix things that get in the way of their goal. There will naturally be better and more frequent individual improvements, identified and implemented more frequently without the call for a specific meeting. This doesn’t mean that retrospectives are never a practice they call upon. Rather, it’s a practice that has less impact as there are many other items in the toolkit that get called upon. Sometimes it’s important for the group to get together, establish a common understanding and to inspect and adapt noting there may not be any specific regularity to these particular meetings.
In contrast, a dysfunctional team are less likely to call upon individual improvement practices, and thus, retrospectives play a more important role, providing an explicit opportunity to improve. I use the term dysfunctional in this sense to capture a broad category including newly formed teams, or simply groups of people. This does not necessarily mean the team cannot advance, nor that it hasn’t had a chance to advance, just simply the state it exists in.
Environmental Effects
I would classify a majority of environments as chaotic. In chaotic environments, improvement isn’t second nature. Through practices that start with good intentions such as auditing (“I want to have confidence you are doing what you say you are doing”), people in these environments become afraid to suggest changes, and are often fearful of attempting anything different because they’ve been punished for a failed experiment in the past. In these chaotic environments, retrospectives have a significant impact by providing an explicitly safe environment for teams to make, commit to, and hopefully be supported in making changes. Retrospectives have a higher impact in these environments because the majority of other activities doesn’t encourage learning, innovation and improvement.
In contrast, a nurturing environment welcomes fail fast innovation, rewards learning from failed experiments and supports continuous improvement in an explicit, non document centric approach. In these environments, the outcomes from implementing improvements and passing on tacit learnings is more important that meeting audits and compliance. Retrospectives have less impact in this environment because individuals are more likely to suggest and implement improvements without the need for a special meeting, and without the need for an entire team. Once again, it doesn’t necessarily imply that retrospectives are not useful (some issues require a shared understanding across the entire team) or that they are regularly scheduled events.
Avoid deciding between whether or not you run retrospectives. Consider when is it best for you to run a retrospectives instead.
Understand what situation you find yourself in using the model above and ask yourself whether or not retrospectives have the potential for the most impact (dysfunctional teams and chaotic environments), or where energy is better spent pursuing other activities because retrospectives have less, but not zero, impact (high performing teams and nurturing environments).
In the next set of posts, I hope to describe different situations I’ve seen first hand and what impact retrospectives had in relation to them.
Leave a comment and let me know what you think.
Vivek asks what are the signs you use to tell if a team is agile? I prefer not to count the practices they might be using because that is almost too easy (to get wrong).
Example: I remember talking to a person about their team who claimed they did lot of automated testing. They apparently had tests but upon further questioning I found many of their tests didn’t work and hadn’t worked for quite some time. I continued to ask questions about their practices and they mostly seemed excessively ritualistic without the team benefiting from them.
Ticking off a checklist about practices is easy to do, yet hard to do well. I prefer to ask questions with a less explicit goal in mind. I care more about how people do what they do rather than what they are doing right now.
I prefer to look for consistent behaviours across what they are doing that tell me:
What other ones do peope look for? I’m sure there are plenty more.
When I go into different organisations, I see many of the people doing the work (analysis, development and testing) split across multiple projects. In my experience there are plenty of reasons why this is just a bad idea, and probably the biggest one that I see is that the split priorities for an individual conflict with a model for ideal teamwork.
What does your organisation have more of? Teams or groups of people “working together”?
There’s a big difference between the two, particularly if your organisation is interested in tapping into the benefits of teams. Unfortunately most of the time organisations miss the mark.
How can you convert groups of people into teams?
Split priorities create natural conflicts between groups. A lot of management theory I’ve read describes how to get the most out of teams by rallying them towards a shared goal or set of goals. At the individual level, setting different goals for different people establishes a dynamic that, at some point, individuals’ priorities will conflict and without a broader shared goal, will go unresolved. Setting the same priority for everyone is, in effect, putting everyone into the same team. Leaving people split across multiple projects, is in effect, setting different sets of priorities for an individual.
In the spirit of Goldratt’s understanding of metrics, “Tell me how you are going to measure me and I will tell you how I will behave,” here are some questions I ask myself when I play the role of a Technical Lead.
Picture of Einstein figurine taken from Dunechaser’s Flickr stream under the Creative Commons Licence.
And of course, this resource is a useful one too.
Comments(3)