Thank you, Lyssa Adkins, for reminding me again what is important
You know the feeling when you look at your earlier professional life in the rear-view mirror and see all the things you would do differently with the knowledge and experience you possess now — do it better?
I take pride in the projects I have been a part of and the teams I have worked with. I feel I have made a positive impact on products and people in my past assignments. There is still danger in comfort. Good enough becomes the new base line for performance if the project is progressing nicely and people around are happy.
Fresh out of school everyone has dreams: You want to be a rock star software developer, the person who cured cancer, an astronaut. Mediocrity was never in your plans and good enough was not the target. Instead of sitting comfortably on ‘good enough’, you forgot that you can also be excellent?
Lyssa Adkins’ book Coaching Agile Teams made me remember that in software development we are leading people, not processes. It also showed me what modern agile leadership looks like without the dysfunctionalities and command-and-controlism of project management structures from the past.
I must admit that I am a natural sceptic when it comes to introducing “new revolutionary methods which will rock your world” but this book was convincing. It showed me that with providing the right kind of influence and framework any team can start elevating their game from good towards excellent, both as a team and as individuals. Let’s look at few morsels of insight which resonated with me the most:
It’s about the team, not you
I used to be the problem solver. The one who looked for trouble and fixed it to guard the team from the exposure of the outside world. This left me in a constant state of stress and the team none the wiser about how to deal with the problematic situations. Through the teachings of the book, I learned that it is much more beneficial (and cheaper) to let the team recognise problems by themselves and find the solutions on their own. The team’s solution is most likely much better than what you would have come up with in any case.
Who is better expert on the product than the team who is building it? If the problem remains unchecked, it is best to let the team fail than to save them from the consequences. Otherwise, there is a missed learning opportunity, and the team has not progressed any steps towards excellence.
Give intent, not instructions
Simplistically said, the only input the functioning team needs to do its work is an answer to the question ‘What’. The ‘How’ and ‘When’ is up to the team to decide. Again, there is no one better to answer these questions than the team.
This works in many levels of the team decision making. Product management feeds the team with the intended next right thing to do in form of prioritised user stories spiced with explanation why this is important and valuable thing to do right now. How this is done and when will it be ready is totally up to the team. The stakeholders want the development progress to be more visible? Let the team decide what to do with this information.
This does not mean that all the work is unloaded to the team and you have more time to enjoy your coffee. This means that after every decision team makes independently, the team is better prepared for the next one. Again, more steps towards the excellence.
Shu Ha Ri
I believe this is something many of you have heard before but for the first time I truly connect it to agile practices. Many times, you hear that an organisation is doing pseudo/ad-hoc/zombie-agile which is derived from bending and cherry-picking the seemingly best agile practices while ignoring others. This leaves the organisation with possibly functional project management tool without any of the benefits which makes agile great.
Shu Ha Ri is a Japanese martial arts concept which describes the steps of learning towards mastery: Shu = Learn the rule, Ha = Break the rule, Ri = Be the rule.
To make agile properly, or at all, you need to play by the rules. Not just some of the rules but all of them. When you have mastered the techniques playing by the rules, you can start breaking them to see what fits your team the best, learn and adapt. When you have found out that something else works for your team better you make is as a new rule for your team while keeping the original intent of the rule in mind. There is no shortcut to Ri, you have to Shu and Ha first.
Agile manifesto and principles
Not again this same old stuff… The funny thing is that everything explained in this book is tightly bound to the good old agile principles. But this time in a way it makes perfect sense. I have huge respect to the author of this book for bringing forth new angles and refreshing ideas on agile software development while binding it all repeatedly on the things already familiar to us all, the agile values, manifesto and principles.
As you might have noticed, I enjoyed reading the book. It is a warm recommendation for everyone working on agile development. I surely learned a lot.