1. Southern Fried Agile, 15 October 2015
Build the right thing:
User-Centered Agile in a Highly Regulated Business
Hijack your project gating process: User Centered Agile in a highly regulated corporation
Presented by Mark Ferencik and Paul Smith
Southern Fried Agile, 15 October 2015
Mark Ferencik
Paul Smith
June 2015

2. How Blended Agile emerged Why our organization embraces it
Why Blended Agile?
Our background
How Blended Agile emerged
Why our organization embraces it
The benefits of the approach
Copyright 2015 – Paul M Smith, Mark Ferencik

3. Development model that plans for change
Blended Agile
Just enough detail to avoid refactoring
Development model that plans for change
Gate 1
Gate 2
-25%/+75%
+/-10%
Copyright 2015 – Paul M Smith, Mark Ferencik

4. Building the right thing
Refining the Agile process
A pure Agile technique speeds up development …
but … 3x quicker code can
still miss the true need
This is about building the right thing
How can you have deep assurance
you will build the right thing
early in the design process?
Graphic courtesy of Cary Milsap, “My Case for Agile”
Copyright 2015 – Paul M Smith, Mark Ferencik

5. Success Rates of Software projects
Does agile adoption increase software project success?
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.
The success and failure rates of software projects according to The Standish Group’s industry survey (1994; 2012)
Copyright 2015 – Paul M Smith, Mark Ferencik

6. I did exactly what they told me to do!
Is this a successful project?
From CakeWrecks.com
Copyright 2015 – Paul M Smith, Mark Ferencik

7. The high cost of refactoring$1 $8
$64
$512
Code
Mockup 8x
Sketching
Taskmap Notes
- Refactoring is very costly – changing code is the most expensive place to make changes
- Sketches are much cheaper and you can test with these
You may only have a couple of chances before your customers move on to another solution (app store)
- Contracting out development work – the cycle time to do code changes has increased
- Large organizations without in place teams – pulls you back from Agile
- Success from a vendor is measured by on time, on budget and defect count, not how useful it is 8x 8x
Copyright 2015 – Paul M Smith, Mark Ferencik

8. Is Agile created software more useful?
Use of Features & Functions
Features & functions actually used went down!
Standish Group Chaos Report: Study of 2000 projects at 1000 companies Standish Group Chaos Manifesto 2013

9. How did we get a large risk averse IT organization to move to Agile principles?
600+ pages
Over 5 lbs!
Our journeys
Mark then Paul
Copyright 2015 – Paul M Smith, Mark Ferencik

10. Has Agile jumped the shark?

11. Are you listening to the right people?
Have you spoken to your actual customers?
That’s all well and good, but here’s what the users really want …
Copyright 2015 – Paul M Smith, Mark Ferencik

12. 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.

13. Gather information from actual users: The Task Directed Protocol
Interview questions
Task List
Task Details
Wrap up
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 Description
Who’s it for?
What business need does it solve?
How often do you do this?
How important is it? (1-5)
Create a contract propo
Contract review team
Let’s the company evaluate the best
weekly 5
Update the prop
Records the contract
Task Directed Protocol
“Tell me what you do. Pretend I’m your neighbor who does not understand the jargon.”
Task Details and follow up questons
Follow up question 1
Follow up question 2
Follow up question 3
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
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

15. How many people is enough to usability test a design?
Five (but it depends on how frequently the problem occurs)
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.
Copyright 2015 – Paul M Smith, Mark Ferencik

16. Structure of a taskmap
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.
Account Manager
User group 2
User group 3
User group 4
Need
Task 1 to meet the need
Task 2 to meet the need
Task 3 to meet the need
Need
Task 1 to meet the need
Task 2 to meet the need
Task 3 to meet the need
Order of needs
Develop account strategy
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

17. Sketchboarding

18. 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.

19. Intuitive solutions increase use over time and decrease long term costs of replacing solutions
We avoid this
The intuitive solution feels easy,
we like it,
we will use it
and we will not ask for it to change much. We won’t seek Phase 2 projects to fix it
The non-intuitive solution is the kind of solution users seek to avoid, ask for changes more frequently,
ask to replace as early as possible which saves us from having to respond with phase 2 projects to fix the interface
So how do we get to the intuitive solution?
In the last session we talked about understanding and confirming that the needs and tasks are well understood before moving into this phase.
That’s how we figure out the mental model, the line
That intuitive approach may involve many features that contribute to the overall experience – which we maybe can’t build or buy all at once.
And the majority of the time you won’t be able to match the existing path perfectly – there may be a lot of tradeoffs
But you want the overall solution to meet those needs as well as possible – that involves looking ahead to solutions that meet the overall needs best…
We gladly use this
Copyright 2015 – Paul M Smith, Mark Ferencik

20. Working with an ideal goal in mind
Blended Agile `
Unused
Features
Value
Scrum
Time
Copyright 2015 – Paul M Smith, Mark Ferencik

21. We Can Change The Balance
Maximum Use of Features & Functions
WRAP UP
- WHERE ARE NOW
 "Simplicity–the art of maximizing the amount of work not done–is essential."
Standish Group Chaos Manifesto Agile Manifesto 2001
Copyright 2015 – Paul M Smith, Mark Ferencik

22. Thank you for your time today!
Mark Ferencik
Paul Smith