A colleague unfamiliar with lifecycles or agility asked, “How can we use sprints in this approach?” and pointed to a phase-gate approach with documentation deliverables after each phase. It looked just like the serial lifecycle in the image on the left. (That's because a finance person drew the lifecycle.)
I said, “You can't use ‘sprints.' You can use timeboxes. But don't confuse timeboxes with sprints. Every sprint delivers working product.”
He said, “We'll deliver documents after each phase.”
I said, “No, documents are not real deliverables. Documents represent what you think a deliverable will be. Not the thinking and learning that go into the deliverables where you end up with something demo-able, if not usable.”
“Oooh.”
He's not stupid. He's ignorant. And I bet some of your senior leaders share his ignorance. So, here are the definitions you can point your leaders to, so they understand.
Understand Timeboxes
I find timeboxes useful for focus and for finishing something inside of a relatively short time period. You might call me a “Timebox Empress.” (I've graduated from Queen to Empress in anything. Hehe.)
I use timeboxes to focus on and finish one small piece of work:
- 15-minute timeboxes to write anything. Nonfiction, fiction, books, articles—you name it.
- 30-minute timeboxes to do a draft of a workshop.
- 10-minute timeboxes to create images
Notice that I use relatively short timeboxes. That's because I have a ton of deliverables over short and long timeframes. I want to make progress on “everything,” but I don't want to interrupt myself with multitasking. When I use a short timebox, I can focus and finish.
I used to recommend that teams use 1- or 2-week timeboxes up until about the early 2000s. (Maybe 2003? 2004?) I still do, assuming one team works on one project at a time with very few interruptions. If your team has many interruptions, I recommend you use a kanban board, work in flow, and avoid timeboxes longer than a day. (See Create Your Successful Agile Project for more details.)
If you know you'll have interruptions, why try to timebox for longer than a day? Don't make yourself crazy with the impossible task of trying to work inside a timebox longer than a day. Instead, accept your reality and plan differently.
You can still have iterations and not make them sprints. First, let's define what a sprint is.
Understand Sprints
Sprints are a special form of iteration. I'll discuss an iteration below.
If you want to use a sprint, first, read the Scrum Guide. It's not a long document. The Guide defines what Scrum is and is not.
The sprint has:
- A sprint goal
- Several events, such as “Sprint Planning, Daily Scrums, Sprint Review, and Sprint Retrospective” (quoted from the Scrum Guide). These events occur inside the sprint.
- Delivery of value during and certainly at the end of the sprint.
If you don't have all three of these, you are not using sprints. You might use an iteration, but it's not a sprint.
Why am I so specific about these ideas? Because most teams I see use iterations, but not sprints. They don't have a specific sprint goal. They do have product goals. Maybe that's fine and still in the spirit of Scrum. However, they don't deliver value, have team-based planning, a review/demo, or a retrospective. If you don't do all of these, it's not Scrum. (I would argue it's not effective either, but that's a different problem.)
All they have is the 2-week timebox. That timebox pressures the team without delivering value. And leads to my colleague's confusion about what a sprint is.
Scrum, with all the details about sprints can make you more effective. However, you have to do all of Scrum to call it Scrum.
Now, it's time for iterations and how they can help you be effective.
Understand Effective Iterations
An iteration is a (team-based) timebox longer than a day. It's often a week or more. And you don't have to use an agile approach to use an iteration.
For example, I used month-long iterations for most of the projects and programs I managed up until about 2003 or so. (That's when I moved to two-week iterations.) At the time, I used an incremental lifecycle, so we could visually see our progress every month. We used internal demos because the cost to release was so high. (See Design Your Agile Project, Part 1 and Frequency of Iterations is Related to Speed of Release. )
If you don't have all the conditions necessary for Scrum, you can still use iterations. Even if you have interruptions.
In this case, set your timebox as large as “much time as you can afford to waste.” (I wrote this in Manage It!) In addition, track your progress with a kanban board, so you can see the progress of all the work. Then, you can see the effect of the interruptions.
If you can afford to waste only a week, set your iteration duration to one week and make sure you have a deliverable when the iteration is done. If you can afford to waste up to a month, make the iteration duration a month. Be prepared to throw everything away after any given iteration.
That's why I prefer shorter iterations to longer iterations.
Most of my clients don't have a goal for each iteration—and that's fine. More and more of my clients integrate demos multiple times a week, not just at the end of a timebox. However, for planning purposes, they use a 2-, 3-, or 4-week iteration. That's about the feedback cycles they need.
How Can You Be More Effective?
When I think about being more effective, I think about the most important work I can do. How can I make progress on my deliverables, especially if they are short and near-term? Do I need to devote a day and finish this deliverable? If I need to wait for other people, I might use a shorter timebox, such as 15 minutes. That timebox allows me to make progress.
If you're part of a team, does Scrum make sense for you? It might. Read the Scrum Guide. Please.
If you have a lot of interruptions, or you have no Product Owner, you might not be able to do effective sprint planning. I suggest you move to iterations and frequent deliverables and demos to be more effective. Don't assume you're doing Scrum if you don't have a product owner. You're not. In my experience, you are way too normal.
Use what makes sense for you. Do timebox at the personal and team levels to focus on and finish work. However, don't think you can “sprint” in a waterfall and deliver documents and see the value of the work. Software product development is learning. Not documents. (See the lifecycle series for more information on how you can work more effectively.)
Good luck.