Juliet said “A rose by any other name would smell as sweet.” Shakespeare was arguing (through Juliet’s dialog) that the names of things don’t matter. What matters is what a thing “is”. And what if someone points to a daisy and calls it a rose? That doesn’t make a daisy smell any sweeter. Your “rose” will not impress your date.
And if you call something an iteration that isn’t an iteration, you’ll be less successful in delivering your software than you thought you’d be. If you use iterations, you want to make sure you enact real iterations in your project. Said another way, iterations should have behavior associated with them, not just timeframes.
It’s been my experience that iterations in RTC are often not used like iterations as commonly defined by the vocabulary of a Software Development Lifecycle (SDLC). So what we call iterations in RTC may or may not enact true iterative development. This leads to some mischief when people customize their processes.
One reason why this is a problem is because RTC allows you to define an “iteration” any way you want, as long as it has start and end dates. But an iteration is more than just dates.
An RTC iteration can represent a Waterfall phase, a Scrum iteration, a chunk of time with some behavior associated with it, or just a start/end date pair. So we don’t want to think that we’re getting “iterative development” for free just by dropping an RTC iteration into a timeline.
An iteration in RTC is often used for its most obvious function: as a date range within a timeline that you can assign work items to. This is useful to be sure, and you can create “iteration types” in RTC that let you identify what you should be doing during that time period. By default, that’s only a description of the iteration (with some defaults for role permissions). But you CAN define true iteration behavior in RTC by adding operation behavior and customizing role permissions for the iteration.
Why worry about the difference between a chunk of time and a real iteration?
Sometimes a Project Manager tells me that they’ve built a hybrid process in RTC. That makes me worry worry. Then they say “I have a waterfall project with iterations.”
No, you don’t. That’s impossible. A Waterfall (or Formal) process delivers its value at the end of the process, by definition. An iteration delivers value at the end of the iteration. By definition. The Waterfall model is designed to do all requirements up front, for instance¹. Iterative development details a subset of requirements each iteration. The measurement of value is different. Iterations measure functionality delivered and Waterfall generally uses Earned Value. So Waterfall and true iterations are functionally incompatible.
There are some things you can do in one of those approaches that you can’t do in the other. Trying to mix-and-match iterations and Waterfall phases is like saying “I like steak and I like key lime pie. If I throw both of them in a blender I’ll get something delicious!”²
What the PM usually means is that they’ve defined Waterfall phases, and they’ve defined sub-sections of those phases (using RTC iterations). But they are not using true iterative development in the context of a Waterfall process because, as we saw above, the two are incompatible.
The mischief happens when a PM thinks they’re getting the benefits of iterations, but they’re only defining timeframes within their timeline. The PM may not really understand the practices he or she is using, so just calling something an iteration seems good enough. In fact, you need to enact and enforce iterative behavior to get the benefits of iterative development.
What does iteration behavior look like in RTC?
Take a look at a project created from the Formal Project template. Open the process definition in RTC and go to Process Configuration > Team Configuration > Iteration Types. Here are all the iteration types defined within the project. If you open an iteration type and select Permissions, you’ll see all the permissions for all roles for that iteration type.
For the Requirements phase in a Waterfall (formal) development cycle, the Developer is only allowed to create defects. Developers don’t define risks or business needs when we’re doing requirements, so we restrict their behavior to creating bugs.³
Similarly, we can define operation behavior for specific roles in each iteration. In the screenshot below, we’re saying that anything delivered during the Requirements phase must have a clean workspace and change sets with descriptions associated with them.
Note that iteration behavior overrides the operation behavior defined at the Team or Project level.
You might be wondering why I didn’t show Scrum iterations for my examples. If you look at the RTC Scrum template you’ll see that there are no iteration types defined. That means that the RTC Scrum template does not enforce iteration-specific behavior!
Actually, this behavior is enforced at Project and Team levels (under Operation Behavior). So all iterations in the Scrum template require identical behavior, all of which is defined at the Project/Team levels.
But it would be better, I think, to reflect that not all true iterations are created equal. Early iterations don’t need so much formality. For example, developers might be creating Epics, you might be experimenting with architectures that you will throw away, etc. Keep things loose and don’t make people do a lot of administrative stuff.
In later iterations you don’t want just anyone creating an Epic, so you might prevent developers from doing so. You want to make sure copyright notices are included in the code. And you want your developers to remove warnings and unused imports from the code as you approach final release. So add those mechanisms into the later iterations.
There’s no reason you can’t have iterations named Early Project, Mid Project and Final Release. They can be mostly the same, but allow for different levels of permission and formality.
You can’t expect to reap the benefit of iterations unless you discipline your team to deliver functionality in the way iterative development is defined. Calling a Waterfall phase an iteration doesn’t make it so, though you can use RTC to customize the phase so it focuses on what your Waterfall approach should focus on.
Similarly, you can define iteration-like functionality at the project and team levels of your Scrum project as RTC currently does. But the focus of iterations change over the course of a project. And not all projects are created equal. For example you may want different iteration types for a 3-member Scrum team versus a 7-member team.
Add iteration behavior to your RTC iterations to support whatever process model you need. But remember that just calling something an iteration doesn’t encourage your team do true iterative development unless you enact it in your process.
1. The observation from Winston Royce is that you find design flaws when you test, so you go back and re-design the product. Kind of a great big second iteration. He’s not the only SDLC guru that recommends throwing away the first attempt. I’d argue that most modern SDLCs actually endorses the practice “throw the first one away.” But that’s for another article.
2. Yuk. Some will argue that modern Waterfall methods incorporate some Agile techniques which allows you to introduce iterations into a Waterfall environment. And I believe that you can be both Agile and Waterfall, since Agile is a perspective and Waterfall is a discipline. But you still can’t jump to the left while you’re jumping to the right. You can’t do everything in your process just once (Waterfall) while at the same time repeating everything in your process (iterations).
3. When I first saw this I wondered why a Developer is allowed to do anything at all during the Requirements phase. To do Waterfall formally, you’d toss the requirements over the wall to the developers and they wouldn’t have any code to write or bugs to report until that time. Yeah, I know this is old school. But it’s still a valid (or at least required) approach for certain types of projects and industries.