Bloggo back to the blog
Bringing information back into IT-->
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.