Rhythm...let's define that word really quick before we move on:
a strong, regular, repeated pattern of movement or sound
In music, that rhythm is the foundational cadence that allows multiple musicians to play together and deliver one common, in-tune, and usually beautiful song. If they didn't have that common cadence, it would be very difficult for them to come together to deliver something of value. In Scrum, we can think of rhythm in the same manner. Many teams overlook the cadence as a foundational element of Scrum. It's purpose is to provide an organizational heartbeat or rhythm of delivery. It is a powerful element of the framework that is sometimes taken for granted. Unfortunately, many teams focus on mechanically going through the motions of performing the ceremonies of Scrum, but likely out of rhythm (or out of tune if you will).
The cadence is simple to follow; just rarely established and consistent. I have 3 things that I do with Scrum Teams before they get to start Sprinting. It's a very effective way to establish the common time of their delivery and allow the organization to understand the cadence as well so they can join in on the song if they choose.
1. Define/Evaluate Roles
It is as simple as saying "Scrum says that we have to have 3 roles". Those roles are the Product Owner, ScrumMaster, and Development Team. Simply write those 3 roles on a white board or chart paper and fill in the blanks for each team. Make the team look at one another and agree that we have the right people in the right role and more importantly that the Development Team has all skill sets required to obtain a potentially release-able product increment by the end of the Sprint. This can take 10 min or 10 hours depending on how well we did at identifying who should be in what role. Even if we don't have the right people and have to start somewhere; we can acknowledge that as a team and ensure we move to correct it as soon as possible.
2. Cadence
This is the sweet spot of this post. Let's agree on the common time of our Sprint. If we are following Scrum, it says that we have 4 ceremonies that happen throughout the Sprint. The Sprint starts/ends and is the same for as long as possible. There is no gap in between Sprints and it should start with Sprint Planning. Doesn't sound too hard right? Well, many teams struggle to define their cadence. Just as we did with the roles, why not sit down and agree on our rhythm. This is obviously not just a Scrum Team decision. The organization has some things to say about this as well.
Agree on the Sprint length (1, 2, 3, or 4 weeks). I like to start defining the ceremonies with the Sprint Review. This helps ensure we are considering the best pattern for our business/stakeholders to make sure they know that every other WED we will be conducting a Sprint Review. They usually have hectic schedules and may travel a lot. Knowing that every other WED is a Sprint Review, they can do a bit better at scheduling travel around that cadence. Agree on the Sprint Review then start filling in the rest of the ceremonies (Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective). After identifying the Sprint Review simply fill in the rest of the ceremonies.
By the end of this exercise, we should be able to look back and understand the cadence and establish when is the best time to conduct Product Backlog Refinement activities as well (when would those fit best with our cadence).
3. Definition of Done
How on Earth can a team start Sprinting if we have no idea the checklist of valuable activities required to call our increment a potentially releasable increment. Ideally the Development Team should be building the Product Backlog Items within the Sprint with the notion that if the Product Owner / Stakeholders / Customers like what they see in the Sprint Review; it could go to Production. While Scrum does not dictate that every Sprint we should be releasing to Production, the team should be building their items at the quality level that it "could" go to Production. This is what helps stabilize quality and minimize the risk of undone work for the organization. It helps us to be a bit more predictable in an unpredictable environment.
That's it! At minimum, before you start Sprinting, try making sure we have those 3 items in place. One other thing I like to do as well (so a bonus item), is to have an education / training workshop to ensure the whole team understands the values, principles, and framework. There are many different experiences and opinions out there and too often we start our process floundering a bit with these past experiences. Let the team hear the same message and congeal on what Scrum should be for THIS organization. Not all of them are the same. I'd be happy to help with that, feel free to reach out to me on the contact section.
Doing this will no doubt help your teams be agile.
