Book Excerpt from "I Want To Be An ACP" - Four Values of The Agile Manifesto

This article is an excerpt from the Book - I Want To Be An ACP. 

It is from Chapter – 2: Agile Principles and Mindset. 

For the partial index of the book, refer: Book Index - I Want To Be An ACP.

********* 

Fours Values of  The Agile Manifesto

The Agile Manifesto has first noted the four values. The official site is: http://agilemanifesto.org/ 

So, what are the values? They are noted in the Agile Manifesto, as shown below.

2.3.2 The Four Values

Look at the wordings closely in the Agile Manifesto. They are not setting rules on values, but through experience in developing software have come to value. Also, look at the last line. They are saying while there is value on the items on right such as process, tools, documentation, contracts, plans, they value the items on the left (in bold letters) more. 

Now, let's take these values one by one. 

Value # 1: Individuals and Interactions OVER Processes and Tools

Software development is inherently based on people, who finally build the product. Processes are needed to get people started, but it is finally people who will build the software. Processes help people to build, not the other way around. 

Projects are undertaken by people, not by tools; architectures are defined by people, not by tool; it is people who decide on what “done” means for an increment and they finalize on which features to take, and how to break the feature down into tasks. These are not done by tools.  

Second aspect of this value pair is “interaction”, is also important. Products or solutions come to life by interaction among the individuals. The interaction and quality of the interaction matters. A team with high interaction among themselves matter more than a heavy set of process and tools without interaction.

But do note that processes and tools have their places and they are needed. But the emphasis is on individuals and interaction among individuals.

Value # 2: Working Software OVER Comprehensive Documentation 

As the saying goes: “Nothing speaks louder than code”, which I would extend to say “Nothing speaks louder than working code.” 

You can have all possible documentation – requirement documentation, design documentation, a lot of Java Docs (for Java/J2EE platforms), a lot of test related documentation. But if your code or software is not working – does all of exhaustive documentation, however great they may be, matter? Obviously not. 

It is working software, which the customer wants to have as it mainly delivers value to him or her. It is working software, which will be finally used by the user on a daily basis. It is ONLY working software which provides the final result and tells whether the team has been “building” something of value. Also, focusing on documentation distracts a developer or team member from the core goal – building valuable software. 

However, documentation has also its place. But the idea here is this: we need “just enough” or “barely sufficient” documentation. 

Value # 3: Customer Collaboration OVER Contract Negotiation 

Software development is highly complex and often unpredictable. The requirement churn in development process is also high. Contract, on the other hand, is a legal document and asks for any change request to be formally approved, managed and controlled.  

The focus in this value pair is on collaboration, not haggling over a contract. Collaboration brings the factor of community, highly interactive communication and relationship. Good collaboration also saves a difficult contract situation. 

Again, it doesn't tell that contract does not have value. They are needed. Rather, as this value tells – you need to be flexible and accommodating instead of being rigid on contract.

Value # 4: Responding to Change OVER Following a Plan  

As the saying goes in management: “Planning is indispensable, but plans are useless.” In real world projects (as also in daily life), it rarely happens that you exactly follow the planned course of action. You have to make changes to your plan – because changes are inevitable. 

Agile manifesto was initially created for software development, though nowadays used in many other product development efforts. Whatever the project may be – changes will happen as initial plan can’t factor in or foresee all the components, unlike a fully plan driven or waterfall projects. Also, in software development, high requirement churn is a reality. Hence, this value tells us to be responsive towards changes. 

But planning is needed and it can’t be avoided. Because planning sets the direction, gives a possible end date and lets you and your team members know what is expected to be executed at what point of time. However, responding to changes (or being adaptive) rather than having a fixed plan, is what matters.

Now let’s do some exercise. 

Note: Before checking on the answers, try to solve it on your own first. 

*********

This section on Agile Manifesto is further explained in the book with: 

• The Twelve Principles
• Exercise on how to remember all the 12 principles

It is further followed by fundamentals in Agile Project Management, Phases in the APM framework, Foundational concepts in Agile such as  Adaptive Leadership, Servant Leadership, Information Radiators, System Thinking, Various Agile and Lean frameworks/methodologies. These can be seen from the index of the book.

Other Excerpts from Book:

• Book Excerpt Book Excerpt from "I Want To Be An ACP" - Fundamentals of Value-Driven Delivery

Book Available for ACP Exam Prep:

• New Book for ACP Exam Prep: "I Want To Be An ACP"