Parkour: Lessons in Agility - July 2016

© 2014 Autodesk

Parkour: Lessons in Agility

Karen Smith and Patty Gale

Autodesk, Inc. ~ Revit Learning Content Development

CIDM Ideas Online Conference ~ July 2016

© 2016 Autodesk, Inc. ~ Parkour: Lessons in Agility @karenarrasmith @tkrytr

Introduction

Our Neighborhood

Challenges

Ideas

Approach

Lessons Learned

Outline


Autodesk: Imagine. Design. Create.

Karen Smith

Learning content developer

Scrum master

Patty Gale

Learning content developer

Information architect

Content strategist

Introduction


To provide context for the information we will be

sharing

Large software development organization

Product management

User experience

Engineering services

Product support

Development

Localization

Internationally distributed development teams

US, China, Poland, England, and more

Our Neighborhood


Content management system (CMS)

Structure content

DITA framework

Legacy content

Single-sourcing strategies

Online help, offline help

Multiple products

LCD deliverables and services

Tooltips, help system, videos, learning paths

Learnability reviews, help with UI wording

Learning Content Development

© 2014 Autodesk, Inc. ~ Parkour: Lessons in Agility #stc14 #parkour @stc_org @karenarrasmith @tkrytr

Get Agile!


ChallengesContent

Legacy content needs

rework and

improvement.

Moving from WikiHelp

to a new proprietary

online help system.

Product scrum teams

Teams are distributed

around the world.

Most teams were new

to scrum and needed

training.

A few were resistant to

the change.


Learning Content Team

Manager

Subject matter expert

Writers (4)

Content engineer

How can we meet the

learning content needs of

20+ scrum teams?


Hire more writers?

Let Dev, QA, and UX write the help?

Embed writers in multiple scrum teams?

Each scrum team requires a certain amount of overhead

for daily stand-ups, backlog grooming, sprint planning,

sprint demos, retrospectives, and daily interactions.

In our experience, this overhead is typically 20% of your

time for each team in which you are embedded. (Your overhead rates may vary.)

2 teams = 40%. 3 teams = 60% overhead.

Little time remains for development of learning content.

Ideas


Organize as a horizontal, service-oriented

scrum team

Provide a service to product scrum teams when they

need learning content for new features.

Each scrum team is assigned an LCD point of contact.

Based on the focus of each team, assign a service level:

Minimal need for LCD (performance, under-the-hood work)

Moderate need for LCD (small features, or low LCD needs)

High need for LCD (large features, or lots of user-facing

changes)

As much as possible, keep learning content in sync with

product development.

Approach


A sport in which participants move between two

points in the simplest way possible.

Participants use everyday structures in a new

way to show that there are no limits and no

boundaries.

Parkour is also the name of our service-oriented

scrum team for learning content.

What is Parkour?


Product owner

Provides the user’s point of view

Helps make decisions about direction, priorities

Scrum master

Servant leader for the team

Keeps team moving, removes obstacles

Performs some administrative tasks for the team

Service-oriented scrum team


Critical to a successful transition to Agile.

Everyone received basic Agile training.

Product owners, scrum masters, and coaches

received additional training.

Agile coaches provide guidance and support when

needed.

Forums for product owners and scrum masters

help them share best practices and important

information.

JIRA administrators help with Agile tools.

Training and Support


Envision and define your

process.

How will you operate as a

service-oriented scrum team?

How will product scrum teams

interact with you?

What deliverables and services

can you provide?

What information do you need

from them?

What will a typical LCD cycle

look like?

Describe the process in a simple

way.

Get buy-in from management.

Evangelize.

Share it with all product scrum

teams.

Process

•For your user story, create a sub-task to request LCD services.

•Complete the LCD Services Request Form and attach it to the sub-task.

•When you receive notification that a corresponding LCD user story has been created, the sub-task is complete.

Requesting team: Requests

LCD Services

•Reviews the request and creates an LCD user story for it.

