Email
Favorite
Favorited ×
Download
Embed
Private Content
Copy and paste this code into your blog or website Copy Customize Close
We have emailed the verification/download link to "".
Login to your email and click the link to download the file directly.

To request the link at a different email address, update it here. Close
Validation messages. Success message. Fail message.

Check your bulk/spam folders if you can't find our mail.

Loading…

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

+ Follow

Adopting A Whole Team Approach To Quality

by Ben Carey on May 29, 2009

2,084 views

A presentation give at Agile Carolinas on some things that I think are needed to build quality software.

More…

A presentation give at Agile Carolinas on some things that I think are needed to build quality software.

The content of the presentation is in the presenter notes.

Less

2 Embeds 553

http://thesherpaproject.com	551
http://www.slideshare.net	2

Statistics

Favorites: 3
Downloads: 27
Comments: 0
Embed Views: 553
Views on SlideShare: 1,531
Total Views: 2,084

Thanks for coming out to the meetup.I want to start out the talk by telling you a short story to let you know what inspired me to put together this talk.
My story begins here, in an Agile team room.I was working with a team that had previously gone from a waterfall methodology and a team of 350 to using agile with a team of about 50.The team that I was working with was developing software for…
… doctors. Well, not just doctors – but specifically for physician’s offices.This includes the physicians, the front office staff, the nurses, and the back office staff.The software was widely used with about 125k physicians using the software and around 500k total users in the US.
Well, one day, someone on our team came to the realization that if we were developing software for physician’s practices, it might be a good idea to go visit one.I thought this sounded like a great idea, so I signed up. I was randomly assigned a few physician practices to visit and I ended up (of all places) in Corbin, Kentucky.This is Corbin.
In Corbin, I visited a fairly typical small practice. There were a husband and wife physician team and a handful of other employees like front office schedulers, a few nurses, and a person responsible for billing.
It was great getting to see how all of those different individuals in the office used our software in a real work environment.It always blew my mind that around half a million people were using our software on any given day.
I had a great time hanging out with the staff during my time that I was there……well, until the last day, when I noticed this…
I was observing Amy doing the end of the week billing cycle. This is where all of the bills are sent out to the insurance companies and the doctors office submit the charges that pay the bills for the practice.Amy was getting noticeably upset while she was using our software. She was trying to do a few routine things – but the software just wasn’t allowing her to get her work done in a way that made sense with how she typically worked. All Amy could tell was that the software wasn’t allowing her to close out the week. She wasn’t sure where she went wrong in aggregating the billings and the end of the day was quickly approaching.Amy usually leaves work at around 4:00 so that she can go and pick up her daughter at school.
Morgan is Amy’s daughter and she had just recently started attending school. She was only a couple of weeks into the school year and although she was having a good time at school, she enjoyed being picked up at the end of the day by her Mom.
As Amy tried and tried to do everything that she could think of to get the billing batch submitted, all she could think of was how lost she was and how she needed to get to school to pick up her daughter.As 4:00 quickly approached, Amy broke down and started crying. She had the pressure of making sure the practice got paid as well as the pressure of getting out of the office to make sure that she was there to pick up her daughter on time.Interestingly, Amy blamed herself for her lack of knowledge of the system.
As 4:00 passed and Amy was working frantically, all she could think of was how upset her daughter was going to be when she wasn’t there to pick her up as class let out.Amy ended up calling a friend to pick up Morgan.
When I went back to the hotel and thought about that day I ended up getting mad and frustrated that this software, the software that we were spending so much money to build, the software that this physician’s practice had spent so much money to buy, let Amy down.This wasn’t Amy’s fault.This was our teams fault.This was my fault.
Our users deserve more than this.Quality shouldn’t be something that we measure at the end. It needs to be continuous. It needs to be baked into everything that we do.To get to the level that quality is a given – everyone needs to be responsible.
If everyone is responsible for quality, then everyone needs to do their part to provide quality software and a quality experience. Your job on your team affects your users in one way or another.In this talk, I want to help you think about things that you can do to improve that quality.
When we focus on building quality software then we end up making everyone happy.Fewer defects, better usability, great experiences, happy users, and (last but not least) – smiling children.
I believe that there are three parts to adopting a whole-team approach quality that will result in building better software.
Let’s talk a bit about Seeing The Whole
There are a few different topics to touch on when I refer to Seeing The Whole.The first topic that I want to discuss is knowing your goal or the product vision.Almost without fail, when I visit any team and I ask them why they are building what they are building, I can never get a consistent answer. Most of the time, the answers have a common basis, but very rarely is there a shared and focused vision for the product that is being created.
At its very essence, the goal or the vision of your product is the answer to “Why are you building this?”Can you answer this question?If you asked everyone on your team, everyone who is involved with your product or service, or everyone throughout the company this question – would they answer it the same?If you feel like you can answer this question, do you really believe in the answer? Is everyone on your team focused on the same answer?Do you have a true understanding of what “this” really is, or is meant to be?
If you have a shared world-view of your answer to this question, then you have established a “True North”The concept of a True North is imperative to building quality software.True North is a contract, a bond, and not merely a wish list.It’s not a marketing slogan. Who are we? What do we believe in? Where are we going? What have we learned?The True North focuses on what is important and keeps us grounded in our decision making. We should constantly be putting our work and making our decisions based on an anchoring to our True North.
The next question that you need to ask yourself is “Who are we building this for?”Do you feel like you really know your users?Do you understand the value that your product or service is delivering through their eyes?
I’m not talking about “understanding your customers” – I’m talking about truly, authentically, deeply understanding your customers.Do you know why they can’t sleep at night? Do you know what they think when they wake up? Do you know their true intentions? Do you know what their desks look like?Do you know what they eat for lunch?Do you know what they think about when they’re driving home from the office?
Saying “As a (role)…” does not mean that you have a true understanding of your customers. I’m not talking about demographics either, 20 – 30yr. old asian female isn’t enough.Who are your users *really*, and what motivates them?In my case - Amy felt an obligation to do the billing. Her true goal wasn’t to do the billing – it was to pick up Morgan from school on time.
Knowing these things about your users lets you practice empathy in it’s purist sense.Your job is to build things that help your users achieve their objectives and accomplish their goals. To be able to do that effectively, you need to know what those things really are.You are viewing the result of your work through the eyes of your customer. When you do this, it’s a very eye-opening experience.
The last element of Seeing the Whole is to understand that it’s not (just) about you. It’s not (just) about your team. There are a variety of other roles, activities, and functions (or dysfunctions) that play into delivering a product or service and you need to understand the elements that allow for your product to go from an idea to generating revenue for your company.
It’s easy to forget the training, the pricing models, the marketing, the maintenance, and the ongoing use of the software when you’re laser-focused on the creation. The truth of the matter is that it is easy to produce sub-optimizations or local efficiencies when your effort and thoughts could be more effective elsewhere. Many local efficiencies result in user nightmares – so understand the overall picture – how the product delivery system functions as a whole – before wasting your thought and effort in places where they might not be needed.
Let’s talk a bit about building the right things
This is the distribution of used features in a typical application.What insights can we draw from this?
Let’s think about this in terms of your backlog.What if you only built the things that were frequently used?
To start with, you can try hanging out with your customers….The best way that I know to do this is to put your users in the center of your process.You can do this by practicing Contextual Inquiry.A customer-centered process requires making an explicit step of understanding who the customers really are and how they work on a day-to-day basis.CI allows you to observe your users in action in their natural environment. I’ve been involved in dozens of visits and I promise you that every single one was worth the time and effort.
Feedback is another huge way that we can build the right things.This thing we have called Scrum does a wonderful job of providing feedback loops and inspect and adapt cycles everywhere. How about we use that 
You can integrate your users easily by doing paper prototypes and other quick and focused testing.
You can build community.Let your users get as close to you as possible and help drive your priorities.Listen to what they have to say (although you might not want to do what they suggest).Listen to understand.
You should also change direction when it’s justified.If the feedback is radically different than what we expected, we might even completely change our service, product, or business model.
Start with no, you don’t want to be a yes-man.Listen to your customers – but make conscious decisions. You don’t always need to make a faster horse.
Let’s talk a bit about building things right
To build things right, we need to build quality into the software.How can we do that?
For us to truly take a quality-focus, we have to unlearn the assumptions that we have about testing practices.
We have to rethink our approaches to building software.
A great area to start is to focus on the TPS concept of poka-yoke.
Poka-yoke means mistake proofing.
Example of Poka-yoke.
We should start by pulling testing fully forward.We need to move into a prevention mindset, instead of a fix mindset.
Take a bit and talk about each of these.
POVIt is my job, it is your job, it is our job –to deliver quality software and a quality experience.Do it for yourself, do it for your users, do it for Amy, do it for Morgan.
These are the majority of the things that I talked about tonight.You don’t need all of these to build better software and there are many more that you might use that weren’t talked about tonight.If you implement just one or two of these items then you’ll be on the right path to building better products and providing better experiences.
Take 3 minutes.Think about your product or service.Think about your role on your team.Think about your users or your customers.Think of one thing that you can commit to doing – that you aren’t doing – that would make your users smile.Take an index card and a sharpie and write that one thing down.Share (ask for volunteers). Fold them up and put them somewhere safe. Work on your item and inspire others to do the same.

