Waking the team from “the They” mode

One of the realities of working with a development team to help them change and adopt an Agile mindset is the fact that, as human beings, it is very natural for us to slip into a routine, to go along with the status quo, keep quiet about long-standing issues and generally blend in. It is all very well, for example, agreeing to be self-organising, promising to focus on one story at a time, sticking to a particular engineering practice, such as TDD or code reviewing and so on, but adopting new habits requires concerted focus and special effort, which implies that it is very difficult to maintain.

Personally, as a former student at various times of existential philosophy and psychology, this makes me think about Sartre, who spoke about the courage required to take personal responsibility, while Heidegger described “the They”* as our most natural state of being.  By “the They”, Heidegger was referring to the same kind of phenomenon that I mentioned above: blending in, going with the flow, doing what “they” do. This is a state of being in which we do not take ownership. We do things because “that is just what one does”, so we do what “they” do, “they” being a kind of general accepted consensus. Heidegger felt that we were in this state for most of the time.

This tells me two things in relation to changing habits, activities and culture within a team: firstly, we should not get too upset when people slip into “the They” mode – this is absolutely to be expected. Secondly, as a coach, I need to find ways to encourage the team to come out of “the They” mode into what Heidegger called “my owned self”** – a state of being where we take ownership of our own actions.

There are lots of things a coach can do to stir a team from the “psychological slumber” of “the They”. Here are just a few I have tried recently:

– asking probing questions in forums such as the retrospective (for example: “What can we make of the fact that we did not deliver all of the user stories that we committed to delivering?”)
– calling things out in the daily stand-up or in other meetings (“I notice that there are a lot of user stories in play”)
– setting targets for unit test coverage
– using statistics to show patterns in work flow

My latest idea was to give the team a questionnaire. The intention was to encourage the team to reflect on their everyday habits with the hope that this might invite and inspire them to try something new. I handed out the questionnaire in advance of the retrospective and asked the team to bring the completed questionnaire into the retrospective and to discuss their responses in small groups of two or three. I told them that I did not want to see the answers myself, but invited them to each consider taking one personal action in light of the discussion of the questionnaire. These actions were put on the board without names, so it was purely left to the individual concerned to take the action or not, but at the same time gave others the opportunity to see what actions were taken by others. I think the private, “self-regulatory” format was an important part of this to ensure that the team did not feel that this was something for me.

For the sake of completeness, here is the multiple choice questionnaire I put together. It undoubtedly reflected what I consider to be positive behaviours for the team, so it was not totally neutral. Perhaps there will be different opinions about this. I am sure that someone else could come up with many other possibilities and/or improve on this:

I learnt new things in this sprint

  •     I learnt a lot
  •     I learnt a few things or one or two really useful things
  •     I didn’t really learn anything significant

I worked out of my comfort zone during this sprint

  •     I did this quite a lot
  •     I did this some of the time
  •     I did not do this much

By working with other team members, I learnt something new and/or enabled someone else to learn something new.

  •     I did this a lot
  •     I did this some of the time
  •     I didn’t really do this

In this sprint, I focused on doing my own tasks without worrying too much about what everyone else was doing.

  •     I did this most  of the time
  •     I did this some of the time
  •     I worked mainly in collaboration with others

In the last sprint planning session, I understood the user stories well enough to be confident that I could finish work more or less according to estimates.

  •     I understood most user stories well enough
  •     I understood some user stories well enough
  •     I did not really understand the stories well enough and things took much longer than expected

I get irritated and/or bored when a user story goes on and on and on and on….

  •     Yes, I usually get irritated and/or bored by this
  •     Sometimes it bothers me
  •     I don’t really care to be honest

My intention with some of these questions was to prompt team members to hold up a mirror to themselves. If for example, I realise that I learnt nothing in the last sprint, I might be prompted to think: “what am I getting out of this if I am not learning?” or “well, it would be nice if I could learn something next sprint” or “I want to make sure that I learn something every sprint!”

Or if I acknowledge that I did not come out of my comfort zone, this might prompt me to consider that this could be a cause of boredom, for example.

Other questions were designed to encourage people to think about the purpose and usefulness of particular activities in the sprint or simply to prompt people to be curious about how they acted within the sprint.

In summary, all the questions were meant to stir people, to wake them from “the They”.

 

 

* “the They” is also known as “the One”, as in “what one does” which is a closer literal translation of Heidegger’s original terminology in German: das Man. But “the One” also makes me think of “the chosen one” as in The Matrix, etc.

** “my owned self” is also known as “my authentic self” – I prefer the former translation because “authentic” in modern English seems to imply too strongly that it is somehow a “better” state of being. However, Heidegger intended no value judgement in his description. The original terminology in German is: eigentlich

For more on Heideggerian terminology, see: http://en.wikipedia.org/wiki/Heideggerian_terminology

This entry was posted in Agile, Scrum. Bookmark the permalink.