•Adds the requesting team's PO as a watcher of the LCD user story.

•Creates sub-tasks for the LCD user story.

LCD:Reviews request, plans LCD work

•Each LCD user story requires a corresponding user story assigned to the requesting team's backlog to complete related sub-tasks, such as a Q&A session (if needed), testing tooltips, and reviewing help.

•LCD PO works with the requesting team's PO to determine scheduling of the related sub-tasks in sprints of the requesting team.

•LCD PO assigns the LCD user story to a LCD sprint.

•Requesting team's PO assigns the corresponding user story to a team sprint.

LCD & Team: Discusses LCD work, plans corresponding

team work

•Completes sub-tasks of the LCD user story.

•Demonstrates and records the results.

•Requesting team's PO receives notification of completed LCD sub-tasks.

LCD Team: Completes LCD work

•Team members complete assigned sub-tasks, such as technical reviews.

•Requesting team's PO closes the user story.

Requesting team: Reviews

LCD work

•LCD PO closes the LCD user story.

•New learning content for the feature is integrated into the next scheduled release, using an LCD release management epic.

LCD Team:Incorporates

learning content into next release


Requesting LCD Services

Provide product scrum

teams with easy ways

to request services.

Make it clear what

services you provide.

A list with links to

details is helpful,

especially for remote

teams.


JIRA or a similar tool for organizing and tracking

epics, user stories, and sprints

Wiki pages for each scrum team

List team members, roles, and contact information

Provide links to important instructions, forms

Record and store information about projects and sprints

Recordings of sprint demos

Helpful for all teams when you cannot attend a demo

Especially useful when teams are located elsewhere

Agile Tools for Success


Lessons

Learned


Get the team organized. Write a charter. Envision

your process. Evangelize.

Share your process. Get buy-in for your service-

oriented team.

Communicate with product teams. Make sure

they know how to request your services. Provide

a point of contact.

Conduct a new Sprint Zero for each new project

or release.

0. Start with Sprint Zero


A cohesive team makes it all work better.

Get to know your teammates as individuals.

What’s important to them?

Daily stand-ups help us understand what other

teams are doing, find ways to help each other,

cross-train, and collaborate.

1. Teamwork is important


Find ways to connect with product team

members.

What are they working on?

What’s important to them?

Cultivate the attitude that “we’re all in this

together.”

Offer help when and where you can.

Allow roles to blur.

Take notes during user testing.

Help with testing during final QA effort.

2. Build strong working relationships


Make it easy for product teams to interact with you.

Attend product team sprint demos

When there are user-facing changes being demo’d

Skip demos when nothing that needs your attention

Ping as needed

If you haven’t heard from a team lately, contact them to see if they

need LCD services.

Remind them that you’re there to help.

Remote teams require extra effort

Language, culture, holidays, vacations

Check on availability before you pull user stories into sprints.

Keep Localization Services informed.

Assign a liaison from LCD.

What’s ready for translation?

3. Communicate


Re-imagine your processes.

What can you eliminate to gain efficiencies?

Copyedits Peer reviews

Monthly translation estimates

Monthly analysis by Localization Services

4. Let go of old things


Offline help as a downloadable file

Adds one month to our development time for help system

Automated publication process and integration

with software builds

Help system (on staging server and in software) is

always up to date

5. Try new things


Accept learning content requests from product

teams however they want to provide it: form,

face-to-face, email.

Iterate the learning content.

In Agile, not once and done.

Expect to go back and update help topics as features are

iterated.

Be prepared to back out your work.

If a feature is dropped from release plans, you need a

way to remove its learning content. Plan for it.

6. Be flexible


Balance new feature work for product teams with

internal LCD projects.

Before bringing a user story into a sprint, check

carefully for dependencies on other teams.

Right-size stories – not too big, not too small.

Don’t overcrowd a sprint.

Allow time for non-sprint/unscheduled work.

If you finish user stories before end of sprint, pull in

another small story.

