Top Banner
Being Agile, Being Good Stephanie Troeth Paris Web, 2009
72

Being Agile, Being Good

Jan 29, 2018

Download

Technology

stephtroeth
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: Being Agile, Being Good

Being Agile, Being Good

Stephanie TroethParis Web, 2009

Page 2: Being Agile, Being Good

Stephanie Troethco-founder/CTO, Book Oven

Previously:✦ UX consultant and mercenary

product manager for startups✦ Director of Interactive Technology

at an agency

What I don’t get paid for:✦ Web Standards Project (WaSP)

member since 2002 ✦ WaSP InterAct

✦ Open Web Education Alliance

Page 3: Being Agile, Being Good

Meeting point: agile & quality

Page 4: Being Agile, Being Good

“Agile” is not a single solution, but is a group of software

development methodologies that share the same core

principles.

Page 5: Being Agile, Being Good

An Agile Approach— “Agile Estimating & Planning”, Mike Cohn

Page 6: Being Agile, Being Good

Work as a team.

Page 7: Being Agile, Being Good

Work in short iterations.

Page 8: Being Agile, Being Good

Deliver something each iteration.

Page 9: Being Agile, Being Good

Focus on business priorities.

Page 10: Being Agile, Being Good

Inspect & adapt.

Page 11: Being Agile, Being Good

Compared to the familiar waterfall:

less documentationless “fixed” processless (long term) planning= perceived chaos

Page 12: Being Agile, Being Good

The philosophy behind agile is that you never start with a

perfect plan.

Page 13: Being Agile, Being Good

It is a method for dealing with the unknown, and to

use new knowledge to guide ongoing work.

Page 14: Being Agile, Being Good

Quality: what is it?

Page 15: Being Agile, Being Good

It is easy to think that quality results from a process.

Page 16: Being Agile, Being Good

It is easy to think that quality results from a process.people

Page 17: Being Agile, Being Good

“The best teams didn’t have a methodology or dogma they followed.

The struggling teams often tried following a methodology, without success. [...]

The best teams all focused on increasing the techniques and tricks for each team member.”

— Jared Spool & User Interface Engineeringhttp://www.slideshare.net/jmspool/journey-to-the-center-of-design

Page 18: Being Agile, Being Good

“But if Quality and excellence is seen as the ultimate reality then

it becomes possible for more than one set of truths to exist.”

— “Lila”, Robert M. Pirsig.

Page 19: Being Agile, Being Good

Quality is relative.

Page 20: Being Agile, Being Good

what is valuable to me !=what is valuable to you.

Page 21: Being Agile, Being Good

Apply this to a team scenario:

what a designer deems as quality != what a developer deems as quality !=

what a project manager deems as quality ...etc.

Page 22: Being Agile, Being Good

So how does a team define quality, if we all have different

and often contradictory ideas of “what is good”?

Page 23: Being Agile, Being Good

1. The Stealth Method: Foster a strong team culture that thirsts for quality.

Page 24: Being Agile, Being Good

Understand what each other needs to succeed...

Page 25: Being Agile, Being Good

... so each of us can take pride in what we do.

Page 26: Being Agile, Being Good

Pride is a big motivator.

Page 27: Being Agile, Being Good

2) The Measurable Method:Instill a quality vision as a belief system.

Page 28: Being Agile, Being Good

A belief system is stronger than any process.

Page 29: Being Agile, Being Good

Empower members in your team.

Enable them to decide what is the right thing to do.

Page 30: Being Agile, Being Good

A quality vision definition:

✦ generic enough so that it can be interpreted in each context

✦ specific enough so it contains a clear vision

Page 31: Being Agile, Being Good

An example of a quality vision

✦ accessible

✦ aesthetic

✦ usable

✦ measurable

✦ findable

✦ interoperable

✦ relevant

✦ robust

✦ secure

✦ cost-effective

✦ scalable

✦ refactorable

✦ valuable

90% of sites we produce should be

Page 32: Being Agile, Being Good

An example of a quality vision

We want our product to be usable, easy and delightful to use for our target audience.

Page 33: Being Agile, Being Good

Use a quality vision to decide:✦ what level of training all team members need

✦ what level of work is globally expected from them

✦ enable them to decide the right thing to do.

Page 34: Being Agile, Being Good

Hire wisely.

Page 35: Being Agile, Being Good

Tips, tricks & (some) techniques

Page 36: Being Agile, Being Good

Use user stories

As a user I would like to see the history of a page so I can work out who did what.

Page 37: Being Agile, Being Good

“A user can pay for access with a credit card.”

