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 Agile Master #4: Lessons on Agile Development from the Tao Te Ching

Throw away holiness and wisdom,
and people will be a hundred times happier.
Throw away morality and justice,
and people will do the right thing.
Throw away industry and profit,
and there won't be any thieves.

If these three aren't enough,
just stay at the center of the circle
and let all things take their course.

- Tao Te Ching, Chapter 19

In agile development, it is the team that is the center of everything, not individuals. Individuals trying to demonstrate that they are better or smarter will poison the team as a whole. Just as you should not blame one member of the team for an error, you should not praise one member. The team makes errors and the team succeeds.

Trust your team. Get rid of procedures designed to enforce expected behaviour. The team will do the right thing without it and they will do it for the right reasons - not out of fear. In the process, they will know true empowerment.

In the same manner, you should not institute individual rewards. The team should not be competing within itself for perks or benefits. This breeds envy and resentment.

The Agile Master should constantly evaluate what is superficial in order to get rid of it. Individual knowledge is superficial and dangerous; strive for team knowledge. Procedures are superficial and costly; get rid of those that do not benefit the team. Which ones are those? Ask them.

You will not be able to fix everything or everyone. Be calm. Be patient.

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

The Master, by residing in the Tao,
sets an example for all beings.
Because he doesn't display himself,
people can see his light.
Because he has nothing to prove,
people can trust his words.
Because he doesn't know who he is,
people recognize themselves in him.

- Tao Te Ching, Chapter 22

The Agile Master embodies what the team should be. He does not tell the team they need to change. Instead, he becomes the change. The Master will not draw attention to this, but others will notice. Through his actions, the Agile Master has earned the team's trust and respect. When he speaks, the team listens.

The Agile Master is not focused on himself, but on the team. He becomes what the team needs and, in doing, is a reflection of the team.

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

When the Master governs, the people
are hardly aware that he exists.
Next best is a leader who is loved.
Next, one who is feared.
The worst is one who is despised.
If you don't trust the people,
you make them untrustworthy.
The Master doesn't talk, he acts.
When his work is done,
the people say, "Amazing:
we did it, all by ourselves!"

- Tao Te Ching, Chapter 17

The Master Agile practitioner leads from behind. Ideally, the team should not realize that she is a leader. Too often people embody their titles and try to fill the role it implies rather than the role that is needed. They end up being loved by their team, but not leading. Or feared and actively block progress. Or despised and there is no team.

You must trust your team. Assume greatness and they will accomplish it.

When the Agile Master works, the team achieves. The team should see all work done by any subset as work done by the whole.

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

"Therefore the sages:
Manage the work of detached actions
Conduct the teaching of no words
They work with myriad things but do not control
They create but do not possess
They act but do not presume
They succeed but do not dwell on success
It is because they do not dwell on success
That it never goes away"

- Tao Te Ching, Chapter 2

Lets approach this from the perspective of an master Agile practitioner. The Agile Master must guide without guiding and teach without teaching. She will do this by being.

One does not merely write good code, but strives to teach others how to do the same and better. She does this not by creating good code, but by helping others discover how to write good code themselves. She manages the work of detached actions through others and teaches by letting others discover the correct path. Control is an illusion.

The greatest creation of a master is that which is created by others. The team will posses only what is created by all. None create alone. The team will succeed, but never dwells on success. Even failure is success. Therefore, there is only success.  

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.

The Agile Team Gardener

Often in my career I've been in a Tech Lead role for the project I was working on. Every time, I would go through a period of trying to figure out what that role meant - and it was always a little bit different. I suspect that this was mainly due to my own lack of clarity over what was expected of me. Someone in a position to decide my fate thought I could do whatever it was that a Tech Lead was supposed to do and told me I was the Tech Lead.

Ok. Great. I got this! Maybe.

Over time, I kind of played the role of trying to do what I thought the project needed and not really considering whether what I was doing fit into the scope of what a Tech Lead was. I noticed that a lot of the people at my company put into the Tech Lead role pretty much do the same thing. What that means is that we end up doing what would be considered Team Lead and sometimes Program Manager and Product Owner activities as well.

Classically, come to find out, a Tech Lead was the person in charge of the technical vision, the software architecture, class structures, database mappings, etc. In an Agile environment, these elements should be emergent properties of the project as it is being built. The team, as a whole, should have a shared vision of the software architecture and the tactical details should emerge over time. Other responsibilities of the Tech Lead have been to foster learning among the developers and to ensure that progress is being made. All of these responsibilities should be team responsibilities in an Agile organization.

In my most recent projects as the named Tech Lead I have, instead, tried to be the Team Gardener. There is still the need for experienced members of the team to provide guidance on technical issues, but, more importantly, there needs to be guidance on team expectations, practices (habits), communication patterns, etc. "But wait," you say, "that stuff is the job of the Agile coach or Scrum Master." If you have the luxury of having a coach or Scrum Master, then they should be providing guidance on these issues, but they can't reinforce the moment-to-moment implementation of these practices in a grass-roots manner unless they are also a developer on the team. If that is the case, then your coach should be playing the role of Team Gardener.

The Team Gardener should be planting seeds of ideas, technical or otherwise, and then letting those seeds grow as the team determines. The Team Gardener provides an example by nourishing certain behaviors while discouraging weeds. Most importantly, the Team Gardener understands and is part of the team environment and allows it to express itself in its most positive ways; they can not and do not try to force the team to bend to their will.

Through consistent and gentile encouragement from experienced technical team members playing the role of Team Gardener, a team can grow into a productive, self-managed group.