The first time I met Sam, who interviewed me in order to implement Scrum in his 200-developers company, he began with the declaration: "I know, scrum is all about iterations, we are already working in short iterations, maybe too short iterations, of one week"! First of all I answered him that Scrum is NOT all about short iterations, but about teams. One month later I audited the company. The results did not describe a regular company working in iterations; definitely not. But each single person I talked with began with the fact that they were working in short iterations, and in fact that each one in the company suffered from these short iterations. One month later I began to escort this company. Very quickly, the situation there, concerning iterations remembered me the tale of "The Great Atheist" I was told years ago by R. Leon Askenazi (also known as Manitou).
During the era of the enlightenment movement in central Europe during 19th century second half; a young student wanted to go to learn directly from the guru, The Great Atheist. He was told that we will be able to find him in Spadovska, a needle-head point village on the map. Resolute to meet him, our young student travelled to Spadovska. Going down of the diligence, he asked a local habitant where he could find The Great Atheist. The autochthon answered that obviously he can be found in the synagogue. The student asked the native if he was sure, after all he was speaking about the Great Atheist, and a synagogue is certainly not a proper place for such a genius; but he was answered with such an absolute conviction that actually he WILL find him in the synagogue, this little building at the end of the grand-rue. Much astonished, our student enters the synagogue, and sees only an old bearded man plied on a pile of old books learning with assiduity the holly texts. He asks him "tell me old man, where can I find the Great Atheist?"; "and why are you looking for him young man?" asks the old man; "I came from very far to learn directly from his lightened mouth" say the young student. "If so, please hear that I AM the Great Atheist! ". Much astonished, our student "you are the Great Atheist. Unbelievable! I imagined you a bit different. Will you teach me?" "Why shall I teach you?" asked the Great Atheist. " "Because I'm your most fervent pupil. I'm totally atheist!" " Wait", continued the Great Atheist, "do you know kabala? Do you know Talmud "Of course not, I'm atheist"! ?" "do you know your bible? Commentaries?" "Of course not, didn't I told you, I am a fierce atheist!"
"YOU FOOL, YOU ARE NOT AN ATHEIST!" ,said the Great Atheist, "YOU ARE IGNORANT!"
This is the anecdote I came back to Sam with a week later. "YOU ARE NOT HAVING SHORT ITERATIONS" I told him, "YOU ARE HAVING SHORT WEEKLY RELEASES! And this is killing you slowly but surely".
There is a critical difference between a sprint and a release, which is the main reason why, each time I begin to work with a new company I enforce distinction between sprints and releases. A sprint is mainly a window of time; within it a team completes working deliverable software. This time window balances between the overhead of iteration (planning, retrospective and review) and the value of frequent feedback which allows us to inspect and adapt. Generally speaking sprint will be minimal, and according to Scrum guidelines, will move between two to four weeks. Producing deliverable doesn't say that you will actually deliver. A release, in opposition, uses a tool called "iterations" or "sprints" in order to progress toward large bunch of features to go live. Because of the "to go live" issue, the overhead of such a release is much bigger than the overhead of a sprint. You have to run integration tests, regression tests, follow release procedures, documentation, operations issues, etc… Weekly releases means, as far as my experience shows it, lowered quality level and increased bug issues, causing frequent costly hotfixes and patching, and avoiding the teams to work properly on their development tasks. Short releases increase the pressure on the teams, they feel always either after a release or before a release, but never in full development stage. This causes teams to work late in the night and during week-ends, they feel squeezed, exhausted. The teams feel like the management don't let them do proper designed and coded work, and only pushes them to "go live". Team motivation can decrease severely. Usually in short releases, teams has no much play room in their capacity, development is prolonged until one day before the release in the good case, and mostly bugs will still be fixed the morning and the release "go live" by the evening. Team attention decreases, they know that there is no way to release properly, they don’t unitest properly, quality sinks, and the next releases counts many bugs to be immediately fix in addition to the new features the teams have to release. The situation can only become worst and worst; this is what I design as the "Quality Spiral" (which I'll speak about in a further article).
This state of fact is avoided when working on longer releases, leaving time for integration sprints, proper QA testing and V&V, and full synchronization with external function groups (like support, operation, IT…).
While working on longer releases, of at least one month, we will still run on short weekly or bi-weekly sprints, leaving room for teams to complete their work and QA to ensure good quality. This is the answer to those pretending that long release means loss on control over the development process. This is right if you still confuse release and sprint. But long release ensure quality , and the short sprints the release is made of, ensures high visibility and best management of the development.
On the other hand, long releases means increased amount of new features to be delivered, thus means more communication channels to be managed between more groups in the company. This synchronization issue may become a critical bottleneck. Just think about several teams not necessarily running synchronized sprints. This asynchronic system has to be properly managed. I'll propose a solution in a further article.
Posts
