Adopting a DevOps practice starts with understanding where you are in the implementation journey. Download the DevOps Transformation Roadmap. Brought to you in partnership with Techtown.

The Background

In my new journey as Agile Coach, I have a big challenge for the first quarter: facilitate, mentor, and coach technical people on Agile teams.

You must be thinking: where the technical lead or something related? So, we have few tech lead inside the teams and I also believe, like you, that we have to some tech manager or any position related.

Today we have 11 Agile teams with around 60 technical people (programmers and testers). Some of them are really good in programming and testing software, some of them aren't.

What's My Plan to Start

First I'm inside some teams (like a new member) helping them to achieve some technical lack, manly about quality and testing practices following the mindset and application of continuous integration and continuous deployment practices.

I believe that the Agile Coaching Competency Framework from Lissa Adkins will help me a lot. So I immediately remembered from this post from AgileForAll about different ways to step into an Agile coaching approach. I decided to create a path to help the teams to achieve the best results they can as a team and as individuals. The figure bellow is the complete plan that will start from Technical Mastery as a Domain, following the Facilitation process and after the Mentoring and Teaching as a Content.

With this plan in mind I must review some concepts about software engineering. Some I know and I apply day by day, others will be a challenge for me.

Which Books I Chose

We need to start simple, but not too simple…

When I talk with developers about some practices, they often think they need to skip a few steps (believing that they already know some steps). I mention The Karate Kid movie when the master teaches a simple "Jacket on, Jacket off" activity.

We need to learn the basics first, or as experienced developers, remember some basic steps, and how they are important like some design patterns, algorithms and so on.

One of the must-read books for software developers. When I read this book (a long time ago) it completely changed the way I write code, so I think other developers will also use it to change the way they write code.

I will revisit all concepts of clean code and start to talk with developers in terms of how easy their code will be to understand.

We have a lot of legacy code, not in Java or another programming languages for financial institutions, when I talk about legacy code I talk about Clipper (yes, this old guy).

For legacy code in Clipper or Java (the languages we use) all developers must have in mind that not all code will turn into a new functionality or a new technology, so we need to carefully change the existing code and turn it in a more readable and error-proof code, covering the code with tests.

Have you chosen to work with software where you write code most of the time? If your answer is yes, you must know Design Patterns.

You have likely heard about GoF (Gang of Four) and, no doubt, it is the best book about OO and Design Pattens.

When we have, at least, a minimum architecture and application of DRY and other principles of software development, design patterns will help us to write flexible and reusable code and design. Even though most of the code examples are in C++, it is worth the reading.

I'll going to use the 23 patterns described on the book to facilitate some design and changing decisions.

Every decent software has an architecture and sometimes different paradigms of programming (OO, functions, structured) and a good design. This book will help me, and the developers, to choose the right paradigm for our context and design principles, such as single responsibility, Liskov substitution, or dependency injection.