/ AGILE
 / 10.59350/mm6ch-4za33

Agility

By Petar Milošević CC BY-SA 4.0 (https://creativecommons.org/licenses/by-sa/4.0), from Wikimedia Commons

I just stumbled over a nice post and became inspired writing about agility in our teams, how we got there, how we use it and how it may fail.

The intellectual foundation for becoming agile in a software development group, is to internalize the “Manifesto for Agile Software Development ”.

Starting the transition

We started off with a new project about 4 years ago and some people that were keen on changing the way we worked in the past. How did we work in the past? Well, our issues were mainly too long lasting projects, bugs and implementations the way the customer didn’t want to have them. In many projects only one person was responsible for everything, from talking to the customer to get the requirements, to coding everything. That didn’t work out and the need for a change emerged.

To have a scaffold for the colleagues we chose Scrum as an agile framework. With the introduction of Scrum we established the groundwork for the agile way. We embraced daily stand-ups, sprint plannings, reviews and retrospectives. Project leaders became “Product Owners”, a “Scrum Master” role was created, as well as everything that was useful to become agile.

For sure, there were concerns having much more meetings than before, but all these meetings are well established and part of our agile success, and also the customers were quite happy to be involved and have results after each iteration (sprint).

Technical Issues

One principle of the Agile Manifesto is

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

With that in mind, we created environments to make it easy for developers to add their code to the main code repository, that automatically gets deployed to a development server, where all team members and the customers may see the current state of the project at any time. Tools such as git, Vagrant, Jenkins helped us initally, but our development and production infrastructure are also victims of the agility, so we dropped Vagrant in favour of Docker, that we use in development and production, and replaced Jenkins with Gitlab CI.

So, for keeping this part short, each change in the source code repository is available on a server in a few minutes. Getting everything that was done in a sprint onto a live server is just a git tag and git push --tags command away.

Human Issues

All these artifacts and technical wizardry are worthless, if the mindset is a fixed one, as described in the article mentioned above. Solving this may become hardest task in the agile switch. Agile Evangelists, Coaches and Scrum Masters can help there, but it’s also on the team members to continuously learn about new things in their area, that change is not a negative thing and failure is a great way to become better and better in the job they do.

Are we done yet?

Never ever! One of the key principles is to inspect and adopt the way we work, become better and resolve the things that don’t make us happy developers.

I want to conclude with the headline of the article that inspired me for writing this one:

Agility: It’s a mindset, not a process.