For some, the term Agile may be a foreign concept. Like me, early on in my career, many are thrown into the agile way of doing software development. There will obviously be many who start their careers working in predominantly an adaptive agile way (e.g. less up front planning and more development early on), as opposed to the more traditional waterfall approach (e.g. heavier on planning the work to be done before starting the actual development). I was initially introduced to agile methodologies when I was an intern back in college.
The company I was interning with seemed to be following the Scrum framework, part of the Agile Methodology. We had a daily standup (now referred to as daily scrum) every day. This is where we discussed what we did the previous twenty-four hours, what we planned to do the next twenty-four hours, and raise any issues impeding our workload. We also had meetings where we reviewed all the user stories the team had worked on in the previous days to discuss if they were completed or not. I don’t recall there being a demo or not, just that we had these meetings once every two or three weeks.
As I was finishing up my internship and last semester of college, I was apart of a senior project. In our senior project we followed the Extreme Programming approach and studied from one of my favorite books, The Agile Samurai. We were in teams of around six and had to demo our code to the product owner, the professor, and the whole class at the end of every week. This is where all my previous experience with Agile Methodologies started to really kick in and my passion took off.
My next exposure to this process style was while working on the Xbox Online team at Microsoft. The team I worked on used Team Foundation Server (TFS) for all of our workload tracking, this is where I became a TFS admin and started to gain knowledge on how to configure tools for our teams sprints. After gaining a ton of valuable experiences with the Xbox Online team, I took a full-time Project Manager position back at the consulting company where I was previously an intern. I wore many hats in this role, including release management, product owner, and scrum master. I soon had a remote team of software developers in the Philippines. The work they were doing seemed more fitted to following scrum and kanban (or sometimes referred to as scrumban). They had no processes, documentation or tools in place when I took over as their remote team project manager.
“…all apart of the experience…”
Based on my previous experiences, I decided to just take the initiative and put in place the proper processes, documentation, and tools. This led to me being their scrum master from afar (also while still playing the role of product owner and release manager) as I would virtually start planning sprint sessions and facilitating them. After about a year and a half, I interviewed and helped hire on a local junior scrum master there in the Philippines which I soon trained to help with facilitating daily meetings face to face. I still joined and facilitated sprint sessions remotely, and continued to mentor and train the new scrum master we brought on. All of this was great in giving me the experience needed towards seeking further training and soon becoming certified as a Professional Scrum Master thru Scrum.org. This is the story of my step into the agile world, all of which led me to the current role of Scrum Master at my current company. Along the way I’ve learned what from my past was true to agile concepts and what could have been done better, which is all apart of the experience.