6 lessons I’ve learned from working with Agile Ninjas

TLDR; Eliminate waste.
Read Time ~ 5 minutes

Boy has it been an odd year. A year of volatility, uncertainty, complexity and ambiguity (VUCA), and having an agile mindset has never been more important.  Despite the sombre backdrop of 2020, good leaders have definitely learned, grown and adapted to the challenge during this time. Thankfully, one of the things that got me through this year was working with a team of awesome engineers, ScrumMasters, coaches and managers trying their best to adapt to change and lead in uncertain times. In the last 9 months, I’ve had the privilege of working with some of the most experienced agile coaches I’ve ever met. A pang of guilt rushes through me as I write this blog, as the contents are primarily a reflection of observations made possible by these awesome people. 

Whilst I’ve been on my own personal journey of growth and discovery, I thought I’d share with you some of my takeaways from those colleagues with an agile mindset so that others can take away something good, however small, from this otherwise sucky year.

1. The value of a good Product Owner

In the past I’ve worked in places where there was no clear product function, and found myself subsequently explaining to each new company-volunteered product ‘champion’ what their role should be, and why they should be passionate about it. So, it came as a nice surprise once I started working for companies who had product owners, where their job title was actually ‘Product Owner’. They not only showed up on time, but actually owned the product backlog and were held accountable for ensuring that the right thing was being delivered. Companies trying Scrum “because it’s Agile” often fail at the first hurdle because there is simply no representation of the customer in the work that engineers do. The benefit of having that PO role embedded on value aligned teams potentially saves months of wasted effort.

2. The team retrospective is the most important ceremony

The only ceremony that’s actually mentioned in the agile manifesto, at regular intervals teams should reflect on how to become more effective. I’m not going to cover well trodden ground about why they’re important (here is a great dedicated article to it) but it’s amazing how many teams either don’t do it or don’t find it useful. The reasons seem to be either:

  1. “We don’t have time with all the other meetings”. Answer – skip the other meetings. How can you possibly expect things to get better if you’re not taking dedicated time to figure out how?
  2. “They’re pointless”. Answer – give them a point. Make sure that actions are actionable, within the team’s control, written up and executed. Keep track of these. Don’t write an action that only “the company” can solve – this is the time to be accountable for your own team’s improvement.

A great way to encourage people to just T-off with retros is making something the team look forward to. Make it fun, and encourage discussion. Some ideas I’ve seen over the years:

  • Ask everyone to bring a gif / movie / weather icon / picture / emoticon that they would use to describe the last sprint
  • Pictionary – draw the last sprint and let the others guess what you’ve drawn and why!
  • Have a theme for the retro – themes I’ve seen include Mario Brothers, The Beatles (with accompanying music), Avengers, video games etc.
“How would you describe this sprint in a GIF?”

3. Real actual deadlines exist

“If you’re really agile, you’ll get rid of deadlines”. I’ve heard this so many times. Try telling that to the people who write software based on government legislative deadlines. Or those that write education software based on a hard back-to-school date. Or ask those that write payroll software to ignore the constant stream of changes to job support schemes and tax changes this year. Product roadmaps in these cases are very useful things, and should even include other non-deadline features based on changing markets, customer demand and engineering improvements. This is not the same as the people that promise the customer a feature that hasn’t been built yet by next week, without talking to the developers. There is still a special place in Hell for those people.

4. It’s about the mindset, not the process

The ScrumLords are not going to cast you to eternal damnation for not having a backlog refinement session

I was (and still am) a massive fan of Scrum, having championed it as the way of delivering agile software. The cracks started appearing when I tried introducing it to mechanical engineering and chemistry teams – they just couldn’t practically work to a regular cadence. After learning a little more about Kanban this year, that really could have worked. 
The ScrumLords are not going to cast you to eternal damnation for not having a backlog refinement session. But you should be confident that you’ve tried it as a team, reflected on it as a team, and come up with an even better prioritisation process as a team.

5. Communities of practice rule

I mentioned in a previous blog about the value of talking to other teams to better reflect on how your own team can improve, and communities of practice are a great way to do this. The DORA 2019 State of DevOps report states that 57% of elite performers use a “Communities of Practice” model as a transformation strategy – more popular than any other strategy, including proof-of-concepts, grassroots and centres of excellence. The Agile and DevOps principles crossover sufficiently enough that we can apply the same logic.

“The best strategies for scaling DevOps in organizations focus on structural solutions that build community”