3 Favorites

Rally Software at Rally Software 2 years ago
Lane Halley , Product designer and UX coach for Agile and Lean Startup teams 2 years ago
J D , Manager at Other Tags software 2 years ago

Adopting A Whole Team Approach To Quality — Presentation Transcript

Adopting A Whole-Team Approach To Quality.
Our users deserve better than this.
What can we do?
Destination
3 parts 1. See the whole. 2. Build the right things. 3. Build things right.
1. See the whole.
Why are we building this?
Who are we building this for?
The real goal.
em-pa-thy noun. the ability to understand and share the feelings of another.
2. Build the right things.
What percentage of software is frequently used?
What percentage of software is occasionally used?
What percentage of software is never or rarely used?
64% 20% 16%
Your Backlog From: To: $1m Cost $200k Cost 12 Months Effort 2.4 Months Effort 100 Stories 20 Stories
How do we build the right things?
Daily Scrum Sprint Product Sprint Backlog Backlog Product Increment
Start With No “ Make features work hard to be implemented. The secret to building half a product instead of a half-ass product is saying no. - 37Signals (from Getting Real)
3. Build things right.
How do we build in quality?
un:learn
re:think
mistake proofing
Start testing here… … instead of here
We Get There Through… Acceptance Criteria Automated Acceptance Testing Test-Driven Design Automated Unit Testing Continuous Integration Continuous Governance
Our users deserve great (quality) software.
Sit together Have acceptance criteria See the whole Automated acceptance testing Have a vision Test-drive design Find “true north” Automate unit testing Know (really know) your users Continuous integration Practice empathy Continuous governance Avoid local efficiencies Use systems thinking Build the right things Focus on the 20% Hang out with users Use Contextual Inquiry Lo-fi usability testing Paper prototypes Leverage your feedback loops Build communities Listen to your users Start with “no” Build in quality Mistake-proof
Ben Carey Agile Coach @ Rally Software ben.carey@rallydev.com www.thesherpaproject.com http://twitter.com/bencarey
Attribution http://en.wikipedia.org/wiki/File:Snellen_chart.svg - Jeff Dahl http://www.flickr.com/photos/wisdoc/2799750403 - WisDoc http://www.flickr.com/photos/thomashawk/229516213 - Thomas Hawk http://www.flickr.com/photos/bookgrl/3193199682 - bookgrl http://www.flickr.com/photos/solyoung/2503383819 - SolYoung http://www.flickr.com/photos/rosefirerising/1175879764 - RoseFireRising http://www.flickr.com/photos/missizss/2470738904 - ~ezs http://www.flickr.com/photos/cesarastudillo/1275797028 - cesarstudillo http://www.flickr.com/photos/frances1972/2247431698 - Frances1972 http://www.flickr.com/photos/ex_magician/2867480911 - Ex Magician http://www.flickr.com/photos/lachlanhardy/3283320402 - Lachlan Hardy http://www.flickr.com/photos/37872410@N00/3146253560 - toml1959 http://www.flickr.com/photos/mkmabus/2988760669 - The Doctr http://www.flickr.com/photos/notjake13/2574325874 - JacobEnos

Adopting A Whole Team Approach To Quality

by Ben Carey on May 29, 2009

Accessibility

Categories

Tags

Upload Details

Usage Rights

2 Embeds 553

Statistics

Adopting A Whole Team Approach To Quality — Presentation Transcript