Five Creative Ways To Start With Scrum Without The Framework
We’ve learned that the best way to start with Scrum is to … not talk about Scrum. Don’t talk about frameworks, events, roles, and…
We’ve learned that the best way to start with Scrum is to … not talk about Scrum. Don’t talk about frameworks, events, roles, and artifacts. Don’t talk about all the benefits and virtues of Scrum. Instead: just do it.
Many people treat frameworks like Scrum as blueprints for change. They read it as an IKEA instruction manual of all the roles, events, and artifacts that need to be “implemented”. But this paradigm inevitably creates its own resistance because it implicitly messages to everyone involved: “How you’re doing things now isn’t effective, and we’re going to change all this starting tomorrow”. Even when it's objectively true that things aren’t effective, nobody wants to hear a message like that. Yet, this is the message we often send in our enthusiasm.
“Many people treat frameworks like Scrum as blueprints for change. They read it as an IKEA instruction manual of all the roles, events, and artifacts that need to be “implemented”.”
In this post, we want to explore an alternative. It's been called “Diveboat Scrum”, “Submarine Scrum” and “Stealth Scrum”, but the gist is always to practice Scrum without explicitly calling it that. It does require creativity. So this post provides five ways to do this with teams that aren’t yet using Scrum or are open to it.
1. “Let's take a step back and learn what we can improve”
Continuous improvement is at the heart of Scrum. You can easily initiate this without referring to Scrum. Instead of beginning about Sprint Retrospectives and how useful they are, just say: “Hey everyone, who’s in to spend 1 hour at the end of this week to reflect on how things are going and identify what would make our work more effective and enjoyable?”. With everyone who opts in, organize and facilitate a session just like you would a Sprint Retrospective. A simple plus/delta is fine. You can also use a short string of Liberating Structures, like this one. Whatever approach you pick, make sure to help the group focus on improvements that are feasible to implement within the coming weeks. At the end ask: “Who’s up for doing this again next week (or two weeks from now)?”. We’ve had good experiences with also adding: “And who else would want to organize that one with our help?”.

2. “Let's take a moment to plan our work”
Daily Scrums may excite people who like to talk about Scrum, but they often raise a lot of questions for those who don’t. Especially to those who are already jaded by years of management methodologies, it will sound like more business bullshit lingo. And they’re right.
You can sidestep all that by not talking about Daily Scrums. Instead, just ask at the start of the workday: “Who’s up for spending a few minutes to plan our work for today? It's also a good opportunity to ask for help if you need it”. With those who join, just have a conversation about what it is you want to achieve today together and how each person plans to contribute. If people like it, suggest doing it again tomorrow. If people don’t want to join, that's okay. If this daily ritual works, they will eventually join anyway.
“If people don’t want to join, that’s okay. If this daily ritual works, they will eventually join anyways.”
3. “Let's visualize our work”
The notion of a Product Backlog is often confusing if you have never seen anything like it. Here too, it's often better to do it (and show it) than to talk about it and how it can benefit a team.
So how do you do this? One approach is to schedule a workshop to just visualize the work together. Don’t talk about “Backlogs”. Instead, just download from your brain what work needs to happen, write stickies for it, and put them on the wall. When you have enough, ask the group to consider in what order it should happen to maximize the value of the work done by this team. What should happen first? Once you have an ordered list, you can keep it on a visible spot in the Team Room of virtual Team Space. Because it clarifies the work that needs to happen, people will likely start referring to it, and you can help by doing so yourself.