“State of DevOps REPORT 2019” DORA / Google

Even if you can’t see tangible progress from your community, the sense of belonging, psychological safety and oneness it creates in a large organisation will pay dividends down the line. It gives members a sense of purpose which in turn creates a positive attachment to the organisation. An excellent article on how to get your agile community of practice off the ground can be found here, and having read it in retrospect, I’m pleased to see we weren’t far off the mark.

The golden rule – eliminate waste

All Lean principles revolve around eliminating waste, and it is hard work finding where the waste might be for your team. The process of estimating, for instance, can necessitate a useful conversation around acceptance criteria, encourage a definition of ‘done’ and eliminate waste for the team by ensuring they’re building the right thing. The controversial #NoEstimates movement however argues why estimating may be waste in itself, where time could be better spent writing software and concentrate on making all stories small enough to fit in the sprint. The retrospective itself can be wasteful if not used correctly. 

“Simplicity–the art of maximizing the amount of work not done–is essential”

Agile Manifesto (Agile Principles), 2001

The agile principles state that “Simplicity–the art of maximizing the amount of work not done–is essential”. I have learned that regardless of whether or not your agile teams are software teams, getting value quicker to the customer involves frequently asking this question of your process – “Is this eliminating waste?”.

In conclusion…

Gratitude is the key to resilience. It is an indicator of high emotional intelligence (written about in my previous blog) and is an essential part of withstanding a VUCA world. In the horror-show that was 2020, we must reflect on the lessons we’ve learned and find gratitude in our journey through it. I can say with confidence that I am grateful for those that have shared these lessons with me.

Feature image taken from the book “Agile Samurai” by Jonathan Rasmusson

Why emotional intelligence is increasingly required in software development

TLDR; Because AI can’t automate human emotion (yet).
Read time ~ 7 minutes

“emotional intelligence—the ability to, for instance, understand your effect on others and manage yourself accordingly—accounts for nearly 90 percent of what moves people up the ladder when IQ and technical skills are roughly similar”


Emotional intelligence (sometimes referred to as EQ) is the ability to understand your own emotions and the emotions of others such that you are able to help, guide and influence situations based on those feelings and the expected consequences of them. There are countless articles, blogs and books on the subject (this being my favourite article), articulated in Daniel Goleman’s book “Emotional Intelligence” into the following model:

  1. Self-awareness
  2. Self-regulation
  3. Motivation
  4. Empathy
  5. Social skills

Using this framework, I’d like to explore why it’s relevant in the digital sector, with particular reference to software developers.You’d be forgiven for thinking that IQ is still the thing that matters in a technical landscape, and that how much you know about a certain domain or technology is still the dominating factor. Unless you’re able to navigate the model below, you’ll be limited to that 10% of development potential (by the way, this definitely applies to tech leads and managers too!).

In a 2011 Career Builder Survey of more than 2,600 hiring managers and human resource professionals, 71% stated they valued emotional intelligence in an employee over IQ; 75% said they were more likely to promote a highly emotionally intelligent worker; and 59% claimed they’d pass up a candidate with a high IQ but low emotional intelligence


1. Self Awareness

I’ve had hundreds of one to ones with software developers, many of them centred around personal development. What I spend most of my time doing with early conversations (and in some cases continue to do so for a long time) is figure out why they do what they do. Is it money (rarely)? Is it cool tech? Is it that they want to build a reputation as an accountable deliverer, or do they like making people happy by giving them solutions to problems?

Knowing your values, your strengths and your weaknesses is the first step in understanding why you react the way you do to certain situations. For me, my values are at the absolute core of the decisions that I make, at the micro and macro level – without them I’d have no North Star guiding me and certainly wouldn’t be able to understand my feelings when I see an opportunity or a threat.

I would argue that without mastery of self-awareness, practising other items in the model becomes backbreaking work.


  • This values exercise helps you understand and prioritise your values. It has been invaluable for my professional development, and recommend it to others wherever I can
  • Seek out some 360 feedback. There are several popular frameworks and tools available, I would recommend the Emotional and Competency Inventory Survey. However, a simple start / stop / continue conversation with your peers and stakeholders would would be a good first step

2. Self Regulation

Self regulation is the ability to regulate your own emotions based on your awareness of the impact of them on your surroundings.

