Tag Archives: Claudia Hammond

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