Scrum practices to introduce to a skeptical team

Why won't there be a Scrum Master?

My advice would be to read the Scrum Guide: https://www.scrumguides.org/  To get started the Scrum Team will need all three roles, enough "Ready" Product Backlog items for one Sprint (30 days or less), and a definition of "Done". 

Read up on empirical process control.  Understand the 3 roles, 5 events, 3 artifacts and the rules.  Don't cut any corners (google shu ha ri).  The Scrum Guide is not a 'how to' guide however.  Consider taking a course.  If you cut corners now, the Scrum Team will struggle.

A month is good for 2 sprints. Do Daily Scrums (15 minutes max), find a stakeholder to do a Sprint Review with, do Retro (even if short), and do planning. If the team feels comfortable selecting achievable PBIs in order to realize the set Sprint Goal, then no finer-grained estimation might be required, if the team does not feel like it. Scrum Master... you will be him, but this is not really a reason to remind everyone about it :)

1. If you don't have a solid understanding of Scrum, how are you able to administer this trial period and expect it to have a favorable outcome? 

2. I would strongly encourage you to give an overview of what Scrum is to your team and decide as a team how to move forward; it's not the best practice to start with a trial of Scrum and dictate what will be included and what will be left out. 

3. How is your knowledge regarding Scrum? You'll have a bit of a challenge ahead if you just know the terms used but don't understand how Scrum should work or how it should look. If need be, take a class prior to beginning this trial; worst case find some videos online and get to a place where you can effectively lead the team in Scrum.

Based off the scenario you described, you're the Scrum Master. You are the resident Scrum/Agile expert, you'll be the resource for keeping the team within the framework, you'll be the "answer-man" for questions about Scrum, all of which is the responsibility of the Scrum Master; having a certification doesn't make you a Scrum Master.

Don't worry about velocity and burn down charts and the external tools like that. Story Point estimation is great but really for this trial, I would just discuss the amount of time that it would take to complete. Story Points are an arbitrary unit of measurement anyway so estimating in time as opposed to story points would work best for this trial. You can definitely record the velocity but it won't really be of any use until you've gone through several sprints. Burn Down charts are great as well but not necessary for your scenario. 

Lastly, if it is just too much to take in right off the bat, start super basic with doing the Daily Scrum (stand up). Have everyone get on the same page about what is being worked on and be open if you need help to complete something. Then move up to Retrospective. Have one every few weeks and discuss what the team has worked through and look for ways to improve. Continue to grow from there. Just remember, 1 or 2 pieces of Scrum does not equal Scrum; all pieces of Scrum need to be utilized and implemented to get a better understanding of whether it will work for your team or not.

Thanks for your swift and thorough responses!

Re: Scrum Master. I meant that there won't be any budget for a dedicated Scrum Master role. I suppose I would take up some of that responsibility; I just wouldn't be as effective.

Re: ShuHaRi. Yes, I tend to agree with this. But we don't have a master to learn from. And company culture leans towards freedom to do things your own way. I fear that imposing too much process all at once would not be received well if the team does not have an intuitive understanding of the reasoning behind it.

@Curtis Slough:

If you don't have a solid understanding of Scrum, how are you able to administer this trial period and expect it to have a favorable outcome?

For what it's worth, I think I understand Scrum pretty well. What I lack is experience, which is why I'm asking for advice. It might not have a favourable outcome, but I'll do the best I can.

I would strongly encourage you to give an overview of what Scrum is to your team and decide as a team how to move forward; it's not the best practice to start with a trial of Scrum and dictate what will be included and what will be left out.

They know what it is. And they've agreed to leave the details up to me. But I will organise an initial meeting to discuss the the plan.

If need be, take a class prior to beginning this trial; worst case find some videos online and get to a place where you can effectively lead the team in Scrum.

Those classes are expensive, and not in the budget, I expect, until I can demonstrate the value of Scrum. I will ask, though. Videos are a good idea. Any recommendations?

Based off the scenario you described, you're the Scrum Master. You are the resident Scrum/Agile expert, you'll be the resource for keeping the team within the framework, you'll be the "answer-man" for questions about Scrum, all of which is the responsibility of the Scrum Master; having a certification doesn't make you a Scrum Master.

Sure. The main thing I cannot be is an impediment bulldozer. I still have to be a software engineer for the team.

Don't worry about velocity and burn down charts and the external tools like that.

But the board and charts seem to me to carry the main benefits of Scrum. A way of centrally organising our tasks, and a way of evaluating our performance. Also, those are things I know we can do well.

all pieces of Scrum need to be utilized and implemented to get a better understanding of whether it will work for your team or not.

If that is true, hope is lost, because I don't expect I can bootstrap Scrum all at once. ;-) The rest of your advice also seem to contradict it somewhat, and is well received. I see the value of going 100% Scrum. But several of its practices are valuable in and of themselves, and can probably help introduce Scrum one step at a time.

