Agile And Scrum: The Prerequisites For Effective Product Management!
Before we talk about becoming a product owner/manager, we need to talk about AGILE and more specifically, Scrum.
👋 Hey, Pramod George here! Welcome to ✨ The Business Of Products Newsletter✨. Every other week I share insights about building products, processes and teams that work!
Before we talk about becoming a product owner/manager, we need to talk about AGILE and more specifically, Scrum.
Why? Did you know that the product owner is a role that’s actually defined to work within the Scrum Framework?
If you wanted to become a goalkeeper, you’d first understand the game of football. If you wanted to become a batsman, you’d first understand the game of cricket. Similarly, knowing the framework in which the role of a product owner/manager is defined is the right first step when deciding to become a product owner/ manager.
So let’s get started!
A Brief History Lesson: How Products Used To be Built!
In the early days of software development (1980-2000), software was still being developed like a physical product because they inherited industrial project management techniques.
Requirements come first, the design comes second, then development, then testing and so forth. This was called the waterfall model - think a slow, trickling, stage-by-stage process.
Under Waterfall, the software project is rigorously designed upfront, in the way that one might manufacture a wristwatch or a car. In a waterfall model, each phase must be completed before the next phase can begin and there is very little overlapping in the phases.
However, this kind of project management technique had many flaws.
No working software is produced until late during the life cycle.
Software development experts referred to it as "the application development crisis," or "application delivery lag" estimating that the time necessary to go from idea to a complete product was almost 3 years.
High Risk and Uncertainty.
3 years is a long time in the software world. A lot can change in just 6 months- requirements, systems, and even entire businesses were likely to change-making your work of the last 3 years obsolete.
Cannot accommodate changing requirements.
Not a suitable model of development for complex projects with a high risk of changing requirements. For example, once an application is developed and is in the testing stage, it is very difficult to go back and change something that was not part of the original plan. When things needed to be changed, we need to start from the top all over again, further increasing the time to deliver the software.
WaterFall Shortcomings Explained Visually
I explain the shortcomings of the waterfall SDLC methods using the below sequence of images. I show the team only the first image (from left) and ask them what it is? No one can tell me what it is. I then show them the second image (from left) and ask them again what it is, yet most are unable to answer. I repeat the question after showing the 3rd and 4th pictures. Only after seeing the 4th picture can the audience actually tell me what the picture is.
This is representative of how much users have to wait to derive value when software is built using the waterfall method. Each block represents a fully completed piece of the tech puzzle that must come together to get the final software to work properly (Think up to date secure databases, frontend, backend, access controls etc). As time progresses few blocks are completed but since the others are not ready yet, the software doesn’t work. We must wait till all blocks are ready for the picture to come together and the user can get to use it.
Fortunately many realised that software needn’t be built like a physical product and thus was born the “Agile” SDLC model. Otherwise also known as the “iterative model” of software development.
Agile Software Development Life Cycle (SDLC)
In this model, the software is developed in versions and is iteratively enhanced with regular feedback from the user. The focus is on early and frequent delivery of a slice/functionality of the final software, which is then reviewed to identify further requirements.
This process is then repeated, producing a new version of the software at the end of each iteration of the model.
At each iteration, design modifications are made and new functional capabilities are added.
Agile Methods Visually Explained
I explain the value of Agile methods by showing my audience only the first image (from the left) from the below list of images and asking them what they think the picture is. Everyone immediately answers - “The Statue of Liberty”. Even though it’s a monotone image with no colours, no background, etc, it’s still immediately recognisable. That is the benefit of AGILE!
In Agile methods, teams aim to deliver a working version of the product that users can begin using so that they can gain feedback about what to do next. It may not have all the features that the end product must-have, but it will have the basic functionality necessary for users to start using the product.
The brilliance of the agile methodology is that it allows the users and customers to participate in the development process and ensures that we are building the right product.
The AGILE Mindset
The AGILE Model is a mindset and can be summarised into “The Agile Manifesto”.
The Agile Manifesto is a document that identifies four key values and 12 principles that its authors believe software developers should use to guide their work.
The 4 Values Of Agile Software Development
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
These 4 values can be further broken down into 12 principles for more clarity.
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 for 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 behaviour accordingly.
If you have read this far you might be getting a hint of why I said it is important to understand Agile and Scrum prior to becoming a product manager or owner because it establishes in you the mindset required to build products the right way!
The Scrum Framework
While the Agile Manifesto gives us the right mindset, Scrum provides us with the project management techniques to successfully run a product development project.
In a nutshell, Scrum requires a Scrum Master to foster an environment where:
A Product Owner orders the work for a complex problem into a Product Backlog.
The Scrum Team turns a selection of the work into an Increment of value during a Sprint.
The Scrum Team and its stakeholders inspect the results and adjust for the next Sprint.
Repeat
from The Scrum Guide
Scrum is simple. Scrum implements the scientific method of empiricism and helps people and teams overcome the challenge of unpredictability by providing a process to solve complex problems.
The below graphic represents Scrum in Action as described by Ken Schwaber and Jeff Sutherland in their book Software in 30 Days taking us from planning through software delivery.
How To Learn SCRUM
Learning SCRUM is easy and all the best resources are available freely. Here are the steps (+links) that I would take to learn Scrum.
Read the Scrum guide patiently at https://scrumguides.org/. It should take you 30 mins or less to go through the entire guide. That’s how simple it is, so don’t skip any parts of it.
Go through the 14 Scrum Foundations Video Lessons playlist by Scrum Alliance on their Youtube Channel.
And that’s it. You could gain a complete understanding of Scrum in half a day.
I hope this primer was sufficient to get you excited about the SCRUM framework. Let me know in the comments.
How did you like this week’s newsletter? 😃
Legend • Great • Good • OK • Meh
If you’re finding this newsletter valuable, consider sharing it with friends, or subscribing if you haven’t already.