Agile Project Management for Data Teams: Sprints, Kanban, Standups & More

This week I want to talk with you about Agile vs Waterfall methodologies in project management.

As someone who mostly worked with startups over the past 11 years and recently joined a large corporate, I can definitely see the difference — and I want to share what to expect if you're making a similar shift.

What is Agile / Scrum / Sprint / Kanban?

The Agile approach breaks down the work into small chunks called sprints, which typically last 2–4 weeks.

Let’s say you're working on developing a churn prediction model for a large organisation and expect to finish it in 2 months. You could break the project into 4 sprints (each 2 weeks long). Then you create tasks like:

• Collect data

• Perform exploratory data analysis

• Build model(s)

• Test performance

• Deploy model into production

This helps split the overwhelming task of “create the model” into manageable, achievable junks. It also forces you to think the project through, identify potential bottlenecks, discuss nuances and clarify deliverables before it’s too late.

Sprint Planning & Types of Sprints

Before each sprint, there's a ceremony called Sprint Planning, where the team decides which tasks (or "tickets") they'll work on.

I’ve seen 2 approaches to the sprints:

1. Inflexible sprints
   Think of it like boarding a ship for 2 weeks — you can’t hop on or off midway. The team agrees on their tickets, and nothing gets added later, even if something urgent pops up.
   This works well for software teams who need focus and minimal distractions to release a feature or product.

2. Flexible sprints
   The workload is planned in advance, but there’s wiggle room to re-prioritise or swap out tasks if something comes up mid-sprint.
   I’ve seen this more often in data teams where ad-hoc requests are common.

Retrospectives ("Retro")

At the end of each sprint, there’s a retrospective where the team discusses:

• What went well

• What didn’t

• How to improve next time

Let’s be honest — it’s the unofficial winge session where people can vent, but also brainstorm ways to make things better. If there is established trust in the team - those sessions are incredibly useful. However, if you work in a toxic workplace, where people are scared to say anything controversial because they can loose their job - those sessions are just waste of your time.

Daily Stand-Ups

Another important Agile practice is the daily stand-up: a quick 15-minute sync to discuss:

• What you did yesterday

• What you’re doing today

• Any blockers or dependencies

This helps to bring up any issues you have right now (data is not available in the Data Warehouse, numbers don’t match, no access to the system etc) and resolve them mid-sprint, instead of waiting for weekly/bi-weekly meeting.

Roles Within an Agile Team

Agile teams (also known as squads) are typically small and cross-functional — between 5 to 9 people. This usually includes developers, data analysts, QA/testers, and sometimes UX or DevOps, depending on the project.

There are two key roles in Agile:

• Scrum Master
  Think of this person as the team coach. They’re not your boss, and they don’t tell you what to do — but they make sure the team follows the Agile process, facilitates ceremonies (stand-ups, planning, retros) and removes blockers.
  If you're stuck because data access is taking forever or waiting on another team, the Scrum Master should step in and help move things along.

• Product Owner (PO)
  This is the person who represents the business side of the project. They set priorities, define the work (tickets), and make sure what the team builds aligns with user needs or company goals.
  In a data context, this might be someone from marketing, operations, or a lead analyst who understands the value of the work and what “done” looks like.

These two roles are essential to making Agile work smoothly — especially when juggling requests, shifting priorities and keeping the project on track.

Kanban Board

My favourite Agile tool is the Kanban board — a visual tracker for all the tickets/tasks.

At minimum, it has these columns:
- To Do
- In Progress
- Done

But you can customise it with stages like In Testing, Data Requested etc.

You move tickets across the board as you work through them. It’s an amazing way to:

• Keep track of all requests

• Make your work visible

• Avoid losing track of random Teams/Slack/email messages that say “Can you just quickly pull this data?”

I personally get satisfaction from moving tickets to “Done“. It is like crossing out a completed task from to-do list. There is something nice about it.

I use Kanban boards not only for big projects like ‘developing a model’, but also to keep track of ad-hoc requests. Most Kanban tools allow you to leave comments under each ticket. So if you receive a request like “I need marketing data”, you can reply directly in the ticket and ask for clarification — what metrics, for which time period and in what format. I find this much more efficient than endless back-and-forth emails.

I also think of the Kanban board as a performance review tool.
You can literally pull up your board to show what you’ve worked on, which can be helpful when:

• Negotiating a raise

• Justifying hiring another team member

• Analysing type of requests you get. If you are asked for the same numbers end of each month, maybe it’s time to create a dashboard to display those figures.

Tools I’ve used for Kanban boards:
- JIRA
- Notion
- Azure DevOps Boards

What About Waterfall?

Now let’s talk about Waterfall, which is still widely used in large corporates.

It’s a more traditional and linear approach:
You complete each phase of the project one after the other, in a fixed order.

Think of it like this:

1. Requirements gathering

2. Design

3. Implementation

4. Testing

5. Deployment

6. Maintenance

The big difference? You don’t move to the next phase until the current one is fully complete. There are fewer feedback loops and little flexibility once you're mid-project.

My Takeaways

After working in both environments, here’s what I’ve noticed:

• Agile is a lifesaver in fast-paced, high-uncertainty projects (especially startups).

• Waterfall makes sense when everything needs to be carefully documented and signed off.

• Some corporates say they are “Agile” but still work in a Waterfall mindset.

Agile or Waterfall — there’s no one-size-fits-all. And there is definitely something to learn from both approaches.

Keep pushing 💪,

Karina

Need more help?

Just starting with Python? Wondering if programming is for you?

Master key data analysis tasks like cleaning, filtering, pivot and grouping data using Pandas, and learn how to present your insights visually with Matplotlib with ‘Data Analysis with Python’ masterclass.

Get CV, Portfolio and LinkedIn Review.

More from me: YouTube | TikTok | Instagram | Threads | LinkedIn