The limits of user involvement

The limits of user involvement2017-10-12T22:05:27+00:00

Experienced users generally have good insight into the real needs of the systems they use – certainly they are an improvement on a formal requirements specification.

The dark side of user involvement

Yet user involvement is not a completely beneficial practice. It can have a negative side too:

  • The users’ attitude to the team may not be especially positive:
    • Often the relationship begins as a customer-supplier relationship in which the customer traditionally expects the supplier to provide almost all of the effort.
    • Historically, many IT departments have not persuaded their business customers that they would benefit from a closer relationship. This has created an adversarial or mistrustful relationship – often on both sides – that makes Agile difficult.
    • Allowing users to work intensively with the team may require complex and difficult changes to the customer/user organization.
  • The users may not represent their areas as well as you would like:
    • If user representatives need to be highly experienced to be effective, they may not be able to represent new or occasional users.
    • Individual users have disproportionate impact on design, and product.
    • Other users may feel excluded and resist the new system as a result. (‘not invented here’)
    • Other users may fear that user representatives will not represent them properly.
    • The user representatives may really not represent other areas properly.
  • Users may not be good at telling you what they really need.
    • Most people aren’t good at articulating even their own needs.
    • Different users may offer different interpretations of what ‘the users’ want or need.
    • Although Agile User Stories are meant to be in user or customer language, developers are not always fully familiar with what that language means.
    • Users may not have been properly trained to use techniques such as User Stories or Acceptance Criteria.
    • They are often quite unaware of what alternatives exist (e.g., as provided for competitors’ staff).
    • Many people don’t welcome radical change, even if it is meant to make their work easier or better.
    • By definition, this method lacks any review of the decisions and information users provide.
  • Users can’t necessarily represent external customers realistically.
    • For example, Help Desk or Customer Support staff may be able to help you to understand the customers’ problems or complaints.
    • But that is not the same as understanding how customers would like to use your systems or even how they really use them now.
  • Even when senior, experienced and authoritative, users are not necessarily well-informed about what the business is trying to accomplish – even at the user level.
    • The ‘vision’ expressed by individual users may conflict with the vision already expressed by the business’s senior management, the Product Owner, etc.
    • NB: Product Owners or business analysts may offer greater insight.

Possible remedies

Some of these limitations are radical and widespread, while others are less likely to impact a well-setup Agile project. However, considering them should be part of preparing any organisation for Agile. There are quite a few things you can do to minimise their impact:

  • Be completely transparent about what it realistically going to be needed.
  • Provide a convincing business case for, and a practical operational analysis of moving to Agile.
  • Train users to be users.
  • Actively coach users through their first few releases.
  • Persuade the business to properly back-full the users’ day job and other responsibilities.
  • Make sure your users are treated as full members of the team.
  • Have contingency plans for all the difficulties mentioned above.
  • Treat crises as learning points for users and for the team, not as failures.
  • Celebrate successful projects with the users.
  • Persuade the business that active involvement in an Agile project should be seen as a plus in the user’s career.

Leave A Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Want to do more than just build systems?