Agile Software Development is a mindset, not a rules list.

I feel like Agile Software Development is one of the most misunderstood things when it comes to developing software. While I tried writing this post to be accessible to all software developers, I have struggled with ideas and principles behind Agile software development for the first couple of years, until I have seen several projects, teams and methodologies.

If you need a refresher, one can find the manifesto at the following link. Chance is that you have already seen this manifesto and gone through it looking for a reason to not write documentation.

While most people can name the 4 "main" things from the manifesto, I feel the need to point out the first sentence:

We are uncovering better ways of developing software by doing it and helping others do it.

Two best ways to get better at developing software

1. Doing it
2. Helping others do it

Be it mentoring juniors, making instructional videos, giving talks, or just plain blogging, helping others become better will likely help you too. Especially if you are part of the team, it makes all the sense to help a team get better as that will help you and your organization over time. Sometimes, even a discussion among peers will prove to be valuable for at least one party.

I had a job interview today. One of the questions that popped up was "have you ever designed a database for a big and complex project". And the truth is that I have never really designed a database for a big and complex project - but I was part of the team that did that collaboratively, and it was great. We spent some time on it, we all learned a bunch and we discussed a whole lot of plans and presumptions surrounding that project. The best part? In the end, we all knew the reasoning and ideas behind design decisions and could rely on each other to keep it up through the project lifecycle.

Principles behind the Agile Manifesto

For me, the principles are what you need to understand to really get into the agile mindset.

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

There is a lot to unpack here: obviously, we need to have a satisfied customer because that is what gets us paid. But customer success is also what keeps the customer coming back, and we need to make sure that the customer gets continuous value out of our software and that every new delivery increases the value provided. As I mentioned in my previous blog post, it is important to understand the value of each and every task you are starting, because that is one of the guarantees for success.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale.

Working software is the primary measure of progress.

I love it when I am part of the teams with the "Always ready to deliver" approach. We make minimal iterations, test them and review them. We must be ready to have working software delivered to the customer in a matter of hours. Maybe some features will be missing, but whatever we have as "stable", gets delivered. And what is considered stable and ready for deployment should really change very often. When you test and review often, both you and the business people can catch problems early. Obviously, end-users of the software must be involved in the development process, as they are the best judges of the value provided.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

The best architectures, requirements, and designs emerge from self-organizing teams.

Trust. Trust is at the core of the agile mindset. If you can not trust your manager, peers, or customer, everything just became much more complicated and slower. All the methodologies you see developed around Agile software development are tools of control that lower the need for trust. You need customers to trust you enough to tell you a problem that they need solved and not how they imagined you would solve it. You need to trust your team to make the best decisions collectively. And if you are a manager, please, for the love of computing and all that is bitwise, trust your team to do the job professionally.

And, maybe the most important principle:

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Just as software development is an iterative process, so is team development. If we do not reflect on mistakes made, how can we make sure that we will not make them again? Or even worse, if we do not reflect on what allowed miracles to happen, how will we have them happen again? Understanding the value of reflection is paramount if the team is to become better. I have been to one too many meetings where developers are there because someone told them to participate, and they do not look to contribute nor do they wish to discuss issues in detail. If you have people who care not for retrospectives, help them understand the importance. That way you helped them and the team.

Conclusion

While these are not all principles listed in the Agile Manifesto site, these are my picks for important ones. Once you understand what kind of professional value these bring to you and your team, you are on a very good path to having proper Agile mindset. Do you agree, disagree? Let me know in the comments, I LOVE discussing Agile.