Scrum is not agile!

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.

My plane is not flying in a straight line

I see a lot of tension during software development between getting a feature 100% right and getting something out the door.  The merits for “doing it right” should be obvious, but some developers fail to see the merits of “not 100% right, but something we can release”.  This problem is analogous to flying a small plane around the world.  One could argue that you should take the most direct and shortest route. However, if you choose to do so, you may find that your plane has run out of fuel before you complete your journey.  To successfully navigate the globe, you must take a course that is “less than optimal” because you need to make stops at fueling stations along the way.  Your plane expends extra fuel because it deviates from the straight line to get to the fueling station, and it expends more extra fuel because it must alter course after fueling to get back to the optimal path.  In software development, sales of your software may be your fuel, or customer satisfaction may be your fuel.  Either way, there are benefits to releasing software that still has known bugs.

This scenario, like many software development scenarios, depends greatly on context.  If the software maintains a life support system and is producing errors, it may be unacceptable to ship the software.  If the error is that a caption is misspelled, then it may be acceptable.  In my own experience, the owner of the software ultimately makes such decisions.  It is the software owner that should decide if the software should be released on the promised date with bugs, or delayed to a future date in which hopefully those bugs will be fixed.  For many deadlines our software team has elected to spend our last week adding a new feature instead of fixing all the bugs in other features.  This is not to say that this decision is best for your environment, but for us it was more important to get the features out and get feedback on them than to have them 100% polished.  Some features we release are not adopted or clients desire significant changes to them to be satisfied.  In those cases, we saved a lot of time by sending out what we had instead of spending additional weeks or months to polish to perfection a feature that would not be used.