When I think about failing, I remember so many great quotes. There are a few that have stuck with me over the years:
“If you’re not failing, you’re not trying hard enough.”
“Doing nothing is worse than failing.”
“The fast way to succeed is to double your failure rate.”
You might be thinking, ‘...is number three even a real quote?’ The answer is yes; the quote comes from Thomas J. Watson, the founder of IBM. My impression of this quote is that the faster we fail, the quicker we learn, the sooner we succeed. To that point, this means to learn to ride a bike, maybe even a backward bike, we must fall more often. To accelerate a team’s maturity for higher degrees of success, we can increase the speed and frequency of failure (e.g. Feedback). So how do we do that? We do that by creating shorter experiments.
A Sprint in Scrum can be defined as an experiment. At the end of the experiment, we use the data we have collected to help the development team not only make changes to the product, but also to improve the team (continuous improvement). These experiments become “feedback loops,” which allow us to use the outputs of the experiment as inputs into the next sprint. Another way of saying this is that we are taking the empirical knowledge we have gained from one sprint to the next.
Over the years, I have “Lifted Off” many new Scrum teams and have had great success using one-week Sprints. Yes, I didn’t stutter - I said one-week Sprints. One-week Sprints provide the team with the ability to learn up to 4 times faster than if they were doing 4-week Sprints, and they accelerate their maturity.
When teams are new to Agile or even just new to working together, they are in the Shu stage of Shuhari. The Shu stage is when the student is learning the fundamentals (in this case, Scrum) and should follow the Master. Now, if you are a product of the ’80s, this means wax cars, paint fence, sand floor, and paint house. Yes, I’m talking about the classic movie The Karate Kid. Daniel was in the Shu stage with Mr. Miyagi. He was learning the fundamentals and following the Master. They even made a pact, “I promise to teach Karate to you, you promise to learn. I say, you do, no questions.” This is Shu, and this is where I have found success with one-week Sprints, just like Mr. Miyagi using repetition to accelerate Daniel’s leaning.
Repetition is a powerful learning tool. Repetition is a powerful learning tool. Repetition is a powerful learning tool. When I was a kid, everything I learned, from the classroom, to sports, to home, was learned via repetition. It’s why homework was given, and it’s how I learned to throw a slider. It’s even how I learned to tie shoelaces. Doing anything repetitively supports learning, and it helps transition what is being learned from a person’s consciousness to the subconsciousness, or moving from Shu to Ha. What those of us in the industry like to call “Doing Agile to Being Agile.”
When you have a team using one-week Sprints, it increases their Scrum event and artifact repetition. The team’s Sprint Planning, Retrospective, and Sprint Review that would occur once every two-week sprint now would occur twice over two weeks. The same goes for the team’s artifacts. There is more attention to keeping the Product Backlog refined since it needs to be ready for Sprint Planning every week. The Sprint Backlog gets created weekly, and we have a new Product Increment complete at the end of each week. Lastly, although not an artifact, the team’s Definition of Done is reviewed every week. All of these things combined “shines a spotlight” on team issues and organizational issues quicker.
Each Scrum Event plays an important role in the overall framework. I have found that conducting one-week Sprints has benefits at every Event to help a team mature.
The Sprint
- It forces small stories
- Stories must be small enough to be completed in 4 days
- Smaller stories force a team into reviewing the Definition of Ready more often
- Creates the understanding of swarming quicker since the team realizes by day three. They need to work together on stores to get them done instead of waiting eight days to figure the same thing out.
- Reduces the timebox for the Sprint planning, Review, and Retro events
- Reduces the need to start using story points out of the gate
- What I have found here is that there’s enough to learn in the beginning, so let’s not add to it with story points. I eventually come back after about 3 to 4 Sprints to teach the team about story points by doing a Relative Mass Valuation on all the stories completed.
- Teams like to be successful, and not only that, they like to celebrate success. Everyone’s probably heard about how good it is to celebrate small successes. The more opportunity you have to celebrate, the more you will celebrate. Remember, if you take the word failure and use it as a learning opportunity, there’s no reason why a learning opportunity couldn’t be considered a success. It’s about which side you are looking at the 6 or 9 from.
- It allows the team to adapt to changing priorities quicker. We all know we shouldn’t be adding work to a Sprint. If the team is new, there is likely a good chance that the product they are working on is new as well. So if a new team has a new product, chances are priorities are going to change more frequently.
Daily Scrum
- With more team members swarming on work, and with less work “In progress” it’s much easier to respect the timebox.
- If you have habitual outside members attending the team’s daily scrum, there is less chance for questions because they are not worried about the story that’s been sitting in “to do” for the last week wanting to know when it will be complete.
Sprint Planning
- Timebox reduced from 4 hours to under 2 hours
- It’s much easier to plan for one week than it is for two weeks
- Eliminates estimation confusion - What goes into the backlog is a gut feel of what the team feels they can complete, and since we are not doing story points, we don’t have to deal with velocity yet.
- It helps the team to rapidly understand their S.W.O.T.
Sprint Review
- Since the team is showing their work more often to the stakeholders, they can course-adjust quicker.
- It helps the team understand the stakeholder’s value quicker, and that leads to understanding the importance of VOC.
- Understanding leads to maturity.
Retrospective
- It allows the team to inspect a shorter duration of time more frequently. The ability to inspect what occurred over the sprint twice as fast as a two-week sprint leads to increased maturity. It’s great to change, but it’s even greater know what to change so we do that by inspecting.
- Once inspected, we can adapt. We are now adapting every week and making changes to the process more frequently. I also found that things have a better chance of getting change since instead of trying to implement two things every two weeks, we are implementing one change per week. So the team has a better appetite for that.
- Since sprints are shorter, so less time goes by, and the team can remember what happened. How many of you have been in a retro and the team can’t remember what happened the day before never mind what happened two weeks ago.
The idea of one-week sprints may seem strange, it may seem abnormal, it may work for you, it may not work for you, but if you have a growth mindset, I challenge you to give it a try. For more information on how we can help you with your Agile journey, view our Agile consulting services.
