I still remember when I first joined tech. Words like scrum and agile were used often, and I had no idea what they meant. As a finance person, I never thought I needed to know that. When I started moving into business operations, things changed. My team had so many competing priorities and way too much work to do.
Since we were supporting the business, managing all the different stakeholder priorities was tough. We had all levels of the organization coming to us – the executive team and other heads of departments. No one had a clear idea of what my team was doing, yet we were always busy and doing overtime. I felt really stuck, burned out and worried about my team too.
Then there was a leadership shake-up and I was now reporting into a new manager in a newly created VP, Operations role. She wanted me to apply scrum/agile ways of working within my team. I was hesitant and a bit resistant at first and also realized we had nothing to lose.
The results were life changing.
In this article, we’re going to walk through 5 key concepts to master agile and scrum for effective teams:
Table of Contents
Now if you’re a purist when it comes to agile and scrum, I will apologize in advance. These tools came into the world with a focus on software development. I am going to speak about this in terms of running effective teams, no matter what kind of team it is. Some of it will follow agile and scrum as I learned it, and some of it will be more application based on my experience of using these models over the past 5 years. Check out the full Scrum Guide here.
Note: Much of the content from this article was inspired the teachings of Daniel Gullo who I did both my Certified Scrum Master and Certified Scrum Product Owner training through. He is an excellent teacher and I highly recommend him.
What is agile and scrum?
Agile
“Agile” is an umbrella of other frameworks and models including Scrum, Kanban and Scaled Agile Framework (SAFe). My scrum teacher, Daniel Gullo, says that “agile is really a summary of the values and principles shared by numerous practices, frameworks, etc.” and “the focus of agile is to maximize value delivery”. That basically just means that agile is about creating value and so it’s focus is around finding better ways to work together to maximize results based on the value to the organization.
Written in 2001 by 17 independent software practitioners, this is the Agile Manifesto:
Agile ways of working were developed and started in software development. They needed to find faster ways to deliver market value so they could stay competitive in the market.
Waterfall was the main methodology being used at the time. It has a focus on extensive upfront planning and then a rigid structure thereafter with milestones and timelines.
No matter how much planning they did, things in the market were changing too fast. Customer needs were changing, deliverables were taking longer than they expected and often these big projects were failing.
So they needed to find another way to work and that’s where agile was born. Here’s a great article from Forbes that talks about the difference between waterfall and agile and a 60s clip that explains more about waterfall.
Scrum
Scrum was named after a Rugby scrum, the formation that occurs when the ball is brought back into play. It’s the coming together of teams in order to move forward. Scrum is a product development framework however, is often now used in project management and I see huge application potential for small teams and businesses. Learn more about scrum from the official guide.
Scrum Values
“It doesn’t make sense to hire smart people and tell them what to do; we hire smart people so they can tell us what to do.” – Steve Jobs
These values need to be in place to successfully use scrum. Note, this was taken from the Scrum Guide:
- People personally commit to achieving the goal of the team.
- Team members have courage to do the right thing and work on tough problems.
- Everyone focuses on the work of the sprint and the goal of the team.
- The team and it’s stakeholders agree to be open about all the work and the challenges with performing the work.
- Team members respect each other to be capable, independent people.
These values create an environment for a high-performing team. I always loved the Steve Jobs quote “It doesn’t make sense to hire smart people and tell them what to do; we hire smart people so they can tell us what to do.” Smart people don’t need to be babysat. They need clear expectations on what needs to be done, a strong leader to prioritize the workload reasonable, the right tools to do the work and then trust in them that they’ll actually do the work right.
Think about the team that you’re working on right now. How many scrum values are present?
Scrum Roles
There are 3 roles when it comes to implementing a scrum model:
Product Owner
The product owner is the person who is funnelling all of the work requests coming from all the different teams and stakeholders like clients and customers, executive teams, other departments and vendors AND all the other work based on the team vision and goals, improvements, clean-up / technical debt, regular service requests and recurring tasks and putting it into the backlog. They are the person making commitments, setting expectations and if they are doing their job right, saying “no” a lot.
This is generally the team leader because they are the one’s responsible for the team goals and knowing where the organization is headed. They will have the clearest view on what is really important and what’s not. They make the decisions on what is a priority and when, creating the direction on the sprint goals. They are also responsible for clearly communicating all of this to the team and to everyone else.
Developer
These are the people actually doing the work, the people on the team that are responsible for executing all of the task level work that will fulfill the team goals and vision, service requests and recurring tasks. They are responsible for creating the tasks for the sprint goals and committing to the workload. By having each team member be responsible and claim ownership like this for their tasks, it ensures a few things:
- Creating their tasks makes sure they are clear on what needs to get done
- A sense of ownership on what they are committing to versus being told this is what they have to do
- Since they will be the one who executes on the work, it only makes sense that they get some autonomy and a say in how that work actually gets done
They hold each other accountable and adapt their plan each day towards the sprint goals.
Scrum Master
This is the person who facilitates the entire process, ensuring the scrum events are happening, facilitating the scrum events and acting as the liaison between the developers and the product owners where necessary. By having a third-party, it supports the team by having someone who doesn’t have a conflict of interest between the work and the team and makes sure the teams aren’t overcommitting or undercommitting in their sprints. They are responsible for the scrum team’s effectiveness.
By having these clear distinctions, it creates more clarity for everyone to focus on their part of the project.
The 5-level model of agile planning is really helpful to understand the differences too.
The higher-level strategy, vision and planning work is more of the responsibility of the product owner. They need to see the bigger picture 2-3 years ahead for the vision, 1 year for the roadmap and quarterly for the releases to make all of that happen. The more tactical and granular level becomes more the responsibility of the developers since they will be the one’s doing the work and will have a better understanding of what it takes – time, energy and resources to do that. They work together to close the gap between both.
I use the terms “more” responsible because the best teams share some of this responsibility. Although the vision should be created by the product owner, the developers should be able to collaborate and contribute to the roadmap and releases. The product owner also will be involved in negotiating and shaping the daily tasks and the scope. It’s the collaborating and how they work together that is the most powerful in this.
Applying the roles into your teams
In my business, I only have myself and my assistant. I play the role of product owner, scrum master and developer. My assistant plays the role of developer.
When I was head of business operations, I was the product owner and scrum master. I had a very senior member on my team supported me with this while also playing the role of developer. Everyone else on the team played the developer role.
Scrum Framework
Now let’s get into what the scrum framework is, starting with the different events and terminology:
Scrum Events
- Sprint: A specific interval of time, one month or less, to plan your workflow. How long your sprint is will depend on how quickly the environment is changing. When you “lock” in your sprint, the entire team focuses on those items so as the team lead, how long can you go without adding a “last minute, urgent” request in for your team? I’d suggest starting with weekly and then changing it from there.
- Sprint Planning: At the beginning of each sprint to “lock in” the sprint goals and determine what needs to get done. By looking forward and looking at the backlog, the items that contribute the most value to the organization are chosen. The negotiation happens between the product owner and the developers to make sure that there is a clear definition of done (how do you know a task is completed?) and that the right amount of work is chosen. This is facilitated by the scrum master.
- Stand-up: Regular occurring events to check-in on the sprint. Typically 3 questions are asked to keep the team up-to-date and communicating flowing, without disturbing the workflow. Some teams do this daily, I suggest at least one or two a week.
- What did you complete?
- What are you working on next?
- Are there any obstacles or blockers?
- Sprint Review: The time when you review all the work from the sprint. Anyone that needs to be apart of the final “showcase” should be in attendance to provide feedback and ask questions.
- Sprint Retrospective: A review of the sprint to capture learnings for the next sprint. This iterative process helps the team to become more effective at working together each sprint. The 3 questions asked are:
- What went well?
- What didn’t go so well?
- What should be done differently next sprint?
Each sprint will have all of these events. It kicks off with planning, then regular stand-ups and completes with the review and retrospective. Then the cycle repeats, moving to the next sprint.
In my business, we do weekly sprints. We’ve combined our review, retrospective and planning into a 2-hour meeting every Monday. Then we have 30min stand-ups on Wednesday and Friday mornings.
When I was the head of business operations, we played around with both bi-weekly and monthly sprints. We also did stand-ups twice a week. To support communication with stakeholders, we did a monthly blog post to keep everyone up-to-date on what we were working on and weekly status reports for bigger projects.
Other terminology
- Vision: This is the big vision for the team over the next 2-3 years (or more) and it should align to the business or organizations goals. How does your team support the bigger vision?
- Roadmap: Based on the vision, the next step is to create a 1-year roadmap moving towards that vision and starting to understand what those milestones will be.
- Backlog: The “wish list” of everything that needs to get done. All of the work requests coming into the team should go into the backlog. This backlog is then prioritized every sprint, keeping in mind the roadmap and vision. The backlog becomes the “gatekeeper” to make sure that whatever urgent and emergent tasks come along, go through some kind of a prioritization process helping your team move from urgent and reactive to strategic and proactive. Here are some examples:
- You have a conversation with another team lead and they’d love to collaborate on a project together. Great! Add it to the backlog.
- An executive calls you up and says they have an “urgent” task. Great! Add it to the backlog.
- There’s a new tool that you want the team to look at. Great! Add it to the backlog.
In my business, I create a vision for the next 2-3 years, followed by 12-month goals and then quarterly planning. We break out the quarterly planning into sprints and review the plan monthly to make sure we are focusing on the most strategic, needle moving items. Reviewing these priorities monthly and quarterly allows me to make any adjustments for new information and change the goals if needed.
As head of business operations, I created updated the vision annually based on the organizations strategic priorities and then created a 12-month roadmap for the year. That 12-month roadmap often was adjusted at quarterly intervals based on new priorities and new information, yet we also followed a prioritization model looking at value to the business.
Applying it to your team or business
When agile and scrum is applied effectively, your team can run as smoothly as the F1 teams changing a tire.
The best advice I got when I started implementing agile and scrum was to take the concepts that fit and leave the rest. It’s not about getting agile or scrum perfectly, although I know a lot of agile/scrum evangelists might disagree with me here. You may not have all of the resources to support having different people in these different roles or it might not make sense to have all of these events all the time. Try it! Mix and match. Continue to iterate as you go.
The goal is to have an effective, high-performing team and these events create the environment so that you collaborate enough and use time effectively.
3 Key Learnings for Successful Implementation
There were a few key things that made this work so well:
- Executive alignment: The product owner needs to be able to make decisions. They need to collaboratively work with their boss or if they are the business owner, to make tough decisions. Prioritizing and saying “no” is never easy but it’s better to say “no” and then recover quickly than to say yes to everything and under deliver.
- Transparency: Leaders are often scared to be transparent with their teams. They don’t want to be vulnerable or seen as weak. They don’t want to involve them into the mess. Yet, it’s that vulnerability and mess that creates trust. It creates buy-in because your team feels involved in the process. This is true whether you’re creating and prioritizing with your main team, or communicating acoss the entire company.
- Just start: don’t worry about getting all the pieces right.
Closing Thoughts
In the end, the real power of Agile and Scrum lies in their focus on value creation and adaptability. The key is to strike a balance between being flexible enough to respond to new information, while maintaining steady priorities to avoid constant firefighting. It’s all about building a system that serves your business needs without overwhelming your team.
Equally important is creating a high-performing, cohesive team where trust and collaboration lead to better outcomes. A motivated team that works together effectively can achieve far more, benefiting both the business and its people.
If you’re interested in diving deeper, I highly recommend Jeff Sutherland’s TED Talk, “How to do twice as much in half the time,” or check out KnowledgeHut’s courses to become a Certified Scrum Product Owner or Certified Scrum Master.
Keep an eye out for my next article, where I’ll explore how to apply Agile and Scrum for small teams and solopreneurs. In the meantime, you can read my piece on Thinking Differently About Leadership in Business.
And if you’re curious about how a more Agile/Scrum approach could benefit your team or organization, I’d love to connect for a 30-minute call to explore how we can work together to reach your goals.
Remember, growth in your work and leadership, just like in life, is a journey of continuous improvement. Every iteration brings new insights and achievements. The world needs your unique brilliance—so keep learning, keep adapting, and keep shining.
