Scrum is not an agile process. I am saying this to get your attention, but I am also saying it because there is some truth in the statement. Our development team has been striving for agility for years now. When I use the term striving, I am not implying struggling, rather I am implying that I don’t think “Agile” is something to be obtained. It is not an end goal, it is a behavior. Once you reach a point where your development processes are finalized and no longer changing, you are no longer agile. So if you want to remain agile, you have to keep looking for ways to improve your processes. You will never obtain that end state of how to develop software the best way.
I know. I know. Scrum includes retrospectives and through the retrospectives you identify process improvements to make. Therefore Scrum remains agile. That is true, at least for those few (apparently few) teams that make use of the retrospective. I think many teams don’t feel they have time for the retrospective and don’t believe they will have much value. Many scrum masters and former project managers get tired of tinkering with the processes and just want to know the patterns to be followed over and over. There is certainly benefit to habits and in knowing what to expect. But it appears that a lot of teams leave out the retrospective and therefore are probably leaving out the agility.
Even worse than the teams that skip the retrospectives may be the teams that seek adherence to scrum above all else. You know these guys from their posts on the blogs and message boards. They have taken scrum to heart and will not suffer anyone to criticize scrum in any way. Unfortunately it may be these people that are the least agile because they are not open to any process that is not part of scrum. I understand how this occurs. When a waterfall development shop seeks to improve their software development processes, they come to believe that scrum will provide such success, and they try fervently to adopt scrum. The danger for some is that they forget the ultimate goal is to write better software, not to adhere to scrum; and if the best software can be developed without 100% adherence to scrum principles, then you should ignore those principles that don’t work for you. Remember, the goal is to write better software. So skip those daily standup meetings, or change their content, or allow the scrum master to also be a developer or dba, or break any of the other rules of scrum if they are not working for you. Remember, an agile team is willing to try new things to find what works best. You are in a constant state of discovery. If someone tells you that you are not agile and not scrum because you aren’t doing a daily standup, just tell them that you don’t care because instead, you write great software.