|
1) Pair Programming
It’s hard to argue that this doesn’t work when done correctly. We know from the work of people like Dr.
Laurie Williams in her book ‘Pair Programming Illuminated’, that this particular practice is filled with
myths and false assumptions. When done correctly you can expect roughly the same amount of work produced
as if the two individuals had worked alone. However you gain two critical elements:
a) Collective Code Ownership. By using Pair Programming and switching your pairs consistently, you will
create a shared knowledge of your system across your team. The typical model I see today is the
‘cowboy’ programmers pulling 100 hour weeks to get a system done, with the rest of the team
struggling to add value on the far less critical elements of a project. Studies prove that these
‘cowboy’ programmers are up to 2,800% more productive then their worst peers (see Robert Glass’s
excellent ‘Facts and Fallacies of Software Engineering’ for more information) so it is no wonder
these high bandwidth individuals tend to say “OK move out of the way and just let me do this. I can
get this done in a few weeks”. They are often viewed as ‘superstars’ and even promoted to management!
This is another fallacy of logic as there is nothing about a high performing developer that would
indicate they would be an effective manager, however I believe that is a main reason why we suffer
in the US from astounding losses in software development in Corporations (up to $140,000,000,000
based on studies from the Standish Group). When performing pair programming, ‘cowboys’,
often feel that they are doing more training then pairing, a key cultural problem to watch out
for.
b) The quality gains in your code are significant, often as much as 200-400% when code is written in pairs.
In turn, producing a productivity rate that is roughly equivalent to that of an individual, once the team learns
how to pair program correctly. Yet why do so many organizations flat our refuse to embrace this
obvious (and free) practice? The pair programming experience is highly social, with one person
‘driving’ (coding) and the other person watching intently and both individuals changing roles often.
For the person watching and discussing the code, it is not so much syntax checking (we have
compilers and IDEs for that). It is about keeping in mind the big picture, and asking for
explanations where code doesn’t make sense. Think of this as a traditional‘code review’, done in
real time. These two parties swap roles when it feels right to do so and they form a highly
productive team. Thus, ensuring that all aspects of their project are accomplished: Strategic,
Tactical and Operational. This is especially helpful when you have a developer who likes to write
incredibly complex code that nobody can understand when a far simpler and 'boring' solution exists.
The pair helps ensure this doesn't happen right at the source (where in a more traditional code
review process it would be to late). One problem in Agile I will address are the 'cowboy'
programmers who are used to being the superstar and being greatly responsible for a successful
project based on their immense talent and long work hours.
One partner could say to the other:
“Do we really need to manually implement a recursive quick-sort when it is already provided for
us in the framework we are working in?”
”Well I can optimize the sort I am sure as I read on a message board they didn’t optimize it
properly”
”Well, the few CPU cycles we would save are not worth the time it would take (if indeed you are
even correct). Remember we optimize last in Agile or we risk optimizing the wrong item, so lets
use the framework and if we find it is a bottleneck we can always refactor to your solution later
on. Deal?”
“OK you do have a point. In that case let me write this line, and we are done. OK let’s run the
Unit Tests to make sure we are all green”
“Great Idea. If we are all green I’d like to drive and lets move on to the next task in our Story”.
NOTE: The term “green” is often used as the color of a successful unit test is green. It is more
common then most developers ever predict. Later iterations of code are almost always written that
break code from previous iterations. These broken segments are often items the developers were
not even considering. The RED test is usually a fairly obvious problem that is quickly resolved.
Once we are ‘all green’ code can be checked in (but that does not mean the build with all the
developer’s code integrated was not broken. I will cover that in Continuous Integration, one of
the easiest and most underutilized wins a team can implement (and the software is free).
2) A ‘War Room’ Environment for a Shared Working Team Space.
This is optimized by walls covered in white boards for impromptu ‘Agile Modeling’ sessions where all team
members are extremely well versed in Object Oriented Design Patterns. This is nothing new (in fact there is
very little new in Agile, It is the fact that these common practices have been brought together that makes
Agile unique. Unfortunately, corporations often cannot dream of asking their people to leave their nice
cubicles. Many managers cannot make this happen so they take a big hit in their probability of success to
allow the core team to often be spread apart, have closed door offices, and suffering vast distances and
time zones separating the team, making one of the most important aspects, face to face communication, hard
if not impossible.
These processes are a negotion, not a 100% mandate. Agile is almost always crafted to the organization. So how do
we deal with these hindrances? How can we quantify the impact these poor decisions have on our likely
outcome?
|
