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 your engineers don’t do any practices, you telling them to start 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 said, coach them.
Fortunately there are amazing Agile Coaches out there that prove that it can be done, such as my role model 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 coding, and at the same time getting a chance to practice 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 Graham’s advice on managers vs makers.
- Read software development books. Books like The Mythical Man Month, or The Pragmatic Programmer can bring a lot of insight into how the developers think and the troubles they face. I have a small list of such books on goodreads if you’d like to find out more.
- Push for 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. Another strategy is to work with the seniors to promote them. 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 experiment with pair or mob programming with the teams etc). 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 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 don’t tell the team what to do, but 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 themselves, 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 with your team, ask for their coaching. If you have more coaches in your company, this is an ideal combination.
- Bring in outsiders 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 with your team. Join your local Agile community and get to know technical coaches, trainers, engineers that are willing to help.
- 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 work scope, as they value your input and advice.
In the end, being a great Agile Coach in tech is similar with being a superstar NBA player at around 5’10”. You can definitely do it but you 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.