Updated: October 2, 2024- 9 min read
Newcomers to Product Management can be easily baffled by some of the terms we throw around, and lurking behind each one is an entire methodology that it can take years to truly master. Is getting to grips with terms like Agile and Scrum a daunting challenge?
Well, not as much as you might think.
We’re here to explain the basic principles behind these two methodologies, explain the main differences between them, and show you the path to learning more about them. You’ll be agile and scrumming in no time!
What Is Agile?
It’s quite rare that one methodology should taken over an industry as completely and as quickly as Agile has taken over both software development and Product Management. Anyone even on the fringes of these worlds is familiar with this methodology, and knows that it enables teams to build better products. But how does it do that, and how does it affect a product manager’s work?
Agile was born in the 1970s, when the then popular waterfall method was criticized as being too restrictive for developing software. The waterfall method involves the idea that you cannot move on to the next stage of building something until the stage before it has been completed. It’s a very rigid framework, which doesn’t allow development teams any flexibility, meaning there is no time to adapt to change.
And, as anyone will tell you, technology changes fast. Something new was needed to allow companies to try, fail, try again, and succeed, at the same rate that technology was evolving.
The Agile Manifesto
Remember that scene in Lord of The Rings, when the Fellowship was formed and it changed the fate of Middle Earth forever? Well in this case Middle Earth is the product world, and the Fellowship is a group of 17 software development practitioners at a ski lodge in Utah.
They agreed that the traditional way of building software just wasn’t working, and together they came up with a manifesto.
The Agile Manifesto is formed primarily of four core values and twelve principles, which can all be implemented and interpreted in a variety of ways to allow to maximum impact. A tiny indie start up with a team of 2 can implement the same agile method as Google, but in a different way.
The Core Values of the Agile Manifesto
Let’s start with the four core values and what they mean for product managers.
Individuals and Interactions Over Processes and Tools:
This is a people-first mindset that places more value on the team than the structures they have to work with. In practice for a product manager, this might mean changing your processes if they’re not working for the team, rather than forcing the team to adapt to the processes.
Working Software Over Comprehensive Documentation:
Before agile, pages and pages and pages of documentation were required before any part of the development process began. Now teams place the emphasis on getting the product into the hands of the customer. Agile processes prioritize the product, not the bureaucracy around it.
Customer Collaboration Over Contract Negotiation:
A key agile methodology is that the shape of the product can change throughout the lifecycle depending on new information from the customers. If you started out promising ABC, but after a few months of research discovered that users wanted XYZ, agile allows you to pivot to meet the new demands.
Responding to Change Over Following a Plan:
“Don’t laminate the roadmap!” In agile, strategic reviews and re-prioritization of features allows teams to respond quickly to change, but in a structured way. Agile doesn’t just allow for change, it expects it.
The Twelve Principles of Agile
Now we can take a look at the twelve principles of the agile methodology, and then we think about what they mean for product teams.
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Business people and developers must work together daily
throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity –the art of maximizing the amount of work not done–is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
There’s quite a lot of information to unpack within these twelve principles, and for a product manager they encompass all aspects of the job, from how they interact with team members, to how they manage stakeholders, and structure the development cycle.
As a product manager in an agile environment, you’ll have to get used to working closely and collaboratively with cross-functional teams much more than you might have in other occupations. Product managers sit at the intersection of business and technology, making them perfect leaders for agile practices.
The focus of agile is also on simplicity. Tools like MVPs are instrumental in agile development as they allow for minimal resources and spending, and maximum flexibility. As a Product Manager, you’ll be always putting the customer first, and making sure that their voice is not lost among office politics and silos.
In fact, all of the twelve principles are absolutely key to a product manager’s job. But remember, these are guidelines and not rules. Agile practices are designed to be bent and shaped around your development team. Throughout your career you’ll try and fail and learn what works.
What Is Scrum?
Once you’ve grasped agile, you’re ready to move up to Scrum.
Scrum, more commonly associated with project management, is a methodology developed by Ken Schwaber and Jeff Sutherland. Self-described as ‘simple to understand, difficult to master’, it takes years of practice to be considered adept. But that doesn’t mean you need to wait until your 10th year in product to start learning!
Scrum is a framework designed to make team collaboration on complex products as effective as possible. The product owner manages the product’s backlog, a collection of tasks that need to be completed to deliver the product. The self-organizing development team then works through these tasks during a period of time known as a sprint. The tasks will be displayed for the entire team to see, usually on a whiteboard with sticky notes, which allows everyone to easily see their progress.
Based on the goal of the sprint (each team may work towards one common outcome on a spring), a sprint backlog is created.
Within the spirit of collaboration, once a day the teams will meet for a fifteen-minute meeting, known as scrums. These daily scrums are an opportunity to discuss progress and help the teams workshop problems.
As the sprint progresses, the product increment grows iteratively, which allows the teams to quickly iterate and adapt based on the progress they are making.
After the sprint, stakeholders are invited to a sprint review, which fosters an environment of transparency within an organization. As Scrum is designed to focus on people over processes, the development teams will also hold a sprint retrospective, where they assess how well they worked together, and what improvements could be make in future.
Who is the Scrum Master?
If you’ve been in the product world for any length of time, you’ve definitely heard this term thrown around, but you might not know what it means. You can think of a Scrum master as a team captain, who helps everyone to understand the principles and processes of Scrum.
The Scrum master keeps track of and organizes the Scrum events (the sprint, the daily scrums, the review and the retrospective) and the artifacts (product backlog, spring backlog, and increments.) This role requires a good understanding of leadership techniques, as you’d be leading the scrum team across the entire development cycle. The role is remarkably similar to a Product Manager, and there is often a large amount of overlap between the two roles.
Agile vs. Scrum: What’s the Difference?
It’s not an easy thing to directly compare Agile and Scrum, as Agile is a methodology which can be interpreted and implemented in a variety of ways depending on the needs of the product.
With its events and artefacts, Scrum provides a structure for teams to follow with specific goals and processes. Two different agile teams at two different organizations may do things completely differently to each other. Whereas two opposing Scrum teams will still carry out sprints and retrospectives etc.
The two methods also differ in a few other ways:
Hierarchy is key for building agile products, whereas Scrum teams are largely self-governing.
People in agile teams are constantly collaborating with cross functional teams
, whereas most of Scrum’s collaboration takes place during the fifteen-minute meetings.
Scrum is better suited to projects where the requirements change frequently, as teams can adapt their daily tasks to meet the new needs of the product.
Scrum is more focused on delivering business value throughout the entire process, not just at the end.
You might now be wondering, ‘is Scrum agile?’
Yes, and no. Scrum is a way for the agile methodology to be implemented in software development. But all agile is not Scrum.
An agile team might implement some of the characteristics of Scrum, such as a daily stand up meeting, but without every piece of the puzzle, you’re just not doing Scrum.
How Do I Choose Between Them?
To learn more about these two topics, we particularly recommend The Scrum Book: The Spirit of the Game by Jeff Sutherland and Dan Olsen’s The Lean Product Playbook.
If you’re in a position to choose the processes your development teams work with, then you’re most likely already very well-versed in both. Introducing Scrum to an agile company which has gotten a bit sleepy in recent years can be a great way to motivate the team. If you’re a large, traditional organization which has yet to adopt any agile processes at all, diving headfirst into Scrum would be inadvisable.
If you’re an aspiring Product Manager who is worried about choosing the appropriate methodology for your team…that’s highly unlikely to be your responsibility just yet. As you move up the ladder in product, having an awareness of how these processes work will set you up for success in the future.
Updated: October 2, 2024
