Motivating Others in Agile Projects

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

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”

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 one. Substitution 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

Optimism Or Delusion? How To Strike A Balance When Trying To Motivate Your Project Team

I came across a post by Ben Horsman that discussed the power and importance of being positive about project goals with the team. It got me thinking, does being positive actually help? I have found in life that some things can only be done through acting as if they will succeed. It’s allure is that it will be a self fulfilling prophesy. Also, planning for success allows us to capitalise on good luck. Daniel Kahneman suggests in Thinking Fast and Slow (p256) that optimistic leaders are more likely to succeed:

Their confidence in their future success sustains a positive mood that helps them obtain resources from others, raise the morale of their employees, and enhance their prospects of prevailing.

So there is this idea of acting “as if” something can be done to increase it’s chances of happening. On the other hand, this idea is prone to abuse. Projects with no chance of succeeding can see their outcomes made worse (and be made less tolerable for the team members) by blatant denial of reality by the leadership. James Boswell wrote in his book Life of Samuel Johnson (1791)

Patriotism is the last refuge of a scoundrel.

It may be that optimism is the last refuge of the leader of a failing project. There is a great Dilbert on optimistic projects here. In addition to being an act of desperation, my experience is that unrealistic goals can have a strong demotivating effect on people. Martin Seligman has demonstrated something he calls Learned Helplessness, which arose in experiments when dogs were faced with insurmountable goals. I suspect something related to this dynamic is what I have seen in teams where we just don’t believe goals are rationally feasible. I wrote more about Seligman and the dog experiments in a previous post. There are so many costs associated with being knowingly unrealistic; colleagues will stop trusting you, some will try to adjust your estimates in their heads back to realistic numbers (with strange results), still others may avoid working with you because they don’t want to be lead by someone who oversells what they can do. All this is to say nothing of the ultimate price of losing personal integrity by knowingly misleading ourselves and others.

So, optimism about project goals can be either helpful or destructive. Is it a question of degree? Kahneman suggests moderation in optimism so as to

“accentuate the positive” without losing track of reality.

and this may be the balance to seek. As I understand it, Jean Paul Satre suggested that we recognise that no endeavour will change our lot in life in any way that matter. So, to lend life meaning, we should take on tasks and act as if they had meaning. He suggests this will work as long as we don’t forget that these undertakings are not intrinsicly meaningful. We may be able to lend sound project teams some motivation if we act as if they will perform better than we calculate they will, while never forgetting that their chances of success or failure must simultaneously be rigorously assessed, regularly checked and clearly communicated to all.

The way I attempt to pull off this balancing act is to aim for realism, communicate optimistic goals to the team and stakeholders, clearly label these goals to all as stretch targets and give feedback towards progress.

A very interesting approach to motivation has been put forward by E. Scott Geller. Ask your team three questions, he says.

• Can you do what we are asking you to do in the project?
• Can the project be done?
• Is it worth doing?

Give people autonomy and regular feedback once work commences and confidence will arise in them. These questions of Geller’s would be at home in any sprint planning meeting. Geller’s assertion that confidence follows is supported by my own experience of agile teams in action.

Geller’s ideas chime with another leading voice of our time on motivation, Dan Pink. In his book, Drive: The Surprising Truth About What Motivates Us,  Pink suggests we look to “autonomy, mastery and purpose” for motivation. This echoes my experience. I have found that agile naturally involves team members in decision making. Mentoring and supporting team members to learn on the job has also been a great way to motivate people (it is also one of the most personally rewarding aspects of my work). Finally, sharing a common goal has been a feature of all successful projects I have worked on. Not just acknowledging that senior management have a certain goal, but personally feeling that this is something that should be done. Both Pink and Geller stress the importance of team members thinking that something is worth doing. Taking time to discuss with the team what I think senior management objectives are based on and why they are globally important has always been time well spent. I have Drive by Dan Pink on my bookshelf at home and may come back to this topic, once I have read it properly. From what I understand so far, it is worth a read as much for understanding “what you thought was true about motivation but is not” as for understanding “what actually does motivate people”.

I mentioned “personally feeling” that something should be done. I once had a Japanese language teacher called Hasegawa Sensei. She made it so abundantly clear that she was personally invested in us talking quality Japanese that it was infectious. We actually cared more because we knew she cared so much. Paying attention to the work produced by the people in my team is something that I strive to do and I wonder if that ever has the effect of making them care more about the work they do.