7. Find your balance


In Agile, you don’t (and won’t) have all the

information you need up front.

Trust that you and your team members can find

solutions when you need them.

Practice “good enough.”

Leave perfectionist tendencies behind.

We broke our monolithic help systems into smaller

modules.

If we find we need to add/update/modify information, it is

easy to republish one module instead of republishing the

entire help system.

8. Don’t stress


Define acceptance criteria for user stories.

Invite customers to sprint demos. Seek feedback.

Moderate user comments in the online help.

Revise content based on user feedback.

Use customer feedback and analysis

to improve learning content.

Participate in/observe user testing

and customer events.

9. Focus on the customer


Continuously look for ways to improve.

Use sprint retrospectives to identify areas to

improve after every sprint. Make an action plan.

Agile Maturity Model: each team self-evaluates

their progress with Agile dimensions every

quarter to see growth and identify areas for

improvement.

10. Continuously Improve


Shout-outs

During sprint retrospectives, verbally acknowledge those

on the LCD team who have made an extra effort, and

those on product teams who have helped you be

successful.

Team Awards

We developed our own Agile award to recognize

individuals who we felt deserved special recognition.

Agile Excellence Award

From Management to teams that have embraced Agile.

11. Reward desired behavior


Create your own team identity

(name, image, slogan)

Keep a sense of humor (eat your vegetables)

Take time to laugh

Celebrate the successes

12. Make it fun


0. Start with Sprint 0

1. Teamwork is important

2. Build strong working relationships

3. Communicate

4. Let go of old things

5. Try new things

6. Be flexible

7. Find your balance

8. Don’t stress if you don’t have all the answers

9. Focus on customers

10. Continuously look for ways to improve

11. Reward desired behavior

12. Make it fun

Lessons Learned: Summary


Agile Manifesto

http://agilemanifesto.org/

Introduction to Agile Methodologies

http://ffeathers.wordpress.com/2011/02/26/introduction-to-agile-

methodologies/

Agile for Technical Writers

http://agilescout.com/agile-guide-agile-for-technical-writers/

A Writer's Guide to Surviving Agile Software Development

http://www.scrumalliance.org/community/articles/2011/september/a-writer-

x27-s-guide-to-surviving-agile-software-d

Agile Tech Writers (LinkedIn group)

http://www.linkedin.com/groups?home=&gid=1115987&trk=anet_ug_hm

Tech Writers in an Agile Environment (LinkedIn group)


Resources

http://agilemanifesto.org/

http://ffeathers.wordpress.com/2011/02/26/introduction-to-agile-methodologies/

http://agilescout.com/agile-guide-agile-for-technical-writers/

http://www.scrumalliance.org/community/articles/2011/september/a-writer-x27-s-guide-to-surviving-agile-software-d




Many thanks go to:

Yinchun Mei (May) for background graphics

Jeff Hanson for Parkour video production

Mary Roy for her enthusiastic support

Shout-outs


Karen Smith

[email protected]

www.linkedin.com/pub/karen-smith/5/4a/126

Twitter: @karenarrasmith

Patty Gale

[email protected]

www.linkedin.com/pub/patty-gale/1/446/997

Twitter: @tkrytr

Q&A

mailto:[email protected]

http://www.linkedin.com/pub/karen-smith/5/4a/126

mailto:[email protected]

http://www.linkedin.com/pub/patty-gale/1/446/997

Autodesk and the Autodesk logo are registered trademarks or trademarks of Autodesk, Inc., and/or its subsidiaries and/or affi liates in the USA and/or other countries. All

other brand names, product names, or trademarks belong to their respective holders. Autodesk reserves the right to alter product and services offerings, and specifications

and pricing at any time without notice, and is not responsible for typographical or graphical errors that may appear in this document. ©2014 Autodesk, Inc. All rights reserved.

© 2014 Autodesk, Inc. All rights reserved.

Technology

Parkour: Lessons in Agility - July 2016