At the start of a project, everything is shiny and new, and both the team and stakeholders are often keen to plough ahead. However, at the start is often where the patterns are set for the rest of the project’s lifecycle, and a wrong decision here that is not designed for change can have a lasting or accumulative impact as things go on. Part of the problem is that at the start of a project the team simply don’t know as much as they will later, because as the project evolves new information will be uncovered about what works well and what doesn’t. Equally, with no accumulated technical debt or other baggage, most things will “seem to work”, only to be exposed later on.
Something that can work well to mitigate the risks early on in the project is to schedule in a “Sprint 0”, where the objective is simple: start the project in a sustainable way. The focus in this sprint is not on volume of work, but on quality. What I like to do is to take a typical feature from the real backlog, and implement it in a couple of different ways. The whole team are involved in this exercise, and everyone is encouraged to try out as many ideas as possible. Try different libraries/frameworks, different architectures, it’s all good at this stage. After an initial phase of brainstorming and trying as many ideas as possible, the team get together as a group and discussed the relative merits of each approach. It may then be possible to take the best bits from a few different ideas and try these as a combination. Failure at this stage is great, because it costs the team very little, and the information gained will save the team from hitting bigger problems later.
At every stage, the obsession in the team has to be on sustainability. Ask yourselves “what would it look like if we did this over and over”. You are trying to weed out the solutions that look like they work, but start to creak as they are scaled out, or suddenly hit a wall where further progress is no longer viable. This could be things like a framework that is missing some vital feature that you will need, but that is not extensible, or an architecture that creates bottlenecks. Whatever it is, you want to find it early, and have a plan to nip it in the bud.
Ideally, you want to try one example of everything, to try and force out problems. If you can’t do one of everything, then start with the riskiest and most daunting aspects of the project. Ask your product owners for examples of the weirdest things they will want, the things they are almost afraid to ask for, and try these out. If you can break these down early, the risk is significantly lower from this point on. The outcomes from these exercise should be a shared understanding throughout the team of the patterns that have emerged by natural selection from everyone’s inputs – which is so much better than having an ivory tower architect dictate down a “vision” that nobody else has been involved in and nobody believes will actually work or fit the problems at hand!
The other thing that is vital to get right early is the team’s workflows and pipelines. It’s pretty easy to write a build script for a “Hello world” application; it’s pretty easy to organically expand it as the first few features and services are fleshed out, refactoring as you go and setting conventions; however, if you allow a solution to grow in complexity and then try to implement a build pipeline later, you’ll find a bunch of disparate implementations and end up with both rework and a more complex pipeline. It’s also a nice way to gently introduce the pipeline to the team when it’s at its most simple, and show them that it was built from nothing and isn’t magic! There are few things more daunting to newcomers to continuous integration than a build server with millions of projects and configurations that seems completely impenetrable.
The hardest part of organizing a Sprint 0 for a project is stakeholder buy-in, where some can see it as an academic exercise or waste of time. This is one of these where as a professional part of your job is to help others understand the costs and benefits from an objective standpoint; in this case it’s all about risk management. It might be easier if you can include the product managers in the journey – invite them to sit with the team and see the kinds of things the team are trying out, and the potential problems that are being unearthed; you could also set a goal of having proof of concept deliverables that can be shown to the stakeholders, that showcases the results of the exercise. The ideal is for Sprint 0 to be open-ended, and finish once the team are confident – this encourages the boldest and most innovative approaches to emerge without an implied pressure, and setting no deadline actually often means the exercise finishes sooner. If you get this agreement from stakeholders, obviously you are then obliged to keep your part of the bargain – stay focused, be disciplined, and be honest at every point about whether the cost/benefit balance is still working. Your goal is of course always to deliver business value as quickly and effectively as possible, so as soon as the risks have been tackled with a trial story, it’s time to scale out and do it for real.