✦ Test with Visa, MasterCard and American Express.✦ Test with Diner’s Club.✦ Test with good, bad and missing card ID numbers✦ Test with expired cards.✦ Test with different purchase amounts (including

one over the card’s limit).

A user story with acceptance test cases:

— “User Stories Applied”, Mike Cohn

Page 38: Being Agile, Being Good

User stories:✦ provide a user-oriented approach to defining

requirements

✦ break the task of building into estimable chunks

✦ facilitate a discussion about what we’re building

✦ make it easy to prioritize what’s important to build

Page 39: Being Agile, Being Good

User stories:✦ allow team members to interpret requirements

✦ allow team individuals to take ownership of the solution

✦ are testable

✦ means no more 200+ pages of specifications!

Page 40: Being Agile, Being Good

Trick:Document only as needed,

especially decisions.

Page 41: Being Agile, Being Good

Estimation & planning

Page 42: Being Agile, Being Good

Method #1: Relative story points

Page 43: Being Agile, Being Good

Assign relative points to each story.

As time progresses, you get a better idea of your burn rate based on your team’s velocity.

Page 44: Being Agile, Being Good

Assign relative points to each story.

As time progresses, you get a better idea of your burn rate based on your team’s velocity.

Page 45: Being Agile, Being Good

Method #2:The 4-hour bucket model.

Page 46: Being Agile, Being Good

Split your stories so that they fit in an approximate half-day slot.

Some will be bigger, some smaller, but eventually they balance out.

Page 47: Being Agile, Being Good

Trick:Let your team own the

task of estimating.

Page 48: Being Agile, Being Good

Evaluate: are we too optimistic or too pessimistic?

Rinse & repeat.

Page 49: Being Agile, Being Good

Design & User Experience

— “12 emerging best practices for adding UX to agile development”, Jeff Pattonhttp://agileproductdesign.com/blog/emerging_best_agile_ux_practice.html

Page 50: Being Agile, Being Good

Agile methodology states: everything happens in the

same iteration.

Page 51: Being Agile, Being Good

But as a designer or a UX specialist, what do you

need to succeed?

Page 52: Being Agile, Being Good

Designers need time to research, and to synthesise product and visual design.

Page 53: Being Agile, Being Good

Trick:“Work ahead & follow behind”

— #4, “12 emerging best practices for adding UX to agile development”, Jeff Patton

Page 54: Being Agile, Being Good

Quality Assurance

Page 55: Being Agile, Being Good

There’s no magic: Make time to care.

Page 56: Being Agile, Being Good

Employ test-driven design and development.

Page 57: Being Agile, Being Good

Method #1:Hire a QA person or team.

Page 58: Being Agile, Being Good

Method #2:Set aside QA and refactoring days.

Page 59: Being Agile, Being Good

Trick: Keep, reuse and add to a

comprehensive list of all use cases or user stories that must pass

before each release.

Page 60: Being Agile, Being Good

Quality doesn’t need to be assured, it needs to be

cultivated.

Page 61: Being Agile, Being Good

Why do we insist on quantifying quality?

Page 62: Being Agile, Being Good

Good work comes from good habits.

Page 63: Being Agile, Being Good

A vision that allow your team members to judge critically is

more powerful than any process.

Page 64: Being Agile, Being Good

Identify accountability.

Page 65: Being Agile, Being Good

Identify what each other need in order to succeed.

Page 66: Being Agile, Being Good

The agile approach encourages good habits but

it’s up to your team to decide what you collectively

want to be.

Page 67: Being Agile, Being Good

Empower your team.

Page 68: Being Agile, Being Good

Give each other a sense of pride.

Page 69: Being Agile, Being Good

What do monkeys, a banana, and a web team have in common?

Page 70: Being Agile, Being Good

Quality should be the way that it has always been done.

Page 72: Being Agile, Being Good

http://www.flickr.com/photos/dariuszka/264054626/http://www.flickr.com/photos/johncarleton/16083172/http://www.flickr.com/photos/32912172@N00/3369828460/http://www.flickr.com/photos/cryztalvisions/343309195/http://www.flickr.com/photos/mostudio/2384804297/http://www.flickr.com/photos/mknott/3642179597/http://www.flickr.com/photos/66164549@N00/2789668253/http://www.flickr.com/photos/boojee/29777131/http://www.flickr.com/photos/72213316@N00/3570803663/http://www.flickr.com/photos/telstar/3174467026/http://www.flickr.com/photos/76283671@N00/184612846/http://www.flickr.com/photos/psd/3731275681/http://www.flickr.com/photos/totalaldo/http://www.flickr.com/photos/sfllaw/302647234/

With thanks