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:
- “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?
- “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.
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
Oranjutanj House 