There are lots of different forms of “Agile” development – Scrum, Kanban, Extreme Programming, etc. When it comes to defining what “agile” is, it seems everyone has their own opinions. But the Agile Mindset is the same regardless of which form of Agile you use.
So, what is an Agile Mindset?
Well, lets start with what it is not. It is not thinking you can make changes constantly and still expecting progress to be made, and it’s not expecting the same work (development of same features and functionality) to be done in less time. It’s not thinking “We can’t release it until it’s all done, so it doesn’t matter if we do it now or later”.
The Agile Mindset is thinking iteratively, and working on the most valuable things first. It is breaking down features so the valuable pieces can get done, but the polishing that make it perfect are put off until later. It’s realizing that a user is happier with a functional feature that they can actually use without all of the polish than without the new feature at all.
It is accepting that no one knows what the final product will be until the final product is done. Ideas become clearer as you see the product being developed. Feedback from earlier users will drive changes during the development process. Embrace the changes and adjust with each iteration.
The Agile Mindset is realizing two heads are better than one. Involve the whole team (developers, testers, scrum master, business analysts, product owners, users, UX, designers, etc.) in creating solutions, and you will often end up with better solutions than if just one person (regardless of how good that one person is) is tasked with solving everything.
The Agile Mindset is understanding that Agile is not a development methodology. It is a change management methodology. Agile is simply a process for managing changes throughout the software development lifecycle.
It is pushing off low value items to the end of the project, and trimming items out of the project if the cost outweighs the value you would gain from it.
It’s understanding that changes will happen. Spending extra time to get things perfect early in the project often wastes time – because you spent extra time getting it just right, and then it changes and you have to spend the extra time making it just right again with each change. It’s better to get it functional and pretty good, and then make it “perfect” at the end of the project when changes are less likely.