Summary of Agile Principles and Practices

A while back I put together a summary of agile principles and practices that I would like to now share with you here:

Principles of Agile Methods

From the "Manifesto for Agile Software Development"

• Customer Satisfaction
  • Through early and continuous delivery of valuable software.
• Welcome changing Requirements
  • Late changes are a customer's competitive advantage.
• Deliver Frequently
  • Every couple of weeks to a couple of months. Shorter timescale is preferable.
• Business and Development interact daily
  • Fast changing requirement require fast communications
• Motivated people, environment and support
  • Build projects around the people provide them with what they need and trust them to get the job done.
• Face-to-Face Communications
  • The most efficient and effective method to convey information.
• Working software is progress
  • The primary measure of progress
• Sustainable Development
  • Processes must enable the sponsor, developers, and users to maintain a constant pace.
• Quality Throughout
  • Continuous attention to quality means technical excellence and good design, both enhance the agile process.
• Simplicity
  • Do what is necessary, don't overbuild, minimize the amount of work to be done.
• Self-Organizing Teams
  • Self organized teams produce the best work.
• Self-Adjusting Teams
  • At regular intervals the team must review and adjust its own processes.

Scrum

Roles

• Product Owner
• Scrum master
• Users
• Team Members
• Stakeholders

Process

• Sprint Planning Meeting
• Daily Scrum Meeting
• Product Increment
• Sprint Review
• Sprint Retrospective
• Update Product Backlog

Artifacts

• Product Backlog
• Product backlog burn down
• Sprint backlog
• Sprint backlog burn down
• Product backlog delta report
• Impediment list

XP Extreme Programming

Values

• Communications
• Feedback
• Simplicity
• Courage
• Respect.

Roles and Responsibilities

• Programmer
  • Writes tests then code.
• Customer
  • Writes stories and functional tests.
• Tester
  • Helps customer write tests them implements them.
• Tracker
  • Provides feedback on estimates and the iteration process.
• Coach
  • Responsible for XP processes.
• Consultant
  • Supplies specific knowledge as needed.
• Manager
  • Makes decisions.

XP Phases

• Exploration
  • Customers write requirements as story cards
  • Team education with tools, technology, and techniques.
• Planning
  • Set priorities of stories and plan content of release.
• Iterations To Release
  • Produce working software for stories in multiple short iterations leading to a release.
• Productionizing
  • Provide extra testing and checking before release to customer.
• Maintenance and Death
  • New iterations and no more customer stories.

Practices

From Extreme Programming Explained, Kent Beck, Addison-Wesley, 2000.

• "The Planning Game—quickly determines the scope of the next release by combining business priorities and technical estimates. As reality overtakes the plan, update the plan.
• Small Releases—Put a simple system into production quickly, then release new versions on a very short cycle.
• Metaphor—Guide all development with a simple shared story of how the whole system works.
• Simple Design—the system should be designed as simply as possible at any given moment. Extra complexity is removed as soon as it is discovered.
• Testing—Programmers continually write unit tests, which must run flawlessly for development to continue. Customers write tests demonstrating that features are finished.
• Refactoring—Programmers restructure the system without changing its behavior to remove duplication, improve communication, simplify, or add flexibility.
• Pair programming—all production code is written with two programmers at one machine.
• Collective ownership—anyone can change any code anywhere in the system at any time.
• Continuous integration—Integrate and build the system many times a day, every time a task is completed.
• 40-hour week—Work no more than 40 hours a week as a rule. Never work overtime a second week in a row.
• On-site customer—Include a real, live user on the team, available full-time to answer questions.
• Coding standards—Programmers write all code in accordance with rules emphasizing communication through the code."

Other Primary Practices

• Sit Together
• Whole Team
• Informative Workspace
• Energized Work
• Pair Programming
• Stories
• Weekly Cycle
• Quarterly Cycle
• Slack
• Ten-Minute Build
• Continuous Integration
• Test-First Programming
• Incremental Design

Corollary Practices

• Real Customer Involvement
• Incremental Deployment
• Team Continuity
• Shrinking Teams
• Root-Cause Analysis
• Shared Code
• Code and Tests
• Single Code Base
• Daily Deployment
• Negotiated Scope Contract
• Pay-Per-Use

Lean Programming

Practices

• Eliminate Waste
  • Eliminate anything which does not add value to the final product.
• Minimize Inventory
  • Requirements and design documents must be kept to a minimum to maximize development flow.
• Maximize Flow
  • Small but complete portions of a system are designed and delivered throughout the development cycle. Additional sets of features are added with each iteration.
• Pull From Demand
  • The ability to make decisions as late as possible provides a competitive advantage.
• Empower Workers
  • Drive decisions down to the lowest possible level, providing both the tools and the authority for people in the team to make decisions.
• Meet Customer Requirements
  • Develop core features early and obtaining customer feedback by iteration. Design to easily adapt to changes over the software lifecycle.
• Do it Right the First Time
  • Write the tests first, and then write the code. Refactor to improving the design of existing software in a controlled and rapid manner.
• Abolish Local Optimization
  • Focus on rapid development and solving the end-user problem. Scope will manage itself when the project is driven in time buckets that are not allowed to slip.
• Partner With Suppliers
  • Adversarial relationships are created by focus on scope, cost, and contracts. Partner with fewer suppliers, vendors can then focus on providing the best possible software for customers.
• Create a Culture of Continuous Improvement
  • Iterate and follow:
    • Plan:     Choose a problem. Analyze it to find a probable cause.
    • Do:        Run an experiment to investigate the probable cause.
    • Check:   Analyze the data from the experiment to validate the cause.
    • Act:     Refine and standardize based on the results.

Context Driven Testing

Principles

• The value of any practice depends on its context.
• There are good practices in context, but there are no best practices.
• People, working together, are the most important part of any project's context.
• Projects unfold over time in ways that are often not predictable.
• The product is a solution. If the problem isn't solved, the product doesn't work.
• Good software testing is a challenging intellectual process.
• Only through judgment and skill, exercised cooperatively throughout the entire project, are we able to do the right things at the right times to effectively test or products.

References

http://www.agilemanifesto.org

http://www.agilealliance.com

http://www.controlchaos.com

http://www.extremeprogramming.org

http://www.poppendieck.com/lean.htm

http://www.context-driven-testing.com