Parkour: Lessons in Agility - Proceedings for STC Summit 2014

© 2014 Autodesk
Parkour: Lessons in Agility
Karen Smith and Patty Gale
Autodesk, Inc. ~ Revit Learning Content Development
STC Summit 2014

© 2014 Autodesk, Inc. ~ Parkour: Lessons in Agility #stc14 #parkour @stc_org @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

Get Agile!

Challenges
Content
 Content is still book-
based, not topic-
based.
 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)
http://www.linkedin.com/groups?home=&gid=3873251&trk=anet_ug_hm
Resources

 Karen Smith
 Karen.Smith@autodesk.com
 www.linkedin.com/pub/karen-smith/5/4a/126
 Twitter: @karenarrasmith
 Patty Gale
 Patricia.Gale@autodesk.com
 www.linkedin.com/pub/patty-gale/1/446/997
 Twitter: @tkrytr
Q&A

 Many thanks go to:
 Yinchun Mei (May) for background graphics
 Jeff Hanson for Parkour video production
 Mary Roy for her enthusiastic support
Shout-outs

Autodesk and the Autodesk logo are registered trademarks or trademarks of Autodesk, Inc., and/or its subsidiaries and/or affiliates 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.

Parkour: Lessons in Agility - Proceedings for STC Summit 2014

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (20)

More from patricia_gale

More from patricia_gale (10)

Recently uploaded

Recently uploaded (20)

Parkour: Lessons in Agility - Proceedings for STC Summit 2014