Parkour: Lessons in Agilit - Proceedings for STC Summit 2014

© 2014 Autodesk

Parkour: Lessons in Agility

Karen Smith and Patty GaleAutodesk, 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!


ChallengesContent 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 01. Teamwork is important2. Build strong working relationships3. Communicate4. Let go of old things5. Try new things6. Be flexible7. Find your balance8. Don’t stress if you don’t have all the answers9. Focus on customers10.Continuously look for ways to improve11.Reward desired behavior12.Make it fun

Lessons Learned: Summary


Agile Manifestohttp://agilemanifesto.org/

Introduction to Agile Methodologieshttp://ffeathers.wordpress.com/2011/02/26/introduction-to-agile-methodologies/

Agile for Technical Writershttp://agilescout.com/agile-guide-agile-for-technical-writers/

A Writer's Guide to Surviving Agile Software Developmenthttp://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

http://agilemanifesto.org/

http://agilemanifesto.org/

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

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

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

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





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


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.