Designing an Agile Methodology Alistair Cockburn Humans and

Designing an Agile Methodology Alistair Cockburn Humans and Technology Salt Lake City, UT http: //Alistair. Cockburn. us Alistair Cockburn ©Humans and Technology, Inc. , 1998 -2002 Slide 1

Agile methodologies emphasize “manoeverable, responsive to change” Agile Software Development Manifesto: We value : Individuals and interactions over Processes and Tools. : Working software over Comprehensive documentation. : Customer collaboration over Contract negotiation. : Responding to change over Following a plan. (© 2001, Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Stephen J. Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas ) All very nice, but how do you do it? Alistair Cockburn ©Humans and Technology, Inc. , 1998 -2002 Slide 2

es Anatomy tiv iti rest and recreation vacations and basic business technical education timesheets project development project sponsor project manager expert user business expert lead designer UI expert reuse point designer/programmer tester writer trainer secretary contractor night watchman janitor envisioningproposal sales setup requirementsdesign & codetest deploy train alter Roles Ac Values Project Lifecycle Alistair Cockburn Quality Products Standards ©Humans and Technology, Inc. , 1998 -2002 Activities Teams Techniques Roles Tools Skills Slide 3

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 Alistair Cockburn ©Humans and Technology, Inc. , 1998 -2002 Slide 4

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. Alistair Cockburn ©Humans and Technology, Inc. , 1998 -2002 Slide 5

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

A Methodology properly discusses the Products, the Factory and the Control System Factory Products Control System Tools People, Organization, Culture Alistair Cockburn Notation ©Humans and Technology, Inc. , 1998 -2002 Slide 7

A methodology has a defined Scope - not all activities of all roles are included. Roles Ac tiv iti es rest and recreation vacations and basic business technical education timesheets project development project sponsor project manager expert user business expert lead designer UI expert reuse point designer/programmer tester writer trainer secretary contractor night watchman janitor envisioning proposal sales setup requirements design & code test deploy train alter Project Lifecycle Alistair Cockburn ©Humans and Technology, Inc. , 1998 -2002 Slide 8

Criticality (defects cause loss of. . . ) Choose a Methodology according to (project size, system criticality, team priorities). . . Prioritized for Legal Liability Prioritized for Productivity & Tolerance Life (L) L 6 L 20 L 40 L 100 L 200 L 500 L 1000 Essential money (E) E 6 E 20 E 40 E 100 E 200 E 500 E 1000 Discretionary money D 6 (D) D 20 D 40 D 100 D 200 D 500 D 1000 C 20 C 40 C 100 C 200 C 500 C 1000 Comfort (C) C 6 1 -6 - 20 - 40 - 100 Number of people Alistair Cockburn - 200 - 500 - 1, 000 involved +20% ©Humans and Technology, Inc. , 1998 -2002 Slide 9

Standard methodologist errors: One size, intolerant, embellished, heavy, wrong. E#1. One size methodology (projects vary) E#2. Intolerant methodology (people vary) E#3. Embellished ('did do' or 'should have done'? ) E#4. Heavy (more writing /= more safety) E#5. Untried (lots of errors) E#6. Tried once (limited applicability) (E 3 -6 also apply to expert methodologists!) Methodology Success = Project delivered + Staff would use same methodology again "Embellishment is the pitfall of the methodologist" Alistair Cockburn ©Humans and Technology, Inc. , 1998 -2002 Slide 10

A simple Methodology is already big! 7 roles, 4 products, 3 milestones = 84 parts Roles Milestones Alistair Cockburn (typically 5 -10 roles) ©Humans and Technology, Inc. , 1998 -2002 Slide 11

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. Alistair Cockburn ©Humans and Technology, Inc. , 1998 -2002 Slide 12

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) Alistair Cockburn 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 ©Humans and Technology, Inc. , 1998 -2002 Slide 13 .

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 Alistair Cockburn ©Humans and Technology, Inc. , 1998 -2002 Slide 14

