Doing agile vs being agile
As a consultant even with my relatively small amount of experience I dislike the way that most teams and companies approach agile. They become focused on the practises and processes that often get taught when you introduce a team to agile software delivery. Using the common practices and processes is just one way you could enable an agile software delivery team, but to become a truly agile team you need to understand why these processes get used. You need to have some understanding of the agile manifesto and why these practices are important.
Agile isn't a process that you can just follow. There is value processes and practices that get introduced with agile but as a team or organisation try to understand why they introduced. Continuous feedback and continuous improvement is something I've always pushed for around the software we deliver, but it also needs to be applied the process and the practices that a team uses. No process is perfect and you shouldn't be afraid to change it, but make changes to your process in the same way you make changes to your software - small incremental changes with feedback.
Just the phrase 'do agile' frustrates me beyond belief, the fact that it doesn't work grammatically should be the first sign you're using the word in the wrong way. Agile is not a process to follow, it's not something you can simply 'do', it's something much deeper than that. Agile software development is about being fluid in what you do, it's about getting feedback early and often, and then responding to feedback. Of course the whole reason you want to do this is so you can deliver more value to your customers and do it quicker.
The most common way for a company to transition to agile software delivery is to start adopting new processes - iterations, story cards, stand ups, retrospectives, and so on. Often consultants will be brough in to introduce these practices. By simply adopting these practices you're taking the first step towards being an agile team, but it will not allow you to be agile unless you understand why these things are important. You need to come back to the agile manifesto -
"Individuals and interactions over processes and tools"
By adopting these practices you're simply replacing one process with another process. I've heard blindly following these practices referred to as following the agile process. I am not by any means saying you should get rid of this process, you probably need to have a process. However, that process should not be rigid and unchangeable, your process should revolve around people and the interactions those people have. The process should be something you change when you're not enough value out of it. The process should never be something you follow blindly, there is value in these processes but not without understanding why they're important.
My favourite measure of just how agile a team can be is how quickly can a team get a new feature (or even bug fix) into production. For example, the business has realised that they are currently in breach of a government regulation, how quickly can the team analyse the requirements for the government regulation, make the smallest change possible and release it into production. To do this the team needs to be able to quickly pivot to pick up the new work, they need to be able to work efficiently to complete the work, they need to have mature testing practises to ensure the changes are correct and they need to have a well established release process. I don't care what processes your team follows if you can do this quickly without compromising on quality or correctness (as verified by the business) you're doing well. There is one thing missing still and that is the fact that you should never accept the status quo and should always being looking at ways to improve this. Regardless of how good you are you can always improve.
Agile isn't a process that you can just follow. There is value processes and practices that get introduced with agile but as a team or organisation try to understand why they introduced. Continuous feedback and continuous improvement is something I've always pushed for around the software we deliver, but it also needs to be applied the process and the practices that a team uses. No process is perfect and you shouldn't be afraid to change it, but make changes to your process in the same way you make changes to your software - small incremental changes with feedback.