1. ©Alistair Cockburn 2003-4 Slide 1 http://alistair.cockburn.us Tuning Your Methodology to You

2. ©Alistair Cockburn 2003-4 Slide 2 Learn to discuss 'Methodology.' Get key issues, ideas for your own 'M'. (based on 6 trial designs + project interviews over 7 years) 1. Basics and Common errors 2. Language & constructs 3. Social Issues 4. Fit to topics Part II 5. Principles 6. Crystal family and other Agile methodologies 7. Social Issues again

3. ©Alistair Cockburn 2003-4 Slide 3 Anatomy Activities Techniques ToolsSkills Roles Standards Teams Products QualityTeams Values envisioningproposalsalessetuprequirementsdesign & codetestdeploytrainalter Project Lifecycle designer/programmer writer tester reuse point UI expert lead designer business expert expert user project manager project sponsor trainer secretary contractor night watchman janitor Roles Activities rest and recreation project development timesheets technical education vacations and basic business

4. ©Alistair Cockburn 2003-4 Slide 4 Methodology: who, what, when of interactions Team Values Activities Techniques Tools Skills Roles Standards Quality Teams Products People MilestonesProcess Regression tests Object model Project plan Use cases Microsoft Project 3month increments UML / OMT C++ Microsoft Project STP Envy/Developer Modeling Java programming JAD facilitation Personality Project manager Documenter Designer Tester Planning Testing MBWA Use cases CRC cards

5. ©Alistair Cockburn 2003-4 Slide 5 Ecosystem Methodology Process Techniques Tools Skills Roles Standards Quality Teams Products People MilestonesActivities Personality Jenny Jim Peter Annika But people are stuffed full of personality Project manager Documenter Designer Tester Values

6. ©Alistair Cockburn 2003-4 Slide 6 Methodology is organization-personal: how you produce and deliver systems "Methodology is a social construction" - Ralph Hodgson Methodology is how you manage to ship systems  Who you advertise for  How tightly requirements are gathered  Design standards, shortcuts, deliverables  Team size and makeup  Languages, standards, scheduling strategy Designing one is NOT like designing software!  Highly variable components (people!)  Very long cycle / debug times  Culture and project dependent  Standard novice errors based on the above.

7. ©Alistair Cockburn 2003-4 Slide 7 Standard methodologist errors: One size, intolerant, embellished, heavy, wrong. e1. One size methodology (projects vary) e2. Intolerant methodology (people vary) e3. Embellished ('did do' or 'should have done'?) e4. Heavy (more writing /= more safety) e5. Untried (lots of errors) e6. Tried once (limited applicability) (e 3-6 also apply to expert methodologists!) "Embellishment is the pitfall of the methodologist"

8. ©Alistair Cockburn 2003-4 Slide 8 Who can use a defined methodology? Any group of people Only experts A team with a minimum number of experts  (How many experts?)  (What ratio to novices?)

9. ©Alistair Cockburn 2003-4 Slide 9 What is expertise? (the Shu-Ha-Ri progression) Level 1  Learning “a technique that works”  Success is following the technique (and getting a success) Level 2  Learning limits of the technique  Success is shifting from one technique to another Level 3  Fluid mastery - shifting techniques by moment  Unable to describe the techniques involved The 3 levels apply to all techniques, including software design, management, & methodology adjustment !

10. ©Alistair Cockburn 2003-4 Slide 10 Finally, a Methodology is... The conventions the team agrees to follow:  range from clothing to coding  change all the time  the team chooses/rejects/affects Requiring a certain level of prior experience to apply:  at least one person having done something similar  some mixture of new people and experienced  ideally a level-3 person present to make adjustments

11. ©Alistair Cockburn 2003-4 Slide 11 A Methodology properly discusses the Products, the Factory and the Control System Notation Tools People, Organization, Culture Factory Control System Products

12. ©Alistair Cockburn 2003-4 Slide 12 envisioningproposalsalessetuprequirementsdesign & codetestdeploytrainalter Project Lifecycle designer/programmer writer tester reuse point UI expert lead designer business expert expert user project manager project sponsor trainer secretary contractor night watchman janitor Roles Activities rest and recreation project development timesheets technical education vacations and basic business A methodology has a defined Scope - not all activities of all roles are included.

