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

Last post 07:47 pm October 25, 2018
by Denis Molan
9 replies
Author
Messages
08:58 pm October 22, 2018

Hi,

New to the forums, nice to meet you all. To give you a quick recap, i started fresh as SCRUM Master at the new company (3 weeks in), been before
7 years senior backend developer and last 7 months doing deep dive into agile development, soft skills and PMI (for cross comparison).

Signs that i noticed at new company:

  • Pre-existing SCRUM master not doing Scrum by the book (example Daily stand ups including tech. discussions, reason being team decided to do so, on time not enforced, POs present at dailys working with team)
  • Spoke with many development teams and they see SCRUM masters as secretary position or as junior project managers 
  • Company does user stories (estimations) but also does log work hours per task and has no burndown charts (the ones that exists are not usable)
  • There are no product owners but there are business analysts that are as well certified PO and Scrum masters (they see scrum masters as secretary as well)
  • hierarchy introduced in the company as well, they have BA (PO), Scrum Masters, Team Leads and Dev team ... dev team and team leads are not on the same level. 
  • They had before many team leads and BA doing triple duty, as scrum masters or BA or team lead and scrum master
  • Using part of SAFe and using part of Spotify logics (quilds and charts ....), nothing fully balanced
  • Same retrospective each time
  • And for last teams are not stable at all

 

Are this signs of SCRUM but, as company is having SCRUM in the name but doing it differently all the way, hard to find balance. 
Many articles say that it is recommended to do SCRUM by the book and after you have experience you add value but avoiding buts as much as possible.
Any tips?

My plan is to recommend using SCRUM by the book and with it make a compromise, get something and give something up. By giving few runs they may see the benefits of scrum by the book.

03:29 pm October 23, 2018

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. 

03:38 pm October 23, 2018

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.

 

03:55 pm October 23, 2018

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.

04:03 pm October 23, 2018

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.

06:23 pm October 23, 2018

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.

06:32 pm October 23, 2018

+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.

08:01 pm October 23, 2018

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.

03:40 pm October 24, 2018

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.

07:47 pm October 25, 2018

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.