Cut stakeholder features that your customers corporation...

Hijack your project gating process:

User Centered Agile in a highly regulated corporation

June 2015

Presented by Paul Smith and Mark Ferencik

Double Your IT dollar

Cut stakeholder features that your customers don't need

Mark [email protected]

Paul M Smith [email protected]

Why Blended Agile?

Copyright Mark Ferencik and Paul M Smith 2015 2

•50% of software features are never used

•We will show how to use metrics to focus only on what is needed

•Agile helps projects be successful but it is not enough

Building the right thingRefining the Agile process

Copyright Mark Ferencik and Paul M Smith 2015 3

Graphic courtesy of Cary Milsap, “My Case for Agile”

A pure Agile technique speeds up development … but … 3x quicker code can still miss the true need

This is about building the right thing

http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&ved=0CC4QFjABahUKEwjgj82SgLbIAhXIVh4KHY3KD54&url=http%3A%2F%2Fmethod-r.com%2Fpapers%3Fdownload%3D96%3Amy_case_for_agile&usg=AFQjCNGGBEhpM_aWALq9xYKc5e7fn-vW1w

Waiter or Doctor?

Copyright Mark Ferencik and Paul M. Smith 2015

Success Rates of Software projectsDoes agile adoption increase software project success?

6

The success and failure rates of software projects according to The Standish Group’s industry survey (1994; 2012)

– Successful projects – delivered on-time, on-budget, and with the planned features.

– Challenged projects – either: over time, over budget, or lacking features.

– Failed projects – the project was abandoned.

1994

Challenged 53%

Failed 31%

Success 16%

2012 Waterfall

Challenged 57%

Failed 29%

Success 14%

2012 Agile

Challenged 49%

Failed 9%

Success 42%


Is Agile created software more useful?Use of Features & Functions

7

Standish Group Chaos Report: Study of 2000 projects at 1000 companies. 2002Standish Group Chaos Manifesto 2014

Features & functions actually used went down!

2002

Never Used, 45%

Rarely, 19%

Sometimes, 16%

Often, 13%

Always, 7%

2014

Hardly Ever, 50%

Rarely, 30%

Infrequently 20%


https://www.standishgroup.com/files/Exceeding%20Value_Layout4.pdf



Are you listening to the right people?

8

That’s all well and good, but here’s what the users

really want …

Have you spoken to your actual customers?


I did exactly what they told me to do!Is this a successful project?

9

From CakeWrecks.com


Blended Agile

10

Just enough detail to avoid refactoring

Development model that plans for change

User StoriesEpics

+/- 50% +/-10%


Gemba – Go to the real work

– What do they really do?– What are the impacts of their environment?– Build a connection with them so you understand them and they trust you.

11


Gather information from actual users:The Task Directed Protocol

Task Directed Protocol

What do you think is working well?

What are the most important things to change about the current process/tool?

Are there any key things you think we should keep in mind as we move forward?

Would you be willing to participate in the future

Thank you for your time

Task Descrip

tion

Who’s it for?

What business

need does it solve?

How often

do you do

this?

How importan

t is it? (1-

5)

Create a contract propo

Contract review team

Let’s the company evaluate the best

weekly

5

Update the prop

Contract review team

Records the contract

weekly

5

Task Directed Protocol“Tell me what you do. Pretend I’m your neighbor

Don’t assume they are using a term the way you

How many others do what you do?

Any other high level questions you need to know

Task Directed Protocola) “Tell me what you do. Pretend I’m your

neighbor who does not understand the jargon.”

Task Directed Protocola) “Tell me what you do. Pretend I’m your

neighbor who does not understand the jargon.”

Task Directed ProtocolTask Details and follow up questonsFollow up question 1Follow up question 2Follow up question 3

Interview questions Task List Task Details Wrap up

- Introduction- Frame the discussion - What is your job (pretend I’m a neighbor who doesn’t know the jargon)- How many others?

- Gather list of the tasks they do in the frames topic- Measure frequency and importance- Who is it for?- What business need is accomplished?

- One per task (stack at your disposal)- Capture the path- Decisions along the way- Critical data used for completing the task.

- Open questions to gather any broad feedback.- What works well?- What doesn’t?- Ask for their involvement on future steps.- Capture benefits


How many people is enough to usability test a design? Five (but it depends on how frequently the problem occurs)

13

• Percentage of usability problems discovered while testing on an individual basis• Nielsen advocates that 5 is enough • Jeff Sauro explains it depends on the frequency that the problem occurs.


http://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/



http://www.measuringu.com/five-users.php

Structure of a taskmap

Account Manager

Develop account strategy

User group 2 User group 3 User group 4

Need Need Need

Task 1 to meet the need







Need



Agile User Story format: As a [user] I need to [task] so that I can [need].

Taskmapping breaks apart the stories to understand the flows and relationships.

Need



Need




Order of needs

Identify goals of the account from account’s perspective

Identify key people to achieve goal of opportunity

Tactics of actions to achieve the goals over next 12 months

Order of tasks per need


Sketchboarding

15


Test a mockup with real users as early as possible

– Users are 5x more likely to fail a task if they don’t find the right path the first time.

– Most significant usability problems are connected to the navigation structure which a quick mockup will flush out.

http://www.measuringu.com/blog/first-choice.php




Intuitive solutions increase use over time and decrease long term costs of replacing solutions

We gladly use this

We avoid this

Copyright Mark Ferencik 2015

The high cost of refactoring

18

Taskmap Notes

Sketching

Mockup

Code

8x 8x 8x

$1 $8 $64 $512


Val

ue

Time

Scrum

Ideal

Blended Agile

Working with an ideal goal in mind

Whole picture design gains


We Can Change The BalanceMaximum Use of Features & Functions

20

Standish Group Chaos Report findings 2014 Agile Manifesto 2001

"Simplicity–the art of maximizing the amount of

work not done–is essential."

The Goal

Rarely, 25%

Used 75%


2014

Hardly Ever, 50%

Rarely, 30%

Infrequently 20%







Thank you for your time today!

21


How did we get a large risk averse IT organization to move to Agile principles?

Copyright Paul M Smith 201522

600+ pages

Over 5 lbs!

The Steps Can be Broken Into A Backlog

23


Maximize your impact, not code produced


Cut stakeholder features that your customers corporation...

Documents

Transcript of Cut stakeholder features that your customers corporation...