Sprint Zero, a Failure Spiral and a Bad Idea!

If you’ve ever had the opportunity to join a team at the start of the Project or Product, you may have been a witness how many organizations make a wrong step from the very the start, eventually leading to severe complications of execution and maybe even a complete failure.

The main cause of this can be very surprising – as starting a project or product from scratch seems like the simplest rudimentary step. However, this is where most failures start. Especially, in medium and large size companies.

Enterprise Planning Beginnings

Those of us who worked in traditional corporate environment, probably remember a large meeting room with everyone involved in a new project coming together to discuss the kickoff. From big bosses to junior developers, this project is a big deal. The budget has been allocated, plans have been agreed upon, teams transferred or formed, people briefed and the message loud and clear “comes Monday, we all start executing at full speed”.

And so we do, kicking off a Sprint Zero with modest goals. Setting up environments and doing something basic in preparation of the main development. All Teams seem to be moving forward throughout the Sprint, until the very first Sprint Zero comes to close. Results – unimpressive. Goals not reached, many things still left to get to a real “done done”, and teams locked in a stalemate of external dependencies.

While many brush this off as expected using a comment of “Its a Sprint Zero, it does not have any definite goals or estimates, we’re just getting started. So, its ok if we miss a few, we will catch up the following Sprint.” And there it goes, the culture of catch up, the endless loop of things not fully done, and a constant sliding scale of slipping schedule.

Optimistically, everyone still believes that this is just a fluke and the Teams will course correct in due time. Except, as a runner who trips at high speed jumping over hurdles, a single trip is often all it takes to fail.

Sprint Zero in Enterprises

The concept of Sprint Zero is what’s to blame. This Sprint allows the teams to skip the discipline of delivery, to lax on goals, and skip work decomposition claiming the unknown. It eliminates Team Member peer pressure for individual delivery and accountability, accepting mediocrity. The message it delivers is too weak – “do what you can”.

This mindset was never the intention of the Sprint Zero as it was defined much differently in the original Scrum Guide, and yet today that is how many perceive it. And perception is reality.

The other problem with Sprint Zero is a wrong approach to execution. No product or project can launch having too many people! There simply aren’t many things to do for everyone. There isn’t enough work for everyone to work in parallel. At this phase of the project, too many things are single threaded with the entire team waiting to engage. And small delays and blockers cause irreparable harm.

Imagine you and a group of friends are hiking in the mountains and approach a rope ladder. There simply isn’t a way for everyone to go across at once. You need to organize, line up, and follow. You need to verify the ladder is solid and that it can hold the weight.

Turns out that most enterprise projects fail immediately at the start. The corporate mentality of budget allocation, timelines, plans, the emphasis on optimal productivity are all missing the fact that scaling too soon is leading to implosion.

Sprint Zero in Startups

Interesting enough, startups do not encounter these challenges. Strapped for funding, they simply don’t have large enough teams and they start small. New projects begin with just a few people. And often, they do not use Scrum. There are no Sprint Zeros, there aren’t any big commitments or huge plans. The aims are small, one step at a time – moving iteratively until desired functionality reaches the point of acceptance.

Startups also do not have bureaucracy either. Need a tool? They buy the tool. Need a database? Created quickly and with ease. Startup teams do not serve many masters – the infrastructure and architecture teams, devops departments and security officers. This allows them to be in full control.

Startups kick off new initiatives exceptionally well. The teams are small enough where everyone can do their part and healthy amount of pressure and personal commitment that does wonders. Where startups struggle – is with scale. Mostly due to limited budgets, the sudden need to do more with limited resources due to the market needs and customer requests.

Improving the Way Projects and Products Launch

Corporate teams can learn a thing or two from Startups – launching new initiatives is better done in a small intimate group. A group that can set up the foundation that can be scaled to expand one team into multiple teams, allowing the project and product development to accelerate. In this initial phase, the team is too small to optimize or scale and the team may even find that its easier to organize itself with a lighter weight Agile methodology than Scrum.

What is important to remember is that scaling the team takes time. Bringing in proper team members, or hiring outside, integrating them into the project and training them to be effective – all that takes time, and a conservative approach to growth typically yields better value in the long term. Growing too quick is prone to self implosion by generating lots of waste within the team.

Startups on the other hand, can learn from enterprises much more detailed plans. Thorough plans are not necessary, but what is necessary is to give the team time to stay the course a bit longer – allowing them to get fully done, as startups rapid context switching drains the mental and physical capacity of team members to consistently deliver – leading to rapid burnout and slower, poorer quality results.

So if your team is launching a new initiative, scrape the plans for a large kick off and Sprint Zero. Just put together a small team and guide them towards early, modest goals.