Precision: How much you care to say. All deliverables have a low-precision view Hazard is requiring high precision from the start : Establish levels of precision for each architecture code Project Plan test cases use cases : Dependency Diagram object model GUI Use cases Actor Goal Buy a product : Actor-Goal List Customer Get a refund Mktg Dept Set up promotion Object design Manager Check statistics Teller : Responsibilities / Channels Methodology Table : Role/Product/Milestone Chart “Handles the transaction” $ release “Holds the money” Balance inquiry Transaction details Vault “Maintains histories and balances” Computer “Provides flat surface for writing” Alistair Cockburn ©Humans and Technology, Inc. , 1998 -2002 Slide 15

Work grows fast as precision increases (therefore use low precision where possible). Failure Condition Recovery Action Success Action Recovery Action Failure Condition Recovery Action Goal Recovery Action Failure Condition Recovery Action Success Action Recovery Action Failure Condition Recovery Action Actor Recovery Action Failure Condition Recovery Action Success Action Recovery Action Failure Condition Recovery Action Goal Recovery Action Failure Condition Recovery Action Success Action Recovery Action Failure Condition Recovery Action Alistair Cockburn ©Humans and Technology, Inc. , 1998 -2002 Slide 16

Use lower levels of precision to start parallel activities. Plan Use Cases UI Design Domain Design External Interfaces Internals Do L 1: Actors-Goals Do L 1: Release Dependencies (split into teams) Do L 2: Main Stories Do L 2: Cross-Team Dependencies Do L 3: Failure Cases Do L 3: Milestones review Monitor Status Alistair Cockburn . . . Study UI requirements Study domain requirements walk through Define shared models tasks Build L 1: Screen flow check usability . . . Do L 2 Initial Domain model (CRC) Do L 2 external interfaces . . . review model . . . ©Humans and Technology, Inc. , 1998 -2002 Identify frameworks to build Design framework review interfaces revise frameworks design complete framework release Slide 17

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. Alistair Cockburn ©Humans and Technology, Inc. , 1998 -2002 Slide 18

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 Alistair Cockburn ©Humans and Technology, Inc. , 1998 -2002 Slide 19

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? Alistair Cockburn ©Humans and Technology, Inc. , 1998 -2002 Slide 20

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. Alistair Cockburn ©Humans and Technology, Inc. , 1998 -2002 Slide 21

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. Alistair Cockburn ©Humans and Technology, Inc. , 1998 -2002 Slide 22

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. Alistair Cockburn ©Humans and Technology, Inc. , 1998 -2002 Slide 23

