TL;DR

In parallel with Sybil (customer) development, we are working as IT professionals in different missions and contexts. Those last weeks, I've been coaching a development team about coding practices and methodologies, notably Agile ones. Facing a very heterogeneous team, mostly self-taught is an interesting experience as it forces me back to the basics, having to explain things that I've taken for granted since several years. If you cannot explain the "why", you do have a problem, and it is up to you to solve it, not to your audience.

Context

The team is one in many development teams by a major company operating in the finance sector. Their background really do vary, as the team is not qualified as "development", but more as "support". Nonetheless, they develop or maintain a dozen of tools in the same number of technologies, from PHP to Balise, from Perl to Java, with a good degree of success (the applications are working to the satisfaction of their users). The project itself is the rewrite/redesign of a legacy XML document processing application in Java technologies, my role being a mix of technical expertise and team leadership.

It looked easy

If you're working in IT, you probably know about this sequence of alternate feelings about a project: start knowing nothing about it, so a bit uneasy, then learn what it is about and link it to past experience, so confidence kicks in, then discover all the "little things" that are different or specific, back to uneasiness, etc. I remember this about the learning process: it is always about de-constructing what you know before reconstructing it at a higher level of knowledge. In between, you're lost.

I experienced the whole process in this case from "outch, this is big" to "ok, I see how this work, here is a design that would fit" to "Can you explain me this requirement?" and back. Finally, I had my analysis of the current system validated, a design proposal that looked good, and a greenlight to start building it along the path I proposed.

Unexpected questions

It is in this first real iteration that some interesting questions started to pop, I tried to get the most interesting/disturbing here.

You are starting in the middle

When I put some tasks on paper for a first iteration (which was very important as it was as much a learning exercise as a project), I did select them with simple criteria:

  • Create something that we can easily test (unit testing was very high on my list of practices to introduce)
  • Produce observable results, even if small
  • Target the main part of the application as soon as possible
  • Try to have different persons work on (initially) separate parts to limit disturbances

All off this was very clear and reasonable for me, until I get a question like "Why are you starting the project in the middle ?". After my initial surprise, I came to understand the validity of the question: the tool we were working on served a process with very clear start and end points, and it looked logical to start the implementation in the same order, something that was for my part totally irrelevant. More importantly, I understood that I probably had good reasons to start the project where I proposed to, but that I certainly had missed to explain and discuss this with the team. The criteria shown above should be very familiar to most people used to Agile and Test Driven practices... Which the team was not.

Turning a problem in an opportunity, we had a quick chat on this, I explained my reasons, we made some update to the plan together and get back to work.

We should probably start with building some basic functions

This one came some day later, when the first classes (and tests) begin to pop in the SVN. Most of the project would revolve around XML manipulation, for which I expected to rely heavily on existing libraries (in the Java world, it is more a problem of choosing wisely than lacking options - we've settled on XOM, and to this point, I like it), so that we would free our time (and precious neurons) to be able to write the real business code. Again, nothing special here (in occasion such as this one, I pride myself for going for the "obvious" choices), again, I should have explained it immediately, however "natural" it felt to me. This actually led us to (another) good exchange, and the project came out better of it.

We will see to this when it happens

This is less about a question than about an attitude than I had and was probably mistaken on the project. As we are (?) working to rewrite an existing code base, a whole lot of history is present on the project: remembering of performance problems, lots of "small patches" tacking very specific issues, implementation choices, etc. While I did take a thorough look on the legacy codebase, I'm firmly in the "Preemptive optimization is the root of all evils" (or, as W.A. Wulf said it : "More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason — including blind stupidity."). This means that if I dutifully noted the potential pitfall, my main answer to most of those remarks was "We will tackle those issues when they happen".

I though that I sounded reasonable, but at one point I realized that it looked very similar to "We'll see later (i.e : never)" or "I do not care about this". Explaining the "responding to change over following a plan" principle  looks simple in theory, but practically, it can make you look like an "know everything" sort of person, which is probably the worse image you can give when coaching a team.

Conclusion

My chance in this situation is that we were working as a team from the start, and that those kind of problems/miscommunication were simply put on the table and discussed. This allowed us to move through them with relative ease, as everyone objective (team, coach, manager) was aligned, and we only ever differ on the best way to do it.

What I did learn is that explaining things that have become second nature to you is difficult on two fronts: first because you do not even think it is worth explaining, second because the most natural something is, the most difficult it is to explain. However difficult, it is probably one of the most important thing to do when you're on a project in some kind of leadership/coaching/expertise position. The experience was fruitful for me, I hope it can be for others.