The Best Development Styles for Preventing Stakeholder Misalignment

Traditional discovery methods don’t do enough to overcome the risks of stakeholder misalignment. The best development styles are context - and behavior-based development philosophies that create shared understanding between developers and product owners. Every business is unique. Even companies operating in the same industry have different operational needs. While this isn’t a problem by itself, it does make working with technology partners more complicated. There’s often a disconnect between developers and other stakeholders. Developers have to understand exactly what’s needed before they can build it, and getting to that point requires domain-specific knowledge they can only get from their partner. This is where the breakdown happens. Stakeholders come to the table with different ideas about what the product should look like and how it should work. When a developer doesn’t make a point of reconciling these misaligned expectations, it can result in budget overruns, damaged reputations, and even project failure. Traditional discovery methods don’t do enough to overcome the barriers in understanding, though. Instead, context - and behavior-based development philosophies should take precedence.

The Problem with Misaligned Expectations

Working around misunderstandings might sound like a simple annoyance, but it has wider consequences for developers. Features that don’t do what the client needs have to be reworked, and new ones get added last minute. Such a stressful experience damages the client-developer relationship. Clients are less likely to use the same company again, and the developer may even have trouble winning new contracts. The consequences go beyond budget overruns and damaged reputations. In 40% of bug tickets developers find that the documentation isn’t clear enough to help resolve the issue. That adds to the time - and expense - of maintenance.

Contextual Development Philosophies

A well-designed development workflow helps get all stakeholders on the same page. It enables developers to hit requirements better, assess performance more accurately, and produce solid documentation that results in more efficient maintenance. Here are some of the most effective methods in use today:

Example Mapping

Example mapping is a method of guiding a conversation to create a shared understanding among stakeholders. It’s also known as “Three Amigos sessions”, which refers to the primary perspectives used to examine an increment of work before, during, and after development:

• Business: What problem are we trying to solve?
• Development: How might we build a solution to solve that problem?
• Testing: What could possibly happen and how would we handle that?

Three Amigos can be used to write acceptance tests before implementing the corresponding functionality.

Acceptance Test Driven Development (ATDD)

ATDD emphasizes communication between testers, developers, and product owners, bringing the product owner into the test design process before any coding is done. Tests are phrased in business-specific terms instead of engineer jargon. Plain-speech feedback comes quickly and is easy to incorporate going forward. This focuses development on actual business goals. It also facilitates clear communication, so everyone understands what is happening, what should be happening, and where things are going wrong. ATDD is a contextual approach to exploring software requirements. Stakeholders suggest scenarios of how the software will be used, then use those to define requirements and design functional tests. The process sometimes even uncovers stakeholders who were missing from the process. Having realistic examples rather than technical abstracts improves communication between clients and developers.

Behavior-Driven Development (BDD)

Under this evolution of Test-Driven Development (TDD), software is built incrementally according to a user story. Developers create features and adjust design specifically in response to real-world behavior and feedback. The process is dynamic and responsive:

• A product owner explains part of the process.
• Developers write a corresponding feature.
• Testers check whether the feature supports the user story.

BDD uses a structured language called Gherkin to create explicit, easy-to-understand requirements which can be read using Cucumber, a test automation tool. Here are some of the most common Gherkin keywords and how they’re used in context:

• Feature describes the feature being tested.
  • “An error message alerting users who make mistakes on the contact form.”
• Scenario is putting the behavior being described in context.
  • “A user is filling in the contact form.”
• Given sets the beginning state of the scenario.
  • “If the user enters letters into the phone number space”
• When describes an action the user takes.
  • “When the user hits send”
• Then details the testable outcome.
  • “The form reloads with the invalid entry outlined in red and an error message explaining how to correct it.”

There are about ten keywords in all with other uses. (For example, “and” can be used to expand any other other operators.) The most important thing, though, is that BDD and Gherkin acceptance tests guide stakeholders in choosing where to start development, deciding how to test, and understanding why tests fail.

Final Thoughts

Good communication is the antidote for nearly all major problems that can derail projects. It follows, then, that the best development philosophies for enterprise software development revolve around improving communication and understanding among stakeholders. Taking the time to prevent misalignment from the start leads to more productive development and a higher quality final product.

At Concepta, we measure our success by the success of our clients. That’s why we use contextual development methods to be sure our products support specific business goals. Set up a complimentary appointment with one of our development team to find out what we can do for you!