Last week I was at one of my favourite Agile events of the year – the ACE! Conference in Kraków. It always attracts interesting speakers and this year was no different. But talks are only a small part of such event for the real value is often is the conversations that follow.
During a few talks this time I happened to have been sitting near Bob, in two of the talks speakers shared their ideas about retrospectives.
Monika talked about “Gamified Retrospectives” and Mark talked about “Retrospectives, the most boring meetings ever”. Both are very passionate and excellent speakers. Their talks were enjoyable, made important observations and shared interesting ideas about novel ways of improving retrospectives. However both Bob and I felt that they were focused on doing the wrong thing righter. Bob, it turned out, has already had some more thoughts on the topic in his “Retrospectives – Wronger and Righter” blog post. We followed it up with a few conversations with others who were slightly concerned about our attitude. After all retrospectives are a cornerstone of many Agile teams. The main argument of the discussions was that retrospectives should reflect on a hypothesis stated before the work has started and too often they don’t.
Another aspect that I would like to draw your attention to is that retrospectives are prone to suffer from the Hawthorne effect. Read the full Wikipedia article but the essence is that
subjects improve or modify an aspect of their behaviour being experimentally measured simply in response to the fact that they know they are being studied
In other words retrospectives may be improving the way we work simply because we run them and not because they result in meaningful improvements to the way our system of work is organised.
You might ask, whether it’s that relevant. After all the team is achieving visible improvements anyway so do we need to care why? Well, we should, we should indeed and the two talks starkly brought this to my attention. They both gave many interesting and innovative ideas about how we could make our retrospectives more engaging, more motivating, different. (And, no, this summary doesn’t do justice to the two talks). So I asked myself: Why do we need to re-invent retrospectives, why do we constantly strive to turn the dial up to eleven? Perhaps that’s because the standard way of running them no longer works.
Our retrospectives are not sustainable.
The workers are being observed and they improve but as they get more used to this observation, improvements fade away so we need to keep changing the observation and experimentation to keep fuelling the Hawthorne effect and this loop eventually runs out.
Instead, let’s focus back on the loop that was always there at the heart of retrospective – the PDCA cycle. By all means, make your retrospectives fun, engaging, challenging, use the great ideas shared by Monika and Mark but make sure that you used them for validation of your hypotheses and to seek to create meaningful, objective changes to the way your work works.
I bet the organisation you work for has a set of values. Practically every large company I worked for had their standard corporate list. They do this to help create a sense of identity and a common standard for how to behave. Aside for the moment, whether these values remain only on paper (they often do) rather than perspire in actions of the employees. To follow Ricardo Semler we could actually go a step further as:
“No organisation needs a corporate values statement on the wall. You can tell what the company values by how people behave.”
However, values on their own are not enough. According to Kent Beck
“Values are too abstract to guide behaviour”.
That is why values are often complemented with principles – “a rule or belief governing one’s behaviour”.
Well written, clear and commonly accepted principles can be very effective at guiding behaviour and creating a homogenous and effective team or organisation.
For example, this is how Herb Kelleher (CEO of Southwest airlines) demonstrates the usefulness of clear and actionable principles (quoted after Made To Stick by Chip and Dan Heath)
“Here’s an example,” he said. “Tracy from marketing comes into your office. She says her surveys indicate that the passengers might enjoy a light entree on the Houston to Las Vegas flight. All we offer is peanuts, and she thinks a nice chicken Caesar salad would be popular. What do you say?” The person stammered for a moment, so Kelleher responded: “You say, ‘Tracy, will adding that chicken Caesar salad make us THE low-fare airline from Houston to Las Vegas? Because if it doesn’t help us become the unchallenged low-fare airline, we’re not serving any damn chicken salad.'” Kelleher’s Commander’s Intent is “We are THE low-fare airline.” This is a simple idea, but it is sufficiently useful that it has guided the actions of Southwest’s employees for more than thirty years.
Few organisations go far enough, or care enough, to achieve such clarity and consistency. It’s a pity. But while you might not be able to tackle this at the global level, there is no reason you can’t make it work for the team you’re on.
Diana Larsen and Ainsley Nies in their new book “Liftoff: Launching Agile Teams & Projects” make writing team values and principles part of the chartering exercise in the chartering alignment part.
The process of collaboratively identifying values and principles gives you team a chance to share and explore views about what’s important, and to define the work environment you will create. And when difficult decisions need to be made, you’ll use the principles as guides.
If you decide to give it a go, and I encourage you to so, there is one aspect to consider.
May times I have participated in meetings where we get together, deliberate, discuss and come up with a list of values and principles we display prominently. This often left one issue outstanding – we didn’t really know if they would work or not. The feedback cycle is too long and often gets neglected. We don’t re-visit the list, we don’t check if it all works, we don’t know if it guides our behaviour as we expected.
Instead, you may want to try a different approach.
Organise a workshop to create your principles together. To make it more effective also prepare a set of realistic scenarios of what may happen in your team or on your project. Things that have happened in the past, things you know may surprise you, situations that require a bold decision to be taken, difficult situations.
- “a senior manager comes to one member of the team to ask them to work on something very important for a few days”
- “one of the developers keeps breaking the builds although others have already tried to help and explain what he can do to avoid it”
- “you suddenly discover the feature you have promised to deliver to your customer in this iteration is not going to make it”
- “a tester comes to you with some back news – there is a high priority defect she just discovered in the live environment”
With your scenarios in hand you can start thinking of and drafting your values and principles, as you would otherwise have. Once an initial list is ready you can then turn the feedback mechanism on, right there, in a safe environment of your workshop, to see how useful what you came up with might be. Take each scenario and try to play it out. You may do it all together or in pairs of smaller groups. As you enact each scenario reach the decision point and see if your principles help you agree on an expected outcome. If the principle helps, you’re on track. More likely though, some will not; clarity will be missing, perhaps a pinch of context, perhaps you’ll find out you have had different expectations amongst you. Go back to the drawing board, adjust and rewrite the principles and give them a go with the previous or new set of scenarios. Iterate a few times.
To continue the previous example, if you decide to pick “courage” as on of your values and write it out as a principle along the lines of “we have the courage to always speak openly and directly about problems that we encounter during our development processes” you could try and test it with scenario 2. The principle will tell you that you should now confront the situation and have a conversation with the developer who is having problems. But how should you do it and who should do it – the whole team, a manager, one of the colleagues (and you know this already failed once in your imaginary scenario)? Maybe in the course of role-playing the scene you realise that the way you address each other creates more defensiveness than problem-solving. This could lead you on to adding another principle around the value of “trust” or “mutual respect“.
Let’s recap; in order to take charge of your principles use the following process to create them:
- Write a few scenarios
- Brainstorm and sketch an initial list of principles
- Test each principle against the prepared scenarios
- Improve and adjust the values and principles
Every now and then my twitter stream comes up with an interesting statement or question that sparks some reflection. The latest one came from Paweł:
Should a senior manager veto decision of one of their team leads if they don't agree with it? Or should they do nothing and see results?
I’m going to treat is slightly broader, speaking of a team rather then just a team lead.
This is not only an interesting question but also one which, I bet, often gets asked, especially as teams gain autonomy in organisations. Let’s leave out, for the time being, the more fundamental issue, whether we need managers at all, and Bob has some tasty thoughts about this.
Let’s consider the two possible solutions to this conundrum.
Veto the decision.
This is most likely the default answer in traditional, command and control organisations. When seniority and position in the hierarchy is confused with experience and knowledge senior managers fell obliged to make their stamp and protect their subordinates from doing the wrong thing. I hope this approach immediately raises your concern, at least a bit. First of all, the higher up you are in the chain-of-command the more removed you usually become from where the real work is done and your understanding of the context and specific challenges diminishes. More importantly however, to blindly veto your team’s decision is a stark demonstration that you don’t trust their judgment or their knowledge. It undermines their autonomy (assuming they had some to begin with) and demotivates them from taking responsibility for their own actions in the future.
Let the team fail.
If you care about your team accepting responsibility, about their autonomy and motivation you may think that the best outcome then is to do nothing and wait for the result. After all, you might accept that you are wrong in your opinion or you may want to give the team an opportunity to learn and fail. The team will continue with their own, independent decisions towards some outcome. They may succeed, or they may fail. If the latter outcome realises don’t be tempted to go and say “well, I always knew this was a bad idea but I wanted you to learn for yourselves”. Regardless, by not sharing your concerns you are withholding information from the team which can potentially harm the team and thus the organisation.
There is a third way.
When Paweł initially asked this question my immediate reaction was that it is irresponsible to do either. It felt very similar to the problem of delegation. “To delegate or not” appears to be a puzzle for many managers. Jurgen gives a good solution to this one reminding us that there are in fact perhaps as many as seven different levels of delegation between the two extremes.
I believe it’s better to aim for the middle in this particular situation too. My preferred choice would be for the manager to honestly and openly approach the team. They should share their concerns in a neutral manner giving the team the information and the context they might be missing. Seeking to learn their position on the problem, exploring the different potential outcomes, exposing any implicit assumptions that either side might be holding and then allowing the team to take an independent, but hopefully better informed, decision. And even though it sounds like a long-winded process it can all be done in a 15 minute chat at a cafeteria.
However, remember what Senge repeats after Argyris
If there is disagreement, it’s usually expressed in a manner that lays blame, polarises opinion, and fails to reveal the underlying assumptions and experience in a way that the team as a whole could learn from.
If that were the case, perhaps the question we begun with is not even the right question to be asking.
It was a beautiful, crisp, cold winter morning today with temperatures finally dropping below zero so I have really enjoyed my cycle to work. I bet there are others, who, on the other hand, didn’t share my weather enthusiasm as they might have had to give up those precious moments of morning sleep to get up earlier and defrost their cars. It got me thinking about the temperature in our offices.
I think it’s a fair assumption that most of us work in some sort of open-space environments equipped with the usual comforts of temperature control; heating in the winter, air-conditioning in the summer; and the little innocent control dial somewhere in the corner. I have often observed all those interesting, intricate patterns of human behaviour directed at the lonely thermostat.
There will be some, who come in the morning, before most of us even start thinking of getting up, to get a grip on the control and set their favourite value. Others, who come later, will perhaps think: “oh no, it’s too hot in here, again” or the contrary “I have missed my cardigan again”. A brave individual will sneak up and turn the dial up, a few hours later someone else will pretend to ramble around and accidently fiddle with it, turning it down. Perhaps, like in one of the offices I worked in, people will start complaining to the building administrator and the thermostat will get locked in an ugly metal box. Now people will continue their battle over comfortable temperature with a barrage of emails.
All this is mostly being done covertly, quietly, often causing at least mild levels of personal agitation.
It might not be as trivial as it seems. Comfortable working environment is an important factor in how well we can do our jobs. If I can’t concentrate on the new piece of code I’m trying to write because my fingers are numb I’m prone to making more mistakes. There is also another aspect, one I’m more interested in –we seem unable to discuss the problem openly together. Perhaps we assume that, since clearly everyone has slightly different temperature expectations, it’s impossible to reach a consensus. Did we ever try to test that assumption? How would we go about doing it?
Surprisingly, it may turn out, tackling the office temperature issue will make it easier to handle other heated debates.
Or maybe it’s another argument for private offices.
Lindesberg from flickr by Ahopsi
This morning, as I was cycling to work, I have noticed my rear tyre would do with some more air. I stopped by a large supermarket to see if I could buy a bike pump. Having quickly scanned the shelves with DIY and car accessories and some household goods, without much luck, I turned to one of the staff members:
– “Excuse me, do you know if you have any bike pumps?”
– “I’m sorry sir, we don’t. A lot of people are asking about it though…”
It’s not the first time I have had a conversation like that and it always baffles me. Clearly, there is an opportunity for the shop to sell an article. They could make some money or at least attract more customers. Clearly, people who work at the shop know very well about it and yet, it is being lost. The information does not reach the shop manager or they choose to ignore it. Those “at the top” believe they know better to make the right decisions.
I was also shopping at another supermarket. This time I couldn’t find my favourite olives so I asked a member of staff. After a nice conversation he said a lot of people were asking for them and they will be in stock from next week. The member of staff on the shop floor turned out be the shop manager. We regularly shop there now.
So which kind of supermarket is your company?