It's OK.
You've been there: you're on a new team, or a team new to Scrum or Agile, and there are old patterns, and skepticism, and fear, and a flavour of, "But Mom, I'm drinking my milk with this tiny spoon and I'm OK with it - it's fine - I don't want to change - I don't care if we miss the bus - NO!"
Usually after a management mandate, everybody is doing this rugby term, running all out for two weeks at a time, planning out how to do just that on a Wednesday instead of a more intuitive Monday, and stopping to stand together once a morning to justify our existence. Oh, and then we talk about our feelings for an hour at the end of this endless cycle.
After some training, or some experience, and usually both, the above facetious characterization transforms into actually doing work, through this Scrum framework.
By the third retrospective, you get at least one person who is at least no longer an ardent skeptic. This may be due to an individual win. "It's easier to get help on something because we all see what's being worked on." "I see if I"m about to get slammed with testing." This may be due to a perceived team win. "We finally delivered something." "We actually talk about the thing we're working on and catching gotchas before we even start."
Implementing Scrum, or anything Agile, is change management. For the change to stick, it takes time as well as knowing both the culture and context. Every context is different, so your Transformation Backlog should be tailored. What can y'all do to get a win for the team? What can y'all address later?
There is great empowerment from self-organizing, and if that manifests in conducting the Sprint as a mini-waterfall, with there being an Analysis stage, then a Development stage, then a Testing stage, then heck: help them get a win. Help them get something to done. Help them see they can do it their way.
Small wins build confidence.
Small wins show this whole Scrum thing ain't all bad.
Small wins embolden the team to take on more change.
Small wins prepare the team for more mature Agile ideas.
Like working out that crutch of an in-Sprint, mini-waterfall practice, and towards an ideal of single-piece flow via a collaboration of generalists, for example. Wait. What?
Take a breath.
(It's OK.)
Let's swarm.
To act out the desire to get things to done by the end of the Sprint, the Daily Scrum puts some focus on the items in the 'Testing' column/stage (usually the column closest to the 'Done' column/stage).
My preamble for the Daily Scrum is:
"Welcome to the Daily, where we see how we can help each other get things to done... starting with things in test."
(If I'm in the mood, I'll say that last bit like, "Pigs in space!" Don't get the reference? It's OK.)
This preamble sets the stage, and also prepares the team for my occasional interjection of, "How can we get this thing to done?" And once the team has some wins under their belt, once they're no longer stumbling with Scrum, but rather walking with Scrum, and usually towards the end of the Sprint, I will nudge with, "Can only the testers do the testing?"
This can ruffle feathers.
(It's OK.)
This question juxtaposes two notions:
we are a set of individuals: we do only what our departmental job title says we can do
we are a team: we help each other, even outside of our core competency
In getting the software developers comfortable with doing some testing, that conversation puts aside the notion of individual efficiency, to acknowledge the teamedness of the Sprintly endeavour, and to go outside their comfort zone to help a sistah out. You'll want the team's hearts 'n' minds to be softened to the idea of swarming beforehand, especially since it's a non-waterfall way of working, so, again, heck: help them get small wins.
Let's set Work-In-Progress limits.
Have the team look at the task board at the Retrospective, and say what they see. If they're consistently looking at a virtually empty board with all their items in the 'Done' column, then you 'n' I should become friends because that's awesome. (Now go find ways to challenge the team to become higher performing.) If not, you're in great company. In my experience, there's usually pile-up in the 'Testing' column, or there's a good chunk in the 'Developing' column with an accompanying emptiness in the 'To Do' column. Probe at that. Ask what we can do to shift this final Sprint visual from lots of work-in-progress, to fewer started and more done. If the team doesn't get there on their own, you can be direct: "Can we encourage swarming by setting WIP limits?"
This will also ruffle feathers.
(It's OK.)
Now you'll hear how they'll finish the work in the next Sprint anyway, so there shouldn't be a fuss. Or how pair programming only slows them down. Or how if a bug is found and a software developer is already working on something, then you could exceed that limit suddenly and easily.
(It's OK.)
Much like the stories are a placeholder for a conversation, exceeding a WIP limit becomes an event for a conversation.
Do we enjoy how getting things to done affords us to start a feedback cycle on that done thing to see if we are making an impact on our users and our business?
Do we want to see this as an opportunity to cross-train? For senior members (or folks who want to have 'Senior' in their title) to mentor junior members?
Do we recognize we are 'breaking a rule', albeit thoughtfully, to prioritize getting the buggy item closer to done, or at least not starting something new?
Watch the team work with WIP limits. They will say more often, "I can help with that." These are small wins. Point this out.
Let's get crazy.
Set the board to just three columns:
To Do
In Progress (with a WIP limit)
Done
Point to the small wins before selling this idea. Point to how more is getting to done by the end of the Sprint. Point to how y'all are collaborating more. Point to how y'all feel more... like a team. Talk about how this is a natural progression.
"This is stupid," you will hear.
(It's OK.)
This is where I usually start cashing in my 'social capital' chips. "Let's give this a try," I'll say. "Look at where swarming and setting WIP limits got us," I'll remind them. "We will be an unstoppable machine that can take on anything because we help each other out because we are The Wombats, or whatever out team name is," I'll proclaim.
Let's get crazier.
Have you heard of mob programming? I have. One of my teams is in the slide deck Woody Zuill uses. I'm bragging now. (It's OK.) Look into this. It's like pair programming, except the whole team is behind one person at the keyboard - there's more to it, but mob programming is about as un-waterfall as you can get.
Let's look back.
You've been there: you're on a new team, or a team new to Scrum or Agile, and there are old patterns, and skepticism, and fear. Then you tailored your Transformation Backlog, iterating it along the way, helping the team get small wins over time.
And all along the journey, especially in those challenging times, there was one recurring message.
It's OK.