I’ve decided to make a short summary of episodes of agile podcasts I listen to, so I can refer to them in the future.
The podcasts:
Jeff Sutherland’s book Scrum: The Art of Doing Twice the Work in Half the Time has these “The takeaway” sections at the end of each chapter that summarize the gist of the chapter in a clear and understandable way. I liked that a lot, so I want to do that for the podcast episodes.
There were a few questions about “Agile Leadership” that were listed at a panel that Bob and Josh did not get around to answering. They were interesting questions, so they discussed them in this episode.
How do you measure the performance of an agile leader? The main gist was to measure the performance of the teams the leader is, well, leading - don’t judge the individual by himself / herself in a silo, as doing so doesn’t illustrate the value the leader brings to the table.
A few metrics discussed were:
Consistency: are the teams able to knock out a number of story points consistently each sprint? A team that is unable to do this, is encountering a lot of impediments that are not being resolved.
Happiness: happy teams perform better, improve faster and won’t leave as quickly (= more consistency!).
What are qualities an agile leader should have?
Consistency: when someone asks you something, they know what to expect. Build a reputation of approachability by being consistent.
Courage: step up and take risks. Many managers or leaders are afraid to take risks, acting conservatively. This runs entirely counter to the agile mindset of embracing change.
Care: an agile leader cares. They’re honest with you and tell you what you need to hear, not what you want to hear. They care about the performance of the team, they care about seeing their team members grow. And sometimes, it takes courage to tell people what they need to hear to improve.
Competent: you need to know what you’re talking about. People see through bullshit and won’t listen to you. If you don’t know something, just be honest.
The “Batman” or “Bug Master” is a role you can have during a sprint to tackle both planned and unplanned bugs to allow the rest of the team to focus on the sprint goal. The role is rotated to prevent concentration of knowledge and ensuring the entire team still feels responsible.
It’s also sometimes done in a buddy system with overlapping rotations to encourage knowledge transfer. Sometimes, one person across teams or projects takes up this role - the buddy system definitely helps here to keep people from feeling out of their depths when they’re on-call for systems they don’t know that much about.