Thanks!

Going 100% Scrum (roles, events, artifacts) is just the beginning. See the ScrumAnd series (https://guntherverheyen.com/2014/11/16/a-mirror-of-the-scrum-masters-work-so-far/  ; https://www.scrum.org/resources/blog/scrumand-stance-requires-thought-and-discipline-0 )

Don't be afraid about it.

If the team is willing to give it a try (as it looks like), it will be easier than if you just implement parts of Scrum.

"But the board and charts seem to me to carry the main benefits of Scrum. A way of centrally organising our tasks, and a way of evaluating our performance." - IMHO you are mistaken then. These things are not mentioned in the Scrum Guide (Sprint Backlog is). A Scrum team can deliver great value, working with zen-like focus, in total accordance with the Scrum Guide, while making everyone happy, with none of these physical items. Which help... but are not most important.

@ Filip - My thoughts exactly. The scrum board is helpful but the burn down charts and velocity score are not the main benefits of scrum.

@ Michiel 

For what it's worth, I think I understand Scrum pretty well. What I lack is experience, which is why I'm asking for advice. It might not have a favourable outcome, but I'll do the best I can.

I didn't mean to insinuate that you did not have a solid understanding of Scrum, I was just calling out the "if factor" because many people will read every book on scrum but still not understand it correctly. If you feel confident with your knowledge, go for it my friend.

They know what it is. And they've agreed to leave the details up to me. But I will organise an initial meeting to discuss the the plan.

This was called out because I didn't know if your team knew anything about scrum or not. You'd be surprised at how many scrum masters feel it within their power to limit their team to only using a few pieces of scrum. I also called it out because the team needs to have a decent understanding of what they are getting into, otherwise they would be flying blind. I'm glad they have that understanding because it will make your task easier.

Those classes are expensive, and not in the budget, I expect, until I can demonstrate the value of Scrum. I will ask, though. Videos are a good idea. Any recommendations?

I agree they are expensive but it is worth the shot asking for sure; worst you can be told is "no". As far as videos, search for videos on "how to implement scrum". You'll find a great deal of helpful videos. Honestly, I have not watched these so I cannot vouch for their content. 

Sure. The main thing I cannot be is an impediment bulldozer. I still have to be a software engineer for the team.

I know your pain. I'm currently doing a dual role of QA and Scrum Master. It's tough but I make the time to fit it in because Scrum is helping my teams and our company overall. There are many impediments that you can raise the issue to the appropriate person and get back to engineering. The main thing is not that you fix the impediment yourself, instead you do what is necessary to remove them in the most efficient manner possible.

But the board and charts seem to me to carry the main benefits of Scrum. A way of centrally organising our tasks, and a way of evaluating our performance. Also, those are things I know we can do well.

I agree the scrum board (product and sprint backlogs) are very important in Scrum but they are not the most important by a long shot. Many other methodologies and frameworks utilize a story board, it's a pretty board tool that is just used a bit differently between say Kanban and Scrum. The burn down chart is just a report, it is not scrum specific either, all it shows is the progress the team has made by "burning through" the backlog. As for velocity, it's just a reference number used primarily for planning and forecasting. It wouldn't hurt to take note of the number of story points your teams completes through each of your sprints through this trial but just know that it won't give you an accurate score after 1 or 2 sprints. It takes 4-5 sprints at least to get a consistent velocity and one that can be trusted for planning and forecasting. All due respect, Do you think that these tools are more beneficial than the events in Scrum (Planning, Review, Retro, Daily Scrum, and the Sprint)? Do you see them as more beneficial than the values and pillars of Scrum? 

If that is true, hope is lost, because I don't expect I can bootstrap Scrum all at once. ;-) The rest of your advice also seem to contradict it somewhat, and is well received. I see the value of going 100% Scrum. But several of its practices are valuable in and of themselves, and can probably help introduce Scrum one step at a time.

You took that a bit out of context. It was just a reminder that if you want your team to see the true value of scrum, they need to utilize all of scrum. Just doing the Daily Scrum or the Retro may help your team, but you cannot gauge whether Scrum will work for your team based on those 2 pieces of Scrum. I had to start slow with my current teams, honestly I'm still working on the transformation here. I had my team's buy in for Scrum but was limited by upper management unfortunately. We started with the daily scrum and retrospective's. For the retro's we just basically met for about an hour every Friday and talked about what went on that week and looked for ways to improve. The team loved it because we were growing and getting better. However, I think you'd agree that you cannot gauge whether Scrum will be truly beneficial and the right fit for your team by just doing those 2 events. That was my point of calling this out. Same way of getting a Pizza and only eating the crust and saying Pizza is your favorite food. There is a lot more to Pizza than the crust. While the crust is important, the sauce, cheese, and toppings impact the pizza to a greater extent than the crust does.