13. ©Alistair Cockburn 2003-4 Slide 13 Number of people involved Criticality (defects cause loss of...) Comfort (C) Essential money (E) Life (L) +20%... Prioritized for Legal Liability 1 - 6- 20- 40- 100- 200- 500- 1,000 C6C20C40C100C200C500C1000 D6D20D40D100D200D500D1000 E6E20E40E100E200E500E1000 L6L20L40L100L200L500L1000 Prioritized for Productivity & Tolerance Choose a Methodology according to (project size, system criticality, team priorities) Discretionary money (D)

14. ©Alistair Cockburn 2003-4 Slide 14 Milestones Roles A simple Methodology is already big! 7 roles, 4 products, 3 milestones = 84 parts (typically 5-10 roles)

15. ©Alistair Cockburn 2003-4 Slide 15 Sample methodology EXTRACT: Roles, Products, Milestones Cross-team Lead - A person who is responsible for the progress of multiple teams, responsible for sewing together the workings of those teams, establishing priorities across teams; allocating resources (people) across teams. Dependency Table: Writer: Team Lead Readers: Team Leads, Cross-team Leads. What this team needs from each other team, and when it is needed by. May include a fallback plan in case the item is not delivered on time. Screen Flow Review: Present: Developers, Cross team UI mentor Purpose: Check usability of overall UI design. Reviewing: Screen flows. Outcome: List of possible difficulties found in navigating the application. List of suggestions for simplifying the navigation or using existing screens or designs.

16. ©Alistair Cockburn 2003-4 Slide 16 Separate into role sheets to be more usable. Role: Cross-team lead Writes: Overall project plan Cross-team dependency table Reads: Team dependency lists Use cases Reviews: Release proposal User viewing Publishes: Dependency table, biweekly Declares: (none) Role: Designer-Programmer Writes: Weekly status sheet Source code, Unit tests Release notes... Reads: Actor descriptions UI style guide... Reviews: Application design review... Publishes: App. configuration, daily Declares: UI Stable.

17. ©Alistair Cockburn 2003-4 Slide 17 Key terms: methodology, weight, size, criticality Methodology = "related methods or techniques" (Method ~ technique = "systematic procedure") M. Size = how many elements in the methodology M. Density = amount of precision, intolerance Methodology Weight = M. Size * M. Density Project Size = # people, geographic separation ("problem size" /= project size) System criticality = damage made by system error

18. ©Alistair Cockburn 2003-4 Slide 18 Hazard is requiring high precision from the start  Establish levels of precision for each Project Plan  Dependency Diagram Use cases  Actor-Goal List Object design  Responsibilities / Channels Methodology  Role/Product/Milestone Chart architecture use cases object model GUI test cases code release Teller Computer Table Vault “Holds the money” “Maintains histories and balances” “Provides flat surface for writing” “Handles the transaction” Balance inquiry Transaction details $ ActorGoal CustomerBuy a product CustomerGet a refund Mktg DeptSet up promotion ManagerCheck statistics Precision: How much you care to say. All deliverables have a low-precision view

19. ©Alistair Cockburn 2003-4 Slide 19 Work grows fast as precision increases (therefore use low precision where possible). Actor Goal Success Action Failure Condition Recovery Action Failure Condition Recovery Action Success Action Failure Condition Recovery Action Failure Condition Recovery Action Goal Success Action Failure Condition Recovery Action Failure Condition Recovery Action Success Action Failure Condition Recovery Action Failure Condition Recovery Action

20. ©Alistair Cockburn 2003-4 Slide 20 Use lower levels of precision to start parallel activities. PlanUse Cases UI Design Domain Design InternalsExternal Interfaces Do L1: Actors-Goals Do L1: Release Dependencies (split into teams) Do L2: Main Stories Do L3: Failure Cases Do L2: Cross-Team Dependencies Do L3: Milestones Monitor Status review Study UI requirements Build L1: Screen flow walk through tasks check usability Study domain requirements Define shared models Do L2 Initial Domain model (CRC) review model Do L2 external interfaces Identify frameworks to build Design framework review interfaces revise frameworks design complete framework release........................

21. ©Alistair Cockburn 2003-4 Slide 21 Accuracy, Stability, Relevance, Scale, Tolerance Accuracy: How correct you are at that precision. Iterations and investigation improve accuracy Stability: How likely it is to change. Keep upstream stability ahead of downstream. Tolerance: How much variation is permitted.

