Failing fast to learn a lot

Being part of an embedded project team I was originally looking forward to
a lot of complex technical challenges but as time passed I realized, as
often is the case, that the success of a project is a lot more about
people, communication and motivation than about hardcore tech skills and
plain competencies.

To set the scene
The project team I’m part of consists of 18 persons where only a few had
done agile development be-fore they got introduced to in halfway through
this project.

The main feedback the development group is getting and has historically
been getting is from the system test group.

That feedback could in the past be boiled down to “We’ve discovered X new
faults and the following Y faults block our progress” repeated a few times
a week whenever the situation changed.

Over say 14 time boxes where the predominant feedback have been “What
you’ve done is not good enough for us to continue with our system work”
even the most hardcore developers I know would have suffered a blow or two
to their motivation. After all we all want to hear “Good job” once in a
while.

The above description is a bit exaggerated but looking at how people
behave and talk I’d say it’s reasonably close to the essence of how
people feel.

So what I originally thought would be a technically challenging architect
task has turned into a motivational task more than creating UML diagrams
and code structures.
And when it comes to being an architect the way every new idea is
presented needs leave a feeling appreciation and motivation in the
involved developers.

The first of two main focuses we’ve looked at so far is communication
within the project.
The system group now emphasizes how many observations (positive word for
bug) the developers have resolved and the testers have verified and no so
much how many unresolved bugs the system has.

First day they did that even the Head of the department was pleased with
the “progress”. I’ve put progress in quotes since there weren’t any
progress from Friday to Monday but the nonexistent progress was valued
because it was perceived in a different manner.
Knowing that you’ve solved 250 bugs and there’s only 40 known issues just
sound a lot better than “There’s still 40 new/unresolved observations”.

The second one is changing how people think about testing and finding
bugs. At present people fear bugs they are considered feedback of poor
performance and hence people test to prove that the code works (which is a
mathematical impossibility within finite time)

This time box we’re going to have a war game of testing. We’ve got 3
development teams and they are all delivering code 4 days before the end
of the iteration and after that deadline, every group is permitted to
write unit tests and unit integrations test to the code of the other
groups. The group that end up finding the most bugs wins the great prize.
The war game has a few objectives seen from a project perspective.
1. We want to change how people write tests. They should be written to
find bugs not to “prove” that the code works.
By actively rewarding the act of finding bugs we’ll change the focus from
“proving that it works” to “finding what doesn’t”
2. We want the coverage up and since there’s two ways of winning: Either
write a lot of tests finding “all” the bugs yourself or write a lot of
unit tests finding a lot of bugs in everyone elses code we’re sure to get
a higher coverage

As secondary objectives it’s worth mentioning that focusing intensely upon
writing unit test while at the same time being educated in writing unit
test hopefully makes the developers realize which code structures are more
robust than others and finding some of the qualities of testable code.

For me it’s back to holding my thumbs, crossing my limbs and hoping it all
works. Luckily I’ve played the games before so I know they do, and I guess
all there’s left to say is:”Let the games begin”