Let me highlight one example. In Marshall Goldsmith’s book “What got you here won’t get you there” he outlines 20 habits that hold you back. Number eight is negativity. “Let me explain why that won’t work”. And boy, do some developers like telling you why ideas won’t work. You know that teammate? When you’re in a meeting, firing ideas around with your colleagues, and they keep responding with “let me tell you why that won’t work”? Whilst massively useful for managers (the good ones anyway, the ones that listen), highlighting risks in a constructive and sensitive way (offering solutions, establishing fact etc) is a skill that needs to be honed. If you’re always that person, and of course you’re aware that you’re that person, have a chat with your manager or someone you trust about how to effectively convey that risk whilst still offering solutions and being part of the change.

Self regulation of course applies to many other aspects and behaviours that all employees / managers deal with – integrity, how we deal with our emotions verbally or physically, adaptability. Again, a good feedback mechanism will allow you to measure and notice this more frequently.


Changing personality habits takes time, with frequent short bursts of practise. “The Coaching Habit” describes a nice model to create new habits to replace old ones, and Box of Crayons (the company founded by the author) has a good short series on creating new habits starting with this one

3. Motivation

“For artists, scientists, inventors, schoolchildren, and the rest of us, intrinsic motivation—the drive do something because it is interesting, challenging, and absorbing—is essential for high levels of creativity.”

“Drive”, Dan Pink

If your motivation is money, security or control in this industry, you’re going to get burnt out pretty quickly. Dan Pink explains it in his book “Drive” that there are two types of motivation – intrinsic and extrinsic. He argues wonderfully that in our creative industry, this intrinsic motivation is crucial for us to innovate, design and craft ideas. Lastly, in our VUCA world, coupled with the compounding uncertainty of the current COVID-19 situation at the time of writing, intrinsic motivation develops the essential life-skill of resilience – to quote a colleague, “the ability to get yourself back up when life kicks the shit out of you”.

Managers take heed – if you do not find the ability to foster creativity in your engineers, you will have a demotivated team.


After finishing the values exercise above, make sure you’re doing activities in your day job (or life for that matter) that match with your values, so that you can draw from that spring when life gets you down.

4. Empathy

Aside from the obvious benefits of empathising with colleagues, I wanted to focus on the customer. I previously wrote a blog on why developers should talk to customers, and this is why. Empathising with the customer is fundamental to developing what the customers actually need, not what we think they want. There are entire processes and methodologies centred around design thinking, human centred design and service design that mandate that humans – in all their irrational and emotional glory – should be at the core (of course, “The Lean Startup” by Eric Ries is mandatory reading on this subject). And yet sadly, there are still engineers reluctant to step away from the 1s and 0s, relying on the vast corporate network of sales, marketing, product owners and directors to empathise for them. Great for the consultants, not so good for your company’s wallet.


I’ve tried to cover how developers can get closer to the customer in my previous blog, hint : it’s at the bottom

5. Social Skills

Something of course that we developers have in abundance. I once went to a ‘team-building’ event where the organisers completely mis-read the room. There was near mutiny when they announced to everyone’s surprise that there would be a 5 minute ‘skit’ that the vast majority of introverted scientific folk would have to perform. It was however team-bonding, in that we now unified in a single point of hatred, and I don’t regret the experience for a second.

And what is it with us creative types using Slack / Teams / Basecamp IM as our default mode of communication? The amount of times I’ve had to encourage engineers to pick up the phone to create a personal dialog with someone rather than relying on an electronic form of communication or ticketing system. It doesn’t develop the necessary discipline to form rapport with people, the fundamental requirement to reminding reminding yourself that the other party is a human being. Ever wondered why IT keep ignoring your requests, no matter how many times you put a ticket in or send them a very clever and strongly worded email? It’s because you don’t have a rapport built with the human being that has to deal with 100 other cleverly worded emails that are just words in one of their systems, devoid of context or empathy. This rapport is forged most effectively through face to face contact, one study citing a face to face request is 34 times more effective than an email. Kim Scott argues in her book “Radical Candor” that by caring personally about people, you are better able to empathise and understand the context of their position in any situation.

In conclusion…

This summarises my point nicely for all elements of this model: you cannot have emotional intelligence without creating relationships. Creating relationships and rapport is hard. It takes time and investment, and requires you to care about and empathise with other human beings.

One day, JavaScript will die. As long as there are humans, emotional intelligence will not.

The balance of people and product

TLDR; favour people.


