My Top Failures as an Agile Coach
Failing is believed to be one of the best ways of learning but what happens when we can't always acknowledge easily that we are failing? Quite often, failures are somehow hidden and so small that we only notice something went wrong after these mistakes snowball into something big and harmful. An example everyone can possibly relate to: buying that ice-cream after lunch a few times a week. Although buying ice-cream might not be seen as a mistake on its own, in the long run, it can lead to negative effects on someone’s health.
It is impossible to live without failing at something, unless you live so cautiously that you might as well not have lived at all — in which case, you fail by default. — J. K. Rowling
When playing the Agile coach role at clients wanting to adopt Agile and/or change their working culture I learned the hard way that small failures often lead to catastrophic outcomes. Here you see the two main learning outcomes from small and overlooked mistakes:
Relying only on bottom-up adoption
It's quite easy to fall in the trap of believing that by only focusing coaching at team level, when teams start delivering value, top management will follow along and support Agile adoption. It happens that teams usually get stuck by organizational blockers way before they are able to start delivering meaningful value. The key learning is to not proceed with coaching until there's a minimum degree of top management engagement to effectively support the changes needed at organization level.
Agile without technical excellence
When you are passionate about what you believe, getting development teams excited about the benefits of adopting Scrum (or any other approach) is easy. The same applies when talking to developers on the benefits of technical excellence, code quality and using practices like Continuous Integration (CI), Continuous Delivery (CD), automation, and Test-Driven-Development (TDD). My small mistake is that I believed by simply organizing coding dojos, as a safe place to practice and learn those practices, the teams would pick up and passionately apply them on their daily work. What happened is that, a few months down the road, the teams were excelling at Scrum, delivering value with working software but the quality was starting to plunge, with increasing regression bugs and team's velocity trending lower and lower. The key learning here is that working in an Agile environment can be quite intense and fulfilling on its own but it's no excuse to compromise on quality, therefore, training and mentoring on software craftsmanship should be the one of the main priorities for any development team regardless of their maturity.
Have you committed the same mistakes like me? Share on the comments how you went about solving them.
