Agile Introduction

Agile Manifesto Principles

The series you are reading currently is the Agile Introduction Series as part of the large set of Agile material. I find it useful to remind leaders, project manager and teams of these when necessary as part of coaching.

The article Agile Introduction Series - Agile Values overview forms the first part of this series. This page on principles is the second. Continue to review both the the value statements and principles as foundation to any agile transformation.

The principles as captured in the Agile Manifesto is presented below. Refer to the agilemanifesto.org site for more information.

Principles

The agile manifesto contains 12 principles

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

• Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

• Business people and developers must work together daily throughout the project.

• Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

• Working software is the primary measure of progress.

• Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

• Continuous attention to technical excellence and good design enhances agility.

• Simplicity–the art of maximizing the amount of work not done–is essential.

• The best architectures, requirements, and designs emerge from self-organizing teams.

• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

These principles are found in aspects of almost every agile methodology or framework you may choose for your team. The principles remains as valid today as they were when written and should be used to drive and lead agile teams and delivery processes.

Let’s review the principles briefly below.

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Shortest time to value delivered. Use lean startup and design thinking approaches.

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

Accommodating change responds to customer needs. Note that too much change will influence time, quality, and other factors. Offset this by considering other values and principles

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

This should need no further discussion when looking at the first principle above. I do discuss this more in summary in the slides and set of related materials.

Business people and developers must work together daily throughout the project.

Increased chance of success when working together and inspecting software regularly.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

High performing teams. Decentralise decision making. Consider other principles in relation to this to enable teams to get the job done.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Many frameworks and methodologies support through daily inspection and discussions. Avoid emails or escalation; Collaborate at the team level first and foremost.

Working software is the primary measure of progress.

This should need no further discussion when looking at the second principle above. I do discuss this more in summary in the slides and set of related materials.

Inspect the build regularly.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Sustainable. There is a plan. A backlog of work prioritized, consistent flow and delivery. Lean approaches are useful to support this.

Continuous attention to technical excellence and good design enhances agility.

Build quality. Testing aspects with automation preferred. Solution architecture supports enhancements and change. Automation of deployments to increase agility. Balanced against the principle ‘Working software is the primary measure of progress’, agile delivery teams can better support changinf requirements and additional feature development to deliver software in the shortest sustainable lead time with best quality.

Simplicity–the art of maximizing the amount of work not done–is essential.

I think I say this at least a couple of times a week. Focus on value, focus on work that delivers the outcome. Don’t gold plate or over engineer, but that doesn’t mean you shouldn’t architect the system to support additions later. Work not done is a lean approach to good quality and ensuring the team is not over burdenened with large amounts of stories that may not actually be needed. Build measure and learn. Iterate.

The best architectures, requirements, and designs emerge from self-organizing teams.

This doesn’t mean no architecture initially, or ignoring the architecture description. This still should be supported by an architecture vision, agile modelling and documentation sufficient to gain concensus. Update the documents regularly or they become useless. This will be discussed again in other series on https://methodolagile.architectfwd.com/series in time.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Continuous improvement is key to being able to continue to refine processes, eliminate waste, maximise the amount of work done (even doing it now to save time in future). Teams should strive for improvement, and thus this principle is significant.

Summary

The health of any agile team or project should be assessed in terms of how they use or do not use the agile principles in their chosen agile methodology.

I detail more aspects of each statement in the slides and related materials on this subject. A full slide deck and set of materials is being developed and will be made available available to discuss the value statements and principles as found in the agile manifesto, with key points of discussion noted for teams to consider. Email if you need a copy or would like agile manifesto values and principles presented to your team.