So a combination of finishing my new favourite book “The Infinite Game” by Simon Sinek, a change in career and some pretty heavy family events has led me to reflect a lot on this question. 

To clarify, when leaders favour people over products, they make a conscious decision to sacrifice the speed of product development in favour of supporting the team that are working on it. When leaders make decisions that favour products over people, they make decisions they have deemed to be for the good of the product, project or bottom line sometimes to the detriment of the team. Sinek also refers to this as “will over resources”. In the infinite game of business, he provides evidence (both anecdotal and empirical) that companies who make more of the decisions that invest in trust and psychological safety over profit stand the test of time. The DORA 2019 State of DevOps report (a benchmark guide for high performing software teams) suggests that elite performers in our industry have a culture of psychological safety as a building block for high software delivery performance. To build exceptional products, it requires an exceptional investment in people.

As he explains it so beautifully in this video, Sinek suggests that even if we can tip the balance of our priorities 51/49 in favour of people (will over resources), the rewards are obvious.

Many leaders have a bias towards people higher than this, not that I have any way to quantify it. This brings its own problems (lack of exposure to at C-level, perceived slower project delivery etc.) which I have personally encountered. This is not a strategy I recommend if you want to climb the corporate ladder quickly, but it is one that I recommend if you want to make a positive difference to people’s lives (and, as it happens, also delivers great products and brings in revenue to the business).

“If employees don’t feel cared for, they are statistically and significantly more likely to leave”

A study by Gallup that pops up time and again (first referenced in “First, Break All the Rules” – 1999, Buckingham & Coffman) asks over one million employees around the world to agree or disagree with the following statement : “My supervisor, or someone at work, seems to care about me as a person”. This Gallup defines as the The Fifth Element of Great Managing. The study finds that those teams that answered this question in the bottom quartile (that is, the teams that answered ‘no’ most often) had a 37% higher turnover rate than those in the top. If employees don’t feel cared for, they are statistically and significantly more likely to leave. For more reading, this post does a better job of explaining it than me.

In Summary

  • Psychological safety is the number one building block for creating elite performing teams in software delivery according to DORA
  • If employees don’t feel cared for, they are statistically and significantly more likely to leave

My personal argument for people over products like this: Investing in teams is like investing in a savings account. You use the capital in the account to ‘buy’ delivery of a high quality product. You cannot call on reserves when you have not invested, and you will pay for it later if you take out a loan to do so. 

Building rapport with humans and creating a culture of psychological safety requires heavy investment, and is hard work. However, Sinek reminds us that to favour ‘will’ over ‘resources’ and to build trusting teams is key to playing the infinite game of business, and ultimately delivers the best possible product for our customers.

A call to action for software companies – talk to each other!

“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly”

Agile Principles

So states the agile principle, but considering we’re all supposed to be finding new ways of improving, it sure is darn hard to talk to other teams about it.

Firstly, let me say networking events continue to be a fantastic source of knowledge transfer for our industry. In our region in Teesside for instance there’s Refresh Teesside and the Hainton meetups, but people tend to have their guard up at these events. The conversation leans towards the ‘this is what we’re doing right’ rather than ‘this is where we’re struggling’. I always find the latter conversation extracts more value, and I feel way more secure talking about this in my environment of work with the people and tools available.

I’ve been on a personal mission the last few years to try and invite developers from other companies to come on site to have a look around at our tools and processes, in exchange for an optional reciprocal tour. Both sides gain insights, understand where their strengths & weaknesses are and hopefully take something back into their retrospectives to make them more rounded teams. Reciprocation has been a challenge at best.

So taking a leaf out of the call centre handbook, I thought I’d share a script to counteract the most common reasons why companies are reluctant to share…

1. We’re too busy / don’t call us we’ll call you

Number one reason we get. I have a simple flowchart that helps in this situation:

Whilst it’s a bit tongue-in-cheek, the situation always reminds me of the following ‘too busy to improve’ graphic that hangs pride of place in our physics office:

2. All my stuff is secret

OK, so let’s sign an NDA. And let’s not look at your super secret project. In fact, let’s not have a look at any projects at all. We’re really just interested in how we can be better developers and improve our delivery, and we’d love to help you out too if we can.

3. Are you scoping me / my team out for a job with you?

Nope. No strings attached, no hidden agenda, we just want to be better, and if we can we want to help you be better too.

4. Do you want a job here?

