Or the moment when trend beats logic. A while ago one colleague of mine wrote a very interesting article about best practices on Agile methodologies. If looking at the title you would expect a set of rules which would allow you to be the best Agile person on the planet, we pleasantly discover that in real life these rules are actual guidelines and adaptations to thousands of different situations. This article made me a little more aware of the next situation: how many times did you actually hear somebody saying: "On my project we implement Scrum 100%". It"s like somebody would say "I have a perfect life". It happens only from time to time and not on Earth.
I am working based on Scrum principles for almost 8 years now. I was involved in a few projects and also had the pleasure to discuss with a lot of people outside of current work: friends in the domain (where else can I have friends if not "in the domain"?) and also in a lot of interviews. I don"t recall somebody saying ever that works in a perfect Scrum environment. There is always something missing. Can be one daily meeting in a week that the team decides for a good reason not to hold it. Can be related to product owner role which is not well defined: sometimes we found him on client side but after 2 weeks work with him we clearly see that he is not an actual product owner. Sometimes the product owner can be on our side, knowing very well what he is doing, but again is not good because is not on client side. Can be the retrospective meeting which again for a good or bad reason is taking place only once at two iterations (not by the book). Let me try to go in more detailed with three examples where adapting overrules the theory.
First example would be related to sprint length. If we take 3 different teams with sprint lengths of one week, two weeks, three weeks and ask the team members the question "How long is your sprint?", in all three cases, almost every time, the answer would be "I know it"s not perfect Scrum, we work with x weeks sprint. Who"s saying it"s not perfect Scrum? I know there are a lot of debates on forums about this, and the bottom line would be that it"s all about the regular cycle of delivering not the length of the cycle. The context is the key to define this. We have a case where client changes the priorities very often based on the need of his clients. We found out that this works out great with one week sprint. And that"s fine. We have another client which is able to provide clean requirements for three weeks work and that"s how we go. We have two different contexts, two different situations, very good results on both. It is all about analyzing the right context, the right solution for that context, it"s all about adapting. Guidelines are great as a baseline but from there agile word comes in.
Another situation I encountered very often is related to end of sprint meetings. Basically we would tend to have sprint review meeting and retrospective meeting. Now the funny thing comes up. Based on the fact that 63% of the statistics are actual random numbers, I can precisely say that 80% of people I"ve talk with are not satisfied about the end of sprint meetings. Either because the name is wrong (because the etiquette is so important, isn"t it?) either for minor stuff like: it"s not a real sprint review meeting because the client goes through what was done not us (and how proud we are when we present the result of our work and in the same time the feelings we have when we say "it perfectly worked until now, something must have gone wrong at the last merge before the demo" are unmatchable and we won"t trade them for anything). The table which stores the retrospective ideas has the wrong header; we use to have totally different notations in a previous project. Tight to notation, people tend to forget the scope which is: review the work, present it to stakeholders, plan what was not complete and improve the process. I"ve seen projects where a better efficiency was obtain when client accepted the stories during the sprint so that the sprint review meeting would have been redundant. I"ve seen project where the retrospective meeting was done only once at 3 iterations. All was dictated by the adaptation to the context and there were successful cases. And as a small cherry on the top: if the ideas on the sprint retrospective remain just ideas on a table, and they are not actually reviewed and used as a starting point for next process improvement and we are doing the sprint retrospective just to mark another scrum "must to have", it"s not the end of the world if we don"t do it anymore. Dump the waste. Save the time for something you find more useful. But please don"t complain after that.
The most controversial sample came into my mind in an internal discussion with my colleagues. How and when do you integrate QA process into the sprint? Performing a quick retrospective over the projects I"ve been part of and also remembering lot of discussions on these theme, I was able to quickly enumerate several different approaches: part of the stories and story estimations; decoupled of story but in sprint cycle; decoupled by stories and scheduled for next sprint cycle; in sprint cycle scheduled at the end of iteration; in sprint cycle scheduled after each tasks and many more. Could be a code feature freeze faster that sprint cycle ends in order to allow bug fixing at the end or there is no such thing. If for sprint length the number of possibilities is somehow reduce to mainly 1-2-3 weeks (anyway very limited) in this case we can have ten different approaches for ten different teams. And each one might be correct; each one could have found what was suitable in that context. Honestly sometimes I wish I have owned the recipe for this because finding what is suitable for the context is not easy, but where would have been the pleasure than? And most important, once you tried something and doesn"t work, don"t be afraid to change. Afterward it"s agile.
In all these situations people tend to forget the end result. Is the team working well together? Does the team deliver what they plan to deliver? Is the client happy? No, what matter the most is that the trend, a perfect scrum world on which we all are dreaming, is not met. And of course the human nature which most of the time is resistant to change. Most people prefer to stick to the easy way, to stay on the safety net and refuse to meet the actual scope of this methodology: to be agile. Logically, if the answer is yes to the above questions and you don"t know that everything that happens now in the world follows the pattern: groom, plan, act, meet daily to confirm that you are acting, show, put down what you learned and do all this in cycles by x weeks, then yes, everybody would be happy. Everybody would be happy that they are doing the right thing, which means actually thousands and thousands different right things.
Bottom line for all this is that we shouldn"t be afraid of adapting, because that is what agile means. We want to be Scrum followers and that"s perfect. But let"s not be so tied to the trend and to the concept that we forget that Scrum comes near the Agile word. It"s ok to start with the Scrum mindset. It"s perfect when we don"t have to change a bit and everything works like a charm. But realistically this doesn"t happen. It"s ok to adapt, to improvise and to find the right implementation for your solution. It"s also what the books are stating but everybody passes very fast through these lines in order to find the rules that would lead them to the perfect Scrum. Start with the concept, see how it works, and find the right way for you which will allow you the best achievement of your targets in the given context. That would not make you less trendy, that would not exclude you from the Scrum world but that will very probably make you more efficient and happy with what you are doing.