Agile research needs help

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.

2014 most common jobs
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.

Working with international teams

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.

 

Deep dive: Planning

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

 

 

Our language, our worldview

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.

spicy
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

By anti-agile, I mean in the sense that they don’t put individuals and interactions over processes and tools, and can be demotivating for creative workers.

 

Guy’s favourite Agile links

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:

Scrum

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.

Agile

Clearly the Agile Manifesto is the source of truth on this.

Lean

I can’t help but recommend Mateusz Gajdzik’s simulator tool. Don Reinertsen’s book Principles of Product Development: Flow is also of interest here.

Psychology

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):

  • Dan Pink on motivation
  • Nudge (and I like many other RSA videos too)

Management and Leadership

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.