There has been quite a lot of commentary on various social media channels about agile ceremonies and the traps that they often pose to enterprises. if not taken in the context of the value that they provide.
This is not a n agile problem. Agile principles are not agile ceremonies. Becoming or being agile is very different from doing agile.
Iteration Zero or sprint zero could be considered to be an agile ceremony fraught with the dangers we have seen with other activities that have been brought under the agile umbrella. Just like the other things in this umbrella, like stand-ups, retrospectives, and so on, Iteration Zero is a tool that can be used by a team to delivery value to customers more quickly and with better safety. It is not to applied blindly. There are likely cases and projects where it does not make sense but in today’s web based world it should be more of a decision not to use it.
Now that we have all the warnings out of the way lets explore the benefits of Iteration Zero.
What is Iteration Zero?
Iteration Zero is the first iteration of an agile project. Why Zero? The name comes from the common programming language practice of starting an index into an array or vector from zero instead of one - the cause of many off by one errors :) It is a non-functional iteration or sprint. Its goal is to set up everything we need to deliver working software into our production environment to be available to our customers. It is a basic test that we can operate software in that environment, know that it works and that our initial architectural assumptions hold true.
-
The most basic application can be built, tested and deployed
-
It is observable through logs and monitors
-
Any required analysis tools for security scanning, code defects and coverage are all operational and providing feedback.
Why should this work be done before our first development story?
Why spend time at the start of a project?
In the excitement to start development on a new project or product it is tempting to dive into building and exploring the features of that product. After all that’s the whole purpose of the work. So why spend time on infrastructure. Surely we can take care of that later when we know what the product is going to be doing and we know more about how it works?
The last mile problem
The last mile problem is that last step from build to deploy. After weeks or months of development and testing we finally have our nice new product ready to put in front of the customer (ignoring here that we should have been getting feedback from the customer all along). Everyone is excited and ready to launch!
It is at this point that reality hits. While we have been building and developing the application we have also been baking in assumptions and ignoring many of the concers that are key to running an application. Security, logging, tracing monitoring are all inconvenient requirements that all to often get ignored along the way …. until we hit the production deployment wall.
It is not uncommon for some fundamental requirement of deployment or operations to have been missed. Key architectural decisions become a challenge when the target environment just does not match what we have built into the application.
Sometimes addressing these concerns can take as long as the product development to resolve.
Even if we have built similar applications in the past and are using the same application stack setting up the path to production at the start of the project within the first iteration is a valuable proof and allows us to move forward with confidence.
How to make Iteration Zero work?
There are two outcomes
-
The path to prod is built triggered either 'on commit' for trunk based development or 'on merge' for feature branch development.
-
Monitoring and logging are in place and operational.
Both the path to prod and monitoring are maintained throughout the development.
We probably have an idea of what our architecture is likely to be. Let’s prove it. What are the distinguishing factors we are looking for in the stack and how do we test it to prove our hypothesis?
- Tech Stack
-
Have we used the tech stack before? If not then lets stand it up and run our tests to make sure that it behaves the way that we need it to behave - Tests and more tests
- Code management
-
Is the code for the new project to be managed as part of an existing monorepo or will it be a new repo? Will the infrastructure code be part of the smae repository or managed separately - GitOps style.
- Build
-
Setup or configure builds. If we are using something new in the tech stack then make sure that and tools used during the build work the way we expect with the new tech stack. More testing.
Builds are taceable from commit and in reverse from deployment to commit so we know what changed to casue a problem as the development proceeds.
- Test
-
Testing is built into the process and executed for every build
-
Unit testing
-
Functional testing
-
Benchmarking
-
Security scanning
-
Code coverage
-
Static analysis
-
Resilience testing
-
Even with a few lines of 'Hello world' code we can use that code to test our build and release pipelines.
- Deploy
-
is the deployment repeatable. Does it match our availability targets minimizing any customer disruption. Can we scale to meet changes in demand (up and down).
- Monitor
-
If something goes wrong how do we know? How do we know that it is fixed? How long does it take to recover. Longer term how to we maintain data integrity. How do we restore data in the event of data corruption?
Wrapping up
This may sound like a lot of work but remember this work will need to be done at some point in the project anyway. What we are doing is front loading the project with this work to reduce project risk, avoiding the last mile problem.
If you have ever been caught out by the last mile problem then you know how painful it can be. For your next project take the Iteratin Zero approach and see difference in launching your project.
If you are just starting out or have been lucky in avoiding the last mile problem then Iteration Zero may not make sense for you … yet. Remember iteration zero should be short and adds value throughout the project by increasing team confidence and ultimately reducing the project risk.