Transition Your Team from Waterfall to Agile Scrum

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.


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.

DSC_4880 (500x483)

April Shepherd

April Shepherd  503.307.9072

Contact Us read more

The Retrospective – Not All Continuous Improvement

How to Handle Retrospective Suggestions that Challenge Agile Practices

Two major tenets of agile are self-managing teams and continuous improvement. Both tenets come into play during the scrum Retrospective, where part of the discussion involves ways to improve team performance. Inevitably, someone recommends a continuous improvement suggestion that challenges one of my core scrum values.

The Scrum Master is the agile scrum expert and facilitator. The Development Team decides how best to work together. What if the Development Team feels strongly that working more efficiently means throwing out an important aspect of scrum? Should the Scrum Master push back or allow the team to implement the new working agreement? Not an easy call.

I know where I stand and how I want to encourage my teams to practice agile scrum, so I recognize my boundaries. My internal alarms flash when my core values are challenged. I always push back. But, I have been known allow the team to proceed in a manner that seemingly goes against my better judgement.

It’s Not Always about Right and Wrong

Because I have completely embraced the agile mindset, I realize that everything is not always right or wrong. I have learned that you can slightly pivot the rules, allow changes to team behavior and still keep the intent of the original agile practice. When you can achieve, then you are truly agile.

One of my new agile Development Teams decided that they did not need me to facilitate their grooming sessions. At first I saw red. Whaaaaat?! It’s my job to ensure the Stories are properly formatted and sized for Sprint Planning. I tried to talk them out of it. I couldn’t. They voted and I lost.

This happened at the first Retrospective. I knew that if I did not permit this improvement to be adopted, I’d lose all credibility with the team.  However, I am the Scrum Master and enforcer of all things agile. I allowed the team to adopt the change, but only if they proved that they could meet the criteria for proper Story grooming on their own.

In the next sprint, I setup a Wiki page that outlined rules proper for Story writing, grooming and sizing.

At sprint planning, I reviewed all sprint candidate Stories for correctness:

  • Story Requirement
  • Acceptance Criteria
  • Story Points

If the Story did not meet the criteria, I had the right to demand it be immediately updated or I could put it back in the Backlog.

And you know what? The process worked. The Development Team was able to work independently to design and write their own Stories and I was able to enforce my core scrum practice of well -groomed Stories. Win-Win.

Some Recommendations are Just Wrong

In the real world, some suggestions are just wrong, but you may have to allow them to be adopted anyway. Why? Because I know a secret: Within the realm of continuous improvement lies continuous learning and more opportunities for continuous improvement.

Some lessons can only be learned through direct experience.

Not all bad decisions have to last forever.

Lucky for us, every Retrospective, the team has the opportunity to revisit all team practices at the end of every sprint. So, as a Scrum Master, I can revisit any adopted change and work with the team to reverse bad behavior choices.

I had another Development Team that decided at their first Retrospective they did not want to Standup every day. Of course, I knew this was a terrible idea. Again, I could not talk them out of it.

You know what? The outcome was textbook perfect: the Development Team completed half the number of Story Points in the second sprint as in the first sprint! Every other day was not frequent enough to keep their eyes on the prize.

At the next Retrospective, I was able to show the Development Team their error in judgement and we returned to daily standups. Yay!

Lesson Learned

As you can see, being a Scrum Master is not the same as being a waterfall Project Manager. It’s not about getting the team to complete tasks in a project plan, it’s about getting the team to work better together, work happier and get more stuff done.

Cynthia Kahn

Cynthia Kahn  503.799.5500

Contact Us


read more

April and Cynthia are GSD Gold

Applying Agile Scrum in the Real World

When I say the word agile and then add the words project management, depending on who you are, your response may range anywhere from “Heck yeah, this is the best thing ever to hit project management!”  to “Agile sucks, it does not work!” How can three little words evoke such a vast array of emotional responses? Because most project managers, developers, analysts, architects and development managers do not really understand agile and they do not correctly apply agile methods.

This is a blog about properly applying agile scrum to get stuff done in the most efficient way possible. Does the world need another blog about agile project management? Apparently, yes it does or else everyone in the world would no longer be using waterfall. Agile, particularly our method of scrum, helps everyone on any project successfully get stuff done, which is a very good thing.

What can you expect to learn from reading our blog posts and participating on our website?

  • How to organize an effective agile team
  • How to rethink your approach to project planning
  • How to setup sprints and monitor sprint progress
  • How to apply concepts of continuous improvement
  • How and when to release

Even more important than learning how to easily apply agile scrum techniques, we will help you shift your current project management paradigm to the agile mindset. Because without changing the way you think about and approach projects, you cannot become agile.

Why listen to us? Yeah and yeah, we both have our PMI PMPs and Scrum Alliance CSMs. We play the game. We both recently attended the PMI ACP 3-day training course, and we wanted to jump out a window within the first two hours. We needed the 21 PDUs, so we stayed the course. By the third day, we looked at each other and said, “Eff this, we can do better!” GSD was born.

That was 3 weeks ago. Now, we have a domain, a website and an outline. We’re agile. We’ll figure the rest out later.

Read our blog so you too can become more agile. We are 100% agile converts. We have taken the leap and left our old waterfall ways behind. We have successfully applied agile scrum to many development projects at multiple companies, big and small. Our agile teams outperform teams of our peers, even teams that also say they are agile too.

We are fun babes to hang out with. Hopefully, you will get as excited about agile scrum as we are. We want to save you from PDU suicide watch and make project management fun!Let’s start hanging out and working together to learn from each other and get more stuff done!

April and Cynthia

April Shepherd and Cynthia Kahn

April Shepherd and Cynthia Kahn

Contact Us


read more