Alistair Cockburn©Humans and Technology, Inc., Slide 1 Alistair Cockburn Humans and Technology Salt Lake City, UT Designing an Agile Methodology

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

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

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

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

Alistair Cockburn©Humans and Technology, Inc., Slide 9 Number of people involved Criticality (defects cause loss of...) Comfort (C) Essential money (E) Life (L) +20%... Prioritized for Legal Liability ,000 C6C20C40C100C200C500C1000 D6D20D40D100D200D500D1000 E6E20E40E100E200E500E1000 L6L20L40L100L200L500L1000 Prioritized for Productivity & Tolerance Choose a Methodology according to (project size, system criticality, team priorities) Discretionary money (D)

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

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

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

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

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

Alistair Cockburn©Humans and Technology, Inc., Slide 18 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., Slide 19 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., Slide 20 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., Slide 21 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., Slide 22 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., Slide 23 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., Slide 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 Videotape Paper Audiotape (No Question-Answer) (Question-and-Answer) Principles

Alistair Cockburn©Humans and Technology, Inc., Slide 25 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 Videotape Paper Audiotape (No Question-Answer) (Question-and-Answer) (Courtesy of Thoughtworks, inc.)

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

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

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

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

Alistair Cockburn©Humans and Technology, Inc., Slide 30 Number of people involved Criticality (defects cause loss of...) Comfort (C) Essential money (E) Life (L) +20%... Prioritized for Legal Liability ,000 C6C20C40C100C200C500C1000 D6D20D40D100D200D500D1000 E6E20E40E100E200E500E1000 L6L20L40L100L200L500L1000 Prioritized for Productivity & Tolerance Different methodologies are possible & needed (project size, system criticality, priorities, fears) Discretionary money (D)

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

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

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

Alistair Cockburn©Humans and Technology, Inc., Slide 34 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) 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?)

Alistair Cockburn©Humans and Technology, Inc., Slide 35 Examples Amber C6C20C40 C80 D6D20D40 D80 E6E20E40 E80 L6L20L40 L80 C6 C10 D6D10 E6E10

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

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

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

Alistair Cockburn©Humans and Technology, Inc., Slide 39 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 ) Amber C6C20C40 C80 D6D20D40 D80 E6E20E40 E80 L6L20L40 L80

Alistair Cockburn©Humans and Technology, Inc., Slide 40 Crystal Orange ( 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.

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

Alistair Cockburn©Humans and Technology, Inc., Slide 42 Crystal Orange standards & tolerances Policy standards: :Deliver to users every 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., Slide 43 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)

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

Alistair Cockburn©Humans and Technology, Inc., Slide 45 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 weeks

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

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

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

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

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

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

Alistair Cockburn©Humans and Technology, Inc., Slide 52 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., Slide 53 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., Slide 54 Thanks for joining this session on “divine anthropology” find more papers at: books: Agile Software Development (Cockburn) Agile Software Development Ecosystems (Highsmith) Adaptive Software Development (Highsmith) Surviving Object-Oriented Projects (Cockburn) Project Retrospectives (Kerth)