As part of the Agile Introduction Series, a new article on Agile Principles from the Agile Manifesto is available. I believe a foundation in these values and principles is useful before moving on to methodologies, frameworks, conventions or further ways of working are discussed.
Agile Manifesto Principles
The Agile Introduction Series - Agile Values overview describes the values. The Agile Manifesto then proposes a set of principles, which forms the subject matter of this article and post..
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. Going back to the value statements and principles is helpful when guiding the why, especially if agile is new, agile ways of working or agile workstreams are not going as expected.
The Principles from the Agile Manifesto is presented below. Refer to the agilemanifesto.org site for more information. I include my own commentary where useful to guide how the principles should be used.
I’ve repeated here what is written there in the Agile Principles from the Agile Manifesto article.
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.
Note: I’m repeating my own commentary below from those on the Agile Principles from the Agile Manifesto article. The article may continue to receive further updates as I go. 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
I detail more aspects of each principle in my slidedeck on this subject, call out if you’d like to see it as it is developed.
The Agile Introduction Series - Agile Values overview page will be updated with more material so refer to that page for more info on this aspect of agile.
Certified Scrum Master (PSM I). Agile Coach. Mentor, Architect. My core skills are in agile, architecture, solutions, strategy, consulting, team leadership, coaching and mentoring. I have over 20 years experience in solving business problems and maximising opportunities through technology in a variety of industries.