My temamates are stuck with "waterfall" aproach.

Forget the mechanics of doing Scrum for a moment. Your team is working in a classic waterfall pattern of sequential handoffs, phase gates, and delayed feedback. Whether they call it that or not doesn’t change the reality. Has your boss articulated the urgency to change to a new way of working using Scrum? What problems have been identified with the prior approach, and how will Scrum make their work lives better and improve value delivery?

First off, no offense but I am not clicking on a link that is encoded.  It may just me but I like my computer the way it is. 

Second, @Chris is right.  There will not be any change made if the rest of the organization is not willing to accept it.  I've been in the software industry long enough to predate Microsoft Project plans. My first boss gave us development requirements using a very small spiral pad that he carried in his shirt pocket.  If your boss wants things to change, he has to show support for it, work to ensure that the rest of the organization is aware of what is going to occur, and provide the ability for everyone to make mistakes while you change. My old boss never changed so we kept doing things the way it had always been. But I have worked with other companies that were willing to change. In fact, one company I worked for made the change to Scrum for the entire organization.  It was driven by the CEO and CTO. Every department used the Scrum framework for their work. Even the C-staff did one month Sprints and their deliverables would find their way into other Product Backlogs in some form or fashion.

Try to work out a way that you can do an experiment with actual product changes and use that as the "picture" of how things will work.  Get your boss to support it and provide themselves as a conduit to make the work visible.

I know a picture can say a thousand words, but unfortunately each picture is in the eye of the beholder. So not everyone will hear the same thousand words.  Actions speak louder than words. 

It is good that your boss is involved—management support is essential for Agile adoption.

Expect some resistance. Training and workshops, and especially letting people know the benefits of change, can help shift mindsets. 

Creating a prioritised Sprint Backlog each iteration, drawn from a Product Backlog, is good. Re-prioritising as new information emerges is good.

However, I am careful with language like "resources assigned to tickets". (Personally I don't like the word resource, we are working with people.) Scrum encourages team ownership, not assignment to individuals. The team pulls items into the Sprint Backlog together, and everyone shares responsibility. While people have specialisations, there are no silos—developers can support testing, and testers can give early feedback even as early as the design phase, and also should do that.

Good luck with the transition! It can be an exiting and rewarding experience.

But lately my boss tried an effort to introduce an agile concept with scrum.

To my surprise it was not well accepted...

Had your boss really tried to do this, or had he or she tried to delegate the matter onto you?

It isn't your organization to change. You can help. You can advise. You can draw pictures., but it's up to your boss to create enough of a sense of urgency so change becomes more important than the day job.

Hello Fredrik,

I've looked at your two first pictures, the third picture's link is broken. Don't worry, I've got a Mac, so it's more difficult to ransomware my system.

1) You are using a Kanban board, but with only 3 columns (To Do - Doing - Done), it is real difficult to manage visual work in a flow.
Best is to split your "Doing" column up in minimum an "Development" column and an "Testing" column. Each of these two columns needs to be split up in two additional sub-columns (In XX, and XX Done). 
So know you will end up with (To Do - Development - Testing - Done) / (To Do - In Development-Development Done - In Testing-Testing Done - (PBI) Done).

2) Next is to manage the sub-columns, I suggest reading the Kanban Guide for Scrum Teams (https://www.scrum.org/resources/kanban-guide-scrum-teams) or if you have previous experience in Kanban.


3) Then we have to take a look at your Upstream approach, which is even more import than starting the Sprint with everything that this entails. So we are talking now about Refinement Session(s)! 

Scrum itself does not prescribe how you do a Refinement, only that you do Refinement and that the resulting PBI (Product Backlog Item) has to fulfill only two rules: "Do we as a Scrum Team understand the problem/need from a Business point of view AND is the PBI small enough to be done in 1 Sprint." 
Sounds simple, but to get there takes some work.

The method that I personally use during Refinement sessions is that besides your PO, the Business stakeholder(s) are present to explain their need. The architects and analysts are there to discuss only the crosstraints (already in place existing architecture that needs to be followed and/or business rules) and the Developers are there to ask questions to better understand the BUSINESS need and the consstraints.
So we talk only about the problem and how to split up the problem in manageable PBI's, we are not talking about a solution in this phase.

4) During the Sprint Planning and in the Sprint itself, it is up to the Developer(s) to talk and implement a solution. Here are the Developer(s) in the lead, but than can ask support from the Business Stakeholder(s), Architects and Analysts when needed and for verifications.


It's not going to be easy to convince and implement this and it is a grow process, first attempts will be bad and improvements will be gradual, but it is a process of grinding, learning, adapting and improving.

Hope that this helps and good luck.



 

Whooo, I was still still half a sleep whzn I typed my response and I can't edit it.

Some typos:
---------------
So know you = So now you
crosstraints = constraints
consstraints = constraints
 

Hey Fredrik,

Thanks for sharing your experience and the images—it's a solid effort to visualize the agile process for a team used to waterfall! From what you described and the images, your approach to showing how the team collaborates in sprints, prioritizes work, and adapts to obstacles aligns well with agile principles.

That said, resistance is totally normal when moving from a long-standing waterfall culture to agile. People often struggle with letting go of clear “handover” points and siloed responsibilities because agile encourages cross-functional collaboration and continuous communication.

A few thoughts that might help:

• Emphasize why agile values continuous collaboration over handovers—how it reduces delays, improves quality, and responds faster to change.
• Maybe try running a few small pilot sprints with the team to experience agile firsthand rather than only explaining it theoretically.
• Highlight how roles overlap and support each other rather than replace traditional silos.
• Keep the language simple and relatable—sometimes jargon like “GIT-flow” or “iterations” can confuse those new to agile.
• Encourage open discussions about concerns and fears around the change, so people feel heard and involved.

Overall, your visuals look good and your explanation hits key agile points. It might just take time, patience, and small wins to get everyone onboard.

Would love to hear how it progresses!