Agile Transformation

This was my second go around at transitioning how we worked. The first time was in engineering, and we were transitioning from waterfall to agile. That's when I got exposed to the agile and was our scrum master for about a year.  Flash forward about 8 or so years, I was the first UX designer to join HR in the learning space, and was brought on to build out Leader Learning Labs and with that success the team grew. I was tasked with hiring a new junior designer from a non-design background to help with designing these labs. The goal was to see if we could re-skill talent. We went from a team of 1 to a team of 2, and now I was mentoring and training a new designer, managing all our projects / requests, and ensuring we were delivering on time and with quality.

About a year later, the team grew once more. We brought on another junior designer in a re-skilling effort and with that we determined how we were currently working wasn't going to be scalable. I proposed moving to a more agile way of working, a version of scrumban (which is a blend of kanban and scrum). See below the steps I took to get to an MVP process and how the journey transformed how we worked, for the better.

In 2022, I stepped into the role of team leader and was now leading a team of design professionals. Together with the leadership team, we began to shift our strategy and transition once again to Agile to enable out Learning-as-a-Product Transformation.

Just with anything solution, there will be growing pains and things that just don't work that you'll learn from.  It took the team some getting used to working in this new way, and there were thinks that on paper sounded great but in our retrospectives we began to tweak things. Ultimately we landed on a great process and it was second nature.

While sometimes, ripping the bandaid off sounds like the best approach, it isn't necessarily the best approach. What I learned is that change was harder for individuals who were used to the way we were working and then having to shift to a different way. For a new member to the team, it was a much easier transition as they were more open to it. If I were to either do it over, or work towards shifting a team towards a new way of working, I'd do it a bit slower, start with a few rituals, then gradually get everyone on board.

I started out with understanding the problem, and what we are trying to solve. It started with working with our Director to understand he'd like to be involved with the team and how he envisioned our work would look like. Since I was responsible for not only the work, but also what we delivered, I mapped out our current process. How did we build labs, how did we take on new requests, work with stakeholders, and etc. 

Then researched the various methodologies out there, and began taking in what our Director said, what might help me, and how the team members worked. All of this played into what our process would look like, and I quickly realized that a pure agile methodology wasn't going to work. What I anchored on was a methodology called Scrumban, which I then modified to meet our needs. The image to the right was the mockup of the first iteration off our process, that we presented to the team to get their thoughts.  We used this as the jumping off point.