Category Archives: Application of psychology to project management

Motivating Others in Agile Projects

Carrot + Stick < Love

When I think about motivating people, I imagine saying stuff. “Well done”, “You are really good at that” and “We did it” are examples that spring to mind. In delivery focused project land, this is understandable but it turns out not helpful for motivation.

I have written a fair bit about motivation on this blog. Mostly I write about environmental factors that can improve or diminish motivation. I have also enjoyed reading around this subject online. Many others have explored motivation in agile, for example seeing the Scrum master’s role in motivation as setting the tone or otherwise controlling the environment in some way. A developer’s eye view is given in the first answer to this question about the introduction of Scrum. This slide deck also explores motivation issues around introducing Scrum. Many of the articles on motivation in Scrum relate, as I have done to environmental factors explored by Dan Pink and his book, Drive.

I have also written about how to talk to project teams so as not to demotivate them and how to allocate tasks in the optimum way for maximum motivation. These all feel like ways to not get in the way of motivation. I like the approach of avoiding demotivating behaviour. It reminds me of the Primum non nocere (first do no harm) edict of the physicians.

Before I look at what can be said that is constructive for motivating ourselves, a word on the role of motivator in the team. I don’t see one person in agile teams as the motivator and there seems no need to explore what to say as “the motivator of the team”. That said, it does seem relevant to look at what we can say to each other at work that is constructive, versus the usual sayings in my opening paragraph. If my other posts and the posts I mention by others look at optimising the environment and processes for motivation, is there an optimum way to give feedback to each other that helps us feel motivated?

According to psychologist Caroline Dweck, we motivate others when we show appreciation for their efforts and recognise the process that they are engaged in. Focusing on results or fixed states like “you solved the problem, you are clever” just piles pressure on individuals to maintain performance levels and discourages risk taking. By contrast, appreciating effort and risks taken (e.g. new strategies tried) encourages others to take a chance and work differently. This is clearly relevant in agile, where iterative assessment and trial of new ideas are central.

Why does this kind of feedback work so well? Dweck posits that many of us suffer from a fixed mind set, where we tell ourselves that we are good at X and bad at Y. These become self-fulfilling prophecies. Dweck is not suggesting we reject reality with “pollyanna platitudes”. Rather, she is asking us to be aware of fixing ideas about people in general and about their skills, talents and abilities in particular. Instead of a fixed mind set, Dweck advocates a “growth mind set”, where we see ourselves (and others) as having unfixed scope for improvement. That is not to say that we can all be Einstein, but it does mean that each of us can improve in any area, given effort and the right attitude. I find that a liberating idea that chimes well with agile. There is no skill level that cannot be improved upon. It is wrong to see ourselves as “just bad” at anything in any immutable way. Dweck is not advocating a blind, “can do” spirit. She is suggesting we be aware of “can’t do” spirit and allow ourselves to be open to “can improve” spirit.

I described to someone recently how I had worked in agile environments that were stressful and challenging. What I liked about agile was that I usually had the feeling that things were going to get better. Dweck’s mind set theory seems like this continuous improvement principle applied to our own capacities.

This post was inspired by another great edition of Mind Changers on BBC Radio 4. The concepts Dweck introduces are popular with educators and have been applied in many schools. They are well illustrated by this online game.

Image is Carrot + Stick < Love by Libby Levi licensed under CC by 2.0.


Control Issues in Projects

Propulsion Control Levers

In agile there is no leadership role. The scrum master is explicitly not in control of the group. This is the Scrum view of agile but even in DSDM there is more of an emphasis on motivation and coaching in the project manager role . And yet, in my experience, these groups do not lack direction and motivation levels are higher than in standard hierarchical structures.  So, why is this?

Way back in 1939, Lippitt and White ran some experiments that might shed some light on this. They ran boys clubs, training the adult leaders in three leadership styles, authoritarian, laissez faire (i.e. indifferent) and democratic. This study is often cited in business leadership articles and in teaching contexts. The findings were not so surprising today but I can imagine they flew in the face of common beliefs of the time (I imagine there was an emphasis on strong leadership/authoritarian style). Team members under authoritarian leadership were unmotivated and quick to blame each other. Laissez faire leaders produced even more of a blame culture. Democratic groups were most motivated, friendly, open and co-operative.

