Scrum offers a fresh approach of software development. However, the philosophy itself is not entirely new. It has been around in various disciplines for quite some time, and it is only now that the software community has woken up to it. I found an everyday example of my sonss full academic year as a great way to explain Scrum to someone new to it.
My sixth-grader son (“Scrum team) has a bag full of books (“Product Backlog”) that the teachers (“Product Owners”) must complete in the given academic year (“Project Schedule”). There are various subjects (you may call them sub-systems, component or modules if you like), and each subject has one or more books, each having several chapters (“Sprint Tasks”). To a great extent, the books don’t change in the middle of an academic year, though some of the factual contents could (for example, when his session started, Pluto was still the ninth planet of our solar system, but that changed a few months back !). The academic year works on a fixed-end-date planning and the holiday schedules are announced for the entire year in advance and the exact exam dates are announced using rolling-wave planning. To that end, there is a very well laid out plan for the entire year.
However, there are always unexpected changes that happen from time to time. Last month, my son got selected to represent his school at the city-level declamation contest. That meant him skipping some classes, and going out on a school on the competition day. He also had to skip an exam. However, all these “changes” were handled by the teachers with extreme professional finesse and personal touch, with him being given extra time to complete the classwork and homework, and letting him write the exam. I personally feel Scrum takes a rather rigid stance on accommodating in-cycle change requests because in real-life, there are always such unavoidable things that gatecrash and must be addressed in the same timeframe without de-prioritizing any of the existing commitments. In this particular case, could I have told my son to skip the declamation contest because his monthly unit tests were more important, or told the teachers that he be allowed to skip the exams ? I think Scrum 2.0 might address such real-world issues.
Some other known patterns of requirement changes include the scrum team (i.e., my son) getting overenthusiastic and volunteering for every second task like preparing for sports day, or annual day, or chart on Global Warming – essentially things that offer a lot of distraction from the core project activities, and take up lot of unplanned effort out of the sprint without really contributing to the tasks to be accomplished (“Sprint Goals”). This is real-life, and as we all know that when well-intentioned plans go haywire, Scrum or no Scrum, we must sit down and slog over the long evenings and weekends. In self-created situations like this he is getting used to his favorite quotation that I told him sometime back “Life is unfair, better get used to it.
Instead of an annual exam alone as the only and final way to assess his learning, the teachers give him and other students monthly (“4-Week Sprint”) unit tests (“Sprint Backlog”) and in the final annual exams, test the entire knowledge (“Product Regression Testing”). So, there are a set of chapters that become part of the sprint backlog in each sprint, and get tested towards the end of every sprint, which are, of course, the monthly unit tests. The schedule of monthly unit tests can’t move (“Fixed-Duration Sprints”) – so, if the given chapter (an item from the sprint backlog) is not complete, the teacher will skip that and put on the top of the next sprint backlog. Some months have more holidays, some have less, and some have school annual functions and other events, so the sprint backlog (and consequently the “Velocity”) is adapted based on net usable time available in a month (“Product Backlog Item Effort”), but the sprint is always four-weekly.
The child comes home every month (for that matter, every week if not every other day) with new knowledge and skills that he can directly apply in real-life (talk about “shippable software”).
At the end of every month, evaluated test papers are sent to parents (the “Scrum Masters”) for review. If the performance is not good, they go have a discussion with the teacher on their child’s performance (“Sprint Retrospective Meeting”), and some of those improvement items become input for next evaluation cycle (“Product Backlog Item”).
Every six-months (so, there are two in an academic year: a mid-point and the second as an year-end), there is a comprehensive assessment of child’s overall academic, extra-curricular and social performance. The class teacher prepares this based on evaluated and observed feedback from other teachers for every child and sends to parents. Not sure what is the scrumology for that would be, but the one closest is “Sprint Retrospective Meeting”.
Daily schedule involves checking classwork and homework, both in class with the teacher (“Product owner”) and with the parent (“Scrum Master”) and various issues related to performance and progress are discussed (“Impediments”). There is a special class of scrum masters in this model, known as “mothers” who always seem to have the right burn-down chart in their minds whether the child agrees with it or not. The daily meetings are quite “standup meetings” by themselves especially when Sprint Goals are not being achieved, if you know what I mean 🙂
PS: Towards completing this article, my son came over, read the contents, asked what Scrum was, but approved the article. But he was not very happy that his contributions were not acknowledged anywhere in the article. So, I hereby thank my wonderful son Chanakya Varma, soon to be eleven this October, for his efforts and a lovely and tough time he gives to my wife and I. Son, you are a great example of how a Sprint Team should behave, especially during tough times, one of them definitely being asking your Mom to help you out.