Both Pink and Geller have great Ted talks, that lay out some of their ideas on motivation. In so far as their ideas relate to motivating project teams, I find them very persuasive and in some part, familiar from seeing agile teams at work. Horsman’s article makes a point restated in a much more nuanced way by Kahneman. If my reference to Satre is justified, positivity has it’s place but must always be clearly labelled as such and people must never lose touch of the reality of what the project’s prospects are. There is so much more to say about motivation. Pink addresses one obvious question I have not gone into. Some think that people are paid to work on projects and that should be motivation enough. The truth is more subtle than that, I find, and it is has been well worth taking time to consider what motivates people, something I am still far from getting to the bottom of.

Image is Read My Mind by Shirokazan 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.

Take 2 Bottles Into the SCRUM? Conditioning in Project Teams

I’m not sure it makes sense to apply conditioning to management practice (Is that naive? I’d welcome your views). That said, I think an awareness of conditioning can be useful in understanding behaviour, including in a work context.

My understanding of conditioning comes from my study of the thinker J Krishnamurti. I think he uses the term to mean all the stuff you take in without knowing it that changes who you are and how you see the world. Psychologists use the term conditioning in a different way, to talk about learning (changing behavior, based on experience). Classical conditioning refers to the pairing of things you do anyway with new stimulae. There are some great info graphics on this here. In time animals learn that the two go together and will respond to just the new stimulae. Pavlov’s dog, who was conditioned to salivate at the sound of a bell, is the most famous example of this. Operant conditioning is where an animal’s behaviour is rewarded, such that it learns to operate on the world in a particular way. Thorndike taught a cat to operate a lever to release it from a box. There have been tales of professors manipulated by their students via operant conditioning to leave the podium during lectures, while being unaware they were being “trained” to do this. One can imagine how these training methods could be extrapolated to apply to humans but that seems plain manipulative.

Ultimately, I think if you are trying to manipulate your colleagues without their knowing then you have a lot bigger problems than low productivity or whatever you are trying to improve. Is there a way to apply an understanding of conditioning to the workplace and projects in particular? Yes, I think there is. Project teams and agile teams in particular are great at shaking things up and trying something new. I learnt in my lecture that Pavlov said that “the laws of classical conditioning are the laws of emotional life”. So, one example of using an understanding of classical conditioning to improve a work environment might be tackling situations where classical conditioning has lead to a pairing of a certain room or meeting format with stressful meetings. You can’t stop meetings being stressful by changing the room but, once the root cause has been dealt with, team members may still associate rooms or meeting formats with stressful experiences. Making simple changes at that point may be beneficial in moving on from stressful situations.

This is the limited kind of role I see for the application of an understanding of conditioning in the workplace to fix problems. I do wonder if classical conditioning can help us understand the effectiveness of the rituals in agile. Do these rituals in part prime our minds to be in a certain state (e.g. alert and focussed on our colleagues at stand-ups)? Not much on the application of operant conditioning here. I’ll have to give that some more thought later but it may be that it is just too manipulative to be appropriate.

Who kept the dogs in? – Continuous Improvement Part 2 of 2

In part 1 of this post I was talking about how, when continuous improvement does work, it always strikes me as a much less stressful way to work and I was wondering why that is.

Although there may be conceptual parallels between Thorndike and AGILE, I don’t feel I have yet gotten to why continuous improvement feels like a more forgiving and easy environment. I was thinking maybe the work of Martin Seligman can shed some light on this.  Seligman (and Steve Maier) put dogs into situations where there was nothing they could do to avoid painful electric shocks. They found the dogs behaved in much the same way as depressed people. Other dogs could stop the shocks by pressing a lever. Still other dogs were not shocked at all. After this, Seligman and Maier put the same dogs in boxes (there they go again with their animals and boxes) and experimented with making them shuttle from one side of the box to the other. He motivated them to move using electric shocks. If they jumped over a small partition they escaped the electric shocks. I find this pretty grim stuff and am not at all clear this was worth it. Still, it is interesting to note that the dogs who had not been shocked and the dogs who had been able to do something about it were able to escape by jumping over the partition. The dogs who had been helpless sadly laid down and were shocked. They did not try to escape.

I am wondering if learned helplessness goes some way to explaining why continuous improvement environments are less stressful. We always feel we can try something new.

There is an interesting take on learned helplessness in people here