Acorel
To Acorel.nl

Agile values

Riepko Beukema, 11 December 2019

At Acorel we frequently use Scrum during our projects. Scrum is a framework in which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value. While I could spend a whole blog describing the do’s and don’ts of Scrum, today I am going to dive into the Agile Manifesto. Agile describes a set of guiding principles that uses iterative approach for software development, Scrum is one of its implementations. On February 11-13, 2001, the agile manifesto was written by representatives from multiple software development methodologies who tried to find common ground. What emerged was the Agile ‘Software Development’ Manifesto:

 

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

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

That is, while there is value in the items on
the right, we value the items on the left more.

 

Individuals and interactions over processes and tools

Individuals and interactions over processes and tools is something I value greatly. A process can be very effective but having motivated people who interact with each other is what makes a process work. As a scrum master I try to have a kickoff with the team when we start a new project. People need to know and trust each other so that they can create the most value for the project. Give them the environment and support they need and trust them to get the job done. Part of the environment can be giving them the right processes and tools.

Working software over comprehensive documentation

I struggle with the guideline Working software over comprehensive documentation. In principle I agree that working software is more valuable than documentation. However, having a working product with insufficient documentation is a short-term gain but a long-term loss. It can also give problems during a project when a feature is built that is not in line with the wish of the customer. If an issue is unclear and not well documented, it can lead to a feature that is a disappointment. My colleague Koen van der Leur wrote a nice blog about Specification by Example that can help with preventing this issue.

The key here is in the word comprehensive. Documentation should not take valuable time away from development. I think a good example of this is that you should document where a product can be added to a cart, but not that the ‘+’ button will up the quantity of the product by one. Another good check is when you finish creating a new feature, check if you can still find how it works in another place then the code you just finished.

Customer collaborations over contract negotiation

Hell yeah, we want to work with the people we create the best customer experience for. That does not mean that a contract is no longer necessary. It is important to have a common view on what will be delivered and at what cost. It is very difficult to create the best customer experience without knowing the scope and requirements of a project. But if we find something that could improve the experience, we like to collaborate to find a way to implement it.

Responding to change over following a plan

This ties in neatly with the last line, responding to change over following a plan. I have yet to participate in a project where there have not been new insights during the project. By showing people early what you have created, feedback can be gathered, and new insights gained. Don’t keep your customers in the dark but show them as early and often the new features you are creating. If customers see improvements, listen to them and try to implement them during the project. Not all changes should be added immediately, while we want to respond to change it can be a very good decision to implement the change after the project is live.

For me the agile principles are guidelines to keep in the back of my mind. It boils down to working together and discussing how we can create the best solution for the problem at hand. As long as we work together towards a common goal, we can create the best customer experience.

Riepko Beukema

Read all my blogs

Receive our weekly blog by email?
Subscribe here: