All methodologies expect users to be involved in development, but Agile is remarkable for insisting that users should be intensively – and almost constantly – involved from start to finish.
But exactly why this level of involvement is so important or how that involvement works is seldom explained in any detail.
Traditional user involvement
First and foremost, users are active members of the delivery team. In more traditional methods they already play a variety of roles, but from an Agile perspective they are not enough to make sure of success.
|Traditional role||Problems with the traditional approach|
- Requirements specifications seldom communicate the wider context of business or operational context of development, or the ultimate goals it is meant to support. So developers are working with very limited visibility.
- It is very difficult to write convincing requirements using a purely formal tool such as a requirements specification. Many aspects of what is really needed are difficult to formulate – and sometimes impossible to imagine – without working through practical examples or prototypes they could create if they were working directly with the developer.
- In rapidly changing markets and environments, users and other requirements authors are often unaware of what is possible, and so ask for things that are not really the best that could be delivered.
- Written requirements are rather like holiday photographs: they can’t always convey to the audience (the developers) what they mean to the person who took the picture (the users).
- Writing requirements is a specialised skill, for which users are seldom properly trained. But specialist requirements authors seldom have any real sense of what the users or even the business need.
|Occasional informants and SMEs.|
- Key issues that an actively involved user would have spotted and which could be dealt with quickly and painlessly can often go unnoticed until it is too late.
- Development can be like a game of Chinese whispers. As the development process moves from capturing requirements to functional analysis and technical design, and then to programming and testing, the opportunities for misunderstanding what the business and its users actually want can only grow. This is often only discovered at the very end of a long development process.
- User reviews are invaluable (and very underused), but still only take place after any errors or omissions have already been made.
- Like writing requirements, reviewing is specialised skill that few users possess.
- Like reviewing, acceptance only takes place after the work has been done. So it is inherently expensive – the best the team and users can hope for is that fixing the problems acceptance raises isn’t too expensive or time-consuming.
- Acceptance is expensive and very demanding for users, so it can easily fail to identify problems that more intensive involvement would uncover.
A good deal of the above can be summarised very simply: Prevention is better – and faster and cheaper – than cure.
The benefits of user involvement
So how does this situation look from Agile’s point of view? If traditional methods are a problem, is Agile really better?
Benefits to the team
There is no shortage of reasons why a development team would want to have users actively involved in the development process:
|Benefits of Agile|
- Developers get a better insight into the context of development – what users actually want to do with the system (and indeed what users actually do for a living), what the business’s goals and priorities are, and so on.
- Requirements are communicated directly from user to developer, without a complex, unreliable and always obsolescent requirements document between them.
- Because developers are working directly with users, they are always aware of how their thinking is changing. So their ‘requirements’ are absolutely up to date.
- When stories become simply starting points for a more detailed one-to-one discussion between user and developer, requirements management skills become unnecessary.
- Rapid, informed decisions can be made about stories, features, themes, etc. Impact analysis and trade-offs are simple and rapid.
- Estimating becomes much easier and more accurate.
- Prioritisation is more likely to reflect the delivery of maximum value first.
- Users are accountable directly to developers for the quality of the requirements.
- Because they are actively discussing the users’ needs, problem, ideas and situation directly with the user, the Agile team is often able to offer options and alternatives of which the users are unaware.
- Feedback on the emerging design and implementation is immediate.
- Designs reflect realistic usage.
- The delivered system has guaranteed usability.
- The developer can validate their interpretation of what the user needs directly with the user, before detailed coding begins.
- Communications lines and feedback loops are short and reliable.
- Most documentation – expensive, slow, superficial, unreliable – is redundant.
- Extremely high speed is achieved, especially by comparison with documents.
- Person-to-person bandwidth is enormous, again especially when compared with formal documentation.
- Communications is no longer a game of ‘Chinese whispers’.
- The interaction brings to the surface issues, mistakes and omissions the user and developer would otherwise (wrongly) take for granted.
- The benefits of pairing apply to users as well as fellow developers.
- Direct interaction with users is professionally and personally satisfying.
|Reviewing, testing and acceptance|
- Because the user is actively discussing the product with the developers while it is being developed, many mistakes and omissions that would normally only be discovered during testing are prevented from happening in the first place.
- There are few surprises – the users are aware of the concepts and design the developers use as they are actually being applied.
- Similarly, little bug fixing or retest is likely to be needed.
- The team’s ‘definition of done’ is more realistic.
- The team’s ‘definition of done’ is better attuned to users’ needs, preferences and priorities.
- New and changed requirements are quickly and easily fed to the team and the developer.
- Change happens safely but without the overhead of extensive formalities.
Benefits to users
Just as the development team benefits from the user’s involvement, so there is no shortage of reasons why users would want to be involved directly in the development process. Here are the main ones:
- Users are empowered the make decisions about things that affect their work.
- Rather than having to express themselves through documentation, users can express what they want more clearly and fully:
- by practical example.
- by non-verbal channels (by physically seeing options, hands-on contact with evolving system, etc.).
- by working recursively with the developer (through what is effectively a prototyping process) to gradually arrive at what they want.
- Priorities are set by the users who are directly affected by a change, defect, etc.
- Formal, bureaucratic and extended procedures for capturing and analysing requirements, preparing and maintaining documentation, review and approval, change control, etc. are eliminated.
- Users learn new technical skills that make it easier for them to understand what is possible in future iterations.
- Users increase their awareness of the technologies they use and the options they provide.
- The developer is personally & directly accountable to users for what they produce.
Benefits to the organisation
Finally, there is no shortage of reasons why the organisation as a whole should want its users to be involved directly with its development teams:
- The business/IT relationship is improved:
- The business (via the user) witnesses the team’s professionalism and commitment directly.
- The business (via the user) shares responsibility for delivering results.
- The radical transparency that follows from direct user participation helps to remove silos and encourages mutual openness across the organisation.
- The standard, potentially antagonistic customer-supplier relationship is replaced by a shared team effort.
- Many myths IT and business believe about each other are exploded.
- When the going gets tough, business and IT collaborate rather than fight.
- Many project risks are automatically mitigated by the right people working together directly on delivery.
- The right product is more likely to be delivered.
What user involvement can’t do
Finally, user involvement is a tool for solving some problems in the development process, but it does not alter the developer’s responsibilities:
- For good engineering.
- For solving problems that the individual user cannot help with, such as performance, load, security, or most regulatory requirements.
- Many of these problems may require the help of members of the Extended Team instead of users.
- Resolving conflicting user interpretations of their own needs.