. . . L 6 E 6 L 20 E 20 L 40 E 40 L 100 E 100 L 200 E 200 L 500 E 500 L 1000 E 1000 D 6 D 20 D 40 D 100 D 200 D 500 D 1000 C 6 C 20 C 40 C 100 C 200 C 500 C 1000 Communication Effectiveness Principles 2 people at whiteboard 2 people on phone er) -an Videotape 2 people on email Audiotapen-Answer) Paper estio o Qu w ns A d (Q on sti ue (N Richness (“temperature”) of communication channel “cold” Alistair Cockburn ©Humans and Technology, Inc. , 1998 -2002 Slide 24 “hot”

Communication Effectiveness Principle 1: People communicate best interactively face-to-face. (but not for legal traceability!) 2 people at whiteboard 2 people on phone (Courtesy of Thoughtworks, inc. ) Videotape 2 people on email Paper ns A dn -a n o sti e u Q ( Audiotape er) w s n n-A tio ues Q o N ( Richness (“temperature”) of communication channel “cold” “hot” Alistair Cockburn r) e w ©Humans and Technology, Inc. , 1998 -2002 Slide 25

Principle 2: Adding people is expensive. (Methodology grows with number of roles. ) Effectiveness person Communications Load (Methodology Cost) Number of people Alistair Cockburn ©Humans and Technology, Inc. , 1998 -2002 Slide 26

Principle 3: Larger teams need more. . . quick payoff, early diminishing returns. Problem size Many people using a heavier methodology Many people using a very heavy methodology Many people using a light methodology Methodology Weight Alistair Cockburn ©Humans and Technology, Inc. , 1998 -2002 Slide 27

Problem Size Methodology weight is costly (but larger teams need more) large team small team Methodology Weight Alistair Cockburn ©Humans and Technology, Inc. , 1998 -2002 Slide 28

Principle 4: Lighter methodologies are better, but have limits Number of People Needed Heavy Medium Light Problem Size Alistair Cockburn ©Humans and Technology, Inc. , 1998 -2002 Slide 29

Criticality (defects cause loss of. . . ) Different methodologies are possible & needed (project size, system criticality, priorities, fears). . . Prioritized for Legal Liability Prioritized for Productivity & Tolerance Life (L) L 6 L 20 L 40 L 100 L 200 L 500 L 1000 Essential money (E) E 6 E 20 E 40 E 100 E 200 E 500 E 1000 Discretionary money D 6 (D) D 20 D 40 D 100 D 200 D 500 D 1000 C 20 C 40 C 100 C 200 C 500 C 1000 Comfort (C) C 6 1 -6 - 20 - 40 - 100 Number of people Alistair Cockburn - 200 - 500 - 1, 000 involved +20% ©Humans and Technology, Inc. , 1998 -2002 Slide 30

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

Completeness, Stability Principle 5: Efficiency is expendable away from bottleneck activities (1). Requirements UI design & Object Design Programming Testing Serial Development Requirements Design Program Test Concurrent Development Requirements Design Program Test Alistair Cockburn ©Humans and Technology, Inc. , 1998 -2002 Slide 32

Principle 5: Efficiency is expendable away from bottleneck activities (2). Designer/ Programmer Designer/ Programmer Alistair Cockburn DBA Completeness, Stability Requirements Designer/Programmer DBA Time ©Humans and Technology, Inc. , 1998 -2002 Slide 33

Principle 6: Inventory slows responses to change. (Inventory = days of work not yet in production). Days of work not yet in production 1000 10 1 0. 1 Alistair Cockburn (Thanks to Kent Beck for this diagram) 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? ) ©Humans and Technology, Inc. , 1998 -2002 Slide 34

Examples E 6 E 10 D 6 D 10 C 6 Alistair Cockburn C 10 L 6 L 20 L 40 L 80 E 6 E 20 E 40 E 80 D 6 D 20 D 40 D 80 C 6 ©Humans and Technology, Inc. , 1998 -2002 Amber C 20 C 40 C 80 Slide 35

Crystal family of Agile methodologies Prioritized for Productivity & Tolerance Common philosophy: Strong on communications, Light on deliverables. "Sw dev't is a cooperative game, which uses markers that remind and incite. ” L 6 L 20 L 40 L 80 E 6 E 20 E 40 E 80 D 6 D 20 D 40 D 80 C 6 C 20 C 40 C 80 Orange Clear Yellow Red 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) Alistair Cockburn ©Humans and Technology, Inc. , 1998 -2002 Slide 36

Crystal separates improve individual skills AND improve team. Individual track: : Becoming a better <designer, manager, tester, …> : Qualities & Standards for <use cases, OO designs, …> : Techniques for <facilitating, getting use cases, , scheduling, resolving conflicts> Team track: : Big-M methodology for <6 people, 15 people, 40, …> : Techniques for <improving collaboration, …> Non-jealous methodology set : Improve people, and improve team : Whichever you need next, whatever you can manage. Alistair Cockburn ©Humans and Technology, Inc. , 1998 -2002 Slide 37

L 6 E 6 L 20 E 20 L 40 Ac Crystal (Clear) Crystal (Yellow) Crystal (Orange) Crystal (Red). . . L 80 E 40 E 80 D 6 D 20 D 40 D 80 C 6 C 20 C 40 C 80 Clear Yellow Orange Alistair Cockburn project monitoring application development sponsor coordinator business expert user lead designer/programmer tester writer setup requirements design code test Roles tiv iti es Crystal family Red Project Lifecycle Quality Activities Teams Products Techniques Roles Standards ©Humans and Technology, Inc. , 1998 -2002 Skills Slide 38

Crystal Orange : scope For D 40 projects: Up to 40 people, same building Loss of discretionary moneys (May extend to E 50) L 6 L 20 L 40 L 80 E 6 E 20 E 40 E 80 D 6 D 20 D 40 D 80 C 6 Amber C 20 C 40 Not for very large projects (insufficient subteaming) Not for life-critical projects (insufficient verification) (Described in Surviving OO Projects, Cockburn, 1998, pp. 77 -93) Alistair Cockburn ©Humans and Technology, Inc. , 1998 -2002 Slide 39 C 80

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

Crystal Orange Products Activities 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 Alistair Cockburn 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. ©Humans and Technology, Inc. , 1998 -2002 Slide 41

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. Alistair Cockburn ©Humans and Technology, Inc. , 1998 -2002 Slide 42

Crystal Clear : scope For D 6 projects: 3 -6 people, close or in same room Loss of discretionary moneys (may extend to: E 8 project) E 6 E 10 D 6 D 10 C 6 C 10 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) Alistair Cockburn ©Humans and Technology, Inc. , 1998 -2002 Slide 43

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

