Putting the Agile Values into practice

Key messages

Agile Manifesto

Compass when making decisions

Transformation and Project Management Practice

The author of this articlePieter Van Brussel - Project Manager
The Agile Manifesto is seen by many practitioners as the Holy Bible of the Agile Movement. The values described in the manifesto offer interesting contradictions. It is a matter of priorities. We think the values on the right are important, but we give a higher priority to those on the left.

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

The agile values are the perfect compass to guide you in your agile transformation journey.

As members of the TriFinance Transformation & Project Management practice, we advise clients who are starting their agile journey to keep these values in the back of their heads. They offer a good compass when decisions need to be taken. Does this decision bring us closer to or move us further away from a truly agile way of working?

In the following text, we describe cases we experienced during our recent projects where the four values influenced our decision making.

Individuals and Interactions over Processes and Tools

Processes and tools are definitely necessary to structure and organize a company’s activities. But they shouldn’t replace the valuable team interactions.

One of the recent teams I worked in was moving tickets in the Kanban tool instead of talking to each other about the progress. This resulted in miscommunication, user stories that stalled for days and an unachieved sprint goal. We solved it by focusing on individuals and interactions. We created a physical Kanban board. It required people to get up when a task was done. Also, fewer tickets were created, and more tickets were discussed as a team.
In a Scaled Agile organization, user stories trickled down from the program layer as a result of feature analysis. As a Product Owner, I often found user story tickets on my backlog that just appeared from nowhere. It wasn’t until we discussed the goal, ambition and scope of the feature that the stories made sense and got prioritized. 

Working Software over Comprehensive Documentation

One of the beating sticks for Agile is often linked to this pair of values: no documentation.
Of course, this is not true. This contradiction emphasizes that working software holds more value than extended documentation. The only documentation that is needed is documentation that brings real value e.g. system documentation, requirements explanation, user notes & FAQ,...

A team documented all its automated test cases. They had thousands of documented cases. As the company wanted to update its UI design, this documentation became a hindrance. The effort to update all test cases increased the workload for the redesign features enormously. In the end, the team abandoned the current documentation strategy and moved on, adopting a documentation strategy that was maintainable.
A team included “high-level architecture” and “dependency analysis” in their Definition of Ready. Without those documents, they wouldn’t even look at the feature. However, they didn’t take into account that they were best positioned to determine the architecture and identify the dependencies. By focusing on the (absence of) documentation, they couldn’t deliver value.

Customer Collaboration over Contract Negotiation

Contracts and formal agreements are, just like processes and tools, important to organize and structure your activities. But they shouldn’t come in the way of close customer collaboration.

The (internal) client wrote an extensive requirements document for the team to follow. He emphasizes that the document is complete and that everything needs to be built as described. The requirements were written while the client took several assumptions that afterwards proved to be wrong. It also described solutions instead of real clients needs. By starting a conversation and collaborating with the client, we managed to show that the requirements were not optimal. We removed several requirements and created new ones that delivered more customer value.
We had to integrate a supplier’s software into our application to deliver a feature. The software didn’t exactly do what its documentation described. By collaborating with the supplier, we solved the issues and a new version of the software was provided after which it quickly integrated into our system. If we would have focused on contract negotiation and we contacted the procurement department who was in contact with the supplier, it would have taken a lot more time, and maybe not for the same result.

Responding to Change over Following a Plan

True agility requires the ability to swiftly adapt to changes and will help a company react successfully to changing clients’ needs, changing market conditions, new competitors or the emergence of new technologies.

The release process in financial institutions usually is very rigorous. When a major production incident popped up in our department, it delayed the release preparations resulting in missed milestones for the release process and the whole organization lost its guidance. The release was troubled as the organization couldn’t respond swiftly to the hiccup. The plan couldn’t be followed as described, resulting in many issues further down the line. Working in a more agile way would have helped to quickly respond to changes. The release process would have been more flexible with features that could have been added or removed from the release easily.
We delivered the first feature of a larger epic. One month after go-live, zero users had actually used the feature. Instead of following the plan and delivering the next features, we got back to the initial plan and questioned some assumptions. Together with the marketing department, we created an action plan to spur the feature adoption. Depending on the results, we will decide if we will continue building features for this epic, or kill it all.
The agile values as defined in the manifesto are already two decades old but they are still relevant in showing you the direction to improve. Whatever choice you make, always keep the values in the back of your head. By doing so, customer value will always prevail.

How are the Agile Manifesto and values supporting you in your decision making? Do you consider them when going for continuous improvement?

Want to know more?

Written by Pieter Van Brussel, Project Manager at TriFinance Financial Institutions and member of the Transformation and Project Management Practice.

About the Trifinance Transformation and Project Management Practice
For those interested in agile, FI’s Transformation and Project Management practice is, among other things, involved in better understanding agile and applying its knowledge on the subject at the client-side. Its members use their experience in project management, business expertise and business transformation to successfully complete projects and to give support to other TriFinance consultants in their work.

Our other sites

The author of this articlePieter Van Brussel - Project Manager

Grow your career

Come join us

Expand your business

Let's work together

Sign up for the latest industry insights
Set preferences