Being Agile with Kano Analysis

Kano and the Agile Project Manager John C Goodpasture Square Peg Consulting www.sqpegconsulting.com johngoodpasture.blogspot.com

Kano and Agile are all about user value
Kano charts user value from ‘ah-hah!’ to ‘don’t care’
‘ Ah-hah!’ is the break-out version of ‘more is better’
‘ More is better’ is group-think race to the top
‘ Indifference’ is yesterday’s ‘ah-hah!’
Agile focus’ on projects where user satisfaction is primary
The product evolves from user experience and adoption
Change is embraced; indeed, encouraged
Value is ‘pulled’ into the market, not pushed
Agile and Kano together bring reality to vision
Kano analysis kicks off envisioning and exploring
Kano ‘ah-hah!’s can be the compelling vision for an agile team
Avoid group-think – it’s not a good place to invest

On the Kano Chart, the upper right quadrant is the place to be! Customer Satisfaction Product Functionality - Quadrant Upper Right Customer Delight Quadrant Upper Left Latent Requirements Quadrant Lower Left Customer dissatisfaction with missing or withheld functions Quadrant Lower Right Customer dissatisfaction with provided functionality Customer Dissatisfaction + - +

Everything loses panache over time! Customer Satisfaction Product Functionality + - M = “must be present” MIB = More is Better Ah = “ah-hah!” In = Indifferent axis MIB decay to M or In Ah decay to In or M Customer Dissatisfaction +

The sweet spot for agile is the ‘ah-hah!’ quadrant
In the ‘ah-hah’ quadrant customers are interested, engaged, and energetic
Early adopters push the ‘ah-hah!’ curve, giving feedback at every iteration
Ah-hahs! will be copied by competitors
Eventually the advantage is lost as ah-hah! becomes ‘me too!’
Customers may not pay attention to In’s or M’s
‘ In’ and ‘M’ must be there, even without customer interest
‘ In’ is the axis for compliance and standards
The more-is-better horserace leads to group-think
The race mesmerizes
MIB’s decay to M’s over time
Other opportunities may be closed out

Agilists pull out the latent requirements
Latent requirements are unknown until revealed by someone else
I’ll know it when I see it
Who knew I needed that?!
Exploratory and envisioning Q&A gets the conversation going
It’s a conversation, not a quiz
The value proposition may be very fuzzy
Prototypes may be needed
Be aware of non-verbal communication
Reduce everything to stories that image the vision
If you can’t draw it, you probably can’t write it!
Frame all the stories with architecture
Every product has architecture!
Make architecture cohesive; keep architecture loosely coupled

From Kano comes the business case
Scope ah-hah! as the project theme
Functional, feature-rich, compelling
Complete the scope with In, M, and MIB
Can’t forget these just because they are not exciting
Estimate the investment
Dollars per team iteration x Story points* / Velocity**
*Total backlog **Story points per team iteration
What does the project benefactor need from the estimate?
Propose benefits at milestones
Who’s in the community of beneficiaries?
What’s their value proposition?
Show value roll-out at milestones
Remember: satisfying the customer is more important than following a plan!

For more…..
Visit www.sqpegconsulting.com for free articles
Search allpm.com & pmi.org for my articles
Read my opinions at johngoodpasture.blogspot.com
And, look for my new book in January 2010
“ Project Management the Agile Way -- Making It Work In the Enterprise”

http://www.johngoodpasture.com	31
http://www.slideshare.net	7
http://johngoodpasture.blogspot.com	1

Being Agile with Kano Analysis

by John Goodpasture on Aug 26, 2009

Accessibility

Categories

Tags

Upload Details

Usage Rights

3 Embeds 39

Statistics

Being Agile with Kano Analysis — Presentation Transcript