A later study might also be relevant to control in project teams. In 1976 Langer and Rodin found that giving rest home residents control over a few choices (such as what night to watch a film and how to care for a plant) lead to increased longevity. Although there were problems with the study, such as a lack of randonimity between members of the control group and members of the responsibility assigned group, the study was repeated by Langer’s student with the same results. Langer and Rodin referenced the dynamic of learned helplessness explored by Selligman in 1975. They posited that people who had more agency were more motivated, happier and healthier. I have talked about Selligman elsewhere and am struck by how relevant it is to project teams.

The importance of control being shared among the group is reflected in my experience of the workplace. I remember a large bank where staff were regularly told to stop talking to each other and only one staff member was allowed to open or close the window. That group had low agency and seemed unmotivated. My impression was that productivity suffered as a result. Conversely, in agile groups with a high degree of input into the team’s direction, motivation and productivity were high.

Sharing control of course does not mean leaving a group to it; that would be the laissez faire approach. Decisions need to be clarified and decision making facilitated.  A list of ill-defined issues and decisions can be oppressive to a group. The remedy is not to supply the group with decisions, rather it is to make explicit what the issues and decisions are and agree a path to decision making (sometimes that can be a matter of referring to someone outside the group).

This post was inspired by some particular material I am enjoying at the moment. The Psychoanalysis of Organizations: A Psychoanalytic Approach to Behaviour in Groups and Organizations by Robert De Board was published in 1978 but seems full of relevant lessons for today’s working environment. The other material I am enjoying at the moment is the radio series Mind Changers by Claudia Hammond. A great series that, like the De Board book, makes the psychological discoveries of the past interesting and accessible. Finally, I have to mention this great prezi presentation that I came across on Langer and Rodin. A fun way to review the material in the Claudia Hammond episode on the Arden House study.

So, is it a stretch to relate a rest home study to project work? What are your experiences of control in the workplace? Is democracy practical in all cases? Is it true that there is no leadership role in agile? What about the matter of responsibility? Thoughts and feedback welcome, as ever.

Image is Propulsion Control Levers by Dawn Endico licensed under CC by 2.0

The Cost of Task Switching. “Could You Work On This Please…No Wait…Do That Please”

Change direction

Yet another of those ideas in Thinking Fast and Slow by Daniel Kahneman that leapt out at me as I read was

One of the significant discoveries of cognitive psychologists in recent decades is that switching from one task to another is effortful, especially under time pressure.

This seemed relevant to project work. Task switching is certainly costly in projects.

Before getting to switching individual tasks, it seems relevant to visit the topic of switching tasks mid-sprint. Switching tasks any time mid-sprint in agile (and indeed any tinkering with scope mid-sprint) has, in my experience, not worked well and this seems related to what Kahneman is saying. Others seem to agree about the costs of switching tasks mid-sprint. I enjoyed the exploration of this theme in the “Product Owner changes” section of this article and the “Changing Requirements” section of this oneSubstitution mid-sprint is a slightly different proposition to change. I am all for substituting scope during the project. For example, where the team is a 3rd party supplier on a fixed price and the product owner identifies new scope mid-project, we have estimated the new scope and substituted out like for like stories. This is a technique that has worked well for me and I would recommend it. So substitution mid-sprint/project can work well but changes in the middle of a sprint carry a cost to performance and morale that has often been significant for me and my team. There are some reports to the contrary, and I’d be glad to hear of other’s experiences with this.

So, Kahneman is advising of the costs of asking someone to switch from one task to another before the first is finished. This is something that should be relevant to agile and waterfall teams alike. The articles I mention above discuss the cost of switching tasks mid-sprint, which, as I say, seems to have related overheads. Much of what these articles say translates to the cost of changing work packages mid-stage in waterfall land. Work packages often come with tolerances which, if exceeded cause project issues to be triggered but we are still left with the psychological cost of task switching. So what is this cost?

