The Agile Master #5: Lessons on Agile Development from the Tao Te Ching

He who stands on tiptoe
doesn't stand firm.
He who rushes ahead
doesn't go far.
He who tries to shine
dims his own light.
He who defines himself
can't know who he really is.
He who has power over others
can't empower himself.
He who clings to his work
will create nothing that endures.

If you want to accord with the Tao,
just do your job, then let go.

- Tao Te Ching, Chapter 24

The Agile Master does not bring attention to herself and does not exalt herself. Don't rush towards a goal without bringing the team with you. You go together or not at all.

Code ownership will insure only that the code will be replaced as soon as someone else needs to maintain it. The more the team can share knowledge, the better the code will be and the easier it will be to maintain; the code will endure beyond the tenure of the individuals who created it.

The human body is recycled completely over the span of years and yet continues to be, fundamentally, the same person. So to the team. As members change nevertheless the team remains. The Agile Master encourages team knowledge above individual knowledge and encourages individuals to teach others on the team. In essence, the Agile Master strives for everyone on the team to become Agile Masters themselves.

You will fail. And in failing, succeed. You will learn and you will teach. This is the heart of the Agile Tao.

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.