Scrum Vs Design Thinking Vs Korus

So let us talk Scrum, Design Thinking and Korus, three different project management approaches, which can actually work together, but before jumping into them, let’s take a helicopter view.

Project management is more than simply tracking deadlines and setting a budget, the purpose of project management from beginning to end, is to ensure that the initiatives and goals are strategically aligned, the project has stakeholder support, and everyone is on the same page.

Why is Project Management Important?

“Operations keeps the lights on, strategy provides a light at the end of the tunnel, but project management is the train engine that moves the organization forward.” ~ Joy Gumz

Too often, organizations overestimate how quickly they can achieve deliverables, underestimate the costs, or both—a recipe for failure; but somehow the question remain, why is it important? Well at the end, project management is fundamental to hold the team and client together, aligned with the project.

Project Management “Crash Course”

You will find several project management methodologies, approaches, I’ll share three that I use the most, one is Scrum, another is Design Thinking and last but not least my personal invention “Korus”.

Let’s start with the “official” project management methodologies Scrum and Design Thinking, how can you use it, when can you use it, what is it?

To start from, you can combine them both, meaning, Design Thinking and Scrum, respectively problem finding and problem solving to improve the outcome.

You can look at Design Thinking as an approach to problem finding and Scrum as a problem-solving approach. It calls for a high degree of empathy and understanding of end users, and an iterative process of developing new ideas, challenging assumptions, and redefining problems, with the goal of identifying alternative solutions that might not necessarily be apparent.

Before going further, let’s dive into the two of them, separately.

Scrum

