I think this is one of the first times I’ve created something new in a psychology context. Let me first outline the problem. I struggle to relax and unwind, but sometimes (even/especially during the workday) I need to do something different to get away from stuff. I guess you’d call this procrastination. Often I would go for a walk or do some exercise, and my friends were saying why don’t you just watch TV / read the internet / play flash games. But I couldn’t. If I did, I just felt guilty and certainly didn’t get pleasure or relaxation from it.
Not all procrastination behaviors either are harmful or lead to negative consequences.
I wanted to be able to procrastinate, not least because of this cool research that can be seen in this wonderful article. Basically, people who were told a problem, then played minesweeper, then attempted to answer a creative problem, came out with many more answers. As mentioned in the article, this may not be strictly speaking procrastination, but what I can do is replicate this creativity study environment at home for myself in the hope of enjoying their reported 28% increased creativity.
Cue the world debut of the Active Procrastination Board:
Each card has something different on it, a little like Brian Eno’s Oblique Strategies. Unlike oblique strategies, they are all activities designed to:
Take me away from what I am doing
Take varying lengths of time (so I can choose what I need)
Be things I would like to do
Be playful
Be a large range of different types of thing
Be mostly “wholesome” activities
Not be too intellectually or physically taxing
When I first used this, I started having it with dice to pick the card, one for the row-number and one for the column-number. However, I found I wanted to use the board more if I picked one I wanted to do at that time instead. For example, “heading to the library to read a random book” in the rain is annoying and takes ages, but in dry weather is fine.
Please let me know your thoughts, and if you try creating your own I’d love to hear about it!
The term “retrospective” is prevalent for any of the Continual Improvement meetings, largely due to the popularity of Scrum. However, this post really refers to any meeting where a change to process is made. Whatever you might call this, it is very important, as I hope I will show in this post.
Why should the team do a Retrospective?
It allows them to talk about their feelings in a safe space (Social Connection/Relatedness)
It allows them to make small changes to their processes, to try to make their delivery better (Mastery/Competence)
It allows them to feel in control (Autonomy)
It allows them to step back and see what they’ve achieved (Purpose/Competence)
So a Retrospective gives a lot of the things that Self-Determination Theory holds are important for motivation (highlighted in bold in the list above). If you aren’t doing retrospectives in some form, then you are perhaps missing out on a chance to motivate and inspire the team, as well as not helping them to deliver more.
Who should run it?
There are a few options here:
An external (to the team) facilitator. This has the advantage of allowing each team member to equally participate. The disadvantage is that the team members may feel that the meeting is happening to them, rather than for them. And of course someone needs to arrange the facilitator.
A scrum master or similar. Advantages include that they are probably good at facilitating, and know how to help the team work well together, and that it is their role so they will make sure the meeting is organised. The main disadvantage is that it can dis-empower the team (as above).
A team member. This has the advantage of making team members feel engaged with the process (especially if they each take a turn). It has the disadvantage of needing meta-coordination, and can lead to variable quality.
A manager. I think this is a bad idea as it reinforces the hierarchical ideas, unless the manager is a very effective Servant-Leader and able to keep her/his opinions to a minimum!
Who should be there?
Everyone interested in the team performing well. So definitely the team including Product Owner (or equivalent), and anyone else who might having valuable insights to share.
What should the outcome be?
The outcome of a Retrospective should be a very small number of SMART actions. A small number since the team can be considered a Complex Adaptive System, and as such according to Cynefin (and common sense) should be conducting small experiments rather than many large changes. By SMART, I mean Specific, Measurable, Achievable, Relevant, and Time-based. Sometimes these actions will be about how the team work together, other times they might be about improving the working environment, software, tools, or interactions with others. Whatever is important to the team at the time.
It is also very important that a Retrospective is FUN! The desired outcome here is that the team want to do it again.
What should happen in a Retrospective?
I’d describe a good Retrospective as Serious play. By that I mean playful but about something serious, with serious outcomes. Tools like retromat give great ideas for how to construct these kind of playful sessions. In particular, using colourful postit-notes, images, memes and other creative tools can make the session feel more fun. For me the important parts are:
Set the scene and let people check in. It is important here to get the energy levels up and frame this positively.
Write down separately comments about the last Time Period in some form
Allow people to speak about them
Agree on important core issue
Get the team to come up with and commit to a SMART solution or experiment
Get feedback on the retrospective itself
I think it is important to allow people to separately write things down because it allows the less vocal in the team to say what they feel without interruption by the more extrovert. It also keeps the discussion wide initially, before narrowing. This intentionally mirrors the Explore-Exploit of “the bandit problem” which is often applied to innovation theory. Essentially with Retrospectives we are helping the team to innovate themselves.
How often should we do Retrospectives?
Scrum says once a Sprint, where a Sprint is usually between one and three weeks. However, the team should decide the frequency. More frequent Retrospectives give fast feedback, and shorter feedback loops, so if you are very “agile” then it is likely you will be doing this very regularly. I’ve worked in teams that have a Retrospective each week, and others that have a Retrospective only once month.And of course they can change the frequency whenever they need, through the Retrospective itself. It really depends on what the team wants (more often is better as it gives faster learning).
I’m often asked “How do you manage to ACTUALLY work from home so often?”.
Well, for me the answer is simple: routine and adapting.
Thanks to reading lots of psychology/sociology books, I also think I have a reasonable handle on what makes humans happy: things like Social Connectedness for example. That means I build them into my rituals.
My schedule:
6AM: Wake up. Yes, every day same time. Apparently this is better for you. I also get out bed immediately, no snooze-button. I have always been a morning person, and appreciate this doesn’t work for everyone. My wife is now almost adjusted to this schedule (we find sticking to it works much better if we both want to sleep at the same time).
6:05AM: Go exercise! I follow a training plan as I’m normally on autopilot this time in the morning, and I find it keeps me motivated. This can be anything from a 30 minute light cycle to a 2hr run. Currently I’m following this half marathon plan. On my way out I let out the chickens (and if everyone else has bins out, I do that too. I can lose track of what day it is).
7 days behind… I can’t keep up.
After this, I stretch, have a protein shake and
shower, then read the news over breakfast (which invariably involves eggs).
9AM: Depending on how long the workout has been, this might be a hour or on a rest day even two hours earlier: but I will definitely have started work by 9AM. First up I write down the stuff I’ve thought of during my workout – I often am like “oh yeah I must do XX”, for example today as I am about to go on holiday it was to look up the best way of exchanging Czech Republic Koruna. I add these as kanban cards to my board. I then check the priorities for the day look right: if I’m lucky I can catch my wife before she goes to work and see if she has anything she wants my help with. An important part of this process is that I’m blending “work” and “home” things together as part of the same list.
Today’s board. The high WIP is due to waiting for replies to emails.
This allows me to flex onto whatever is more important, reducing the amount of “work” I do for “home” if that is what is needed. These tasks might me anything from “Do laundry” to “Write a blog post” to “Find out if data.gov has usable, open Littering Data”: I think the variety of these tasks keeps me engaged throughout the day.
9:15AMish: Crack on! Picking up either what was in progress yesterday, or whatever is more urgent today, I do it. And repeat. During these large work periods, I break it up with water breaks and whenever my Garmin Vivoactive watch tells me I need to get up and go for a quick walk round the block (around every hour).
12AM: Early lunch. No resting, just refueling. Usually leftovers or steamed veg.
12:30PM: Back to work. At around 3-4PM I am likely to start flagging, so I’ll probably change what I’m working on. I’ll also try to speak to a friend or family at some point.
6PM: Stop work. Sometimes if I’m not feeling in the mood this will be earlier. Make dinner. Eat with my wife (usually not chatting as she doesn’t like “eating air”).
6:30PM: Go for a walk with my wife (usually 5km, in the countryside). We talk about our days etc.
You might be thinking that anything like “going out” or requiring a late night would throw everything out of whack: and it does. I try to see friends on nights before I’m having a rest day for exercise, and I allow myself to wake up later if I need on that day. I ran several experiments where I reduced sleep, and it led to much less being done during that day. Seeing people is really important, and as such I try to go to one work-related event (eg Agile Meetup) and one friend-related event (eg pub) a week.
I make sure I top-up my social connectedness at weekends: like many young professionals I don’t have “free weekends” very often. The biggest thing I miss about working in an office is the social connection I found with colleagues, and indeed I am consider going to a co-working space, or even choosing to take on a full-time contract that would require me being in an office for several months.
I am also not fixed in this way of working, I am always trying new things. I tried a month of 5am starts in July, and did evening work sessions in August. Again, Inspect and Adapt is king.
Reading some academic papers on Agile recently, there is a huge misunderstanding about what Agile means.
In particular, some academics use the word Agile when really they mean Scrum. There are papers (for example this one) which say “agile teams” and continue on to describe how long their iterations (or even worse, Sprints) are. Sprints are a feature of Scrum alone, of all the Agile frameworks: the Agile framework of Kanban for example does not have iterations. Maybe this is an accidental slip-up, but I would hope for more accuracy from academics.
There are also lots of really great articles by people who helped come up with the very idea of Agile. The reason I am worried about even a few dodgy papers is that one experiment (or research paper) can easily be cited out of context or generalised by another paper, leading to huge misconceptions and ultimately a misleading (but popular) HBR or linkedin article without the right context.
Having said this, it is great that academics are starting to look at Agile: some claim the “research lags years behind of the practice” [1]. For me in particular, I am interested in whether the motivation experiments (which we rely upon for incentivising software developers and trying to keep them motivated) truly apply to software development tasks. This BBC article summarises some of the studies, on playing computer games, maths tests, and repetitive-key pressing. But there are none that I can find which examine software development motivation.
In some disciplines, generalising and abstracting is necessarily bread-and-butter: in Physics this makes loads of sense, but in Psychology given how complex and counter-intuitive some human decision making can be (eg “it was found that everyday hassles and uplifts were a better predictor of concurrent and subsequent psychological symptoms than were the life events scores” [2]). I’d love to share more of these things in a subsequent post, though I am by no means an expert in Behavioural Economics.
The most common job in each US State (2014)
The most common job in several US states is now Software Developer (rather than Secretary or Farmer, as it once was) [3]. Given the huge numbers of people now employed as software developers throughout the world, it would be great to be sure that we are interacting and incentivising them properly.
I hope this post inspires some academics to get more involved in fieldwork and talking with industry, and also inspires some Agile evangelists working in organisations to take a bit more of a rigourous and self-critical perspective when it comes to documenting and sharing what they are learning.
I thought it might be good to share some of the things I’ve learned from my five years working in international teams. This is purely based on my experience, so feel free to share any differing opinions.
Firstly, I’d like to point out that multi-country collaboration can work! I’ve worked in teams and had many meetings with one person in Brazil, France, Spain, and the UK. The most challenging part is the very few hours of shared time together (if across multiple timezones) so make the most of those hours together. I’ll be focusing on video-calls as I found these essential for international working.
Videocall setup tips:
Make sure the camera can see everyone (a lot of communication is nonverbal).
Power imbalances make communication hard, so try to switch “hosting”.
Everyone being in the same social situation helps eg evenly sized groups or all individually dialling in (yes, even if in the same office go to different spaces).
Having a constant Hangout/Skype on can help, depending on the amount of collaboration required. If you don’t need to collaborate, I find it distracting.
Arrive on time LIKE IT IS A NORMAL MEETING.
Improving videocall quality:
Background noise adds up and interrupts others: put yourself on mute if not talking.
Using headphones stops Skype’s auto-cut-out and allows you both to speak and listen at the same time.
Plug in the ethernet (not just wifi).
Building team connections in other ways:
It is very much worth (early on in the relationship) visiting each other’s locations for at least 2 weeks. 2 weeks because it gives a weekend to relax and understand the culture better, as well as to know the people you will be working with.
Go to the pub, sportsbar, or culture-appropriate-alternative together.
Don’t forget you can do 1:1’s and other small meetings over videocalls too. I’d recommend building these confidential meetings into your rituals where possible, as it helps build trust. Also 1 to 1 video calls are actually pretty good.
If you’re coding, agree your coding standards together. Lots of collaborative software exists (Slack, Jira, Trello, Google, Github,…). I can’t advise what will be best for you: simply explore and see what works best for your needs.
So those are my tips. As ever I’d suggest Inspect and Adapt! For example in retrospectives it might be helpful to add in an activity to talk about how you collaborate and any experiments you might like to try.
In this post, we’ll discuss different ways of planning. When I talk about planning, I mean deciding what to do or what objective to achieve.
As such, estimation and other timeline-related activities will be out of scope here ;-).
When do we plan?
In Waterfall, we start with a planning phase: deciding all the work to be done, up front. It looks a little something like this:
Waterfall Planning
In Scrum, we have iterations (sprints) which have a Sprint Planning meeting at the start of each. So our picture looks a little bit like this:
Scrum Planning
In kanban, teams can do as they wish. Often this results in doing planning when it is needed (eg once all the “in progress” work is done) so it is more sporadic:
Kanban Planning
Overall, the proportion of time spent on planning might be about the same: Agile evangelists would say that because of the pivoting this repeated planning allows, the value they deliver overall over the same time period will be much higher. (I agree with them!)
One of the things I find interesting as thought experiments is applying these concepts to life. As a child, many of us have some dream of what we would like to do. As time progresses, perhaps this dream changes: in some sense perhaps this is a bit like a failed waterfall project… I hope though that we can instead see it as more like kanban planning: if you wanted to be married by the time you were 25, but didn’t meet the right person, it doesn’t feel fair to call that a “failure”.
Who does Planning?
In Waterfall, it is often a Project Manager, with the help of a few trusted Business Analysts. Perhaps the rest of the team have not even been assembled at this point.
In Scrum, the Product Owner sets the direction (and if they are a “good” team the rest of the team will be very involved too). Often the developers are involved in estimation, and in a good team they will also be involved in creating some of the stories, with the Product Owner having an overall accountability for it.
In Kanban, it can be anyone, though it is common to have someone fulfilling a kind of Product Owner role, to engage with stakeholders and understand what work will add value and be the best return on investment. Importantly, it is often those doing the work who will trigger the planning sessions (eg when they have no more work to do).
Psychology of Planning
It seems clear from Self-determination theory that those doing the work being involved in planning will lead to more intrinsically motivated workers, who actually want to work. This is particularly true in creative work. If you are interested, I would really encourage you to read up on Self-determination theory and see how you can apply it to your team to help them be more fired-up about their work.
Language shapes the way we view the world, as George Orwell points out in 1984 through the genius of Newspeak: part of the idea being that by replacing the word for “bad” with “ungood” for example, we limit our ability to conceptualise “bad”.
Spicy?
As you may have noticed by the (Chinese inspired) name of my company, I’m interested in language. One of my favourite mind-opening discoveries is that Mandarin Chinese has many different words for “spicy” including:
辣: general word for “spicy”.
干辣: literally “Dry spicy”
香辣: literally “Fragrant spicy”
麻辣: literally “Numbing spicy”
Since this realisation, I have noticed much more the different types of “spicy”, and I find myself wanting to refer to different types of spiciness. As for many Chinese people, the blanket term of “spicy” often doesn’t do enough to describe the different tastes.
Numbing spice from Sichuan. This is for breakfast…
Tense
Tense (indicating past, present or future) is also not as well defined as I had imagined before learning Mandarin Chinese. In Chinese, Past and Present are the same. WHOA. There is a nice article from The Guardian on this topic.
Chen’s argument is that the more you think of the future as a radically different thing, the easier it is not to worry about how too many cigarettes – or too little money – might cause problems in that future.
Coming from the other angle, apparently Sicilian dialect has no future tense (interesting video source).
Why is this useful?
Language matters. Different words can have hugely different connotations to different people. We need to be really careful in Agile about our use of metaphor. Some I would argue are anti-agile:
Describing the company or organisation as a “machine”
Describing managers in a hierarchy as being “above” others
I thought I’d share with you some of my favourite tools and resources I use as an agile coach. I find all these topics to be essential for being a coach.
Retrospectives
I love helping teams do retros, so they can reflect and improve the ways they work. But better is getting them to lead their own retros. To help, I often share my favourite retrospective idea sites:
I try to use only the scrum guide here. Too often I hear people say things like “We must have User Stories because we are doing Scrum”, which is not only untrue by the definition of Scrum, but also may stop the team from doing something smarter (though I do like user stories in general, to ensure the team have a value focus).
Kanban
David Anderson’s “blue book Kanban” suggests a fairly rigid approach, which is worth considering and learning from. I would argue it runs counter to the philosophy of empowerment evangelised by the Agile movement.
I like the “primary sources” for this, such as this from Toyota.
I tend to use coursera to expand my horizons in Psychology (as well as in other areas such as gamification or mathematical techniques), as books get out of date very quickly. I very much enjoyed “foundational neuroscience for perception and action”, “social psychology” and “inspiring leadership through emotional intelligence”. These change all the time and many of the above are no longer available, so have a browse yourself.
I also love the following videos (which I am sure to have mentioned before):
The distinction between management and leadership is critical. For some “agile appropriate” tools, I like Jurgen Appelo’s work, particularly Management 3.0 #Workout.
For leadership theory, I’d recommend reading some summaries to broaden your perspective, such as this.
Coaching skills
Lyssa Atkins’ book Coaching Agile Teams I found a helpful and well-thought-through guide. Overall though, I’d suggest that in coaching there is no substitute for practice. Inspect and adapt.
I’d love to hear about your favourite resources, and any feedback or suggestions for better resources.
A few weeks ago, I attended the Presidential Address at the Institute of Mathematics and it’s Applications (IMA). Using this, the IMA President Chris Linton argued the need for bridging the distinctions between “Pure” and “Applied” mathematics. Without giving too many spoilers, he also put the case that the “success path” for people at university is often seen as further academic study, eventually leading to professorship. Progressing into being a teacher, actuary, or any other job is culturally, perhaps, seen as a failure. In summary, I took Chris’ Address as a call for action: for changing the culture of success in mathematics to being more balanced across academic, industrial, educational, and other options. If you’re interested in mathematics, I would recommend going to one of the branch meetings where Chris will be repeating this talk.
It is this same belief that led me to start full time working on Fuza a little over 3 months ago. You can see an example of maths applied to industry in this post. Indeed perhaps more broadly, I believe we should be using the science we already know:
British greenery: Sunshine not often included (Letchworth Garden City)
It has been shown recently that 30 minutes of visits of green spaces reduces instances of depression and high blood pressure [source].
In another study, countryside walks were associated with reduced rumination (associated again with depression). [source]
There is a weight of science supporting the benefits of urban trees [source]
To me, it seems logical and worthwhile that some city should conduct a practical experiment to see if we could reduce depression, perhaps by simply planting some trees. It seems sensible to conduct a small trial, in order to get some fast feedback. The alternative to a local trial is either to do nothing, or wait for a central government policy to implement it everywhere.
In my town of Letchworth Garden City (UK), we are lucky to have a heritage foundation who do lots of good work, for example converting one of our 100-year-old houses into an eco-home [source]. Experiments do happen, but I would love to see more.
More countryside (Bristol – you can see the suspension bridge in the distance)
As a society we are, according to me at least, not implementing enough of these experiments. I have written this blog in an attempt to inspire some of my local decision makers to try more things for the benefit of their fellow citizens.
This is of course just one piece of science that I think it would be interesting to implement. Perhaps there are things you care about that we should be experimenting/implementing within our communities or businesses. I hope we can all do our bit to help get science used in reality. In the meantime, perhaps I will go out for a countryside walk.
FUZA 