22. ©Alistair Cockburn 2003-4 Slide 22 Milestones: Review, Publish or Declare Review: Who is sitting in the room? What are they reading?Who wrote that? What is the effect of failing the review? Publish: By whom, for whom, how, when? e.g. configurations, installing software, printing Declare: Who says it, whose life changes? e.g., Declare UI stable, Declare ready for Alpha

23. ©Alistair Cockburn 2003-4 Slide 23 Methodology is a social agreement: check values, tolerance, priorities, fears, acceptance, enforcement Values - Hierarchical / consensus / silent culture? Work nights / Go home at 5:00? Priorities - Deliver soonest, build for the future, simplify training, reduce legal liability? Tolerances - High / low discipline? Process checks? allow much / little variation between people? Acceptance - Do people accept to work this way? What when they don't?

24. ©Alistair Cockburn 2003-4 Slide 24 Tolerance: People lack discipline, are good at looking around. A methodology that relies upon discipline is fragile. People say they'll be diligent, but they won't.  Put as much tolerance as possible into the 'M'.  Create checkpoint/encouragement mechanisms e.g. style coaches, mentors, reviews People are very good at communicating, looking around, building their own picture of the world.

25. ©Alistair Cockburn 2003-4 Slide 25 Fears: Make them explicit, address explicitly "All methodology is based on fears" - Kent Beck Too easy to overconstrain the development process  (e.g., Many deliverables, with low tolerance) Fear of … people quitting, not communicating, not knowing where the project is, … Why exactly do you feel the need for … a requirements document? a design document? coding standards? regression tests? user reviews? Fear comes from previous experiences.

26. ©Alistair Cockburn 2003-4 Slide 26 Brief summary of what you have heard:...UML, C++, Java are notational standards....Incremental development is a staging standard....1 size cannot fit all. What you will hear in Part II....Adding a little weight adds a lot of cost....Managing your use of precision and accuracy....What an “agile” methodology looks like....How to get started.

27. ©Alistair Cockburn 2003-4 Slide 27... C6C20C40C100C200 C500 C1000 D6D20D40D100D200D500D1000 E6E20E40E100E200E500E1000 L6L20L40L100L200L500L1000 Richness (“temperature”) of communication channel “cold”“hot” Communication Effectiveness 2 people at whiteboard 2 people on phone 2 people on email Videotape Paper Audiotape (No Question-Answer) (Question-and-Answer) Principles

28. ©Alistair Cockburn 2003-4 Slide 28 Principle 1: People communicate best interactively face-to-face. (but not for legal traceability!) Richness (“temperature”) of communication channel “cold”“hot” Communication Effectiveness 2 people at whiteboard 2 people on phone 2 people on email Videotape Paper Audiotape (No Question-Answer) (Question-and-Answer) (Courtesy of Thoughtworks, inc.)

29. ©Alistair Cockburn 2003-4 Slide 29 Number of people Communications Load (Methodology Cost) Effectiveness per person Principle 2:Adding people is expensive. (Methodology grows with number of roles.)

30. ©Alistair Cockburn 2003-4 Slide 30 Methodology Weight Problem size Many people using a light methodology Many people using a heavier methodology Many people using a very heavy methodology Principle 3: Larger teams need more...... quick payoff, early diminishing returns.

31. ©Alistair Cockburn 2003-4 Slide 31 Methodology Weight large team Problem Size small team Methodology weight is costly (but larger teams need more)

32. ©Alistair Cockburn 2003-4 Slide 32 Light Medium Heavy Problem Size Principle 4:Lighter methodologies are better, but have limits Number of People Needed

33. ©Alistair Cockburn 2003-4 Slide 33 Number of people involved Criticality (defects cause loss of...) Comfort (C) Essential money (E) Life (L) +20%... Prioritized for Legal Liability 1 - 6- 20- 40- 100- 200- 500- 1,000 C6C20C40C100C200C500C1000 D6D20D40D100D200D500D1000 E6E20E40E100E200E500E1000 L6L20L40L100L200L500L1000 Prioritized for Productivity & Tolerance Different methodologies are possible & needed (project size, system criticality, priorities, fears) Discretionary money (D)

