My First Agile Scrum Project
The first question traditional waterfall development managers ask when they are looking to transition to agile scrum is, “How do I make this happen?” I’m going to share my first transition from waterfall to agile scrum five years ago and, hopefully, this will help you with yours.
Background
I was a traditional waterfall project manager at a Fortune 500 international company. My team consisted of 2 developers, 2 quality engineers and 1 tech lead. The overall scope of the project was to procure and build the infrastructure from the ground up then to develop the following functionality: Email, Push, In-App and SMS.
Waterfall is OK for Architecture Buildout
We managed the procurement and buildout of the supporting architecture using the traditional waterfall approach, because there were simply too many dependencies on technologies and non-dedicated team members needing to do work outside of what would be an agile scrum team. We referred to this buildout period as Sprint Zero.
Begin the Transition from Waterfall to Agile
Sprint Zero
I obtained my Certified Scrum Master (CSM) certification and our team engaged an onsite scrum coach (similar to the services we offer at GSD) to train our entire team. Everyone on the team attended the training, including our new Product Owner.
Topics we learned included:
- Defining Epics
- Defining Sprint cycle
- Story Writing
- Backlog grooming
- Estimating and assigning story points
- Sprint Planning
- Daily Standups
- Product Demos
- Retrospectives
- Reporting sprint velocity
- Setting up and configuring tracking tool (JIRA)
Training sessions were spread over a few weeks to minimize disruption to the team and to allow them to complete their infrastructure buildout tasks. As a new scrum master, I worked closely with the team to ensure we were all aligned on how to implement agile scrum and how to be successful.
Sprints 1 to 3
We decided to start with 2 week sprints as our coach advised this is optimum for most development teams. We have found 2 weeks to be the magic number with all our agile scrum teams. We also found this was a good amount to analyze, develop, test, and document potentially deployable packages of code.
To ease the transition, our scrum coach attended all of our Story Writing, Backlog Grooming, Sprint Planning, Product Demo and Retrospective sessions during our first 3 sprints. Our scrum coach would be a silent observer in these sessions, but would interject if the team went off track or had questions about scrum.
This support gave our team, including our new Product Owner, confidence that we could fully function and deliver as a new agile scrum team. We wanted to demonstrate that we could quickly develop deployable code and show tangible work progress in a short amount of time. This was great because the team realized quick wins by demonstrating functional pieces of code. The Product Owner and stakeholders were getting continual feedback on the team’s progress. It was a win for everyone!
Operating Agile
I found the experience so amazing I knew I wanted to be an Agile coach. If we didn’t have ours, I don’t think we could have done it alone. The coach was crucial not only to training, but providing support to ensure we were embracing our new agile mindset and not falling back into waterfall processes. It also gave our stakeholders confidence we were working with an expert who could guide our team to success.
Let me know if you have any questions or need help with your transition to agile scrum.
April Shepherd
April Shepherd
AprilS@gsd.guru 503.307.9072