Agile Software Development Methodologies


Published on

Revenge of the Programmers (presentation given to colleagues at Pason Systems, 2002)

Published in: Technology, Business
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Welcome to Tech Talks. Hoping to have participants present on interesting topics in software development.
    Goal: Further our programming practice as Software Engineers.
    Art, Craft, Science, Engineering question -> good topic :)

    “Revenge of the Programmers” : Phrase coined by Bertrand Meyer upon learing of Agile methodologies. What are programmers getting revenge against?

    Development Methodologies:
    1) Lightweight: agile world
    2) Heavyweight: RUP, CMM, MILSTD world
    3) Ad-hoc: What's a methodology?
    4) Tailored: Take the best of all worlds to suit your situation...
  • Agile is a group of lightweight software development methodolgies. “Agile Alliance” created by representatives from various methodologies in 2001 on a ski trip in Utah. Fancy term for light weight.


    Extreme Programming: Beck (1996)

    Scrum: Sutherland, Schwaber, Beedle (1996)

    Crystal: Alistair Cockburn (1995)

    DX: Robert Martin (1998)

    Feature drvien design (FDD): Coad, Lefevbre, Deluca (1997)

    Adaptive Software Development (ASD): Peter Highsmith (1994)

    Dynamic systems development method: ??? (1992)

    Pragmatic Programming: Thomas, Hunt (1999)

  • Not to say that things on the right are never done or are completely useless, just that agile processes have a preference for the items on the left.

    Basically about empowering the individual developer

    improves communication with customer

    improves time estimates through measurement of velocity

    improves testing (TDD, automated); better software quality

    attempts to reduce the pain caused by rapidly changing requirements

    no more death marches to meet arbitrary deadlines

  • Communication: Most problems traced to miscommunication between team members.

    Simplicity: What's the simplest thing that could possibly work?
    Feedback: Rapid releases, automated unit testing
    Courage: Admit failure, to refactor, to pair program

    XP defines four project variables that affect the outcome of all software projects. Management can pin down any three of the variables, but not the fourth. Any software project were all four are dictated by management without developer feedback are likely to fail.

    Good example: Fred Brooks classic “Mythic Man Month” describing the a death march to release IBM OS/360, added more junior programmers
  • Customer Satisfaction

    On-site customer: answer questions, define needs, prioritize features

    Small, frequent releases: early, constant feedback, easier to plan

    Software Quality

    Metaphor: Overall idea of the system, consistent naming scheme

    Testing: test first design; automated unit, regression, and acceptance tests

    Simple design: design for today, not for the future

    Refactoring: goal is to keep design simple

    Pair programming: peer review is good so do it all the time

    Project Management

    Planning game: determine user stories, priorities, release schedule

    Sustainable development: Never more than two weeks of OT in a row

    Collective code ownership: Keeps code clean, discourages “experts”

    Continous integration: avoids traditional big bang integration problems

    Coding standards: Easier for all developers to understand whole system

  • User stories (requirements) from customer; input for acceptance tests

    Spikes: a throw-away test program that addresses major uncertainties

    Release planning: Overall project schedule meeting, based on user story estimates, move user story cards around on big table to set releases

    Iterations: plan each iteration just before entry; follows from release plan; consider current project velocity (total of story estimates completed in an iteration), generate acceptance tests

    Acceptance tests are black box system tests. Customer responsible for verifying correctness.

  • Roughly 1-3 weeks long

    Initial planning meeting:

    Choose user stories to complete based on customer priority

    Handle failed acceptance tests from last iteration

    Estimates for stories must equal project velocity of previous iteration

    Break user stories down into programming tasks

    - developers choose and estimate their tasks (1-3 days of ideal time)

    - total estimates for tasks can't exceed project velocity (snow-plowing)

    All estimates are encouraged to be accurate, low-balling doesn't help

    May need to re-estimate all user stories and redo release plan every 3-5 iterations depending on requirements flux.
  • Daily stand up meeting

    Short (no chairs)

    Communicate problems and solutions

    Promote team focus

    Encourages communication between whole team

    Replaces tedious meetings (can determine if private meetings are necessary, can remove need to even schedule official meetings)

    Nearly immediate heads-up if individual is overloaded

    Promotes collective understanding of system, sharing

  • Any developer can add functionality, fix bugs, or refactor

    Reduces chance of one person becoming a bottle-neck

    - Move people around to promote cross-training

    Pair programming (proactive peer review)

    - One thinks tactically about method, other strategically about system

    Requires unit testing

    - drives design; test first design ensures the simplest solution is built

    - results in higher quality software, easier to refactor safely

    Requires continous integration

    - ensures unit tests are passing, catches problems fast!

    - only one pair integrates at a time (sequential integration)

    Allows constant refactoring to improve system (no more crusty code!)

    Class, Responsibilities, Collaboration (CRC) cards are used find simple solutions to complex problems; use cards in informal design meetings

  • Don't plan with too much detail too far out. Set the right scope.

    Feedback is critical to ensure the project is on track.

    Most effective for responding to changing requirements and project conditions.

  • These are not necessarily separate people; can wear multiple hats.

    Programmer: code, refactor, unit-test; strive for simplicity, communicate

    Customer: domain expert, able to make decisions, write user stories

    Tester: liase with customer to write, run, and report functional tests

    Tracker: track estimates and schedule, log defects, provide feedback

    Coach: responsible for process as a whole, steer the team (hands off)

    Consultant: XP doesn't create specialists, hire them to teach team

    Big Boss: courage, communication, occasionally oversight

  • Consultants love it because it leads to higher customer satisfaction by involving customer throughout project.

    Same thing with custom software or in-house development.

    But shrink wrap software usually has diverse customer base

    Already do insane peer review & quality control -> space shuttle coders

    Nailing down all four project variables, no place for XP feedback

    Most experience indicates 20-30 is upper limit on team size

    - Servidium had 30+ , New Architect article two teams of 50+ total

    - Can you split up a big team into XP sub-teams? Issues?

    Anecdotal evidence indicates that XP requires an experienced group of coders; junior teams don't do as well with XP

    What is the affect on traditional architecture and design process?

    What is the affect on traditional quality assurance process?

    Currently research at the U of C on Distributed XP (Frank Mauer)

  • Refers to scrum from rugby (team working to common goal)

    Originated in Japan in 1987 (Nonaka and Takeuchi)

    Mentioned in software context by Degrace and Stahl in 1990

    Applied to software by Schwaber and Sutherland in mid-1990's

    Undefined (unpredictable, complex, dynamic) processes require different manage & control than defined (which CMM assumes)


    Product Backlog: master list of all functionality (tasks and stories)

    - in order of priority with time estimates for each

    Sprint: an iteration (30 days) in which team has total freedom/responsibility to accomplish the goals

    Sprint Backlog: The portion of the Product Backlog the team selected for completion during the Sprint

    Tasks: Breakdown of items to complete to finish a sprint backlog item

  • Note absence of traditional roles like programmer, tester, architect, etc.
    Leads to discussion of Scrum team in next slide.

  • Like XP, Scrum uses cross-functional teams whose members have various strengths. All contribute.

    Like XP, requires a small team to enhance communication

    Inside sprint, team decides who will do which tasks, not dictated from management

    Important point: During a sprint, the team has full authority to make any decision to meet sprint goal (within org conventions and budget)

    Also have responsibility to meet the goal they have set for themselves.

    Scrum doesn't dictate engineering processes that team must use, could do XP, RUP, whatever as long as produce results.

    Use metascrums or “scrum of scrums” approach to scaling. Diagram shows 243 people in a number of scrum teams

    This approach has be scaled to over 800 people by Jeff Sutherland.

  • Really two separate meetings...
    First between team and product owner (and other observers):

    Product owner presents high priority items from product backlog

    With input from all, the team selects the backlog it can do in next sprint

    Identify a “sprint goal”: a short theme for the sprint (like XP's metaphor)

    Team publicly commits to completing backlog in coming sprint

    Second just the team and scrum master (product owner can observe):

    As a whole the team creates a Sprint Backlog of tasks based on the Product Backlog items committed to.

    Tasks should 4-16 hours of “ideal work” to accomplish (estimates)

    Team self-organizes to assign the tasks to each other

    Can modify sprint backlog throughout the sprint

  • Why daily? Brooks: “How does a project get to be a year late? A day at a time.”

    Short (~15 minute) meeting held each morning at same time (stand-up?)

    Only “pigs” can speak or ask questions, “chickens” just observe

    - Joke: A chicken asks pig to start a restaurant called “Ham 'n Eggs”. Pig says “No thanks. I'd be commited, but you'd only be involved!”

    Decisions: team has full authority to make any decision required to convert product backlog into product increment.

    Any items requiring further discussion should fork off follow-up meetings of just those involved.

    Scrum master plays role of meeting facilitator

    Create peer pressure to accomplish what you commit to...

  • Main project metric is hours remaining to complete in a sprint. This provides a good measure of team progress.

    If team finds itself overloaded in a sprint, it can call a meeting with the Product Owner to reduce that amount or scope of product backlog selected (like XP's snow-plowing)

    A sprint can be abnormally terminated:

    Management can decide sprint goal is no longer necessary

    Team can cancel sprint if they face major roadblock or sustained outside pressure to modify sprint goal from external sources

  • A Sprint Review Meeting should not become a distraction or significant detour for the team; rather, it should be a natural result of the Sprint.
  • Empirical process control: better suited to complexities inherent in software development (more agile than CMM for example)
    Team controls their destiny: team sinks or swims together, have full authority and responsiblity -> allows good teams to be very productive

    Socialization and knowledge transfer: team develops strong ties, open environment and scrum meeting lead to good knowledge transfer, pecking order in team changes minute to minute based on knowledge/expertise

    Risk management: reduces risks of poor estimation, low customer satisfaction, not meeting commitments, not resolving issues, contanstly changing requirements

    Management: requires management sponsorship and buy-in

    Result varies between teams -> assumes you have good people who can work more productively (always hire the best you can get)

  • XP and Scrum are complementary:

    XP is an engineering methodology (propeller heads)

    Scrum is a project management methodology (PHBs)


    Ken Schwaber

    Applied by TransCanada Pipelines on their development projects

    - 300 people working on three large projects

    Scrum manages project while XP ensures high quality


    Mike Beedle

    Evolved from supporting multiple projects which resused components

    Can bridge gap caused by splitting up XP teams?

  • Alistair Cockburn

    Hired as a consultant to IBM in '90s to determine best methodology:

    - found successful teams apologizing for not following the process

    - found failed teams thinking they didn't apply process correctly

    Devised a family of Agile Methodologies for different projects

    Reliance on people, communication, and frequent delivery of running code.

    The methodology for 2-6 person projects is Crystal Clear, for 6-20 person projects is Crystal Yellow, for 20-40 person projects is Crystal Orange, then Red, Magenta, Blue, etc.

  • Does more in the way of documentation (particularly UML) as done by Peter Coad of TogetherSoft.

  • Three non-linear, overlapping phases in ASD.

    Highsmith views planning as a paradox in an adaptive environment. (Draws heavily from chaos theory for his work)
  • Calgary is hot-bed of Agile development right now both in industry and at the U of C.

    Next presentation:

    November 21 (6 -7 pm )

    Agile Methods and Design: is software a big enough town for both of them?
    Martin Fowler (ThoughtWorks guru)
  • Tracks:

    User stories


    Project velocity

    Developer tasks

  • Agile Software Development Methodologies

    1. 1. Agile Software Development Revenge of the Programmers? Guy Davis – Pason Systems 1 10/01/09
    2. 2. Overview Agile Manifesto eXtreme Programming (XP) Scrum XBreed, XP@Scrum, Crystal, dX, FDD, ASD Agile Resources 2 10/01/09
    3. 3. Agile Manifesto Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan 3 10/01/09
    4. 4. eXtreme Programming (XP) Core Values Project Variables Communication Cost Simplicity Scope Feedback Time Courage Quality 4 10/01/09
    5. 5. Key Practices of XP 5 10/01/09
    6. 6. XP Process 6 10/01/09
    7. 7. XP Iteration 7 10/01/09
    8. 8. XP Development 8 10/01/09
    9. 9. XP Collective Code Ownership 9 10/01/09
    10. 10. XP Planning 10 10/01/09
    11. 11. XP Roles Programmer Customer Tester Tracker Coach Consultant Big Boss 11 10/01/09
    12. 12. XP Limitations Good for consultants, custom software dev. What about other types of software dev.? Shrink-wrap software? Misson or life critical systems? Fixed price, fixed scope contracts? Scalability of the XP process to large teams? On-site customer possible for your project? Team must be co-located? Distributed teams? 12 10/01/09
    13. 13. Scrum 13 10/01/09
    14. 14. Scrum Roles Product Owner Solely controls the product backlog (prioritized) Arbitrates requests from all customers Does NOT control the sprint backlog Scrum Master Enforces the values, practices, and rules of Scrum Interface between developers and management Removes impediments for developers 14 10/01/09
    15. 15. Scrum Team No traditional roles Cross- functional Self-organizing Size: 7 people ± 2 Has both authority and Scaling Scrum Projects responsibility Can follow any 15 10/01/09
    16. 16. Sprint Planning Meeting 16 10/01/09
    17. 17. Daily Scrum Each team member answers three questions: What have you done since the last scrum? What are you planning to do before the next scrum? What got in the way of doing your work? Goals of this short meeting: Identify impediments slowing progress Make decisions collectively as a team Track team progress during the sprint 17 10/01/09
    18. 18. Sprint Burndown 18 10/01/09
    19. 19. Sprint Review Meeting Demonstrate functionality added during sprint Team, product owner, and customers attend Product increment is assessed against sprint goal Discuss successes and failures from last sprint Short prep time for team (~2 hours; no M$ PP) 19 10/01/09
    20. 20. Scrum Benefits/Drawbacks Benefits Empirical process control Socialization and knowledge transfer Team controls their own destiny Risk management Drawbacks Management not used to letting go of the reins Outcome dependent on the team (variable?) 20 10/01/09
    21. 21. XP/Scrum Hybrids 21 10/01/09
    22. 22. Crystal Light Methods Rank projects by # of people & error consequence Adapt your methodology to your project's need Use the least disciplined methodology that will still succeed 22 10/01/09
    23. 23. dX: Hybrid between RUP & XP An agile RUP-dervived approach (oxymoron?) Inception: use-case cards, prototypes, velocity Elaboration: iterative, UML, refactor, test Construction: indistinguishable from elaboration Transition: early release, active feedback Helping drive sales of Rational's tools ($$$) 23 10/01/09
    24. 24. Feature-Driven Development Deliver frequent, tangible working results A feature defines a task Group features into business-related sets Focus on delivering features every two weeks Track and report progress through feature progress Plan, build, and design by feature 24 10/01/09
    25. 25. Adaptive Software Development Short iterations Deliverable-centric instead of task-centric 25 10/01/09
    26. 26. Agile Resources Calgary Agile Methods User Group Monthly meetings at the U of C Books (tons of these on Agile topics) eXtreme Programming eXplained by Kent Beck Agile Soft. Dev. with SCRUM by Schwaber et al. Articles, discussion, information on the Web 26 10/01/09
    27. 27. Milos Agile Project Tool 27 10/01/09
    28. 28. References Beedle, Mike. XBreed web site (description page). 2002 Cohn, Mike. The Scrum Development Process. Mountain Goat Software. 2002 Cockburn, Alistair. Crystal Light Methods. Cutter IT Journal. 2001 Law, Amy and Keijin Huang. SENG 623: Scrum class presentation. 2002 Martin, Robert. Object Oriented Analysis and Design with Applications. 2001 Maurer, Frank. SENG 609.24: Agile Methods Class Slides. 2002 McBreen, Pete. SENG 609.33: Agile Testing Class Notes. 2002 McBreen, Pete. Questioning eXtreme Programming. 2002 Murthi, Sanjay. Scaling Agile Methods. New Architect Magazine. October 2002 Schwaber, Ken. XP@Scrum web site. 2002 Sliwa, Carol. XP, Scrum Join Forces. ComputerWorld Magazine. March 2002 Wells, Don. web site. 2002 28 10/01/09