34. ©Alistair Cockburn 2003-4 Slide 34 Plan-driven sweet spot Time and Effort Invested in Plans Damage from over/underplanning The “correct” mix of planning vs. reacting depends on the individual project’s risk exposure. from “Get Ready for Agile Methods – With Care” (Barry Boehm, IEEE Computer, January 2001) Agile sweet spot

35. ©Alistair Cockburn 2003-4 Slide 35 Principle 5: Efficiency is expendable away from bottleneck activities (1). Serial Development Concurrent Development Requirements Design Program Test Requirements Design Program Test Completeness, Stability Requirements Testing UI design & Object Design Programming

36. ©Alistair Cockburn 2003-4 Slide 36 DBA Designer/ Programmer Completeness, Stability Time Requirements Designer/Programmer DBA Principle 5: Efficiency is expendable away from bottleneck activities (2).

37. ©Alistair Cockburn 2003-4 Slide 37 Principle 6: Inventory slows responses to change. (Inventory = days of work not yet in production). Days of work not yet in production (Thanks to Kent Beck for this diagram) 1000 100 10 1 0.1 5-year waterfall (e.g. military) project = 1,200 days 3-year waterfall project = 720 days Quarterly incremental releases = 65 days 3-week iterations (XP) = 15 days Daily release (Swiss XP project) (what would this mean?)

38. ©Alistair Cockburn 2003-4 Slide 38 Examples Amber C6C20C40 C80 D6D20D40 D80 E6E20E40 E80 L6L20L40 L80 C6 C10 D6D10 E6E10

39. ©Alistair Cockburn 2003-4 Slide 39 Common philosophy: Strong on communications, Light on deliverables. "Sw dev't is a cooperative game, which uses markers that remind and incite.” Principles: Fewer intermediate products are needed with : * Short, rich, informal communications paths * Frequent delivery. * Use people's natural strengths (talking, looking around) beware natural weaknesses (careless, low on discipline) Crystal family of Agile methodologies Prioritized for Productivity & Tolerance Red C6C20C40 C80 D6D20D40 D80 E6E20E40 E80 Clear Yellow Orange L6L20L40 L80

40. ©Alistair Cockburn 2003-4 Slide 40 Crystal separates - improve individual skills AND improve team. Individual track:  Becoming a better  Qualities & Standards for  Techniques for Team track:  Big-M methodology for  Techniques for Non-jealous methodology set  Improve people, and improve team  Whichever you need next, whatever you can manage.

41. ©Alistair Cockburn 2003-4 Slide 41 Crystal family Activities Techniques Skills Roles Quality Products Teams Standards Crystal (Clear) Crystal (Yellow) Crystal (Orange) Crystal (Red)... Red C6C20C40 C80 D6D20D40 D80 E6E20E40 E80 Clear Yellow Orange L6L20L40 L80 Activities setup requirements design code test Project Lifecycle sponsor coordinator business expert user lead designer designer/programmer tester writer Roles project monitoring application development

42. ©Alistair Cockburn 2003-4 Slide 42 Crystal Orange : scope For D40 projects: Up to 40 people, same building Loss of discretionary moneys (May extend to E50) Not for very large projects (insufficient subteaming) Not for life-critical projects (insufficient verification) (Described in Surviving OO Projects, Cockburn, 1998, pp. 77-93) Amber C6C20C40 C80 D6D20D40 D80 E6E20E40 E80 L6L20L40 L80

43. ©Alistair Cockburn 2003-4 Slide 43 Crystal Orange (25 - 40 people) Roles : Sponsor, Business expert, Usage expert, Technical facilitator, Business analyst / designer, Project Manager, Architect, Lead designer/programmer, Designer/programmer, Design Mentor, UI designer, Reuse Point, Writer, Tester. Teams : System planning, Project monitoring, Architecture, Technology, Functions, Infrastructure, External test.

44. ©Alistair Cockburn 2003-4 Slide 44 Crystal Orange Products Every product has an owner. (Negotiable ownership assignment) * Requirements doc * Release sequence, * schedule, * status report * UI design doc * Common object model * Inter-team specs * Usage manual * Code * Test cases Activities Pre- & mid-increment methodology review Start each new activity as soon as preceding activity is “stable enough to review” Deliver to users every 8-17 weeks Publish each work product Declare each work product stable enough to review, & application correct enough to deliver.

