Signs of SCRUMbut or something else that i missed ?!?

Yes, that is Scrumbut.  And according to the Scrum Guide, you can't do part of Scrum.  However, remember that Scrum is a framework and not a methodology.  Procedural decisions are up to the people in the teams but you still need to honor the values, events, artifacts of Scrum. It is not unusual to see elements of SAFe, Lean, Kanban, etc in a pure Scrum shop. 

Having said all of that, there is very little in what you describe that is Scrum. I would almost call what you have ButScrum.  We do all of these things but we call it Scrum.  

Given the history you describe, you will have a long road to get everyone to "SCRUM by the book".  And it is going to threaten the world in which a lot of your people live. If you do get some traction on your idea, I'd also suggest that you attempt to get some outside help.  Someone who is completely neutral to your company but is well versed in implementation of Scrum and Agile.  You will most likely need some kind of hybrid solution and that is what Agile Transformation or Corporate Agile Coaches do best. 

Good luck. 

Is it "ScrumBut but we'll improve" or is it "ScrumBut because we won't change"?

For me, that's key in what makes ScrumBut what it is.  The idea that Scrum should change to fit the company rather than the company change to fit Scrum.

Thank you Daniel for feedback, confirmation is what i required as current co-scrum masters that are longer at the company are doing it as above but they give me free hands how i wish to do it. I started with agile for the framework reasons and the benefits it bring to the team, my plan is to follow the framework, letting them fail and with power of suggestion bring it to my teams and company. This things take time and for sure i will not give up as i see it as a good challenge to undertake.

The extra information i gathered is that agile development is in the company for 4 years, old SCRUM masters work period ended in 1 year and half in average during this period (sounds a bit demotivating but i stay always positive).

Good things that i see and may work in my favor which i can use as entry point:

• I consider myself as neutral as well still as i am pretty new and maybe my observations will help them see
• Company is providing education which is good thing, SCRUM, SAFe and LeSS certifications
• Company is supporting agile way but has to listen as well
• During last three weeks company as well encouraged communities of practices, one of them is for agile change and second one is for team leads in which they find a best way to bring junior devs up to speed
• My boss is as well open to ideas and transparent, did not yet try to give proposals and my assessments as i am pretty new and young (my next step)

Regarding external coach to help us with transformation is as well a good idea, maybe they already had one before (question for a new day).



Any feedback is welcome that can assist me. Techniques that can be used for slow approach without out bursts.

Is it "ScrumBut but we'll improve" or is it "ScrumBut because we won't change"?

For me, that's key in what makes ScrumBut what it is.  The idea that Scrum should change to fit the company rather than the company change to fit Scrum.

I believe it is then SCRUMbut we will improve, for that reason i am motivated to continue and help to improve. 

As Daniel said SCRUM is a framework build on many years of proven experience,  the changes i see in the company are only harming the company and not helping at all, for that reason is better go back to basics, learn the basics and master them ... when basics are mastered and then you can do SCRUMand to improve and bring extra value.

Any feedback is welcome that can assist me. Techniques that can be used for slow approach without out bursts.

Find out who wants Scrum, at an executive level, and why. You’ll need a sponsor who will help you to overcome organizational gravity, and those impediments which lie outside the team’s ability to resolve, such as dependencies on others for work to be truly “Done”. An organization cannot typically be expected to transform faster than its management are willing to change.

+1 on Ian's remark.

And to add on that, start by focusing on the stuff that actually impedes your team. A lot of people don't respond well to arguments about Scrum by the books. They do tend to respond better to improvement suggestions where they feel the consequences of the impediments.

Find out who wants Scrum, at an executive level, and why

 

Exactly. I think our Head of IT is the person to which i must turn to. He is doing a lot of actions in this regard (for example he started the initiative agile change and community of practices), But what i see where he is failing is that he try to oversee everything (daily, plannings, retros ... )  and not trusting people to self organize so he is seeking constant feedback.

A lot of people don't respond well to arguments about Scrum by the books. They do tend to respond better to improvement suggestions where they feel the consequences of the impediments.

Confirmed, in first three weeks i got this already.

Really thank you all, all the feedback and confirmation on the current observations.

The way I got my team closer to Scrum by the book was to not call it that.  I was asked to facilitate the daily standup (yes that's what it was called, which was actually a sit down) where we previously went through every item in the current Sprint and people reported.  I got it down to 15 minutes by focusing on just what moved from to do to in progress or from in progress to done.  The rest of the items got ignored until someone started working on them.

We did allow for discussion after the 15 minute meeting if people had impediments, questions, needed to brainstorm, etc.  But the standup was always 15 minutes.  Wasn't able to get everybody to call it the scrum, but small steps.

I also introduced a review halfway through the sprint to allow for us to look at what had been finished and what was left for the rest of the sprint.  Our biggest challenge is that items were hanging on from sprint to sprint, so another thing we started doing was estimating.  There was a conflict between using story points and hours, so the compromise we settled on was pointing the stories during grooming and estimating hours at the same time.  We also track hours at the task level.  This was due to management desires, but I also see it as being useful in that we can track time against the estimates as an additional prediction tool for further refining our pointing process.

Finally, I started scheduling the sprint retrospective so that it always happened.  

Most importantly, everything was done as a suggestion for process improvement, and everything was an increment.  If you do it slow enough, they don't even notice, which reduces a lot of resistance.

Most importantly, everything was done as a suggestion for process improvement, and everything was an increment.  If you do it slow enough, they don't even notice, which reduces a lot of resistance.

This is the key that sometimes i forgot when alot of information floating around me. Thank you.