Agile lean workshop

LEAN-AGILE-TDD TUTORIAL/WORKSHOP

AGILITY AND POWER TO OUR TEAM

AGENDA

• WHY & OBJECTIVES & ABOUT (5)• AGILE AND LEAN PRINCIPLES (10)• TDD, SCRUM, KANBAN (15)• STORY AND TASK (15)• AGILE EXPERIENCE (60)

• STORY WRITING, VALUE AND EFFORT ESTIMATE, PLANNING, EXECUTION, REFLECTION… • WRAP UP, Q&A ETC. (15)

WHY?

HOW?

OBJECTIVES

• GET IN SYNC ON AGILE PRINCIPLES AND COMMON PRACTICES• WHY, WHAT, HOW• CONCEPTS AND TERMINOLOGIES

• GET IN SYNC ON A DESIGN GOING FORWARD• COMING UP WITH *A DESIGN*• EVOLVE THE DESIGN

INTRO

• FORMAT• TALK + DISCUSSION (TIME BOXED < 5 MIN)• SIMULATION EXPERIENCE – A SPRINT IN 60 MINUTES

• ABOUT ME• 10 YEARS OF AGILE EXPERIENCES (PLUS OF COURSE CRAFTSMAN, WATERFALL)

• FORMS: XP, SCRUM, KANBAN, SCRUMBAN …• TOOLS: XPLANNER, SCRUM BOARD, JIRA, WIKI, VERSION ONE, CUSTOM APP...

• ROLES: SDE/ARCHITECT, SCRUM MASTER, PRODUCT OWNER, MANAGER, CUSTOMER

AGILE PRINCIPLES

• CUSTOMER SATISFACTION BY EARLY AND CONTINUOUS DELIVERY OF VALUABLE SOFTWARE

• WELCOME CHANGING REQUIREMENTS, EVEN IN LATE DEVELOPMENT

• WORKING SOFTWARE IS DELIVERED FREQUENTLY (WEEKS RATHER THAN MONTHS)

• CLOSE, DAILY COOPERATION BETWEEN BUSINESS PEOPLE AND DEVELOPERS

• PROJECTS ARE BUILT AROUND MOTIVATED INDIVIDUALS, WHO SHOULD BE TRUSTED

• FACE-TO-FACE CONVERSATION IS THE BEST FORM OF COMMUNICATION (CO-LOCATION)

• WORKING SOFTWARE IS THE PRINCIPAL MEASURE OF PROGRESS

• SUSTAINABLE DEVELOPMENT, ABLE TO MAINTAIN A CONSTANT PACE

• CONTINUOUS ATTENTION TO TECHNICAL EXCELLENCE AND GOOD DESIGN

• SIMPLICITY—THE ART OF MAXIMIZING THE AMOUNT OF WORK NOT DONE—IS ESSENTIAL

• BEST ARCHITECTURES, REQUIREMENTS, AND DESIGNS EMERGE FROM SELF-ORGANIZING TEAMS

• REGULARLY, THE TEAM REFLECTS ON HOW TO BECOME MORE EFFECTIVE, AND ADJUSTS ACCORDINGLY

Frequent, effective communication to keep on doing the right things

Faster looping for faster feedbacks

Constant evolving design to maximize productivity

LEAN PRINCIPLESDrive from business valueSmall increments

Make all work visible

LEAN-AGILEVisibility – see the value stream

Flow design• Limit work to capacity, Manage work in progress, Remove delays

Built-in quality

COMPUTING BUSINESS VALUE

• A) POTENTIAL GAIN/LOSS• B) EXPECTED GAIN/LOSS (WITH PROBABILITY)• VALUE SCORE = A*B• IN REALITY – IT’S NOT AN EXACT NUMBER, BUT A ROUGH-ORDER-OF-

MAGNITUDE ESTIMATE

Getting better at what you

do

Eliminating delay

between what you

do

WHICH GIVES YOU BETTER RETURN?

TDD – SCRUM – KANBAN TEST-DRIVEN DEVELOPMENT WITH SCRUM/KANBAN

WHAT IS TDD – TEST-DRIVEN DEVELOPMENT?

• A SOFTWARE DEVELOPMENT PROCESS THAT RELIES ON THE REPETITION OF A VERY SHORT DEVELOPMENT CYCLE: • REQUIREMENTS ARE TURNED INTO VERY SPECIFIC TEST CASES, • THEN THE SOFTWARE IS IMPROVED TO PASS THE NEW TESTS, *ONLY*.

• THIS IS OPPOSED TO SOFTWARE DEVELOPMENT THAT ALLOWS SOFTWARE TO BE ADDED THAT ISN'T PROVEN TO MEET REQUIREMENTS.

WHAT WE NEED DO

• KEEP THE END (GOAL) IN MIND• WRITING TEST CASES HELPS A LOT

• FORCING COMMUNICATION• WHAT TEST CASES ARE NEEDED

• KEEP IMPROVING• REFACTORING / EVOLVING

TYPICAL SOFTWARE DEVELOPMENT