45. ©Alistair Cockburn 2003-4 Slide 45 Crystal Orange standards & tolerances Policy standards:  Deliver to users every 3 + 1 months  Direct user involvement, 2 user viewings per release  Single, common object (not analysis & design models) Local standards are set and maintained by team:  Templates, Coding style, Regression test framework Policy standards are mandatory but substitutable  “Scrum” can be used for project steering Any design technique is allowed  Overeat, design during dreams, etc.

46. ©Alistair Cockburn 2003-4 Slide 46 C6 C10 D6D10 E6E10 Crystal Clear : scope For D6 projects: 3-6 people, close or in same room Loss of discretionary moneys (may extend to: E8 project) Not for large projects (insufficient group coordination) Not for life-critical projects (insufficient verification) (Described in Crystal Clear, Cockburn, 2003 also in Agile Software Development, Cockburn 2001)

47. ©Alistair Cockburn 2003-4 Slide 47 Crystal Clear (3 - 8 people) Roles Sponsor, Senior designer, Designer/programmer, User (part-time) Combined roles: coordinator, business expert, requirements gatherer Teams Single team of designer/programmers Seating One big room, or adjacent offices

48. ©Alistair Cockburn 2003-4 Slide 48 Crystal Clear Products Release sequence, Schedule of user viewings, List of actors & goals Light use cases... Design sketches & notes as needed ! Activities Pre-increment & mid-increment methodology review Start each new activity as soon as preceding activity is “stable enough to review” Deliver to users every 4 -12 weeks

49. ©Alistair Cockburn 2003-4 Slide 49 Priorities Productivity, maintainability. Rely on tools, communication. Lighten methodology by increasing discipline. C6 C10 C20 D6D10D20 E6E10E20 Extreme Programming characterized (1) Activities Techniques Skills Roles Quality Products Teams ToolsStandards (“I sense much fear” - Yoda) setup requirements design code test Project Lifecycle designer / programmer user coordinator sponsor Roles Activities project monitoring application development UI designer coach designer / programmer

50. ©Alistair Cockburn 2003-4 Slide 50 Adjusting Extreme Programming: Add UI design techniques setup requirements design code test Project Lifecycle coordinator sponsor Roles Activities project monitoring application development coach designer / programmer setup requirements design code test Project Lifecycle designer / programmer user coordinator sponsor Roles Activities project monitoring application development UI designer coach designer / programmer UI designer user

51. ©Alistair Cockburn 2003-4 Slide 51 Extreme Programming characterized (2) Quality System comparison test Functional test Full unit tests Coding standards Code cost model "Once and only once" Activities Setting the metaphor Planning Daily stand-upmeeting DesigningProgramming Testing Postpartum Teams Programming teams User team Production team Products Release Plan Story Cards Task list & estimates Running code Migration programs Tests Reports Standards Coding style Episodal development 3-week deliveries Test case style Always perfect unit test Programming in Pairs Techniques Metaphor building Planning / estimation Teamwork motivation Test-case-first development Refactoring Roles Sponsor User Coordinator Designer/Programmer Production support Coach Skills Programming Refactoring Testing Tools Smalltalk / Java /... Envy/Developer Refactoring browser Test-case framework Performance tuning Values: Communication Keeping it simple Testing Courage

52. ©Alistair Cockburn 2003-4 Slide 52 Adjusting Extreme Programming (2) : Retain close communication (Courtesy of Thoughtworks, Evant, RoleModel Software)

53. ©Alistair Cockburn 2003-4 Slide 53 Part III: Attack of the Cultural Antibodies Keep these Try these Problems test lock-down quiet time daily meetings pair testing fines for interruptions programmers help testers too many interruptions shipping buggy code

54. ©Alistair Cockburn 2003-4 Slide 54 A methodology is a micro-culture embedded in two outer cultures.  Company culture  National culture Methodology is cultural engineering.  fit the outer culture  It can be rejected  Both will change What sort of culture do you have?  Hierarchy  Chaos  Consensus  Synchronized Silence Notation Tools People Organization & Culture

