3 Cases for communication

I have recently been making a drive towards increased customer communication in our development processes. By a happy coincidence soon after starting this drive I attended the Agile Testing and BDD Exchange and watched Gojko Adzic's presentation on Challenging Requirements. At RainStor we have strong relationships with our partners, and in the majority of cases deliver working software, on time, doing what the customer wants. However, on occasion I feel that the underlying customer requirements can sometimes be misinterpreted through the story definition and elaboration process. My aim was to get our customers more involved throughout the development cycle to ensure that the number of surprises on both sides is kept to a minimum.

Only a few weeks into this incentive I have encountered 3 separate cases where communicating with the customer directly has resulted in a significant benefit:-

1. Clarifying the usage reduced the scope

One of the requirements was for the customer to be able to view metadata fields alongside their existing data fields in their archive from ODBC/JDBC clients. These fields should only be visible when the customer wanted to view them, and not appear the rest of the time. Solutions in discussion were all centering around enabling the fields somehow through syntax functions or hints in syntax comments. Perceived problems were whether the client tools would strip out comments before passing back to the server, and whether tools would hit issues having cached the data schema on connection if suddenly the schema were to change. I contacted the customer to clarify the requirement and established that it would be acceptable to create a separate database connection if using these metadata fields. This meant that we could switch on the metadata fields in the database connection, thereby avoiding any complex testing of syntax parsing and wouldn't be susceptible to unknown client tool behaviour. Simply communicating with the customer reduced the scope and complexity of the requirement to a far simpler case than was being considered.

2. In removing an assumption which was not valid

Being a pattern based storage system, one of the limitations on building a table is that the table have more than one column in each table. One of the requirements being developed was to allow the populating of some data columns with fixed literal values rather than the customer having to add those values into the source data for every row of import data. One of the development/test assumptions was that imports of single column source data would not be supported. However, on contacting the customer I established that it could be the case that they did require multiple column tables where all but one column in the table could be specified as a literal, leaving only a single column to populate from the source data file, thus the assumption was not a valid one. Removing the assumption caused extra effort to work and test the new use case, but the result was functionality that would support what the customer wanted to achieve and avoid any nasty surprises on delivery.

3. A demonstration of functionality flushes out inconsistencies.

On a long running, multi-story 'epic' requirement I felt that some uncertainty regarding the customer requirements provided an opportune time to run a demo of the functionality developed so far and also what we were working on at that time. As a result of the demo a number of inconsistencies between the use cases in development and the customer's perception of how they wanted to use the delivered functionality were uncovered which necessitated some further negotiations and clarification on both sides to resolve.

Now some folks who are working alongside their customers in an Agile context may say that these kind of cases are obvious and dealing with the customers is what we should be doing on a daily basis. I agree that this is great if you have that level of access to the customer, however as Gojko Adzic points out in his blog post The Mythical Customer Problem, the idea of a single point of access 'Product Owner' is often not realistic and instead, as we do at RainStor, collaborative specification is the most effective way to ensure that what is delivered is actually what the customer wants. In this kind of environment it is not always clear who is responsible for communicating issues, questions and progress back to the customer and at what stage. By taking the responsibility of doing this I intended to, and succeeded in, demonstrating the value that more frequent communication with our customers can add. I can then use these cases as arguments for putting in place more defined methods and responsibilities for customer communication on further developments, and ensure that cases such as the ones listed here are cleared as a natural part of our development approach in future.