On user involvement

Users are one of the two keys to successful implementation.

So here are some thoughts on user involvement:

  1. User representatives need to be actively, directly and constantly involved in releases:
    • In story definition.
    • In Release & Iteration Planning, to articulate stories (i.e., before Iteration 0).
    • In Iteration 0, to classify how risky, etc. stories are, define Acceptance Criteria, support prioritization, etc.
    • During development, to flesh out what stories mean in enough detail for the release team to implement them.
    • In Showcases (perhaps).
    • In UAT.
    • In their own training.
  2. This is plainly impractical:
    • Being a user representative is also a specialist activity: as story writers, testers, etc.
    • Users have day jobs too.
    • If they are involved in nothing but releases, they will soon cease to be credible users!
    • User representatives can find themselves doubly involved (!) if successive releases overlap – as, in any full-tilt Agile environment, they often will.
    • There is seldom any training for the specialised skills a user representative needs.
  3. So I suggest that each operational area should have designated teams of user representatives, all of whom are:
    • Designated explicitly as user representatives.
    • Properly trained in story-writing, working with developers and in UAT (script writing, data preparation, execution).
    • Allocated time to do the job (i.e., they don’t have a full-time day job to do while they are representing their area in a release).
    • Explicitly given credit in their personal assessments for actively contributing to improving systems (so others will be motivated to join in too).
  4. Each area should have at least 2 such teams, and ideally more. That way, all user representatives loop back into the ‘real world’ between releases:
    1. To refresh their experience.
    2. To avoid ‘Agile fatigue’.
  5. Useful users are only a (usually quite small) subset of all actual users. Apart from available, they need to be:
    • Expert enough to be able to tell the development team exactly what a story requires.
    • Empowered to approve (if not formally accept) the implementation of a story, and if the story turns out not to work as expected, to change it – both without going back to their management for clearance.

And the second key to successful implementation? Senior management. But more of them another time.

By |2018-01-18T13:04:07+00:00Friday, August 21 2015|Categories: Agile, All, Empowerment, Principles, Resourcing, Users|0 Comments

About the Author:

Chief Architect, Agile201.com.

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?             
error: Agile201 is wholly copyright and copy-protected.