Crystal Clear Products Activities Release sequence, Schedule of user viewings, List of actors & goals Light use cases. . . Design sketches & notes as needed ! 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 Alistair Cockburn ©Humans and Technology, Inc. , 1998 -2002 Slide 45

(“I sense much fear” - Yoda) Extreme Programming characterized (1) Roles Ac tiv iti es Priorities project monitoring application development sponsor coordinator user UI designer / programmer Productivity, maintainability. Rely on tools, communication. Lighten methodology by increasing discipline. designer / programmer coach setup requirements design code test Project Lifecycle Quality Activities Teams Products Techniques Roles Standards Tools Skills Alistair Cockburn E 6 E 10 E 20 D 6 D 10 D 20 C 6 C 10 C 20 ©Humans and Technology, Inc. , 1998 -2002 Slide 46

Adjusting Extreme Programming: iti es Roles Ac tiv iti es Add UI design techniques Roles Ac tiv project monitoring application development sponsor coordinator user UI designer / programmer coach setup requirements design code test Project Lifecycle designer / programmer coach setup requirements design code test Project Lifecycle Alistair Cockburn ©Humans and Technology, Inc. , 1998 -2002 Slide 47

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

Adjusting Extreme Programming (2) : Retain close communication (Courtesy of Thoughtworks, Evant, Role. Model Software) Alistair Cockburn ©Humans and Technology, Inc. , 1998 -2002 Slide 49

Part III: Attack of the Cultural Antibodies Keep these test lock-down quiet time daily meetings Try these pair testing fines for interruptions programmers help testers Problems too many interruptions shipping buggy code Alistair Cockburn ©Humans and Technology, Inc. , 1998 -2002 Slide 50

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 Alistair Cockburn Notation Tools People Organization & Culture ©Humans and Technology, Inc. , 1998 -2002 Slide 51

Buy-In: self-determination or crisis Expert's buy-in : Has mental tool box proven complete : Needs full breakdown to create space for alternate tools Novice's buy-in : Has mental tool box with space and need for new tools expert may need crisis to accept new ideas. Buy-In through self-determination: : In methodology workshop, team members name their : roles, teams, products, standards, milestones, tasks. . but how do you install an 'M' across projects? Alistair Cockburn ©Humans and Technology, Inc. , 1998 -2002 Slide 52

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. Alistair Cockburn ©Humans and Technology, Inc. , 1998 -2002 Slide 53

Thanks for joining this session on “divine anthropology” find more papers at: http: //Alistair. Cockburn. us books: Agile Software Development (Cockburn) Agile Software Development Ecosystems (Highsmith) Adaptive Software Development (Highsmith) Surviving Object-Oriented Projects (Cockburn) Project Retrospectives (Kerth) Alistair Cockburn ©Humans and Technology, Inc. , 1998 -2002 Slide 54