55. ©Alistair Cockburn 2003-4 Slide 55 Get Started: interviews, workshop, feedback Build the control system first.  Settle increments,  Hold interview & workshop after each. Preload the system.  Interview projects to learn key issues, hazards, tricks.  Ask what they did, liked, didn't, would change or keep.  Identify fears, priorities, success factors, hazards. Ask the group.  Let the group influence first increment's methodology. Use your feedback  Check mid- and post-increment opinion  Update your principles, fears, strategies.

56. ©Alistair Cockburn 2003-4 Slide 56 Crystal’s Mindset “Software development is a (resource-limited) finite, goal-seeking cooperative game of invention and communication.”

57. ©Alistair Cockburn 2003-4 Slide 57 Infinite Organization Survival Career Management A finite, goal-directed cooperative game Competitive Cooperative Finite w/ no fixed end Jazz music King-of-the-hill wrestling Finite & goal-directed Tennis Software Developmen t Poker Rock-Climbing Games

58. ©Alistair Cockburn 2003-4 Slide 58 Sw Development is a Game of Economics Economic consequences to each choice. Resources are limited. “Less” is usually better. “Barely sufficient” is Best !

59. ©Alistair Cockburn 2003-4 Slide 59 Players in the game are “People” - Highly nonlinear, spontaneous active devices Weak points: Consistency Discipline Following instructions Strong points: Looking around Taking initiative Copy /modify-ing Communicating Rewards: Pride in work Pride in contributing Pride in accomplishment

60. ©Alistair Cockburn 2003-4 Slide 60 The game has a primary and secondary goal: Two Games in One ! Primary Goal  Deliver working software.  (Mess up the first goal => no software. Secondary Goal  Set up for the next game.  Mess up the secondary goal => disadvantaged next project

61. ©Alistair Cockburn 2003-4 Slide 61 Crystal’s Priorities Project Safety Development Efficiency Habitability of the Process

62. ©Alistair Cockburn 2003-4 Slide 62 Crystal’s Properties: The ‘7’ properties of successful projects 1: Frequent Delivery 2: Close (Osmotic) Communication(Crystal’s core) 3: Reflective Improvement 4: Focus (priorities & time) 5: Personal Safety 6: Easy Access to Expert Users 7: Configuration management Automated regression testing(Technical Environment) Frequent integration Evidence of the properties in action:  Collaboration across organizational boundaries (Any pre-named procedures may not deliver the properties... & the properties are more important) `

63. ©Alistair Cockburn 2003-4 Slide 63 Richness (“temperature”) of communication channel “cold”“hot” Communication Effectiveness 2 people at whiteboard 2 people on phone 2 people on email Videotape Paper Audiotape (No Question-Answer) (Question-and-Answer) Crystal’s Principles

64. ©Alistair Cockburn 2003-4 Slide 64 Methodology Tuning Workshop Methodology Tuning Workshop

65. ©Alistair Cockburn 2003-4 Slide 65 Base technique in Crystal: Methodology-tuning interviews, workshops Build the control system first.  Settle increment size,  Hold interview & workshop before/after each. Preload the system.  Interview projects to learn key issues, hazards, tricks.  Ask what they did, liked, didn't, would change or keep.  Identify fears, priorities, success factors, hazards. Ask the group.  Let the group influence first increment's methodology.

66. ©Alistair Cockburn 2003-4 Slide 66 Base technique in Crystal: Post-iteration reflection workshop Hang a flipchart, create two columns  “Keep these”  “Try these” (Create a small area for “Recurring Problems”) (Don’t create an area for “Don’t Like These”!) Spend 30 minutes filling in the chart HANG THE CHART IN A PUBLIC, VISIBLE FREQUENTLY SEEN PLACE !!!!! Make sure you actually try some of the Try These ideas ! Repeat after each iteration

67. ©Alistair Cockburn 2003-4 Slide 67 Activity: Three Sheets - 8 minutes per sheet Sheet 1: Things that worked well --- work hard to keep these  Vote with 3 stars to select the top 2-3 items. Sheet 2: Things that were horrible --- find antidotes  Vote with 3 stars to select the top 2-3 items. Sheet 3: Antidotes to the problems --- try these  (If necessary) Vote with 3 starts to select the top items Compare sheets

68. ©Alistair Cockburn 2003-4 Slide 68 http://alistair.cockburn.us Tuning Your Methodology to You