1st Scrum Master to a organization
Hi everyone. Long time lurker and decided to finally take the plunge and join the community. Been a Scrum Master for a few years now but I've found myself in a scenario that I hadn't been in before and wanted to reach out to the community to get their insights.
Was hired into a medium sized organization who has not done Scrum ever and a few people in the org have worked in scrum environments. Right now they have a 2 year schedule. And I'm working with the teams to break them down. I am the only scrum master they have.
A few obstacles (and how they are being addressed):
-The team is completely new to scrum and the work is in a profession with a lot of regulations.
-We have no backlog (Currently working with the team on breaking down requirements documentation to create the epics, features + stories) We've spent a week and a half doing this and it is looking to take a month's time.
-Product Owners have zero input outside of people individuals who just want the work completed and the timeline met, regardless of it meets testing standards
Some things I am thinking and wanted to get the community's thoughts on it.
1) Going ahead and scheduling the ceremonies, even though we don't have the backlog fully groomed, I still want the team to get used to doing the ceremonies and what we have groomed we can start planning and estimating even though development work is not being done in the sprint?
2) Have the team to go ahead and start doing some dev work while still taking time in the sprint to do WBS as a user story, we are creating a brand new software platform from the ground up and the plumbing needs to be in place.
3) Should I do infrastructure work + dev work in a sprint, or spend the first few sprints doing only infrastructure work? Like I said, this is a new scenario for me and I want to get the input of others as well.
Why did you organisation moved to agile? You might want to ask your management the reason, start from there. If you want to pursue on adapting agile framework, it needs to be from the top cascading to the employees, not the other way around (you will have a hard time if you did it that way).
If you management answered that they move to agile because it is faster, they might have a different understanding of agile which you need to explain or teach.
Like Sherwin said, the reason for agile is important. When you say that there is a schedule of 2 years this may sound like a waterfall approach. Whatever, it will be up to you to help management have the right vision about agile. So good luck.
On your comment about Product Owners have zero input outside of people individuals who just want the work completed and the timeline met, regardless of it meets testing standards. From this sentence, we could say that the deadline is set in stone, if we suppose your team won't change and the money spent has already been set, and if you want some agility, only the scope will vary. When I say the scope, it is not only the goal but the way technically you do it (software, architectures, databases, ...). And maybe your stakeholder don't care about anything else, but maybe your PO could use the architecture to use the data inside to provide more value : services to other departments or as input to other software, ...
So to come to your questions:
1) you don't have to have a backlog with all defined. Only the most significant items, so that people can begin working. This way while the Dev team begins to work on the most important items, the PO could work more on the PBI. The increment only has to be a PBI with a definition of Done potentially releasable. So don't worry too much, because at the beginning, the Sprint goal will be crafted by the Dev Team and the PO. The design will take most of the time of the sprint, maybe 1 or 2 after. But at least there should be something releasable and so initiated, even very simple. Let the Dev Team decide what is the best, and not have them do, "just" by rightfully questionning a lot will be done.
2) already answered
3)I highly suggest infra + dev, because questions will emerge and so the architecture will change and your practices too.
Should I do infrastructure work + dev work in a sprint, or spend the first few sprints doing only infrastructure work? Like I said, this is a new scenario for me and I want to get the input of others as well.
If you don't provide an increment of usable functionality -- however small it may be in relation to any infrastructure work undertaken -- would it really be a Sprint? How would you demonstrate value to the PO and stakeholders, and make it clear to them that they have an opportunity to shape product delivery now?
A few observations regarding your situation:
Right now they have a 2 year schedule
What evidence does your company have that their projections 2 years out are valid and accurate?
Currently working with the team on breaking down requirements documentation to create the epics, features + stories
What is most important in refinement is the conversation between business and the Development Team. From the way you explained it, it does not seem that this is taking place. Instead, business has thrown a big requirements document (BRD) over the wall, and the Development Team is working in a silo creating Jira items from it.
This is not Scrum.
Product Owners have zero input
The primary responsibility of a Product Owner is to maximize the value delivered by the Development Team. How can this be supported if your Product Owners have zero autonomy over what the Development Team works on?
As Ian pointed out, every sprint must provide an increment of potentially-releasable functionality. Which of your suggestions would support that?
And going back to the initial question posed by Sherwin, why did your organization choose Agile/Scrum? What is their understanding of it, because based on how you've explained your situation, they appear to be simply re-labeling existing practices and calling themselves Agile.
Stop asking the question "why the hell would your organisation want scrum" but start selling it to the organisation. Show the clear advantages and disadvantages to come with it. Scrum is painfully good at showing where the problem is. Showing, realistically, what was delivered every sprint and how that impacts the planning and future can be painful, but I'd rather take that pain today than near the end of the project.
There's a lot going on here :-)
1) Yes. The best moment for change is right now, there will always be questions and unclearancies, and if you want it to be anywhere closer to perfect the first time around than it is right now, you are forgetting that scrum itself is emperic and there always is room to improve. Whether it is right now or 6 months from now. Just be honest to your surroundings: it's not going to be perfect the first time around, but give it time to grow and at some point, no one is willing to let go of it anymore.
2) and 3) The goal of every sprint is to have a working increment at the end of the sprint, starting at your first sprint. This does not mean that all plumbing should be in place before you start writing code, but just sufficient plumbing. I understand that especially for big organisations it could take long before the first piece of plumbing is in place, but therefore I refer to question 1, setting up the first scrum team in your organisation means something for the organisation as well.
Good luck taking your company on this new, great adventure!
I was in your situation not long ago in an organization that didn't know Scrum and thought that they knew Agile. Here is what I did:
Step 1 - Organize and run workshops so that those who will be in Scrum Teams know what Scrum is. You can use materials provided to you in an in-person Scrum training class
Step 2 - Have the Development Team leads and/or Product Owners (where relevant) schedule all the Scrum Events
Step 3 - Don't overthink it. Let people start to collaborate. Give them the space to talk, think and breathe. Don't force Scrum. Agility takes months to get started. Focus on serving the team(s) and the rest will come with time.