As will be familiar to you, it takes a certain amount of mental investment to understand a task and think through how the requirement is going to be met. Once the task is done, the back story and details can be forgotten but, until then, it all needs to be kept in mind. Blumar Zeigarnik demonstrated how we remember unfinished tasks more easily than completed ones. The eponymous Zeigarnik Effect that she identified goes some way to explaining the cognitive effort involved in incomplete tasks versus complete ones. The theory is that incomplete tasks take up mental capacity which is “released” once the task is complete. It makes me think of caching and flushing the cache in computing but this may be on the wrong track. Such an allocation issue with mental resources would go some way to explaining the drop in productivity from switching tasks. Perhaps an explanation is emerging but the Zeigarnik Effect is not the whole story.

I imagine the “significant discoveries” Kahneman is referring to is the body of research suggesting multi-tasking is not a great idea. While the American Psychological Association (APA) says that

Although switch costs may be relatively small, sometimes just a few tenths of a second per switch, they can add up to large amounts when people switch repeatedly back and forth between tasks.

My own experience (and that of my team members) is that task shifting carries a significant cost per task (not “relatively small”). The APA article mentions two cognitive costs of task switching, “goal shifting” (getting your head around the new task) and “rule activation” (if this is what I am going to be doing then this is what I will need to bear in mind). I wonder if this is what we project managers call the learning curve or something different. Since both of these need to be repeated in some measure when you go back to the old task, they are pure overhead.

Another component which I mention above is the blow to morale. Completing tasks carries intrinsic rewards. We experience these as this is experienced as positive physical sensations, as the brain releases neurotransmitters upon task completion (notably dopamine). Similarly, extrinsic rewards often occur in projects in the form of peer recognition and stakeholders showing approval and appreciation for completed tasks. Task switching means that the team member is now further away from the satisfaction of completing the task. While they were working towards that satisfaction on the original task, they will now not get that reward (intrinsic or extrinsic) any-time soon. Instead, they are now back at the start of something, so while they might have been hours from the satisfaction of wrapping something up, they are now days from that pay-off.

To summarise thus far, we have cognitive overheads like the Zeigarnik effect, goal shifting and rule activation. These are perhaps taking up memory and cognitive resource for the act of task switching. We also have social effects such as missing out on peer approval and stakeholder appreciation and the biological perspective of missing out on the positive sensation of neurotransmitter release in the brain, which is part of the mechanics of how we motivate ourselves. There is also the cognitive perspective on intrinsic motivation. All of these paint a picture of some of the main costs in time and morale that come from task switching. Incidentally, in writing this post I came across a surprising theory on the interplay between intrinsic and extrinsic motivation called cognitive evaluation theory. It seems positive feedback is not helpful where people are already self-motivated. Kahneman mentions that the cost of task switching is especially high “under time pressure”, which projects are almost by definition (and many projects extremely so).

Of course, project teams don’t have the final say on if the task gets switched and it may be worth it to the organisation despite these overheads. What seems important is for organisations to understand the full cost of task switching. It’s more than I thought it was.

Image is Change direction by Phil Whitehouse licensed under CC by 2.0

Why Collaborate?

Given a choice, most of us would choose to work somewhere where our colleagues offered support whenever they could and actively shared information they thought would help us. Perhaps some of us prefer the idea of our colleagues helping us but not having to help in return. Our choice is to collaborate or compete. It seems like corporate capitalism favours ruthless competition and short-term self-interest. But psychology suggests competing or trying to cheat the collaboration system does not pay off in the long run.

When I think about my own working environments over the years, there has been a wide variation in how collaborative they have been. Project teams are by their nature temporary. Like most project managers, I have had the interesting experience of becoming a part of a great many temporary teams in various organisations.  I realise, looking back, that I take my cues about how much I collaborate from the group I am joining. This approach is explained by the psychological theory around collaboration. Teams seem to find a level of collaboration. This is part of what is referred to as a Nash Equilibrium (after him out of A Beautiful Mind). We make decisions about how open and giving to be, not in isolation, but keenly aware of how giving our colleagues are likely to be. In competitive environments, team members act as if someone will end up on top and the others will be the losers. This relates to the zero sum game in game theory.

