I became a Certified Scrum Master (CSM) in 2013, and I am in the process of applying to be a Certified Scrum Professional (CSP). One part of the application is an essay about my experience using Scrum. I still need to gain more Scrum Education Units (SEUs) to qualify for the CSP, but I wanted to share my application essay:
I was introduced to Scrum in 2004 when I managed a product support team for a large bank. I was a consultant, and my supervisor on the client side came into our work area one morning during the summer of that year and announced that we would be having a daily meeting called a "scrum". It would start at 8:45 AM each morning, and I have to admit that I was puzzled by the idea. This scrum seemed to just be a daily status meeting. Why did we need a daily meeting when we met every Friday to review the week? And why did we have to stand up?
I soon learned that this "scrum" was more than just a daily meeting. My supervisor laid out the simple constraints of the meeting. We would stand in a circle and share three pieces of information: 1. What we did since the last scrum; 2. What we plan to do today; 3. What blockers stand in the way of our plans. After just a few weeks, I began to see results. Issues no longer waited until the weekly meeting to get resolved. More importantly, our team stopped forgetting to discuss issues that occurred on Monday or Tuesday that they forgot about by the time Friday rolled around.
A few months after we started using Scrum, my supervisor asked me to facilitate the daily stand up. I soon realized that I had a knack for listening to the updates from the team and teasing out blockers that weren't obvious. This was due to my technical background, and I think my supervisor saw that as an asset I could better provide to the development team during the scrum. I didn't know it at the time, but I was functioning, albeit in a vestigial manner, as a ScrumMaster.
My role on the project ended a year later, and I worked on other projects from 2005 to 2008. Most of them were waterfall based, but every now and then I noticed a few teams doing daily standups. I left consulting in 2008 to attend business school, and it was during a class on project management that I really learned about agile development. The class presented agile development as an alternative to waterfall, and I realized that the scrums I first encountered in 2004 were part of an entire framework for delivering complex projects. I began to learn about events like sprints, artifacts like burn down charts, and roles like ScrumMaster (that was me!) and Product Owner.
After graduating from business school in 2009, I returned to consulting. I was keen to find an opportunity to use the full scrum framework, and I found one on my first project. While I was nominally the project manager, I served the team as a ScrumMaster. I organized the work into sprints, facilitated the daily scrums, involved the team in estimating work, and leveraged the principle of "iterate and inspect". My team enjoyed having a say in what they would commit to before each sprint, and we immediately began delivering better results through working software that the client would see in demos every two weeks. I found that scrum was a great framework for a consultant like me to use. I reported to clients who were employees of the company that paid for the project, and I managed contractors that did the work. So, three constituencies were involved: the client company, the consulting company that paid me, and the company that provided the contractors. Scrum provided a way for me to provide continual and iterative improvements to the company that chartered to the project, create an inclusive and motivated team of contractors, and send regular fees to the consulting company that provided me with gainful employment. Agile development became my secret weapon.
I left consulting again in 2012 to join a small construction software company. The Director of Technology hired me because he liked my blend of experience in Scrum and the structure of classical project management. He also paid for me to become a Certified Scrum Master in 2013. I ran our legacy projects using waterfall, and I used scrum for our next generation projects. I chose this dual method because the updates to our legacy products were quarterly and relatively small in size. However, our next generation products were complex and needed frequent releases to both the maintenance updates needed for our cloud infrastructure and the features requested by our customers.
It's 2015, and I have come a long way from the "daily meeting" I was introduced to in 2004. I love Scrum, and I enjoy helping teams practice it. I'm even working on a book about how Scrum can be applied to spiritual discipline and growth. I would like to become a Certified Scrum Professional to quantify my Scrum experience and gain more opportunities to help organizations and people develop and sustain complex projects.