SCRUM

• ACCEPT REALITY – SOFTWARE DEVELOPMENT IS *NATURALLY* CHAOTIC• CONTROL MANAGE CHAOS• USING – SCRUM

• PEOPLE• THINGS• BEHAVORS

SCRUM

KANBAN

STORY AND TASKCLEARLY DEFINE STORIES AND TASKS

WRITING USER STORIES

• BASIC FORMAT• AS A {ROLE}, I WANT {SOME GOAL}, SO THAT {BUSINESS VALUE}

• TWO MORE THINGS• VALIDATION STRATEGY (METHOD)• VERIFICATION CRITERIA (METRICS)

EXAMPLE

• USER STORY: AS AN IA, I WANT TO EXPLORE (FILTER) FREELY ON ALL CUBE DIMENSIONS OF A RANGE OF MEASURES (INFLATION, SLACK, REAL FX ETC.) SO THAT I CAN BE MORE PRODUCTIVE TO SPOT ANY POTENTIAL CORRELATIONS TO FORMULATE A SIGNAL.

• VALIDATION STRATEGY: I WANT TO HAVE AN EASY-TO-USE APPLICATION THAT ENABLE ME TO SEARCH AND FILTER ON DIMENSIONS (COLUMNS) OF DATA FAST

• VERIFICATION CRITERIA: • THE APPLICATION NEED HAVE LESS THAN 10 CHOICES IN OPTIONS DURING EVERY STEP• RESPONSE TIME SHOULD BE WITHIN 5 SECONDS• OTHER SLAS…

USER VS DEVELOPER STORY

• OFTEN USER STORIES ARE TOO BIG • AND REQUIRE SEVERAL DEVELOPERS/TEAMS TO DO

• NEED SPLIT INTO SMALLER PIECES – DEVELOPER STORIES• WE CAN HAVE BOTH OF THEM IN JIRA

MODEL STORIES NEED BE ESTIMATED IN JIRA

EPICS • USER STORIES

STORIES

• DEVELOPER STORIES

TASKS• SMALLER

BITE-PIECE WORK

SUB-TASKS

•RELATED WORK NEED BE DONE SEPARATELY

STORY POINTS ESTIMATION

EPICS AND STORIES ESTIMATION

EPICS – PO & LEADS• 100 - SMALL• 200 - MEDIUM• 300 – LARGE• 500 – X-LARGE• 800 - HUGE• X - EXTREME

STORIES – PO & TEAM• 1 - TINY• 2 - SMALL• 3 – MEDIUM• 5 – LARGE• 8 – X-LARGE• 13 - HUGE• U - UNKNOWN

TASKS

• ALL TASKS NEED BE NECESSARY TO STORIES – NO NICE-TO-HAVES - KISS• NEED HAVE TEST TASKS• AND DOCUMENTATION / HAND-OFF / TRAINING• RESEARCH TASKS NEED BE TIME-BOUND

• USUALLY OUTPUT A REPORT• BUGS ARE NOT TASKS

• BUT BUG FIXING CAN BE PUT IN A STORY• TASKS DO NOT HAVE POINTS – THEY ARE EXPECTED TO BE DONE IN 1 REAL DAY (NOT IDEAL

DAY)

EXPERIENCEDESIGNING AN EFFECTIVE PARKING SYSTEM

EPICS: WHAT CAN BE DONE

• ARCHITECTURE (FLOOR PLAN), IN/OUT• LOCATION• ALLOCATION SPACES

• GUEST/VISITOR, HANDICAP, RESERVED, SERVICE, MOTORCYCLES BIKES, EXECUTIVE …• ACCESS CONTROL• OPERATION• PRICING• MULTIPLE GARAGES?

WHERE DO YOU START?

• BUSINESS VALUE / ROI• BANG OF BUCK• NOW ESTIMATE EPICS

STORIES IN AN EPIC

• WRITE STORIES• AS [], I WANT [], SO THAT {}• VALIDATION STRATEGY• VERIFICATION CRITERIA

• NOW ESTIMATE STORIES

TASKS

• WRITE TASKS• INCLUDING RESEARCH AND SUB TASKS

• REVIEW THEM• NOW RE-ESTIMATE STORIES

REVIEW A STORY

• CUSTOMER (OR REPRESENTATIVE – P.O. / PRODUCT MANAGER) MUST BE PRESENT

• ACCEPT / REJECT• CAN ACCEPT WITH BUGS TO FIX• CAN ALSO SPLIT STORY INTO TWO (NOT RECOMMENDED, BUT SOMETIMES

UTILIZED)

REFLECTIVE

• WHAT WENT WELL• WHAT NEED IMPROVE• ACTION ITEMS

WRAP UP, Q&APLEASE COMPLETE THE POLL

CREDITSALAN SHALLOWAY, J. A. FARR., SHORE LABS, CARBON FIVE, IVANATERRORBULL,

AGILE MINDS, TECHWELLPRESENTATIONS, FRANCESCO MAPELLI, BRIAN RUSMUSSEN