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.
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.