Saturday, December 30, 2006

What does an XP Coach/Mentor actually do?

One of the things I do is XP coaching and mentoring. But a question that keeps cropping up (bizarrely, often after I have been hired!) is "What does an XP coach/mentor actually do?".

Interesting question. And is there a difference between a Coach and Mentor?

In my opinion there is a slight difference, but first the common ground.

What both do is to guide a given team through the learning process of implementing XP. It is the responsibility of the Coach/Mentor to gently guide the team around the pitfalls by encouraging the good agile behaviours - communication, testing, team self review etc. Equally, destructive behaviours - slipping into mini-waterfall process, not talking to (or not having!!) customers etc - are discouraged.

Often the best way of doing this will be from inside the team, demonstrating by example the power of the techniques. IMO this is the "Coach" part of the job description.

As the team begins to understand and becomes truly self-organising, the Coach must become less involved if the team are to stand by themselves. But they must still have the skills to keep themselves on-track. This is the "Mentor" stage - when the team is trying to stay agile after getting the idea. This stage involves acting as more of a sounding board for ideas; a sanity check that the decisions made as the development process adapts and evolves are correct and not reverting to traditional waterfall. I have found that this often involves acting as an ├╝ber-team lead, advising the existing team leader and/or experienced engineers on how to handle specific situations but generally not solving the problems for them.

Sunday, November 19, 2006

Change code? Be afraid. Be very afraid....

In my role as a software developer I have come across many strange attitudes to coding, but none so strange as the fear of changing code.

A good example - I was working with a team trying to use XP techniques. I was hired as a XP developer to strengthen the team and get them over a busy patch - not as coach, but simply as someone who had developed Java code in an extreme agile environment. No problem there.

The product we were working on required new functionality added to it. Since the current software structure did not easily accommodate the new stuff I mentioned in the stand-up that I would be restructuring the internals to make it fit more elegantly. This kind of refactoring is normal practice in any agile team, and is necessary to evolve the design with emerging requirements, keeping it coherent and stopping it from descending into a meaningless Ball Of Mud antipattern. I thought nothing of it. But one of the senior engineers threw his hands up in horror at the thought. "You can't do that! You might break something!".

The thinking went something like this:
"Currently the code works. The area of code being touched took a long time to get right and there is a load of undocumented features we discovered along the way but we cannot remember exactly what these were. Therefore to change it is likely to break the end product. Also we don't have tests that check what the code should do so your changes might break the software without us even knowing it is broken. So any changes must not affect existing code. But we cannot test it so we can't tell if it does affect it...." let's get this straight. The code "does something". We don't know what that something is (we don't have tests) but we suspect that this unknown something will change if anyone touches any existing code in a certain area. Therefore we cannot change the code, only add to it even though the new functionality should really require a structural change to maintain architectural integrity. But we can't even tell if the external changes have affected anything because we don't actually know what this thing does!

So the burning question is "How can anyone change any code anywhere if we (1) don't want any existing functionality to change and (2) we can have no certainty that a change has not affected existing functionality"

Now I should add at this stage that the guy in question is fundamentally a good, competent, normally coherent engineer (and is also a representation of several real-life engineers who I have come across in this situation!). Which raises the question why good, competent engineers can get themselves into this logical black hole and fear making changes in code.

There are several key issues here:
  1. No tests. So we cannot reproduce what the product should do.
  2. Lost information. The Team has not been sharing information effectively so nobody really understands why things are structured the way they are.
  3. Undocumented features discovered in a third party library.
  4. Unclear code. The code in question is satisfying several sets of responsibilities resulting in a monster 1500 line class.
The issues do highlight deeper issues with the way the specific team is working. They are indicative of several common behavioural antipatterns that often cause agile processes to fail. I intend to try and pin down specifics in later blog entries.

Monday, October 16, 2006

It's finally happened....

Well, it's finally happened. After ages of deliberation, soul searching mixed in with good measures of apathy and procrastination I have started a Blog. So what finally gave me the boot up the proverbial backside to do this? Primarily an excellent blog entry from Steve Yegge explaining why everyone should start a Blog.

What will be in here? Good question. But I suspect it is going to be my thoughts, experiences and opinions in the field of software development, especially in agile processes. In addition it gives me somewhere to document all those irritating two-days-to-solve-a-simple-problem solutions for the amusement of others that knew the answer all along (and hopefully help at least one other person struggling to solve the same problem...).

So bear with me while I work out how this blog-thing will work in the Real World - always the hardest thing for an engineer.