Agile Principles

Principles from the Agile Manifesto

The Agile Principles, Agile Manifesto and Agile Values provide orientation for working with Agile Practices and shape the Agile Mindset.

manifesto is a published declaration of the intentions, motives, or views of the issuer, be it an individual, group, political party or government. [[ 1 ]](https://en.wikipedia.org/wiki/Manifesto#cite_note-1) [[ 2 ]](https://en.wikipedia.org/wiki/Manifesto#cite_note-2) [[ 3 ]](https://en.wikipedia.org/wiki/Manifesto#cite_note-3) [[ 4 ]](https://en.wikipedia.org/wiki/Manifesto#cite_note-4) 

The Agile Principles behind the Agile Manifesto provide orientation for the described views of the Agile Manifesto and help to align agile methodologies.

With absence of principles the agile practices are often inappropriately used.

A team that uses the agile practices to help attain the goal of building working software that customers value through interaction, collaboration, and responding to change will get more out of their projects than the team that simply adopts better planning, programming, and documentation practices.

[[ Learning Agile ]] (p38)

Delivery

  • Principle #1: Our Highest Priority Is to Satisfy the Customer Through Early and Continuous Delivery of Valuable Software.
    • release software early
    • deliver value continuously
    • satisfy the customer
  • Principle #2: Welcome Changing Requirements, Even Late In Development. Agile Processes Harness Change for the Customer’s Competitive Advantage.
  • Principle #3: Deliver Working Software Frequently, from a Couple of Weeks to a Couple of Months, with a Preference to the Shorter Timescale.
    • key to welcoming changes

Communication and working together

  • Principle #4: The Most Efficient and Effective Method of Conveying Information To and Within a Development Team Is Face-To-Face Conversation.
    • considering that documentation is one form of communication too
    • Overly comprehensive documentation increases the risk of ambiguity, misunderstanding, and miscommunication between team members.
    • when people look at a topic in a similar way and communicate openly they work with a shared perspective
  • Principle #5: Businesspeople and Developers Must Work Together Daily Throughout the Project.
    • a project should be valuable enough to that business people and developers can see that it is worth putting the effort to collaborate
    • teams should prioritise most valuable items first so that business people can get value delivered
  • Principle #6: Build Projects Around Motivated Individuals. Give Them the Environment and Support They Need, and Trust Them to Get the Job Done.
    • everyone on the agile teams feels responsible for the project and accountable for its success (being the pigs and not chickens)

(Project) Execution

  • Principle #7: Working Software Is the Primary Measure of Progress.
    • working software and regular demonstration of it can replace (huge portions of) status reports
  • Principle #8: Agile Processes Promote Sustainable Development. The Sponsors, Developers, and Users Should Be Able to Maintain a Constant Pace Indefinitely.
    • working with iterations
    • closing feedback loops e.g. via Dailies and Retrospectives support that
  • Principle #9: Continuous Attention to Technical Excellence and Good Design Enhances Agility.
    • therefore software becomes fast to deliver and change

Improvement

  • Principle #10: Simplicity — the Art of Maximizing the Amount of Work Not Done — Is Essential.
    • comparison to construction work fails as in software things can be change far easier and also be reverted easily
    • The most destructive thing you can do to your project is to build new code, and then build more code that depends on it, and then still more code that depends on that, leading to that painfully familiar domino effect of cascading changes…and eventually leaving you with an unmaintainable mess of spaghetti code.
    • Agile teams keep their solutions as simple as possible by avoiding building unnecessary features or overly complex software
  • Principle #11: The Best Architectures, Requirements, and Designs Emerge from Self-Organizing Teams.
    • When a team is self-organizing, it means that they work together to plan the project (instead of relying on a single person who “owns” the plan), and they continually come together as a team to revise that plan.
    • Self-organizing teams share responsibility for all aspects of the project, from conceiving the product to project management to design and implementation
  • Principle #12: At Regular Intervals, the Team Reflects on How to Become More Effective, Then Tunes and Adjusts Its Behavior Accordingly.
    • The only way to become more capable as a team is to constantly look back at what you’ve done so far, to assess how well you’re working as a team, and to come up with a plan for getting better.

Linking

Enjoy this post? Buy me a Coffee at ko-fi.com

Notes mentioning this note