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 mark.ferencik@gmail.com Paul Smith paulagilesmith@gmail.com June 2015

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

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

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

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

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

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

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. 2002 Standish Group Chaos Manifesto 2013

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

Has Agile jumped the shark?

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

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.

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

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

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

Sketchboarding

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

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

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 2013 Agile Manifesto 2001 Copyright 2015 – Paul M Smith, Mark Ferencik

Thank you for your time today! Mark Ferencik mark.ferencik@gmail.com Paul Smith paulagilesmith@gmail.com