Your Method Already Has Retrospectives. It Calls Them Lessons Reports.

Does Waterfall Have Retrospectives?

Yes, under a different name. PRINCE2 names "learn from experience" as one of its seven principles¹. It keeps a Lessons Log, created during the Starting Up phase in an activity called Capture Previous Lessons, and a Lessons Report is typically included in every End Stage Report². If you run PRINCE2, you already hold a structured review at the end of a stage and write down what you learned. That is a retrospective.

You have probably been told the opposite. The idea that traditional teams "don't do retros" is one of the most repeated and least examined claims in the delivery-tooling market. It does not survive contact with the manuals. What traditional teams are missing is not the practice. It is the tooling.

Think about where a Lessons Report actually goes. Someone writes it at a stage boundary, usually under time pressure, usually after the interesting details have already faded. It gets attached to an End Stage Report, filed to a shared drive, and read by approximately nobody at the start of the next stage. The learning is captured and then stranded.

In fairness, agile teams are not obviously better at this. A retro board full of sticky notes gets photographed and abandoned just as often. Neither group has solved the problem of making last month's lesson change next month's behavior. The difference is that one of those groups has spent fifteen years building software for it, and the other has been told the software is not for them.

Whatever your method, PRINCE2, an internal stage-gate process, or something your organization assembled over two decades, the shape is the same. At the end of a phase you review what happened and you write it down. The open question is never whether you do it. It is whether anything happens to what you wrote.

What Do Agile Ceremonies Map To in Traditional Delivery?

Every agile ceremony has a traditional counterpart, and most of the counterparts came first. Retrospectives map to lessons reviews. Standups map to status reports. Demos map to stage gate reviews. Estimation maps to the numbers already sitting in your work breakdown structure. The vocabulary is different. The work is the same, and you are already doing it.

The left column is a vocabulary you did not choose and do not need. The middle column is work you already do, on a schedule someone else set, usually into a template. Simyl Flow automates the middle column. The left column is only what the buttons happen to say.

You can use the product for a year without ever saying the word "sprint" out loud.

Does Simyl Flow Require Two-Week Sprints?

No. A sprint in Simyl Flow is a named date range with a start and an end. No length is enforced anywhere in the product. A six-week phase, a quarterly release, or a milestone whose end date has already slipped twice all behave the same way, because every metric is computed from timestamps on your tickets and commits rather than from the length of the container.

This matters more than it sounds. If a tool assumes two weeks, that assumption leaks into everything downstream: the charts, the comparisons, the thresholds that decide what counts as slow. Tools built that way genuinely do not fit a phase-based organization, and the reasonable response is the one you already had.

Here the container is a label on a date range. Call it Phase 3. Call it Release 4.2. Call it Q3 Hardening. Cycle time is still the interval between a ticket starting and finishing. Bug rate is still a ratio. Neither becomes meaningless because your phase ran eleven weeks instead of two.

What Can You Measure Without Changing How Your Team Works?

Connect your issue tracker and your code repository, and six metrics appear without anyone attending a new meeting: Velocity, Cycle Time, PRs Merged, Commits, Bug Rate, and Unplanned Work. Every one is derived from records your team already creates in the course of doing the work. No estimation session, no standup, and no retrospective is required to produce any of them.

This is the honest entry point, and it is the one we would recommend even if you were enthusiastic about ceremonies. Nobody has to learn new vocabulary. Nobody has to be sold on a philosophy at a Monday meeting. The data is already in Jira and GitHub, sitting there, describing how your delivery actually behaves.

The ceremonies do exist in the product. You can turn them on whenever you want, or never. A team that connects two systems and opens nothing else still gets a cycle time trend, which is more than most traditional shops have today.

What tends to surprise people is where the waiting shows up. Not in development. In the handoffs between phases, in the gap between "code complete" and "test environment available", in the week a change order spent waiting for a signature.

What Does Velocity Not Tell You?

Velocity tells you how much work closed in a period. It cannot tell you whether that work stayed closed, how long any of it waited before someone picked it up, or what it cost to get out the door. A phase can hit its velocity target exactly and still ship defects that eat the following phase. The number looks the same either way.

This is not an argument against velocity. It is a genuinely useful number, and tracking it puts you ahead of the many organizations that track nothing at all. The problem is not that velocity is wrong. It is that velocity is usually alone.

Picture two phases with identical velocity. In the first, work moved steadily, review took a day, and almost nothing came back. In the second, everything sat in review for nine days, shipped in a burst in the final week, and a third of it returned as defects inside a month. Velocity records those two phases as equivalent. Cycle Time, Bug Rate, and Unplanned Work do not.

Unplanned Work is usually the one that lands hardest in a phase-based shop. It is the number that finally explains why the plan slipped when nobody on the team did anything wrong. You planned for the work you knew about. Something else arrived. Most planning processes have no way to show that, so the slippage gets attributed to estimates, or to people, and the same thing happens next phase.

You can see how the six dimensions fit together on the effectiveness overview.

We're Not Running a Long Con

There is no phase two where we ask you to adopt Scrum.

The measurement works because your phases have dates and your tickets have timestamps. It does not work because of the framework printed on the wall. If you connect your systems, never run a retrospective in this product, and never estimate a single item in it, it still tells you whether delivery is getting faster or slower and where the waiting happens.

We would rather be useful to you as you already work than wait for you to become someone else first.

Not a conversion funnel. A measurement tool.

Frequently Asked Questions

Do we have to adopt agile to use Simyl Flow?

No. The product reads dates from your issue tracker and timestamps from your repository. Neither depends on a framework. Teams running phases, stage gates, or a bespoke internal process get the same metrics as teams running two-week iterations, because the underlying records are the same in both cases.

Does Simyl Flow require two-week sprints?

No. A sprint is a named date range with a start and an end, and no duration is enforced. A phase, a milestone, a release, or a quarter all work. Metrics are computed from timestamps on tickets and commits, so the length of the container does not change how they are calculated.

We run PRINCE2. Where does it fit?

Your End Stage Report is the natural place. PRINCE2 already puts a lessons review at that boundary, so the retrospective features have somewhere obvious to live if you ever want them. You do not need to use them. Connect your tools and the delivery metrics work regardless of which process wraps them.

We don't run retrospectives. Is it still useful?

Yes. Cycle Time, Bug Rate, Unplanned Work, PRs Merged, and Commits are all derived from your existing tickets and code history. They require no meeting and no facilitation. Retrospectives add a place to act on what the numbers show, but the numbers arrive whether or not you hold one.

What's the minimum setup?

One issue tracker or one code repository. Connect it, pick a date range that matches how you already plan, and the metrics populate from history. Nothing changes about how your team works that week, which is the point.

Sources