A colleague of mine recently asked me and a few other Excella developers our opinions about creating user stories. The developers my colleague was working with had said that the stories did not specify the underlying infrastructure of the software, so the developers had no direction by which to develop on. Now it had become a civil war within the team:
Business analysts had said that user stories just describe functionality, and how the story is developed is up to the developer.
Developers had argued that without specifying the underlying infrastructure, how could they develop user stories?
This is a classic question that comes up in many Agile software development projects, often when a team is faced with creating a solution from scratch. Teams are then tasked to make huge decisions that can have long-term consequences.
Now what was our answer? Unfortunately even among my peers, we couldn’t come to a consensus, so here’s my take on the situation. What I’ll aim to do is give my best argument AGAINST doing a Sprint Zero, and why you should do development from Sprint 1.
Why a sprint zero?
Here are some of the arguments in favor of a Sprint Zero:
- Having an existing framework will speed up future development and allow developers to deliver at sprint intervals.
- It will let developers know how development will be done (i.e. which technology stack will be used).
- We need Infrastructure to do best practices: Continuous Integration, Version Control and a Testing framework.
Although I think that these are all valid points that are true. They can all lead to poor development practices and are generally not suggested. Here is why:
Develop as if there’s no tomorrow
Another concept of Agile software development is that you should “develop as if the project ends tomorrow.” Not necessarily tomorrow, but when you plan for sprints you should be thinking as if this sprint as your last.
This will accomplish two things: It keeps in mind that you will be focusing on the most important things. “If the project was to end tomorrow what would we rather have: The ability to store inventory? Or some base classes, a web API, and a login page?” This is a great way to compare and prioritize what needs to get done, but also ensures that the work that is taken on is critical to the system.
You might argue that it’s naive to think this way, and that creating an overarching scaffold for the project could make it faster! This could also be true, however it violates one of the principles that we try to adhere to in Scrum: Always deliver potentially usable value.
Keeping it Lean
One of the biggest arguments against creating technical tasks is the concept of “minimizing waste.” Waste in a development sense is code that is developed but is not necessary for success.
In order to have “lean code,” teams should always be developing against a User Story. When development is driven by necessity, developers can now scope their development with the guideline “do we need this in order to accomplish what the user needs?”
If developers are given technical stories for a sprint where there is no end-user functionality that they accomplish, there is a risk that some parts of the code may never be used!
How am I supposed to develop with no Framework?
Well you aren’t expected to develop without a framework. Every software solution requires a technology stack underneath it, certain patterns that will be followed, and an infrastructure.
This can be done within Sprint 1 as a part of the story development that is taken on. With this in mind, we can ensure that the infrastructure is fine-tuned to the problem that is at hand. Infrastructure in software isn’t like a construction project, we need to think of it as something that can be changed throughout time to fit the business need, not as a rigid structure that is immovable and must be developed around.
This can cause some serious problems when down the line, you realize that you’re using Backbone.js when later on you realize “hey, this would have been a lot easier to develop using Angular.” If a lot of time wasn’t spent developing a large underlying infrastructure for Backbone, it wouldn’t be as difficult to transition to an entirely new front-end framework (a scenario developers are all too familiar with).
CI Pipelines and hosting environments
I feel like this is probably one of the better arguments for having a “Sprint Zero.” Having a continuous integration pipeline with development environments is essential to good development practices. Having to set these up while delivering a working product would be quite the daunting task.
However, this brings up some very serious questions and considerations. Do we really need a developer environment? How many testing environments do we really need? What testing framework would work best for our situation?
This line of reasoning can really save you a lot of headaches in the future, where you’re left with dozens of environments that you have to manage, and only a few of them that are actually being used. Is this beginning to sound familiar?
Final thoughts
I definitely see the benefit of having a technical Sprint Zero and there certainly are advantages to this approach. It will certainly make it easier to deliver things in the short term. You can focus more on creating software, instead of the technical nuances of software development.
What you gain in short term productivity, you lose in creative freedom, agility, and you will have an entire sprint whose output is completely unusable.
One of the key takeaways, is that necessity should drive development and work. Whether it be prioritizing your backlog or choosing between Dojo or React, you should always be aware of what problem you are trying to solve.
If you’re to truly embrace Agile philosophy, you also have to also embrace the discomfort of approaching problems from an empty canvas. It’s okay to not have all your ducks in an order. Your focus should be on solving the business problem, and not the technical solution.