The wide and deep scope of these areas of involvement mean that the users are in almost continuous demand within the team. As a result, one of the greatest obstacles to implementing Agile is getting the right level – and the right kind – of user involvement. This is hard for many good reasons:
- Users have day jobs, which they’re often expected to continue full-time, even while they’re also working with you.
- True on-site participation in development could demand significant travel and other costs and inconveniences.
- Think about going to them (using a demo rig, etc.).
- Or using remote communications technologies.
- Many organisations are not good at releasing their best people (which is what Agile requires) for what they often see as secondary work.
- Even when key users are made available, they don’t have authority to make real decisions. Everything still needs to be referred back to someone higher up the management chain.
- Their day job will often throw up urgent demands that, even if they are not especially important, often seem more important to their managers than your systems development.
There are many possible strategies for dealing with this difficulty:
- Minimise the demands on any single user by involving several users from each area.
- Agree a definite schedule for user involvement that respects their other responsibilities.
- Identify alternative sources of information – models, defect reports, user metrics, change requests, strategy documents, and so on.
- Create alternative interaction tools – e.g., brief issue-driven meetings at the user’s own desk.
- Substitute analysts or the Product Owner for users until very late in the development process, and only then require real users to confirm the developed product.
These strategies are not without risk, but they may be your only realistic options.
In the longer-term, there are other things you can try:
- Before you begin using users in your teams, make sure that their senior management are:
- familiar with – and persuaded by – the reasons why users are so heavily involved in Agile,
- aware of the likely impact on other users (e.g., taking over the responsibilities of users’ participating in Agile teams).
- willing to manage this impact actively and constructively.
- Once your Agile programme is under way, use the success of early Agile projects to prove the value of active user involvement to the wider business, and use this to persuade senior management to release users for longer periods, to back-fill their responsibilities more completely, and so on.