Proximity to Requirements

In working with a set of teams that were consistently having problems delivering on their commitments a friend and colleague of mine described what he felt was a key problem by using the phrase "Proximity to Requirements". By this he meant keeping the chain of requirements, from their original source to the developer(s), as short as possible. His feeling was that the developers were too isolated from the end users, leading to a loss of fidelity as the requirements were translated through intermediate layers.

I think he hit the nail on the head in this situation. The teams, allegedly following an agile process, had no actual user representatives working directly with them. The client described what they wanted to a member of the account management team. From there it was handed over to a business analyst who wrote a high level design document that the customer signed off on. These were then handed off to a development manager who translated them into stories for the teams. The end result was software that didn't meet the clients needs and had to be reworked, often multiple times, before finally being accepted.

One obvious problem in the situation above is that it is very difficult to successfully implement an agile development process if the rest of the organization is still stuck in a waterfall model. The company culture has to change to become (more) agile overall. This can be a challenge when you need to have client sign offs and other contractual milestones, but there are solutions to these challenges. But that's a topic for a later post.

The concept of maintaining "Proximity to Requirements" should be something every agile team keeps in mind. Do you have a user representative as part of the team who can communicate user needs directly to the developers? If not that could be a red flag. And is that person still close to the client's needs? If they've been "embedded" with the development teams for a sufficiently long time they may have lost contact with the end users. I would recommend making sure that your user representatives (Product owners, product managers, UX experts, or whatever you use) have a chance to renew that contact. Have them involved with the sales and/or services teams from time to time to make sure their perspective is current. Get them out into the field interacting with current and prospective customers to make sure they stay current so they can be effective in their role. Whenever possible I also suggest getting the developers that kind of exposure. At a minimum can all of the developers actually run through an end-to-end demo of the product? I'm not suggesting having them do actual demos, since their time is better spent creating business value within the system, but understanding how the product works at the user level will put them into a better position to understand what they're being asked to build and will help insure that the entire team maintains that proximity to the real world requirements.