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

Being Agile, Being Good

Embed Size (px)

Citation preview

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