Organizational Rhythm

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).

CreatingCadenceExercise

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.


Related Articles

We can't release until the end of the sprint...

As I work with Scrum Team's, I find a common thread in teams that believe our releases are "tied" to the Sprint time-box. This is not the case. Releases are independent of the Sprint time-box. If you have something that meets the team's definition of done, the Product Owner has...

Read More

So you want to do Scrum?

What do you truly want? I have spent a career helping organizations go from whatever process they are doing to wanting to be more agile. The request typically starts with "We would like you to come in and conduct some Scrum Training". Great, I love conducting workshops and helping people...

Read More

Core Scrum Roles

Just like the US Government has 3 branches (Judicial, Executive, and Legislative Branches), Scrum has 3 roles. Many people compare the counter-balance of each roles in Scrum to that of the US Government. It's really about the checks and balances. But I truly believe it is even more than that...

Read More

Is Your Team Focused with a Sprint Goal?

One of the 5 values of Scrum is Focus. Too often, I will ask Product Owners "What is the goal of this sprint"? Their response? "To get all of these Product Backlog Items done!" (and they look at me like...duh!)  My question is focused on ensuring that our Development Team...

Read More

Stop Starting and Start Finishing

Ever run in a race or participated in a track meet? No matter how far the distance, when you cross the finish line, you’re done. It’s easy to understand and you don’t have to linger around, waiting for anything else to happen. What happens when you need to get an...

Read More

The Role of a Project Manager in Scrum

We had a great turnout at DFW Scrum last TUE for "The Role of the Project Manager in Scrum". Many organizations struggle with what to do with the Project Manager when they have a Scrum Team. Chris Eberhardt and myself facilitated this fascinating conversation. The reality is, there is not...

Read More

Requirements in Scrum

Let's be honest. Most teams struggle with how to get requirements into their new "agile" process. Take Scrum for instance. Scrum says you start with what is called a Product Backlog. Let's see what the Scrum Guide says about the Product Backlog: The Product Backlog is an ordered list of...

Read More