This is an example of an entry-level educational blog post that aims to introduce a target audience to a concept, practise or discipline and walk them through the absolute basics. Whilst technical in nature, it aims to explain the concept or idea in simple terms and present the author as an expert, yet relatable in that they can present their expertise in a manner that is easy to understand.
As the audience moves from newbie to more advanced stages, the technical nature of these blog posts become increasingly more sophisticated and are designed to help move the target audience through each critical stage of the buyer’s journey, armed with the information and evidence they need to make a great purchasing decision.
The blog post starts now.
What is Scrum?
Scrum is a collection of good product development practices. A collection of good ideas.
Every part of scrum could be used in isolation, and they would still deliver value. The sum of its parts is greater than the individual bits, and so when you use the Scrum framework the way it was intended to be used, it becomes incredibly powerful in helping product development teams solve complex problems and build complex solutions.
Scrum Application
Scrum is a tool.
It doesn’t solve problems, it highlights problems and provides you with a framework to effectively solve those problems, correct dysfunctions, and optimize the environment for the team to succeed.
It doesn’t fit every problem though, so you need to select the right agile framework to help you achieve specific goals and objectives rather than deploy Scrum into every given situation.
In complex environments where you require a team of people to work together to solve a complex problem or develop a complex solution, Scrum is a great tool. It helps you quickly and effectively validate that you are solving the right problem or building the right solution and ensures that you quickly and consistently get working products or features into the hands of customers.
Scrum ensures that you get things done.
It ensures that you provide a customer or stakeholder with a working product or feature at the end of each Sprint, and use the feedback, data, and guidance you receive from customers and stakeholders to inform what you work on next.
So, in a nutshell, Scrum helps us validate that we are working on the right thing and whether that thing is valuable to a customer, a product stakeholder, and the organization.
The origin of scrum.
There are a million different stories about how Scrum was invented, but we’ll stick to the narrative of the cocreators of Scrum, Ken Schwaber and Jeff Sutherland.
Ken and Jeff were developing software and frequently ran into problems using the traditional project management approach, and so they consistently developed good software engineering practices and over time, Scrum simply evolved because of those great practices and interventions.
Scrum in the context of product development
Scrum became incredibly popular for product development teams because it gives you a great place to start. If you had a product to build or a problem to solve, Scrum gave you a lightweight framework that helped you get started and build momentum quickly.
Scrum is a way of achieving agility, but it doesn’t represent ALL of agility.
When you have an enormous series of problems to solve and don’t have a clue where to start, having a framework that sets things in motion provides significant value.
Structure
Scrum also brings discipline and structure into the product development equation.
The framework recommends that you do X amount of events, at the very least, and actively deliver a working product or feature at the end of each short sprint.
You’re not going to spend 18 months in planning, you’re going to deliver something that works within a maximum of 4 weeks. Something that a customer or stakeholder can review and provide feedback to inform you of what you attempt in the next 4 weeks.
Scrum ensures that:
- You plan to deliver something within a maximum of 4 weeks.
- You actively deliver something that works within a maximum of 4 weeks.
- You actively engage a customer or stakeholder within a maximum of 4 weeks.
- You actively engage the team on how and where to improve every 4 weeks.
- You actively engage your team, every 24 hours, on what is happening and what is preventing you from achieving your goal for the next 24 hours.
And so forth.
Even if you don’t call it Scrum or don’t adopt Scrum formally, simply doing those things will ensure that you are on the right path to product development success.
So, Scrum gave teams a great starting point, instilled a degree of discipline to ensure that the right boxes were being checked, and helped teams identify the problems that prevent them from achieving their goals and objectives.
Why do I recommend Scrum to others?
I recommend Scrum to others because it’s a great way to start, especially in creative fields where you can’t know the answer upfront and can’t follow a formula to produce a valuable result.
When you don’t know what you can’t know, Scrum allows you to get going and discover what you need to learn through the process. With each Sprint (a maximum of 4 weeks), you’re going to learn a great deal and you’re going to deliver something.
Sure, the team can evolve from Scrum, and often do over time, but it’s the perfect place to start when you are dealing with complexity and uncertainty.
Scrum reveals problems.
Some of those problems have always been there, we’re just making those problems visible and providing a context as to why that problem is significant.
Other problems are revealed because we are working on complex problems and in the context of complex problem-solving or solution development, this element needs to be addressed before we can move forward effectively.
Evolving from Scrum.
Some of the problems you encounter may be because Scrum isn’t exactly the right fit for your context and organization. Great. We can simply identify what isn’t working and look for a different solution to that problem.
It may be that planning on a regular cadence isn’t working for the team, given the nature of the environment, and so having a pull-based system like Kanban is a better fit that allows you to manage the flow of work effectively whilst retaining the core elements of Scrum that do work incredibly well with your team environment.
My focus is always on value delivery.
We don’t need dogma and rigid, robust rules in a product development environment. That is precisely why we moved away from traditional project management, and so we want to be agile and make sure that the team can adapt and respond as necessary.
We want the team to develop a hypothesis, run an experiment, validate what works versus what needs work, and to move forward based on data, feedback, and evidence.
We’ll leave the Agile dogma and rules for people who are more concerned about being right than doing the right thing.
Scrum holds us accountable for consistently improving over time. We are supposed to identify what is preventing us from succeeding, and we are supposed to adapt and respond appropriately, so it’s natural that we will evolve from our initial starting point.
If we improve by 1% every month, that is a 12% improvement over a calendar year.
A 12% improvement could mean a lot of money in revenue generated or costs eliminated. It could mean a great deal more customer satisfaction, a greater number of customers acquired, or a significant improvement in customer retention.
That is the power of Scrum.
It gives you a great place to start, it holds a team and organization accountable to actively deliver value in short, rapid periods of time, and it forces us to evaluate where we can improve each sprint.
It is virtually impossible not to improve. It is virtually impossible not to evolve.
