Implementing Scrum and the Agile Management Process

Post created by Jace Gersten (Applied IMC, Fall 2022)

If you are like me, you have probably thought to yourself what does a manager even do? Doesn’t a manager just tell their team what to do? What’s so complicated about that?

As it turns out, team organization is much more complicated than I realized and there are several tools that are used to hold a cohesive team together. In my Applied Integrated Marketing Communications class at WWU, I had the opportunity to learn what it takes to be a manager. In this role, I oversaw a team of 5 other students where we rebuilt a podcast talking to alumni of the marketing program. During this time I was finally able to make use of the practices I had learned about and implement them in a real-world environment.

As a new manager, one of the first things I was told is that my job as a manager is to assist and support my team. Just like a coach in team sports, my job was to improve and organize the team in a way that best demonstrates the team’s skills without directly doing the work myself. My job was to be the coach, not the quarterback. This tip was essential to our process for two reasons:

  • First, it allowed me as the manager to understand that my role was to uplift my team and play to their strengths. Even though I was ultimately responsible for our success, I had to understand that this was their project, which brings me to my other reason.
  • Second, this process was not about me. Since I had taken the class before my team, I had more knowledge of many of the projects and tasks we were given. I could have done many of the projects myself. But, especially in our situation, that was not my job. Our primary objective was learning, even if that meant failing to deliver some of our projects on time.
flowchart showing the scrum process and agile

As I hinted at above, there were times when we made mistakes and failed to meet deadlines, but this was to some extent encouraged. It was all part of the process of learning by failing. But with all these moving pieces and variable deadlines, how were we able to stay organized? The answer was Agile and the Scrum methodology.  Scrum is an iterative approach to project management where big projects are broken down into shorter increments. Plans and objectives are continuously evaluated so that teams can react quickly and stay flexible. What is the difference between Agile and Scrum? "Agile" is more of a philosophy or mindset of how software should be developed and  "Scrum" is a methodology. Scrum is not a singular framework, but a series of many other supporting tools such as Sprint cycles and Kanbans.

Sprint Cycles

The first extremely important process we followed was sprint cycles. As I said, Scrum focuses on breaking down a large project into smaller pieces. This makes it easier to stay organized, as well as ensures that your team’s success isn’t completely riding on the last final project submission. 

With Sprint cycles, the project is broken into iterations so that you can frequently collect data and feedback, then react accordingly. What is a sprint cycle? A sprint is a short time period (less than a month), where a team works quickly to finish a deliverable, like a draft, prototype, or any type of completed content. 

 For us, we worked in 2-week sprints, meaning at the end of every 2 weeks, we had a new product iteration to turn in. And at the end of every sprint, another one started, until 11 weeks later, we had our final product: 4 new podcast episodes.

Each sprint cycle is broken down into 4 steps: Sprint planning, daily standups, sprint review, and a sprint retrospective. The start of the cycle begins with sprint planning. The team collaborates in a lean meeting (check out my blog about Lean methodology), where the team lays out all the work needed to be done within the sprint. These tasks are often organized using another tool called a Kanban, which I will explain in further detail later. Once the sprint tasks are organized and everyone on the team knows what needs to be accomplished, then the work begins.

Throughout the sprint, daily standups are conducted. Standups are short and frequent meetings with your team. Ideally, meetings are daily and only take around 15 minutes. Standups consist of just 3 questions: What did you do yesterday (or last working day), what are you going to do today, and what are your blockers? The purpose of these meetings is to keep the team organized and discuss any problems (or blockers) that may arise. Standups also keep the team accountable to each other since they have to stand up in front of their peers and talk about what they have been working on.

At the end of the sprint, the next steps are a sprint retrospective and a sprint review. The sprint retro and review are very similar. In both cases, the team gets together to discuss what went well, what didn’t go well, and possible solutions. The only difference is that the sprint review covers what went well with the actual product, and the sprint retro covers what went well with the process such as team cohesion, communication, or project management tools used (like the Kanban!)

Kanban cartoon drawing of arms and hands sticking post-it notes on a blackboard


A Kanban is a project management tool that keeps track of all tasks needed to complete the product. You can think of a Kanban as a glorified to-do list. The Kanban is split into 4 general categories, but more can be added. The fundamental 4 columns of the Kanban are the backlog, work in progress, pending, and done. The idea is to have a visual representation of the team’s workflow.

  • Sprint Backlog: All tasks for the sprint that have not been completed yet. Team members can easily pull tasks to work on, instead of waiting to be told what to do.
  • Work in progress: Tasks that are being worked on. Team members should only claim 1 task at a time.
  • Pending: Any tasks that cannot be finished due to some outside influence, like waiting for responses.
  • Done: Tasks that have been completed.

Other columns can be added as needed like editing, testing, previous sprint rollover, or product backlog. The product backlog same as the sprint backlog, but is an accumulation of all deliverables needed to finish the final product. You can think of the product backlog as an overview of all sprint backlogs into one backlog.