Last year in November I attended the LeSS training with Bas Vodde in Singapore. After three days of immersion in LeSS and Lean I asked Bas:
“Would you hire a Scrum Master who is not a software developer?”
The answer was expected. At the same time, earlier in the course, we discussed engineering practices. Bas said if our engineers don’t do any practices, you telling them to won’t be effective (no matter your background). Don’t tell them what to do, make them excited about clean code, quality, finding code smells, refactoring and so on. Otherwise put, coach them.
And fortunately there are amazing Agile Coaches out there that prove that it can be done, even if you’re not a developer, such as my personal idol Lyssa Adkins, an amazing coach and author, former project manager.
At the same time, being non-tech has its own advantages. Let’s explore what you can do to be a better Agile Coach, if your background is product development, but non-tech.
- Learn to code. No, it’s not about you becoming a programmer but understanding how to solve problems with code, and at the same time you get a chance to practicing what you preach (pair programming, mob programming, TDD, etc.). I’m currently doing Harvardx’s CS50, but also recommend the MITx Python course if you want to go in depth.
- Talk to engineers about their coding philosophy, approach, practices, experience and so on. Understand what it means to be a good programmer or write good code and how they grow their skills. One thing I changed from constantly talking to our devs is to set meetings back-to-back in one day or beginning / end of working schedule, following Paul’s Graham advice on managers vs makers.
- Read software development books. Books like The Mythical Man Month, or The Pragmatic Programmer can bring a lot of light into how the developers think and the troubles they face. I made a small list of such books on my goodreads if you’d like to find out more.
- Push engineering practices through your seniors. As mentioned above, telling your team to do pair programming or TDD might not work if they’re not interested and passionate about it. My strategy is to use the seniors to bring these in, so I worked with the CTO, leads, seniors, CIO to validate my technical improvement proposals and help them bring it up to the team (through a learning sharing session, through seniors starting to do pair mob programming with their teams as an experiment and so on). Seniors are always open to improvement, teaching and mentoring, no matter if you’re a techie or not. If you got curiosity and the will to learn and help the team grow, they’re on board.
- Leverage your strengths. I worked in product management, project management, and I’ve been a consultant. I’ve been practicing for over 10 years clear communication, conflict resolution, persuasion, coaching, servant leadership, change management and so on. These are my strengths and also represent my comfort zone. This is the area where you can constantly be superior to a technical coach, so use those skills and don’t forget to level up.
- As a non-tech Agile Coach you can be more objective in your coaching the team. As a coach, you’re not supposed to tell the team what to do, but to help them figure it out on their own. So your focus is to create the right environment for the team to make their own decisions, facilitate their learning and make sure they keep being agile and continuously grow. Not being technical, makes the facilitation easier and makes it easier for you to not tell the team what to do. I’ve talked with technical Agile Coaches that have a lot of trouble to have the team following their advice to do one engineer practice or another. It’s not that the team doesn’t respect them or their experience, it’s basically that people do what they’re told reluctantly. When the initiative comes from them, the commitment is much stronger.
- Pair with a technical coach if you can. Work together, do joint retrospectives, learn from them and if there’s a technical area you need to improve, ask for their coaching. If you have more coaches in your company, this is an ideal combination.
- Bring outsiders in for training, workshops, learning sessions and so on. If you want to push TDD forward, why not a two-days workshop on agile testing. If no budget for this, approach senior software developers in your city (your industry or any if not possible) and ask them to come speak to your team about the topic of your team’s interest. Join your local Agile community and get to know technical coaches, trainers, engineers that are willing to come talk to your team.
- Last but not least: have an excellent understanding of Agile values and principles, frameworks, and agile transformation. You should be the in-house expert in all matters Agile, be passionate about it and inspire your team at the same time. You know when this is the case when your team comes to you with questions about agile topics outside of their working domain.
In the end, being a great Agile Coach in tech is similar with being a superstar NBA player at around 5’10”. You can do it but you do have to work harder, learn more, and get out of your comfort zone to grow into the role. Just be so good, they can’t ignore you.