Psychologists and game theorists sometimes talk about collaboration as reciprocal altruism and a famous game in this area is The Prisoner’s Dilemma (Flood and Dresher 1950). The premise is that two prisoners are being questioned separately by police. If they both stay quiet they both get off on lesser charges. If prisoner A gives evidence against prisoner B, prisoner A gets off scot free and prisoner B gets a heavy sentence. If they both give evidence on each other, they both get the heavy sentence.

Analysis of The Prisoner’s Dilemma reveals a lot about collaboration. Mathematically, we are best off over time if everyone collaborates with each other (Axelrod and Hamilton 1981 and Worker and Reader 2004). Collaboration here means both prisoners collaborate with each other (i.e. both stay quiet) not that they collaborate with the police. This dynamic reminds me of being on a see-saw. If we jump off without warning the other person, we get to decide and control our descent but the other person gets to come down with a rude bump. It takes coordination for both of you to come down slowly enough to be comfortable (and nobody be the loser with a sore rump). This is by far the least stressful way to descend from a see-saw, as I’m sure you will agree.

So it seems that true collaboration, not cheating the system, is in our long term interest and is least stressful in the short term. I’ll talk below about how this relates to my experience of project management specifically. In general, it is a phrase frequently encountered on the web but if you Google “project management collaboration”, you get a bunch of software tools rather than theory examples. I guess the tools are easier to monetise than the theory.

Perhaps the benefits of collaboration in project management are so universally accepted as to be invisible. Examples come to mind easily. In a programme setting, open and proactive communication makes it easier to manage dependencies and risks. Projects benefit from sharing lessons learnt and exchanging intelligence on common risks and issues. Examples of a lack of collaboration in projects are similarly easy to call to mind. In competitive teams, members take on as little as possible and avoid supporting others, while maximising the appearance of their contribution. Likewise, if team members are competing then sharing intelligence about risks and issues lessens the chance of their project looking good relative to others.

Considering how something like the Nash Equilibrium might relate to my experience of project teams, I’d say the collaborative dynamic is surprisingly binary and sensitive to competition. As soon as one team member competes to do the minimum work for the maximum recognition, everyone else has two choices: either continue to collaborate and feel a mug, or compete.

The logical conclusion from my experiences of project teams chimes with the game theory concepts above. Collaborative teams are the most efficient and pleasant kind to work in, and if you want to work in a collaborative team, everyone needs to collaborate.

Of course, people don’t choose to either collaborate or compete based purely on reason. There is a nice story about a turtle and a scorpion that illustrates non-cooperation in the face of self-interest.

The references above to The Prisoner’s Dilemma come from the evolutionary psychology section of my Open University textbook. There are new books being written about this topic all the time and it will be interesting to see how much of this filters through to the workplace.

The above has been a brief look at collaboration in project teams. I have found it particularly hard to cover such a large topic in this short post. I have discussed choice of approach (collaborate or not) but I have not talked about the detail of how we collaborate. I touched on this in my post on how project teams talk. Mercer’s exploratory talk is a good example of trying to add light to a debate, rather than just the heat added by disputational talk.

Psychology for Project Managers?

Should project managers be counsellors or hold psychology degrees?  This 2011 post on PM hut muses about this. I think one reason why I like the PM role is the variety. I can see an argument for psychology training but then I can also see an argument for a finance, legal or HR degree. There are many strands to the PM role and some awareness of psychology will surely help, but I think I would stop short of thinking a degree is required because many other skills are required and PMs can’t hold degrees in all of these areas.

A related older post, this time from 2012, takes a look at psychology for technical managers. I found a lot of interesting ideas there about skills acquisition and imposter theory. I mentioned other similar articles on this topic in a previous post. I think what I like about the psychology for technical managers article was the feeling that it was a similar endeavour to this blog. Finding ideas from psychology that can be applied to people’s working life (in my case to project management).

Team Talk

One of the more obvious areas to look for insights into what makes project teams tick would be the field of social psychology. While Freud wrote about groups in the twenties, and industrial psychologists have been looking at this for a long time, much of the impetus for the modern study of what happens to humans in groups seems to have come from people trying to understand the behaviour of the Nazis in the Second World War. The applications of social psychology are many. For example, educators I know are particularly interested in how social psychology can help them improve teaching and learning. So what can social psychology tell us about working in project teams?

