What defines a Scrum sprint? Is it the fixed duration? The pauseless succession? The amount of work you can put into one increment?

In principle, the benefit of sprints lies in focused synchronous communication to deal with ambiguity. Dealing with means variable sprint lengths and cooldown phases.

This should be applied and interpreted according to the situation, not stiffly.

This is what living agility looks like to me, but your team does not live this principle. Instead, you and your team hope to have a non-decreasing quality by applying the same parameters repeatedly.

You’ve already understood that software development is a marathon. So do you run a marathon by concatenating sprints? While in the traditional sprint, the duration is fixed and the scope varies, I see more effectiveness in a reversal of the ratios.

Compare a Sprint to a Sprint

Usain Bolt is the world’s fastest sprinter, which means he ran extremely fast at 100 meters.

I can’t imagine that you trust him to be good at running long distances at the same speed. Besides that, you can’t expect him to run best times in sprint after sprint throughout the entire day.

But isn’t that exactly what is expected of you?

This seems unintentional and impossible. But in Software Development, one sprint follows another. Immediately.

Even though this breathlessness has great appeal for managers, I guess the word sprint is simply too tempting.

Or could you resist the image of an unending succession of victories? With this kind of mentality, it is a wonder why the executives haven’t this song from Paul Young as an anthem for their running (away) developers.

Please hurry, why don’t you come back
Please hurry
Come back and stay for good this time
Come back and stay for good this time
You said goodbye

— Paul Young

The Core Principle Every Sprint Should Comprise

But what is it that makes up the sprint?

What is the principle behind it?

Software development is more of a marathon than a sprint.

And you don’t run a marathon with a concatenation of sprints. Nobody does this.

As long as you think of the name sprint, you think about a rule. A rule is mechanical — dead.

It would be best if you started thinking about principles. A principle, on the other hand — is alive. It leaves room to breathe, room for interpretation, and balancing.

And these are the things a human being needs.

In fact, it seems to me to be one of the reasons why Scrum has gained acceptance as a process model in software development. Also experiencing increasing interest beyond this.

It doesn’t matter whether Scrum is really one hundred percent successful or not. I think this approach is unhealthy.

Being constantly “at war” means having no time to rest, ultimately leading to tunnel vision, burnout, or decreased software quality.

I worked in an agile team, where we had an IP-Sprint (Inspect and Adapt) every 5th sprint. This meant for us to slow down the development and inspect what we’ve accomplished so far. Moreover, what we could have done better.

Nonetheless, every sprint, including the IP-Sprint, had the same length of two weeks…

Acknowledge the Unknown

The first things that come to my mind about sprinting are the constant length and the constant speed. Besides the cadence, the rhythm, the lockstep is supposed to be important. For me, however, this feature seems the least important.

It is an externality and smacks of the artificial to me.

When Scrum was invented (1993), such lockstep and the accompanying predictability may have been necessary, even advantageous, in a certain context.

But whenever in history worked a derived and universally valid rule? Never.

We are all human beings, and we don’t fit under one hat, besides having unique requirements and goals for each sprint.

Whose idea was to stuff everything into a fixed sprint length?

It is not the duration that makes the sprint, I think, but the content.

And what is the content?

What is it all about?

I’ll describe it this way: focus on the unknown.

In software development, a lot of things are notoriously unclear.

Does any customer really know what he wants? Does the development team really know how to implement requirements that mean functionally plus sustainably the best?

In the end, it is also unclear whether the implementation will meet with the customer’s approval.

Acknowledging this ambiguity is perhaps the central achievement of agile.

So how do you avoid getting overwhelmed? By focussing on the right spots. For this particular case, acknowledge ambiguity and focus on it.

Clarify the Unknown

Once clarity is established on order, the contractor can finish working on its fulfillment without further communication.

This is the desirable state; with clarity, the result is produced most quickly.

Communication for clarification is wasteful in comparison. Communication is, therefore, to be avoided. It may be necessary, but it is only a means and not an end.

The great ambiguity in software development now requires that communication aims to overcome it as quickly as possible.

For this reason, agile software teams are cross-functional; the customer is at least as much a part of them as the developers. The communication path is thus drastically shortened, which serves to clarify issues quickly.

Sprints are, therefore, also times of increased synchronous communication — which can be a hindrance if not contained. Interruptions and meetings can quickly get out of hand.

So what essentially comes together in sprints?

It’s all about focused synchronous communication.

The focus stakes into the outcome.

Synchronous communication addresses the surrounding ambiguity.

The Big Bill — Conclusion

The time limit does not belong in the definition of the sprint but arises naturally from the focus.

Focus is a function of ambiguity. Where there is a lot of ambiguity, there should be less focus. It also follows that timing is a function of ambiguity.

I deduce from this; a fixed sprint length is counterproductive.

I advocate variability in sprint length. Sometimes it makes sense to focus only one week; sometimes, three weeks are more appropriate to the topic.

This should be decided from sprint to sprint or topic to topic.

I see more effectiveness in a reversal of the ratios of fixed duration, and the scope varies.

The scope leads, the duration follows — within a certain framework, so there is an incentive for true incremental development.

In addition to sprints, there could be other basic scales for focus periods, such as Leap for one to four days or Step for one to four hours. This could further structure a sprint.

Sprint, Leap, Step: A hierarchy of result horizons emerges.

From the existence of focus periods, it follows that there should be something in between.

Defocus periods without pressure to achieve results and synchronous communication are important. It is like being “at war”; reorder to draw strength again and to regroup.

Performance without a break cannot be good in the long run. You and I are all humans.

Taking a coding course feels impersonal, and being left alone with a task to code? Well, I take you by the hand and serve you knowledge weaved in emotions, fun, and a remarkable and unique teaching style. With my ArnoldCode Academy, you are never alone. Reach out 24/7!