Allow People To Do What They Think Is Best

To find out that the programmers in the team are seeking out product owners, stakeholders, and teammates on their own to ask clarifications and start meaningful discussions is a positive thing for me, to notice them initiate communication to whomever they need to talk to is always a major confidence booster about their ability to work on problems on their own. They never need my authority or permission to do what they think is best, they manage their own tasks, they own the responsibility to do the right thing as they see fit. I’m just there to help them perform the best work they can, in the form of suggestions and testing.

That’s why it’s bewildering to see someone get disappointed over a behavior that I deem to be on the plus side. Why would letting developers talk directly to stakeholders make you feel overstepped, if they think it supports better work? It seems to be, at least for me, a shallow use of a leadership position, a certain level of being clingy to power that’s not serving the team mission. It’s an upsetting, controlling reaction that I feel does not do any good.

Focus on empowering the team.


Lessons from NewVoiceMedia’s “So You Want To Be A Scrum Master?”

The agile community at NewVoiceMedia recently wrote a book for Scrum Masters and for everyone who is looking to improve their knowledge about what scrum masters do. Their output during a hackathon, within 48 hours, the “So You Want To Be A Scrum Master?” ebook available at LeanPub, contains great ideas, stuff that I’ve learned through experience since I had the opportunity to become a scrum master myself, alongside being a software tester.

Some takeaways from the book:

  • Maximise the time a team member spends doing what they love, and less thinking about how they should be doing it.
  • Being a Scrum Master can sometimes come with the misconception that you are there to tell people what to do. That is definitely not the case. We’re not in the business of telling people what to do and when to do it and we’re not in charge of anyone.
  • Make problems more visible before trying to point them out, and before offering a solution.
  • Your job is to help team members stick to their commitment – we all find building new habits a difficult thing to do. You are protecting the team from themselves, from the tendency of human nature to pull each of us off the path we actually want to be on.
  • To turn around a team, work with individuals in the team and listen to them.
  • Always help. But only when your help is requested or when your offer of help is accepted.
  • Not everyone who truly believes they are agile knows what it really means. They need battle scars of having tried lots of different things and lived through the consequences.
  • Just because your label is Scrum Master you do not have to only follow the Scrum methodology to the letter. In fact, your job demands that you do not.
  • Let the team fail.
  • The end goal of a Scrum Master is to effectively make themselves redundant for their team.

Lessons from Ben Williams and Tom Roden’s “50 Quick Ideas To Improve Your Retrospectives”

Today, I’d like to share some insights I took note of while reading Ben Williams and Tom Roden’s 50 Quick Ideas To Improve Your Retrospectives“, which is the last of the 50 Quick Ideas series of books. Before, they talked about how to improve user stories and tests. Now, they want us to think more deeply about our retrospectives.

  • Plans are of little importance but planning is essential.
  • Constraints have inspired people to do their best work. They give us important puzzles to solve, and we learn to work around our limitations.
  • The value of releasing new products or features early can sometimes outweigh the cost of design shortcuts, so incurring technical debt is justifiable in the short term. But eventually the aggregated effect of technical debt can significantly impact team productivity and long-term product support effort, so there should be regular repayment plans.
  • Technical debt is most commonly associated with software design, but it can also include deviations from sound engineering practices that may produce future risks.
  • Like user stories, we should measure the impact of retrospective improvement ideas that we decide to implement. In order to do that, we need to know what to measure, how to measure it, what the baseline is now, what the target for success is, and at what point in the future the measurement is to be taken.
  • If you find yourselves saying ‘we’ve always done it this way’, remember why that is. Check if the reasons are still valid.
  • For a team to truly improve, they need to show vulnerability, and to do this, they need to feel safe. If there’s no privacy, they won’t feel that way. If the members of the team feel that they are being judged, they won’t feel secure, and retrospectives under these circumstances will most likely be superficial.
  • Be disciplined over work-in-progress limits. Finish the ongoing tasks first before taking on new items.
  • Giving personal feedback is often overlooked during retrospectives. Teams tend to focus on process or technical issues while ignoring human ones.
  • As scrum masters, what we do for the team should reduce their reliance on us and make our role a little more redundant. It is our job to help teams decide for themselves, to provide them with opportunities to develop their skills to solve problems on their own in the long term, to self-organise.