Wednesday, July 8, 2015

The Embedded Agile Practitioner

"Are you a developer or a coach?"

As an Agile consultant, it is usually assumed by those in the consulting business that I am an Agile Coach or worse, a SCRUM Master. The truth is that I am a coach and a developer, what some have termed an Agile Practitioner.

I don't mean that I am an Agile coach and I do some development when I'm not coaching. I don't mean that I play both roles depending on the need. I mean that I coach through my code and while I am writing software. I know that this seems like a subtle difference, but it is an important one. When a team has an Agile coach, that person can advise on process issues and can suggest practices such as TDD or pair programming as solutions to various issues that the team might encounter. They generally do not have anything to say about Object Oriented (OO) principles like single responsibility or dependency inversion. Most don't code at all within the teams they coach. In other words, the coach facilitates changes to the process and team structure, but doesn't dare tell developers how to write code.

Agile is not about project management; it is about producing good software as efficiently as possible. This includes aspects of project management, but SCRUM and many Agile coaches seem to have forgotten about writing software and instead focus on the efficiency of the process. While this is needed, it is not the whole solution.

When doing Test Driven Development (TDD), for example, the developers must have a good grasp of how to write unit tests, integration tests, etc. They must know how to refactor code to remove duplication, extract super classes, interfaces and any number of other patterns. In order to see the full benefit of TDD, they need sufficient experience in lots of different engineering techniques. A SCRUM master is not likely to be able to help here. That's where an Agile Practitioner comes in. They can support the practice by pairing with team members to actually write code and teach the techniques needed. Just as important, the Agile Practitioner can explain why these techniques are useful.

The Agile Practitioner leads by example. They gain the respect of the team by being a competent software engineer and living the principles they espouse. The Agile Practitioner walks the walk and talks the talk. That respect gives them the ability to gently challenge the team and individuals to become better without being condescending or prescriptive. I do this through a Socratic method of questioning some specific point or assumption that I hope will lead them to realizing the crux of the issue and eventually come up with a solution of their own. In the end, the team or person I'm pairing with will have solved a problem that they helped identify.

The Agile Practitioner can even provide guidance without being physically present. How can this be, you ask? By setting the standard for code quality and patterns that the rest of the team can follow. This should happen naturally, not by fiat or oversight. Let's be honest, much of the code written for any project is based on previous code written by someone else, either in the current project or by some genius on Stack Overflow. Because of the strong desire to remain internally consistent, if there is an example of some code practice or technique already in the project's code base, then that is the pattern that will be followed.

My greatest feeling of accomplishment comes when other members of the team start reinforcing Agile practices because they understand and believe in them. My ultimate goal is to make each one of my team members Agile Practitioners.