Another approach is more involved but works when the first approach doesn’t draw the excitement you’re hoping for. In this case, create a visible space somewhere in the Team Room and start tracking the work that needs to happen on stickies yourself. Whenever you talk about the work that needs to happen, walk over to the work you’re tracking and talk about it there. Update it during your conversation. Eventually, you are likely to see people referring to your list or even updating it themselves. People always like a visual overview of what is happening. So if you do a good job of visualizing the work for a team, they are likely to follow that example.
4. “Let's decide what to focus on this week”
Eyes often glaze over when you start talking about Sprint Planning, Sprint Goals, and Increments. It's often easier to just avoid all the jargon and lingo and do it instead. Here’s how.
At the start of a workweek, ask: “Who’s up for deciding what we want to focus on this week?”. With those who are up for it, spend some time together to set the focus for this week. Just don’t call it a “Sprint Goal”. Once you have some idea of what the focus should be, ask “So what tasks need to happen in order to achieve that goal that we know of right now?”. Visualize what people say on stickies and put it in a “To Do” column on a wall. Once enough work has been identified, you can help the team coordinate who will start with what and who needs help from whom. Before you wrap up, ask: “Who’s up for reviewing at the end of this week to what extent we were able to work towards our focus? And who else should we invite from beyond our team to help us review it?”.

Move the “To Do” column to your Team Room or virtual Team Space. Also, add columns for “Doing” and “Done”. Show the example by always moving stickies across the columns as you work on them, or do it a few times for others and then encourage them to do it themselves. Again, we often find that people start doing this out of their own volition eventually.
5. “Let’s get some feedback from our users”
Finally, Scrum and Agile are rather pointless if teams never talk to their users, customers, and other stakeholders. However, you often lose teams when you start talking about “stakeholders”. It's better to keep it simpler.
If you’ve already done the previous point (“Let’s decide what to focus on this week”), the end of that point already invites teams to think about who else to invite. You can make suggestions here, like “What about [end-user A]?” or “Shouldn’t we ask [end-user B], since this work relates to them?”. Then, facilitate a review with everyone who wants to join at the end of the week just like you would a “Sprint Review” (just don’t call it that). However, spend a substantial amount of time inviting and listening to feedback from users that are present. Although teams don’t always see the value of this initially, we often find that teams quickly see the benefit of listening to users and asking them questions.

If you’ve not yet done the previous point, you can instead begin by scheduling a workshop where you invite a few users, customers, and other stakeholders. Anyone from your team who sees the value in this and wants to join is welcome, and while you can gently encourage people to join, it's okay if they don’t want to. Good facilitation is important here. You can use a string of Liberating Structures like this one. Or pick a single structure like What, So What, Now What.
Closing Words: It’s About The Purpose
One pattern in the five strategies we shared in this post is that they all begin with the purpose. They don’t start with a reading of the Scrum Guide, theory, or the potential benefits of a “Daily Scrum”, “Sprint Review” or “Sprint Retrospective”. By beginning with a purpose, it's easier for people to join in. Another pattern in the five strategies is that each is opt-in. If members don’t want to join, that's fine. You can apply some gentle encouragements like, “Why don’t you try it this once so you at least have an informed opinion about it?”, but you ultimately accept their decision. The nice part of each of the five strategies in the post is that they bring overview, transparency, focus, and collaboration. People like that. So they often eventually join in anyway. The (facilitation) challenge for you is to make it so infectiously fun and useful that people don’t want to stay on the sideline.
These five strategies are a nice starting point. If teams like it, you can use similar strategies to introduce other elements, like the roles and the notion of shippable increments. The best strategy is to just keep your eyes open for opportunities where you can suggest the need for “one person who ultimately decides about what we’ll be working on as a team”, “a list of criteria we all want to adhere to provide a high-quality product” or “an integrated new version of our product at the end of this iteration”. If a problem or challenge arises where those parts of Scrum make sense, it will be much easier for teams to accept that they can help them.
Finally, all of these strategies don’t implicitly signal to teams that they are doing things wrong and “the Scrum Framework needs to be followed to do a better job”. Instead, you’re simply trying out new things and learning together if they work. If the result of this is a process that looks like what is described in the Scrum framework, that's great! If it's not, or not completely, and you’re still able to expand your Agility, that’s great too!
