The transition from classical project management and development to Agile & Scrum can be quite drastic, turning the way work is done on it’s head (TDD) or even doing away with some things altogether (long isolated phases).

A lot of teams struggle through the transition – especially while working with legacy code that did not see the light of day on the green fields of Agile development but was created under the unyielding whip of crunch time.

Leaving all that – and the accumulated habits –  behind is difficult.

It’s therefore all the more compelling to map existing structures and workflows and plug them into the “new way of doing things” – and then call it “Agile”.

During every single Scrum training I received over the last years the trainers always issued a stern warning to be vigilant for signs that you are not really Agile but just pretending to be.

This creates (at least) two problems:
– You are not reaping the benefits of doing Agile & Scrum
– You are stuck with the issues of your old processes & habits

The first step to address both is to realize if you are deviating from the Agile path and then carefully plot your way back.

This blog post is based on my own experiences and understanding of the Agile & Scrum processes and intended to give you a few pointers and suggestions.
It’s not an attempt to declare what is “the right way to do it” – that is ultimately left for each team to decide on it’s own.

Without much further ado – let’s get started!

1. Stabilization / Hardening Sprints

Have you ever added Sprints at the end (or in regular intervals) where code changes are reduced to a minimum and all efforts are focused towards ironing out the bugs & integration issues?
If so you have probably created something like a Stabilization Sprint.

This kind of Sprint is more-or-less a direct equivalent of the Waterfall end phase where all QA testing and bug fixing is applied to the project. It’s where all the big integrations happen.
It’s also the time where things (latest) go south. Issues crop up like crazy, the integration fails and a storm front of crunch time is headed straight for you.

When following the concept of Scrum that only code that is covered by exhaustive, automated tests and accepted by the Product Owner is allowed into the release code how can that happen?

Well in theory it should never happen. And here’s where theory ends.

Stabilization Sprints and integration issues are a sign that automated, isolated quality control (TDD, Continuous Integration) is lacking.
This is an issue most often found with legacy code that wasn’t written to be properly tested. It could also hint at a team relying a lot on manual tests.

Either way you are highly vulnerable to unexpected stability issues and late-game deal-breakers.

To address this issue is to ensure high unit test coverage, deploying a fully automated CI system and doing a full test/integration cycle daily if not more often.
Some teams automatically integrate & test code every 15 minutes.

If you already have all that implemented find out what is causing the need to spend two or more weeks on hunkering down and squashing the bugs & quality issues.
Because you should be release-ready at the end of each sprint.

2. Sprint Zero

Have you ever added a Sprints with the number zero to your planning? Or even multiple ones (Sprint 0.1, Sprint 0.2)?

This kind of Sprint usually comes up when a project is something requiring a lot of upfront research and preparation. It includes clarifying the requirements, researching on technologies, setting up the development environment and so on.
Sprint 0 is an equivalent of the Plan/Design phases of Waterfall.

Now here’s where it gets controversial:
I think that spending time on research and preparation is time well-spent and it seems, depending on who you ask, the Scrum world is undecided if Sprint 0 is okay or not.
However let’s think about what Sprint 0 actually symbolizes: No customer value delivered. (That’s why it’s not Sprint 1).

And that – in my opinion – is not a good idea.

The goal of Agile & Scrum (and especially XP) is to get you writing code and generating value as fast as possible. Sprint 0 gives up on the focus on delivering customer value entirely.
It turns the entire time spent into sunk costs – essentially forcing the Product Owner to commit resources & time for Sprint 0 and at least another Sprint before value is created.

Instead of doing a Sprint 0 try a regular Sprint and use the time for prototypes and to implement the brutally simplest thing to do – even if it’s just a big fat hack.
Initiatives such as Hack Days yield mind-blowing results in just a single day. And they show what is possible and what is not by creating code that you can run and toy with.

And if you now think “Ah, but Hack Days are different” – what’s the difference? If you can be highly productive in a single day, what keeps you from doing the same in your regular project?
What can you change to enable it?

3. Sprint Length

How long are your sprints? 8 Weeks? 3 Months? Do your “Sprints” look more like a month-long death march?
Also did you ever extend the length of a Sprint because not all Stories could be closed at the regular end date?

If any of the above rings true you might be still working with the time scale & behaviors of regular project planning.

Scrum defines Sprint lengths to be exactly 30 calendar days.
Agile in general is more flexible depending on methodology used – going from seven days (XP) to six weeks (RUP).

With Agile teams can deliver smaller increments a lot faster than using regular project planning.

Both of the teams I guide as a Scrum Master are on two-week sprints. Both deliver solid customer value at the end of each sprint.
We had a lot of discussions on the right Sprint length and also tried out one week and three weeks but in the end two weeks were the ideal time frame.

Before that? Well … we were taking months between deliveries.

If your team is at the very limit of four/six weeks and still struggling – it’s not time you’re fighting, it’s most likely code quality (see 2.)

Lastly one personal remark on sprint extensions:
Do not extend the length of a sprint after it has been started. I did this once with one of my teams and it confused the hell out of people (“The sprint ends this week – right…?”).
We also de-synced from other teams leading to even more confusion down the road. While the underlying reason (a lot of people where away on holidays then) was sound the course of action was not.
It would have been better to look at the time frame ahead of the planning and check with the other stakeholders to see if there are any unexpected side-effects.

The Bottom Line

The transition from traditional project planning to fully embracing Agile & Scrum is long and can sometimes be difficult as it forces you to break with established processes & habits.
Not allowing this break to happen can cause you to be stuck with the worst of both worlds.

Three common signs that your team is still in the transition phase are Stabilization Sprints, Sprint 0 and Overlong Sprints.

If you consider yourself “doing Agile” and encounter any of these signs – it might be wise to check where you actually stand.

Do you deliver customer value quickly? Can you ensure that after every Sprint you have something stable? Something created to easily find the acceptance of the Product Owner and Stakeholders?
Concepts such as Test-Driven-Development, Continuous Integration and ultimately DevOps show a way to be ready. Every time. All the time.

So what’s holding you back?