Questions questions and questions. We had a Q&A session with Ken mostly about implementation of Scrum in various types of projects and environments. The gist of it is there’s really no right answer. That is why Scrum is not a methodology, but rather, a framework that can help you identify the issues, and forces you to resolve them. In every day work, we are faced with numerous impediments and problems that can slow down our work, but often times we ignore them and just accept the inefficiency. Scrum practices exposes them to the maximum level and mandate them be resolved.
Most of Day 2 were focused on the actual practices of Scrum, and less on the philosophical aspect of it. Though the practices reinforce the believes of the framework. We touched on various engineering practices, a lot of them were derivative of XP or other agile software development processes. It is again important to note that Scrum doesn’t tell you how you can develop your software, it provides a framework to help you manage the development process.
As I started to talk to more people about Scrum, most will object to the idea of “I can’t tell you if we can do it, all we can tell you is we will do our best.” What people need to realize is that is not a cope out, but rather, an important mentality that all software development organizations need to have. Instead of operating with false confidence that “Yes, we can do it,” we take the bull of uncertainty by the horns and face it with absolute clarity. We still estimate long term, we still try to put our best guesses out as to when things are done, we still budget. We simply must not fool ourselves that we WILL get it done. We must manage and mitigate the risks.
Another interesting discussion was from a lady who is not a software developer all together, and asked if she could make a good ScrumMaster. The answer was yes. As a ScrumMaster, you call on different strengths based on who you are. With different background, you bring different things to the table. And most of the soft skills required to be a successful ScrumMaster is not software development specific. In situation where the team is stuck in design, an engineering manager might seem a better choice. But it is not the ScrumMaster’s job to solve the team’s design issues. As long as the ScrumMaster can facilitate, whether by himself being the expert, or by calling in an expert, the ScrumMaster is removing the impendiment for the team.
All in all, I have learned so much in the last two days, both from Ken and from my classmates. I have gained a much deeper understanding of what Scrum is about. I have learned a lot not even just from the class materials, but from all the thinking that resulted from attending the class. I feel that I have a new level of understanding of agile software model as a whole. I truly thank Turbine for sending me to the class.
I feel a little silly to be all charged up and excited about rolling out Scrum correctly. I do not want to lose the energy and momentum I have obtained through this, and wish to spread the knowledge of Scrum as soon as possible. I once again have started to evangelise Scrum, but this time around with much more fealty and passion towards it. I will do so by leading successful Scrum teams. I truly believe in the power of the talented individuals we have in our company, and given the proper guidance and empowerment, we can really shine as a world-class software developer!