In my experience working on IT projects means a constant
struggle with information, either too much or, more often, not
enough of it.
Timing is an important factor as well. Many people will have
uttered the words "I wish I'd known that earlier..."That includes
not only testers, but programmers, project managers and other roles
on the project.
You'd think that people in IT would know about passing on
information, but when I look at CVs, very few mention anything
about communication skills and figuring out if people are good or
bad at maintaining and improving communication is a challenge.
I'm convinced that where Agile works well it's because a lot of
the communication problems found in more traditional approaches
have been eased if not removed.
In this blog I'll look at the problems with communication focusing
on the people side rather than processes or environments and share
some of my experiences.
Part I - Recruitment
I recruited quite a few testers and the one thing I want to know
is what a typical day in the office looks like and what project
they're currently working on. If the candidate can explain in a few
sentences what their company, project, application and team is
about so that I understand it, the interview is going very well
indeed. From that we can then have a deeper discussion about test
approaches and strategies, giving me an insight into their
skill-and mindset.
This approach is basically a test run to see how the candidate
would perform in a project situation as well, how they'd pass
information back to developers, project managers and their peers.
Asking the right questions is a skill and if someone can
demonstrate that skill in an interview situation which is
notoriously stressful they'll be likely to do the same once they
work in a project. An IT project is usually a bit more complex but
it's a good starting point.
Part II - The definition of "Done"
In the past I've often heard the expression "I'm done." I
usually hear that when I chase a missing a piece of information
trying to find out where the bucket stopped.
What people mean with "I'm done" is usually "I don't want it to be
my problem anymore, I want you to have it." That could be a piece
of code written (unit tested or not) or something else. In this
example what people forget is that they may have passed the bucket
to someone further down the chain, but they seem to forget that it
will come back. I'm not sure if it's a human trait, creating a
small space of time in which they'll flee before the big beast,
figuratively speaking, of a project coming back to eat them.
Sometimes that can be overcome with training and work culture
which most managers should be able to implement, sometimes that's
not possible. Regardless of their technical skills, in the long
term it may be better for the company to either micro manage them
or let them go.
Part III - Reporting
I spoke to one of my new team members recently who wanted to
report on passed vs failed test cases and thought that this would
be a good quality measure - I begged to differ. I asked about the
target audience and how the number he wanted to report would be
taken in by that particular audience keeping in mind that it didn't
consist of testers - the difference between passing on the number
and how
this information would be processed. We had a great discussion
about it where both of us learned something. In addition to the
numbers he did provide a fantastic description of what the coverage
of the tests were and what the remaining problems were which we
took as a basis for a discussion and later decision to release the
build into production.
He came to me a day later and said that his approach was based
on wanting to please people, me as the test manager as well as the
project and release managers - to give an easy summary about the
application being tested. In other words the providing of a single
number as quality measurement (to which Michael
Bolton has
something to say) was based on fear, the fear of not being seen
as having a valuable contribution to the project.
I think that this is most likely the case in other companies as
well, that instead of giving information we're selling the comfort
of single numbers and the illusion of working software.
I looked mostly at the people part in this blog. I
created a MindMap about some of the other factors, please feel
free to contribute or comment.
Thanks for your time.