eWorkshop On Agile Methods
Tim Mackinnon
Connextra Ltd.
I have been team leader of an XP team that has been working on web based contextual analysis products for almost 3 years. Our team has ranged in size from 3 developers (initially) to 12 developers (max) and is now 9 developers. We have consistently delivered working products (with increased functionality) every 3 weeks for 31 iterations.
Early on in the
growth of our team we adopted the practice of hiring people based on a hands-on
interview where candidates pair with 3 members of our team for an afternoon.
Approximately each hour the candidate will swap partner and explain the task
they are working on what tests they have written so far. We have found this an
excellent way to ensure that our team is composed of “XP” compatible team
members. Note however, that our team is composed of team members with varying
levels of technical skill however all members (through this interview process)
have shown an interest in an agile method of working. Specifically we look for
good communications skills, good interpersonal skills, an ability to learn new
things, ability to question, and an ability to write tests (or think about how
to test software).
While we have a
team that is composed of different technical abilities, we all share a strong
discipline for applying the “XP” practices to the strongest degree that we
possibly can. In this respect I strongly disagree with the “Figure 1” diagram
in Barry Boehm’s article. As a representative of an XP team I feel that for XP
to be placed on a scale close to “Hackers” is not reflective of the discipline
that our team (and many others that I have encountered) exhibit. While there
are many definitions of hacking – a lack of discipline is often synonymous with
“hackery” and I have encountered many teams that use milestone plan-driven
models that are much closer to hacking when it comes time to implement what
their upfront plans have dictated. In this respect I would say that this
diagram is too simplistic and should be drawn in 2 dimensions – hackery on one
scale and software engineering discipline on the other (on this latter scale I
would place XP and some of the other agile methods very high up the scale).
Finally, I would say that our team is most successful due to its level
of discipline more than sheer technical talent. While I would agree that
technical talent has on many occasions helped us out – it is the discipline of
the members that keeps us going day by day. Furthermore, the agile value of
“individuals and interactions over processes and tools” is an extremely
important one. This value needs a lot of attention – to the degree that our
team now holds a retrospective after every iteration to ensure that all members
have an opportunity to voice concerns and issues in a safe environment.
Previous to this practice we measured a high level of discontentment, which we
were able to show reduced over the course of several retrospectives. My feeling
is that teams need much more than great developers to be productive and to
write great software.