Venus and Mars in the Workplace


How Do These Differences Affect a Software Project?
Here are a few project activities where such fundamental differences emerge:

·         Software requirements

1.      Venus perspective: Activities that will enable us to do our business better in the future (such as software projects) are secondary to the day-to-day running of the business. The software developers often tell us that they know our business and our priorities.  Why, then, are they surprised when given a choice between satisfying a customer and missing a software project meeting and we choose to satisfy our customer first?

2.      Mars perspective: Since it is the IT customers who want the software, it should be up to them to drive the project. Without solid requirements that are clearly articulated by our IT customers, there is no way that we can guess what problems the software is intended to solve. If the software project is important, then IT customers must allocate the necessary time to properly articulate the requirements.

3.      Achieving Venus/Mars harmony: As with any relationship, understanding the other's viewpoint is critical. When developers say that they already "know the business" it means that they are familiar with the general processes and procedures. It does not, however, mean that they know the detailed requirements to be supported by particular software. Early, targeted conversations to clarify and confirm requirements are fundamental to ensuring the software will support the activities intended.

·         User acceptance testing

1.      Venus viewpoint: User acceptance testing is really a misnomer. We're the "users" and yet the developers keep all the rules about what they perceive to be a "good" user acceptance test plan. We've had a series of meetings among ourselves to find out what they might really be after, but it always seems that we come up short-and then the business priorities get in the way.

2.      Mars viewpoint: The project activities were clearly laid out at the beginning of the project and the IT customers assured us that they would allocate the time and resources to properly "test drive" the system before it goes into production. However, when we took a look at their acceptance test plans, they were a bit of a joke.  There are going to be a lot of latent defects if they don't get more serious about rigorously testing the system soon.

3.      Achieving Venus/Mars harmony: User acceptance testing is a developer term and developers often have a condescending way of hinting that its contents should be obvious to anyone with any business savvy. From the IT customer viewpoint, it would make sense to work together to define what needs to go into a good user acceptance test plan, so that the IT users could then develop one. While all of the permutations and testing combinations might seem obvious to a seasoned developer, the occasional IT customer doesn't know the terms or the test plan development rules by heart. Working together without acronyms blocking the communication will go a long way to having successful testing experiences.

About the author

Carol Dekkers's picture Carol Dekkers

Carol A. Dekkers is President of Quality Plus Technologies, Inc., a management consulting firm specializing in creating peace of mind for companies who want to improve their software processes. Software measurement, software quality, process improvement, requirements, and software sizing (using function point analysis, as an example) are a few of the Quality Plus areas of specialization.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, is the place to go for what is happening in software development and delivery.  Join the conversation now!