Karen Smith

November 01, 2012

While the transition to Agile software
development means big changes for everyone who’s “going Agile,” it has the
potential to have the greatest impact on User Experience Designers (UXD) and
User Assistance (UA) writers. Although Agile teaches that team members should
be fully dedicated to one team, the budget constraints of many teams dictate
that some people are shared across more than one team – and those people are
often UXD and UA. As more project teams transition to Agile software development
and strive to deliver more customer value in shorter, sprint-like chunks,
sharing our experiences and best practices with others in UXD and UA is now
more important than ever.

At the outset, participation on
multiple Agile teams may seem overwhelming, perhaps even unmanageable. Over the
last year and a half of working with a variety of Agile teams, we’ve learned
that when UXD and UA work together, and have a shared vision with their Agile
teams, the process becomes more manageable.

To ease the difficulty of
working across multiple Agile teams and work more productively, here are some best
practices for UXD and UA:

Show your Agile team that you are a shared service and
that your time is divided between multiple projects and assignments. This helps
them understand why you may not be able to attend every standup meeting.

Volunteer to help with other needs of the team. For
example, offer to take notes during a user research or feature usability
session, or offer to help with testing. Agile is about breaking down traditional silos
and accepting team responsibility for the success of the product.

Even though Agile means a full schedule of meetings,
UXD and UA should participate in non-Agile team activities, such a lunch
outings, impromptu coffee chats, etc. Getting to know your teammates pays off when
you need help documenting a feature or understanding what design choices are
possible.

In addition, here are some best
practices specifically for UA:

Prioritize the various Agile meetings. Daily standups,
planning, and demos are the “must attend” meetings. UA should skip meetings
that aren’t relevant or that don’t add value to the development of learning
content.

Track UA tasks separately from software development tasks.
The biggest advantage to this approach is that the closing of a software
development user story included in the definition of “Done” is not dependent on
the completion of learning content. In addition, Agile team members can
separately assign user stories and tasks to UA. If you’re using JIRA to track user stories, you
can add links from the UA user story to related software development and QA
user stories and tasks, making it easy to find the related information later
on.

Provide feedback to your Agile team on best practices.
Getting involved in the team is the key to building trust and earning
credibility. Set expectations for UA deliverables, identify where you can
contribute to shared team objectives, and be clear about what you will
contribute.

The article centers on the Knowledge / Importance, or K/I Matrix, as a tool to,

get a clear vision of overall project status at any given point

know where to best allocate limited resources, and

be sure you - as a project team member - are working on what you should be at any point.

A K/I Matrix is a two-dimensional graph with Knowledge on the X axis and Importance on the Y axis, where,

Knowledge is how well a team understands a task, and

Importance is the relative value of an item to project success.

Project teams collaborate at regular intervals in the development cycle to position work items in the K/I Matrix. In this way the team collectively agrees on relative value, and understanding of each item. This allows for more informed decision making.

Over the last year the K/I Matrix has been successfully incorporated into a number of projects in Autodesk's AEC group. It's proving to be useful in quickly building team consensus around project priorities, and making teams more effective in the process.