Not Getting What You Want?


not be done in the presence of developers or programmers. Keep the demonstration running smoothly by providing an outline to the attendees. Be sure to notify the developers or programmers when this demonstration is taking place so a testing area is available. Finally, never blame a developer or programmer in front of a group when a feature or function does not work or look as expected. Comments like "I guess Harry forgot to fix this" do nothing but harm. Always offer to take issues to appropriate persons and report back on the progress. Don't be tempted to sacrifice integrity for short-term payoff.

Communication before Delivery
Quality Assurance should clear the path so that developers and programmers can openly discuss snags in the project and offer alternatives. It is important to realize the best window of opportunity is after the request has been made and before the delivery is complete. Delivering without a feature or function or with a questionable alternative is a symptom of poor planning and communication.

A final note: Holding to the requested features is not about inhibiting innovation. Users are best equipped to tell you what they need. It will be a test of understanding their needs, and of communication skills, to implement real innovations.

About the author

TechWell Contributor's picture TechWell Contributor

The opinions and positions expressed within these guest posts are those of the author alone and do not represent those of the TechWell Community Sites. Guest authors represent that they have the right to distribute this content and that such content is not violating the legal rights of others. If you would like to contribute content to a TechWell Community Site, email

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!