This document outlines the agenda and content for a workshop on Lean-Agile-TDD principles and practices. The agenda includes introductions, discussions of Agile and Lean principles, Test-Driven Development (TDD), Scrum and Kanban methodologies, user story writing, effort estimation, and a hands-on Agile experience simulation. The workshop aims to get participants aligned on common Agile concepts and practices through explanation, examples, and an interactive experience planning and executing a sprint.

1. LEAN-AGILE-TDD
TUTORIAL/WORKSHOP
AGILITY AND POWER TO OUR TEAM

2. 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)

3. WHY?

4. HOW?

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

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

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

8. Frequent, effective communication to keep on
doing the right things
Faster looping for faster feedbacks
Constant evolving design to maximize
productivity

9. LEAN PRINCIPLES
Drive from business value
Small increments
Make all work visible

10. LEAN-AGILE
Visibility – see the value stream
Flow design
• Limit work to capacity, Manage work in progress, Remove delays
Built-in quality

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

21. Getting better
at what you do
Eliminating
delay between
what you do
WHICH GIVES YOU BETTER RETURN?

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

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

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

30. TYPICAL SOFTWARE DEVELOPMENT

31. SCRUM
• ACCEPT REALITY – SOFTWARE DEVELOPMENT IS *NATURALLY* CHAOTIC
• CONTROL MANAGE CHAOS
• USING – SCRUM
• PEOPLE
• THINGS
• BEHAVORS

32. SCRUM

33. KANBAN

34. STORY AND TASK
CLEARLY DEFINE STORIES AND TASKS

35. 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)

36. 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…

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

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

39. STORY POINTS ESTIMATION

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

41. 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)

42. EXPERIENCE
DESIGNING AN EFFECTIVE PARKING SYSTEM

43. 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?

44. WHERE DO YOU START?
• BUSINESS VALUE / ROI
• BANG OF BUCK
• NOW ESTIMATE EPICS

45. STORIES IN AN EPIC
• WRITE STORIES
• AS [], I WANT [], SO THAT {}
• VALIDATION STRATEGY
• VERIFICATION CRITERIA
• NOW ESTIMATE STORIES

46. TASKS
• WRITE TASKS
• INCLUDING RESEARCH AND SUB TASKS
• REVIEW THEM
• NOW RE-ESTIMATE STORIES

47. 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)

48. REFLECTIVE
• WHAT WENT WELL
• WHAT NEED IMPROVE
• ACTION ITEMS

49. WRAP UP, Q&A
PLEASE COMPLETE THE POLL

50. CREDITS
ALAN SHALLOWAY, J. A. FARR., SHORE LABS, CARBON FIVE, IVANATERRORBULL,
AGILE MINDS, TECHWELLPRESENTATIONS, FRANCESCO MAPELLI, BRIAN
RUSMUSSEN