With some experience at a smaller company and a wide variety of roles under my belt at The Learning Bar, I decided to take my skills back to IBM as a full time Software Developer. My main goal at this time was to get more experience as a team member on an agile team. I wanted this experience so that I could be more confident in the future when I am acting in a Scrum Master or Agile Coach role. I want to be able to say I’ve walked the walk before I talk the talk about how team’s can succeed by applying agile values.

I started back with IBM in a familiar team, The WinCollect team that I did my first co-op with. The team had expanded to a full team instead of just a responsibility of the integrations team. I was joining as a software developer with a specialization in automated testing. The team was in a phase of developing a major re-write of the WinCollect agent and most of the development was focused on backend unit testing with little work put into end-to-end testing. I was tasked with building this end-to-end testing pipeline including everything from test planning, configuring build pipeline triggers, and developing the automated tests themselves.

I came to this role with my previous experience of automating tests in Java and Selenium. This time around I would expand those skills by learning Groovy and Geb. Groovy is a programming language that is built on top of Java. It provides some abstractions that provide it much more relaxed and varied syntax than Java that lends itself well to descriptive tests. Geb is likewise an abstraction above selenium providing more simple syntax and a more reliable browser interactions. Using these technologies I developed a set of test suites that tested the WinCollect Agent inculding install scenarios, functional end-to-end tests, integrations with external systems like the QRadar SIEM, and even some non functional requirements like security and accessibility. After building out these tests I also worked hard to provide good documentation and training to my other team members so that they could also contribute to the tests. Having multiple people able to contribute helped our team distribute the work and be more agile, preventing a testing bottle neck at one person and allowing for quicker close times of tickets.

As I joined the team and shared my aspirations for agile with everyone, I quickly took over the Scrum Master duties for the team. I had originally wanted to just be a team member for some time before taking Scrum Master on again but it felt like a natural position for me to fall into given my passion for it and given the interests of others on the team who filled it just because it needed to be filled by someone. I worked closely with the Product Owner, Technical Lead, and Manager to determine what is important for the project from the perspectives of the customers, the tech stack, and the business. I started to bring more formality to some meetings like release and sprint planning. I pushed for a more inclusive culture on our team where all team members work and opinions were respected equally. Retrospectives were one of my favorite tools in my toolbelt to get opinions out on the table in place where everyone felt safe sharing. I used fun activities like a skills marketplace and a roles and responsibilities discovery workshop to build team communication and better define how we could all work together to reach our goals.

As these strategies were showing their effectiveness on my team, I started to work with other Scrum Masters from other teams to share what was working. I would help other Scrum Masters who were new to their role or facing a particular challenge on their team.

I got numerous opportunities to expand my work outside of my team as well. For my QA and Automation work I participated in a QA guild. In the QA guild I was mostly an observer and audience member, learning from the lessons of my colleagues on other teams and applying their recipe’s for success in my own work.

I was also lucky to be able to be part of a strike team which worked on a migrating data from a legacy ticket management system to Jira. Our team also defined customizations for Jira that fit our team’s workflows. I very much enjoyed this role as it was reminiscent of my work as a Business Systems Analyst. It was a great experience to be a part of the team defining those workflows that we still use today.

In my Scrum Master work I had the chance to participate in a scrum of scrums meeting which kept all agile teams working in the same space aligned. I would be much more active in this group, often suggesting ways that we could improve and asking questions of my fellow scrum masters about their in progress work to identify dependent work my team may have missed in planning and identify any breaking changes that might effect our team. I eventually ended up taking over the facilitation of the Scrum of Scrums meetings and although that facilitator role does rotate every so often I am widely viewed as the go-to person for this group should new teams need to be onboarded, a facilitator needs someone to cover for them etc.

As my role expanded further and further outside of my own team, and I started to be viewed more and more as a leader on my team I am proud to say I secured a promotion to Band 7 Software Developer. Check out my separate blog post to see how my role continued to grow.