First, let’s cover Scrum, most likely one of the most famous agile approaches, if not the most famous. Scrum has a short fixed schedule of release cycles with adjustable scope known as sprints to address rapidly changing development needs. A Scrum process differs from other agile processes by specific concepts and practices, divided into the three categories (Roles, Ceremonies and Artifacts.

Roles:

Product Owner – The Product Owner represents the Customer, should be responsible for the product backlog, and should act as the bridge between the Customer, respective stakeholders and the Scrum Master and respective Development Team.

Scrum Master – The Scrum Master should make sure that the Team, follows up with the Scrum Process and act as the facilitator, giving guidance to the Team and help to unlock any potential block. 

Development Team – The Development Team is responsible for addressing the sprint backlog items, in order to deliver a “potentially shippable” product and respective increments at the end of each sprint

Artifacts:

Product Backlog – Is the list of everything that is due to be deliver. The Product Owner should be the responsible for the Product Backlog, wish means that the same cannot be tampered without his/her approval

Sprint Backlog - Is the set of requirements that are due to be delivered at the end of the sprint, by the development team. Normally, together with the Sprint Backlog you will find a task board, where you can check on the evolution of everything that needs to be done, from “Backlog” till “Done”.

Ceremonies:

Sprint Planning Meeting - that aims to define a sprint backlog, identify the work for the sprint, and make an estimated forecast for the sprint goal.

Daily Scrum – It’s performed on a daily basis (10 -15 min), to review what was done on the day before, what will be done today and to check if there is any blocker, this for every team member. Any blocker in the daily scrum should be captured by the scrum master and displayed on the team’s scrum board, with an agreed person designated to working toward a resolution (outside of the daily scrum). No detailed discussions should happen during the daily scrum.

Sprint Review – Should be held at the end of each sprint. The same normally takes a shape of  a Demo, with the new functionalities that will be deployed. It’s also a good opportunity for the Team to make a final check before the same is presented to the Customer.

Sprint Retrospective – It’s a kind of a “lessons learned”, at the end of each Sprint, to review if everything is working as it should, if not to, look for ways on how to improve the way of working. The whole team should be part of the session.

Design Thinking

Design Thinking is an iterative process focus on the user, on it’s challenges and assumptions, It’s a solution based approach to identify the problem/s. In a nutshell is a user-centred approach and not a product centred approach to problem solving, that normally takes into consideration ( the user/human centred approach, out-side of the box thinking, collaboration and prototyping).

The classical Design Thinking is made of five stages:

Empathize – Understand people, their behaviors, and motivations, the understanding emerges through viewing users and their behaviors in their context (e.g.: place of work) to identify patterns, ask questions, and challenge assumptions.

Define – Create an actionable problem statement to define the right challenge to address, as well as the set of needs that are important to fulfill, based on the organization, its goals, and the perspective of end users.

Ideate – Leverage techniques such as brainstorming, mind mapping, sketching, or creating paper prototypes to step back, go wide, go out-side the box, in order to come up with different and innovative, impactful solutions to solve the problem.

Prototype – Focus on trystorming, create quick prototypes in order to show to the user how could it work and begin collecting the feedback, before jumping into building.

Test – Learn from the user’s experience and feedback, and repeat the process repeatedly, until you have the minimum viable product.

Scrum & Design Thinking together

Although Scrum as become a very popular project management approach, does not guarantee, that your teams will, on a consistent way deliver the most engaging and spot on solutions. Why? Scrum is focus on solving the problem and deliver, is not focus on knowing what’s the correct problem to solve, to start from.

Giving an example, the first Iphone, came and solved some challenges/problems that people “didn’t knew they had”; such as, the fact that people had to use a kind of a “pen” to be able to touch the screen and select whatever function was available. Another, the fact that the mobil phone was focus on security and not on being intuitive to people, as consequence of that, it took much longer for people to understand and work with the phone. At first we didn’t see it as a problem, because it worked, meaning the phone worked; but one thing is for certain after the Iphone was released a revolution started, that even caused indirectly the completely collapse of some mobile phone brands.

So taking that into consideration, let’s make an analogy and map it with the two methodologies, so the first one could be done by Scrum, it did delivered a working product, but it missed the problem. Apple was able to solve the problem with a more human/user centred approach, and revamp completely it’s brand and products, that could be a reflection of design thinking approach. I’m not saying that was exactly what Apple did, but let’s assume it was analogy wise. If we look, to most Apple products that were launched since then, you can tell that the Customer/User/Human is indeed in the centre and not the product.

For this and other reasons, there is a growing need to leverage both, design thinking and scrum (or another agile methodology) for problem finding (Design Thinking) and problem –solving (Scrum). After you identify the problem, you can use scrum to incrementally build the solution and making it a “living product” that evolves at each release, taking into consideration the user feedback and market feedback.

To conclude, you can applied them alone, and not mix them, but there is without a question room for the two methodologies to work together, for instance whenever there is a need for human/user centricity and rapid and continuous iteration.

What is not Design Thinking and what is not Scrum

Design Thinking is not a process, is much more of a mindset, it’s about customer centricity. Although methodologies and processes are important, there is a need to change the mindset, and focus on the “right” problem and on the user, not just deliver.

Scrum is not about doing more work, with less people. Scrum is not about having unclear requirements because of the changes along the development of the product, you should have clear user stories to be added to the Spring backlog. Scrum is not about having fixed pre-defined budgets, with constant alterations to the backlog, but looking to pay the same, is not about having a Product Owner that does not talk to the Scrum Master nor the Team. It’s about having an agile approach, that will lead to continuous iterations, to tackle the lack of complete view of what will be final solution. 

The pitfalls of Scrum and Design Thinking

Scrum Pitfalls

Based on my experience I would highlight five pitfalls.

-         Having Scrum only on the IT side.

o   Essentially this should adopted by all, not just by the Tech part, it needs to be inclusive Business and IT, need to adopt it

-         Lack of a big picture

o  Since Scrum is focused on continuous improvement and iterations, there is a constant thinking that there is no need to understand where are we going, but rather adapt the product/solution as we go.

-         Unpowered and Confused Product Owners

o  You cannot have a Product Owner that does not own the scope, nor the backlog, nor the interaction with the rest of the Business, they are fundamental for project success.

-         Lack of leadership sponsorship

o  Essentially and as refered before, this is not about IT, this is about everyone, including top management, they should sponsor the way of working and the project to make sure that is a success.

-         Skipping Scrum bits and pieces and going back to old habits

o  Normally this happens when the Team, is not still fully embedded with Scrum and we have setbacks, project wise and we need to “deliver, deliver”, therefore enter into “war mode”, there is a tendency to loose direction and fall back into old habits, that will eventually have an impact on the Team, on the Project and the Customer.

Design Thinking Pitfalls

-         Island Behaviour

o  Lack of engagement with key parts of the organization, can lead design thinking island behaviour, that at the end will not bring any added value to the organization.

-         Problem Finding vs Problem Solvers

o  Most people, tend to be better at problem solving, but no as good at problem finding.

-         Start with the solution in mind

o  Instead of looking at the challenge with an open mind, there is a tendency to jump into solution mode, or even start with the solution in mind, that will clash with the out-of-box mindset that you need to have in order to find a innovative approach to the problem

-         Go around and around

o  Although there is a need to be open minded, there is also a need to avoid going around in circle or to prototype without a purpose, therefore loosing time and wasting resources.

 Why do I prefer “Korus”?

Well, I prefer, because it’s focused on project iterations with a strong focus on customer centricity and big picture without losing sight of the need of continuous project iterations (waves / releases), in order to adapt to the business needs and market demands. It assumes that the Project Team, needs to be proficient on the solution, that they are working on, in order to better advice the customer, on my case and because I work on Salesforce and on Marketing and Revenue Operations, that would be mean that you would need to be proficient on Salesforce Sales Cloud, or Salesforce Service Cloud for instance plus having business knowledge (Marketing, Sales,etc.)

I’ve split the methodology into three main stages Project iterations, Pipeline and Daily Meetings. Within the Project iterations stage, I normally focus on five sub-stages, the Project Kick-off, the Discovery Session, the Design & Test, the Enablement and Lessons Learned, with a strong view on Project KPI’s, to make sure that we deliver accordingly. 

On a daily perspective and to make sure that the Project does not fall into the cracks, I tend to use two approaches, one the Daily meeting, like the Scrum meeting, focusing, on what was done, what will be done today and if there is any blocker, that we need to address, another looking at the Pipeline, essentially a board that displays the full pipeline, across the different stages( Backlog, Blocked, To do, Today, In Progress and Done), this of course with a priority methodology in place.

For those that are at the beginning of the project management journey, feel free to check the Ultimate Guide to Project Management by Lucidchart I found it quite interesting!

Please feel free to reach out if you have questions, happy to help.

Enjoy your day ;)