I often work with internal development teams who are struggling to improve their value to the organization. Individually they each have a job to do and most of them work very hard at it. As a team, the results are not always as valuable as the effort would indicate. I believe that the problem centers on the perceived value of work and the focus on the people doing it.
In a Hospital the focus is on the doctors, in a school board the teachers, in an airline it is the pilots, and in a development shop it is the developers who are regarded as the highest value providers. This solitary view diminishes the value of the contributors to that value. Value must be viewed holistically. Lets be clear that I am not simply stating some old hackneyed saying that everyone is valuable and that we have to treat them that way. I’ll leave that for a different discussion. What I am saying is that if that solitary view is taken, then the doctors, pilots, teachers and software developers taking that view will find themselves less able to maximize their own value.
Within teams the same thing happens where certain members are viewed as more valuable than others. In the case of an internal product development shop within an organization, many of the developers that I have worked with tend to view others and their roles rather simplistically and the business analyst or business relationship manager/customer representative role is often regarded as unnecessary. The role of a tester is often seen as nothing more than icing on the cake or a coat of paint at the end of the production line, yet those two roles are key for ensuring that what is developed provides maximum value to the customer.
Aside from the developers, the business relationship manager AND a representative from testing should be present at all stages of development, though some organizations will have dedicated quality control people in place with overlapping responsibilities.
It may sound counterintuitive to involve testing before you have anything to test, but recognize that they have to be involved early enough to at least develop the tests if nothing else. I view early involvement of testing even more critically however, not necessarily because they will know what tests to run, but because they are less likely to be satisfied that the acceptance criteria has been established. Other roles do not tend to focus as much or push so hard for clear acceptance criteria as those whose role is to generate the evidence that the criteria has been met.
What do I mean by acceptance criteria?
When organizations buy software they typically perform an evaluation to make sure that it meets their needs by comparing one product to another, or at the very least checking to see if a single product meets their requirements. They don’t simply test to ensure that the screen functions work correctly.
Why is it then that in developing in-house products for their own consumption, companies (and specifically development teams) often overlook such an evaluation? Sure requirements are gathered, but aside from providing a guiding direction for development, the requirements are never seen again. Instead, usability is considered the main success criteria and clicking through screens is the test.
When I see these projects I wonder then what are the chances that what is usable can be deployed, supported or even provide any business results? Many do not consider any of those criteria, but they would if the testing group was involved in helping establish acceptance criteria with each of the stakeholders from the outset. Your test team is not simply people with just enough low level skills to move a mouse or click a button, their value is in the advanced skills that they possess in helping you establish acceptance criteria.