True wisdom lies in knowing what you don’t know, and I have certainly been served my share of humble pie just with the first of my two-days ScrumMaster Certification training. I was reminded of many things that I have forgotten or let slided.
As I am sitting here at 6:30 AM in the morning, getting ready for day two of my training, the one thing that still haunts me from yesterday is how loose we are following the Scrum practices. What the training yesterday gave me was a perspective of importance of all apsects of Scrum, most importantly, the rigid timeboxing that one must follow. Scrum heavily relies on timeboxing, from the 15 mins daily meeting to the strict 30-day iteration cycle (note I didn’t say release cycle). One participant asked if a team just needs two more days to polish up the product for release, can we be flexible? This is a situation that I have already allowed to happen. The answer was a resounding, no. Reason being, the team must learn to become a better engineering organization by learning how to commit to work in a 30-day timebox. Buffer time should be built into the Scrum to allow uncertainty. To allow for such to happen is to lose an opportunity to learn.
Without this rigid timebox, teams learn to slack and doesn’t self-manage. The 30-day mark, for all intents and purposes, is a deadline just like any other real deadline. The goals of that deadline can change, but the deadline cannot. It’s a “fixed date release” instead of a “fixed feature release.” If something is not really “done” when the 30-day mark comes around, it doesn’t get shown. That is another thing that we do not emphasize currently, the meaning of “done” and subsequently affect what and how we demo things.
There are a multitude of other things that I have learned and noticed what we are doing wrong with Scrum, even tiny things such as the tone and direction of the daily scrum meetings. It is not, and should not, be used as a meeting to report status to the ScrumMaster, alone. But rather, it should be used to report status to every single person in the team. Team members are mutally responsible for each other’s progress. Without that mentality, they remain individual contributors and will never get into the hyper-productive state. Even more important than reporting progress, it is a chance for the members to commit to each other what they will deliver, and such committment is evaluated immediately at the next daily meeting.
Among the Scrum talks, there were also valuable reminders and insights into software engineering as a whole, most I have already read/heard, but it’s always good to be reminded of those again. Atrophy, whether in knowledge, process, software, is such a huge obstacle to combat. There’s a reason why people attend seminars. It’s not necessary that they have not heard of all of that already, but rather, be reminded of them, to combat atrophy.
One particular point that was driven through us like a 18-wheeler was how we as software engineers assume the risks of our customers, without ever telling them. We are trained to say “Yes, we can do it,” but without explicitly educating our management of all the risks involved. Even a world class surgeon exposes and explains all the risks involved in a surgery to the patient, will not say to the patient, “Yes, I can do it,” and let the patient decide whether to proceed with the surgey or not. The surgeon has no rights to assume the risk for the patient, just as software engineers have no rights to assume the risks of our customers and business. To do so is unethical. This is an interesting highlight because I am reading Waltzing with Bears by Tom DeMarco and Timothy Lister currently and it preaches exactly that.
Finally, Ken Schwaber is a wonderful trainer and speaker and I really enjoy his insights into software and project management. I highly recommend any of you that are interested in agile software development to attend his events and courses.
As it’s now 6:50 AM, I must get ready for day two of Scrum goodness!