When Ben moved to another team he faced some pretty challenging situations. A fully distributed team with a Scrum Master in another country trying to juggle the time zone differences.
It was only fitting that Ben would then take over the Scrum Master role shortly after. The journey from developer to Scrum Master is hard enough, but in this story, we talk about how to take on the Scrum Master role for a distributed team as well. Not an easy first assignment as a Scrum Master. Listen in to learn about that journey and the lessons that you can apply in your own work.
The major obstacles Ben faced in his Scrum Master journey
When Johanna visited Agile 2017, one of the largest Agile conferences that year, she was disappointed that the main advice people were giving on stage was: “don’t do distributed”. She then met Mark and started sharing her experience on how she had been able to make distributed agile work in her consulting work.
Distributed teams are a fact of the multinational organizations we work with. Hiding from it is not going to remove that. And crying “distributed agile = bad agile” is only going to alienate people who genuinely need to learn to cope with the fact that distributed teams are the new normal.
There are good and bad ways to adapt to the reality of distributed software, and copying the methods and practices from co-located teams into the digital world is not enough. Molood shares some of the common anti-patterns that arise when we plainly try to copy the co-located team methods into the new distributed reality.
One such example is the communication channels: trying to copy daily meetings from the co-located team into a digital world will eventually bump against the frustratingly low quality sound of some conference room setups. Molood suggests a different route and shows how a team she helped took full advantage of Slack (or any other asynchronous communication channel) to make their daily meetings for effective, and efficient for everyone involved.
When the big Agile adoption wave started in the early 2000’s, certification was all the craze. These days it looks like you can’t have a coffee meeting without getting a certificate. But here’s the thing: a certificate only states that you know the basics! I have (infamously) said, “Please do share that you have a Scrum Master certificate so that I can eliminate you from the hiring process!”
Why did I do that?
Certification does not say you want to learn. Certification does not say you are an insightful Scrum Master or coach. Certification only says: “I know the basics”. And if that’s all people can quote as their achievements it further says: “I don’t want to know more than the basics”.
Go beyond the basics
At the Scrum Master Toolbox Podcast, we believe that learning on the job, learning every day is how we get better. How we improve our craft and our profession. Agile coaching or Scrum Mastering is not something that you can learn in a university, you learn it on the job!
As part of our efforts to help you learn on the job we decided to sponsor 2 online summits, which are FREE (no excuses!) for you to learn from amazing speakers.
This week we are sponsoring the Remote Forever Summit which has amazing speakers that share their insights on how to work (specifically) with remote teams.
We hope you like it, and we will continue to support more online summits and even conferences in the future that help Scrum Masters and Agile Coaches learn from people who’ve been applying these ideas and sharing their experiences for many years.
Go learn! Be better, every day!
PS: are you thinking of organizing an online summit? Get in touch, we’d love to help!
Recruiting is not easy, but when you are recruiting for an offshore team you face even more problems. How to select the right candidate? The role of language in the relationship with the client, and how to handle multiple cultures are also topics in this episode. Teams face cultural barriers, and remote stakeholders. In this offshore context recruiting is not easy.
Team dynamics are affected by many factors, including certain individual behaviors. Teams that exhibit some of the symptoms referred by Mario may be in trouble. We need to learn about those symptoms and have strategies to deal with those.
This story starts with an US based company acquiring a Latin American software development organization. Mario shares what happened after that, and what he learned from the experience, where distributed agile development was the main method of development.