One feature I like about agile teams is that everyone is equal and has a respected opinion. I find this so important that I try hard to ensure all my waterfall projects are like that too. I temper this with always trying to give clear direction and leadership. As Laura Markham has said, people want to know that a ship has a captain and that captain is taking care of the ship. If the ship hits an iceberg, they don’t want the captain to come to their table and ask their opinion in a democratic and caring way. They want the captain to take care of the iceberg situation. So, I try to work in a team of equals, each with a clear and equally valid role. In that team, part of my role is to take overall responsibility.

This sense of equality is crucial to how the team talks to each other. Neil Mercer is a psychologist who studied the different kinds of talk in the classroom. I’d like to repeat his work in project teams. In his paper on the subject Mercer says

In exploratory talk, then, a speaker ‘thinks aloud’, taking the risk that others can hear,
and comment on, partly-formed ideas. Engaging in exploratory talk is therefore rather
a brave thing to do, and tends not to happen unless there is a degree of trust within a
discussion group.

This reminds me of both the ethos of agile teams (everybody is equal) but also the structure of the rituals. In the sprint retrospective or daily stand-ups, everyone has a chance to speak. The rituals make room for everyone to have a say. This encourages trust that one will be listened to seriously and an atmosphere of open sharing. Also, the permission (implicit in agile) to try out ideas and fail means that the groups is more disposed to entertain partially formed ideas and examine possibilities together.

Ron Friedman has been questioning the wisdom of collaboration on partially formed ideas, suggesting that it is better to do most of the creative work solo and come together only to share already formed ideas. I find his article very interesting and I easily related most of his examples to my working life. I do think, however, that his ideas apply less of the time than his article suggests. Friedman is not looking at agile teams in particular. I can think of lots of cases where solo creation might be best in agile. Still, it is worth noting that some of my most fruitful experience of agile teams has involved formulating solutions in groups. I’d say that is one of the strengths of agile.

Mercer defines three kinds of talk. I am interested to know if you recognise these from project teams. Disputational, cumulative and exploratory. Disputational communication is competitive. I find a lot of technical discussion sites highly competitive and intolerant of mistakes. I don’t know why this is so commonly the case. Cumulative communication is something I have come across a lot in conflict averse environments like some parts of the public sector. Ideas are accepted and built upon but without much analysis or apparently deep understanding. There is a lack of engagement. I also find this can happen when there are experts in the mix. People will listen to legal advisers thinking “well, it’s her job to know this stuff so I’m not going to question it”.

I once did a rather annoying drama exercise as part of a rather annoying team building day. It was interesting, The annoying bit was feeling compelled to take part (i.e. “You will have fun”). The exercise involved finding a partner, then listening to them start a story. When they stopped, you would say, “Yes and…” and continue the story. The shared ownership of the story made one pay attention and feel a lot more invested in where the joint story went. I imagine this is what exploratory talk is like but I wont be suggesting that exercise to my team any time soon.

There is much written about the interesting practicalities of communication in agile. I am interested in analysing the nature of that communication and would be glad to hear about your experiences.

Clear Goals and Feedback

Clear goals and feedback is a phrase I was reading in Flow by Mihaly Csikszentmihalyi (apparently pronounced Mi High Cheek Sent Me High). This phrase got me thinking about how agile sprints work. Csikszentmihalyi talks about the near instant feedback of the tennis player. They know when they have succeeded in hitting the ball over the fence to their opponent. Working with user stories, I know when I have reached my goal thanks to the definition of done.

Csikszentmihalyi goes on to talk about emerging clarity of goals, where they “…are invented on the spot”. He makes reference to kids trying to gross eachother out or making fun of a teacher. The end goal is evolving. This brings me to a lesson I have learnt in applying agile. One of the most common failings I have seen is the lack of availability of the product owner. This talk of emerging goals gets me thinking about why the product owner needs to be there, not just to provide clear goals at the start (users stories or requirements in waterfall) but to make constant decisions and clarifications about relative priorities of user stories, alternative ways of delivering user stories and what the user story is trying to achieve.


The water around Cosne Sur Loire

So, when we have clear goals (or support from a product owner to clarify as needed) and feedback, we have a good chance of being totally absorbed in our work and experiencing flow. More on flow here.