Probably not. I’ve knowingly arranged for my team to go to companies where they’re interested in hiring them, on the understanding that they’ll come back with some valuable insights on where we can improve our processes (I could probably do a whole other post on why it’s not a good thing if you’re a manager and this scares you!).

So please do seize these opportunities to improve (drop me a line on LinkedIn if you want to arrange a no-strings-attached meetup!) and ask this question of yourself : “Am I the hairy guy with the square wheels?”

Should developers get involved in engaging with customers?

And what we can all learn from Mort the mouse lemur

Read time ~ 4 minutes. TLDR; yes, they should.

After my last blog, the area that got the most attention was around whether to put our creators (be it developers, engineers or designers) in front of customers. This prospect might seem frightening to both our developers and commercial teams, but let me explain through a laboured analogy. Bare with me.

I love to watch the film ‘Madagascar’ with my young son. In it, there’s a scene where the castaway animals from the New York Zoo (including our protagonist “Alex the Lion”) land in Madagascar and happen upon a petrified bunch of Lemurs, led by King Julien. How does King Julien know that these new giant animals are not “fierce savages”? Well, he takes the most cute and lovable mouse lemur called ‘Mort’ and dropkicks him in front of the animals to see if Alex the Lion eats him.

So at this point, Mort is our developer, Alex the Lion is our customer, and King Julien is someone who wants to see what happens. Usually me. Sounds pretty brutal right? Just to give you an idea of how commercial teams (certainly in the business-to-business product world) envisage this interaction going, here is Mort in this situation:

If the story ended here then this would be a horrifying way to engage with our customers. However, Gloria the Hippo soon scoops Mort up into his arms and assures him that everything’s OK. Alex befriends him too, although he’s a Lion so he’s still a bit scary. After a while, they’re all best of friends and sailing together in boats crewed by penguins and monkey powered biplanes </analogy>.


Surely it stands to reason that if we as creators take the risk to build up a rapport with the people we’re designing for, it allows us to understand their pain points and motivations which are the reason we’re building their products in the first place. Understanding our customers’ pain points gives us that intrinsic drive that pushes us so much further than carrot / stick models, knowing that our work is actually helping human beings make their lives easier. Taking that initial first step is crucial in fuelling that drive.

Commercial teams need not worry – your customers and users will respect you for trying to understand them and treat them as humans. Your products will be better because your creators haven’t got pre-biases on what they’re thinking, and will have asked some interesting questions. And yes they might not know everything about your field and look a bit bewildered, but if they never get the opportunity, they will never get better or create that empathy.


It is not the sole responsibility of developers to understand their customers and the user journey. A good Product Owner should be the primary contact with customers and users. However, they should be facilitating this interaction with the development team so that they get the best possible product.

In great organisations, especially those business-to-consumer models, there is a whole team dedicated to user/customer experience and product design that will integrate and facilitate these activities with all teams. If you don’t have this, to get started you should at least get in touch with some of the fantastic agencies dedicated to customer experience that the region has to offer – I can put you in touch with a few if you like 😉

And finally, four easy things developers can do in the short term

1. Start conducting usability tests if you don’t already. There are reams of literature on good test strategies including in “Don’t make me think”, however if you’re looking for a cheap hit here are some basic rules.

2. Find an easy going customer to practise on. Maybe a Gloria the Hippo, rather than an Alex the Lion. That latest bug that was filed? Call the customer to see what the problem was. If you’re nervous like Mort, you can always lead up to interactions through email, then phonecall, then face-to-face, but always remember there is immensely more value to be had gauging body language and tone of voice (Albert Mehrabian’s views are well documented – and cited – on importance of non-verbal cues)

3. Talk to your commercial teams about how best they can facilitate customer-developer interactions. They might have just never thought of the idea before.

4. Volunteer for customer visits. Commercial / product teams seem worried that developers will embarrass the company by not knowing anything about their domain or staying quiet. I’ve outlined above how this seems counter-intuitive.

And that’s it. Thanks for reading, as always interested to know who’s reading this, what you do and any comments you have on this or any more of my content. Thanks beautiful human for reading.

July 2020 Edit : I just felt that my wonderful experience of taking part in a Design Sprint last year should be noted as an excellent way to get closer to the customer. Whilst developers might not end up talking to the customer, it’s an intensely customer focused 5-day workshop that uses design thinking to produce a prototype of your idea directly to the customer at the end. Empathise, test assumptions quickly, and get that feel-good feeling after slogging a great idea out for a week.