Remove Proxies to People

In all cases, try and deal with the primary source of information, don’t rely exclusively on proxies to people: augment or replace proxies with direct involvement whenever possible to get better overall communication. You may be surprised at how many “proxies” you currently rely on.

Pain Points

  • Despite adding in multiple layers of subject matter experts, teams still build the wrong things
  • Requirements take months or longer to generate
  • Teams complain about the scarcity of information in the work they’re trying to complete
  • Development and QA teams constantly feud over what a particular requirement means and how it should be implemented
  • Developers are told what to do, and never seem to do the right thing


  • Direct access to information enables faster and better decisions
  • Direct access to users enables teams to understand how the software works, how it’s broken, and how to deliver value
  • Fewer layers means faster access and less interpreted/misunderstood information
  • Information power brokers are pushed aside and real work can progress


  • Developers have full, unfettered access to product users (500pts)
  • Team has full, unfettered access to managers and executives when needed (200pts)
  • Executives have full, unfettered access to team when needed (see TeamWideInteruption) (100pts)
  • Team has only occasional access to managers and executives when needed (5pts)
  • Developers have occasional access to product users (5pts)
  • Use schedule or budget alone to rate product/project/organization quality (-200pts)
  • Team has no access to managers or executives when needed (-200pts)
  • Executives rely on managers instead of communicating with the team when needed (see TeamWideInteruption) (-100pts)
  • Developers have no access to product users (-500pts)


✓ Critical ❑ Helpful ❑ Experimental

Adoption Experiment

First steps to create this habit:


  1. Take an inventory, try and identify any proxies you rely on
  2. Ask others for help finding additional proxies you may not have thought of


  1. Prioritize your identified proxies based upon their impact or their importance
  2. Start going through your proxies one at a time, and find ways to eliminate the proxy in favor of a relationship with the person or people represented by the proxy1

Evaluate Feedback

  1. How did you do? If you did this well, your information should be clearer and you should have a more accurate picture of where you are in relation to your goals

What Does it Look like?

What do we mean by a proxy? Here are some examples:

  • An analyst is a proxy for a user
  • A manager is a proxy for an executive
  • A manager is a proxy for development team members
  • An estimate is a proxy for learning
  • Story points are proxies for working software
  • A User Story is a proxy for user needs
  • A certification is a proxy for competency
  • Velocity is a proxy for value produced by a team

The problem with any of these is that you will experience information loss by relying exclusively on the proxy.

In the GROWS Method®, development teams work directly with users. Now, depending on your organization, you might still have product specialists in place to collect and filter information, but that does not replace direct user involvement and the valuable feedback it provides.

Team members can take turns going into the field and shadowing users as they perform actual work. Key users answer questions about work flows. When developers and QA disagree about something, both product developers and users provide the answer.

Teams don’t write code for their own sake. They write it for the users. As much as we enjoy the creative act of development, we must harness that enthusiasm and channel it effectively.

Warning Signs

  • No one on your teams has ever met a user
  • No one on your team has talked to a user in the last month
  • A user has never attended your team’s demos (even virtually)
  • All user contact is forbidden and information is routed through a specific set of proxies
  • Teams complain about not getting information when they need it
  • Teams have no idea how users work with the product

How To Fail Spectacularly

  • Relying on spreadsheets and reports instead of person-to-person communication
  • Hiding developers from users, and vice-versa
  • Setting up a customer feedback program, then hiding the results
  • Polling users for feedback, then ignoring the results

  ←Prev (Create Psychological Safety)(Answers From Experiments) Next→

  1. Recall the first item from the Agile Manifesto, “People and Interactions over Processes and Tools.” 

Follow @growsmethod in the Fediverse, or subscribe to our mailing list:

Sign up for more information on how you can participate and use the GROWS Method®. We will not use your email for any other purpose.