Forward. Maintain direction. Inspire your team
Unactionable retrospectives are throwing money onto a ship that has already sailed
You Cannot Inspect Performance Into a Team
I will be referencing DevEx: What Actually Drives Productivity in this article.
I talk to a lot of leaders now that I’m coaching tech teams. By far the most common dread they feel is the ongoing cycle of lethargy where large year-long cycles seem to be repeating for the team that reinforce bad habits and a general lack of progress.
Common industry fads will tell you to have retrospectives and sprint reviews. God forbid you went to get your Agile/ Scrum certificate from the wrong organisation. You may got handed a very lousy toolkit to work with that ill-suits your challenges.
By large the pre-2020’s approach was to hold retrospectives and analysis “what went wrong, what went well, what can we improve.”
Yuck!
As if going to work and building something great is an incident report.
There isn’t much you can do after-the-fact unless you do deep, hard root cause analysis. I haven’t seen anyone do that successfully. And worst, once you’ve done a mistake, the time for it is already gone. You can’t get it back.
The approach I prefer and coach is to focus on today instead. Focus on the time period where your actions have immediate benefit.
When you have a complex task to work on, make a slight adjustment to your process to make it easier to work on.
Then do the task.
This may be changing your meetings, dropping some of your processes or simply mob programming to learn rather than trying to optimise everything too early.
Needless premature optimisation is the root of all evil.
This quote applies to your human processes as well.
Embrace mob programming.
Adopt the principle of least surprise.
Make sure your most junior developer understands where the seniors are headed and why.
Adapt to serve your most confused team member rather than optimising for your MVP to do things by themselves. And above else — as a leader — resist the temptation to go in and do it yourself, by yourself. This is hard.
Don’t steal your team’s problem. Don’t steal their decision. By doing so you are robbing them of their learning and growth opportunities. Speak last. Speak seldom. Your voice as a leader carriers a lot of influence.
No matter whether you are a Tech Lead, Manager, TPM, Product Owner or when you are the most senior person in the room.
Remove Obstacles between Engineering and Product
This is the #1 productivity boost. If you stop reading here this is the point you need.
You are not writing code.
You are building a product.
Everyone in your engineering team is making personal contributions to the product, not the codebase. You may have dozens of tools that shape and mould how the team interacts with your Github or Bitbucket repositories.
How many do you have that shape how they interact with the product? This is where Domain-Driven Design comes in.
“The most valuable asset in the software industry is the synthesis of programming skill and deep context in the business problem domain, in one skull.”
- Jess Watson, Amazon: The One-Skull Rule
Gratitude, Shared Values and What Works
Share often the little things that work really well. Interactions and mutual respect that are the accumulation of relationship building.
Create a space to show appreciation for the team doing their best even when things go wrong.
Reward responding to and learning from mistakes rather than punishing or preventing making them.
Make it Personalised, not Personal
Burn down charts, velocity reports, 360 reviews, generic pulse interviews.
Get rid of all that. Take a look at the DevEx report above, section about surveys and Table 1. The majority of friction points are human problems.
Human problems are irrational by nature.
You can’t get those irrationalities on a GANTT chart by looking at your commit history.
Ask your team in safe environment, hire a coach to facilitate if necessary (this is what I do):
We all know we should be focusing on X. Yet we aren’t. The team likely has a strong reason for acting this way. What prevents us from pursuing X?
What are the priorities? (Ask this individually?) Do we agree on them? If not, who should adapt to whose interpretation?
Do we understand where we are headed? Describe what it looks like. Describe what it feels like to arrive there.
What annoys you about the process, even if it’s a small thing?
What prevents you from leaving work stress-free? (if that’s the case)
It’s still a Business - Always Target Real Customer Problems
As you may have noticed in code examples, katas and bland Todo-list example apps:
There are no tangible problems in a vacuum.
Any goal you may be focusing on - if the KPI of that goal is the goal itself, you’re in a vacuum. And inside that vacuum none of the progress is tangible.
Your efforts will have an immediate impact on your team’s wellbeing and flow when you target a real business concern that you have right now.
Not “we’ll do it later.”
Not “maybe next quarter.”
Not “after this emergency.”
Today.