Something we believe make us stand out at earthware are the processes we follow to make sure our projects are built on a firm foundation. When it comes to development we think that taking the time to ensure quality and robustness are built into our projects from the start is an investment that pays us back many times over.

The road to delivery

At earthware, most of our projects go through several distinct phases:

1. We spend time with the client working out what they need and starting to define the shape of the solution. During this time we might work on user stories, user experience, and some aesthetic design. We won't necessarily finish all of these things, but we will do enough work to ensure we understand what we're going to deliver and get an idea of how long it will take.
2. We enter into an iterative development cycle where we are both building the technical solution and probably also continuing the work we started in step one.
3. We reach a point where we have sufficient functionality to go live with version 1 of our solution.
4. We enter into a support phase, potentially also continuing to develop new functionality.

As the above implies, there is a bit of a grey area between the first and second steps and that's the subject of this post.

When do we start?

When is the right time to start development? It varies between projects, but ultimately you need to reach a point where you have a coherent picture of what you're building, and enough detail that you could keep your dev team busy for at least a couple of weeks. You also need to know that by the end of that two weeks, you'll know enough about what they need to keep them going for the next two weeks. Rinse and repeat.

It won't necessarily be a full time role, but we'll always involve a Technical Lead at this stage (other organisations might call this role "technical architect", "solution architect", "design authority" or similar. We think "technical lead" more accurately sums up what they do). This means we have someone around who can give a good view on when there's enough clarity to move onto the next stage.

It's day 1 - what do we do now?

We generally adopt Scrum for project delivery. A pretty standard concept in Scrum is "Sprint Zero" but as with many Scrum/agile terms, it's one that's been thoroughly abused by people who can't let go of Waterfall as a way of doing big design up front. Don't do this. Or if you do, don't call it agile.

So that said, what kind of things should you be doing during your Sprint Zero?

Make sure your product backlog is in good shape

Before we start development we need a product backlog to work from. This can be written in the form of user stories, or it can just be a list of tasks - whatever is best for the project. You should always work on this with your Product Owner, as they are the owner of the backlog. Once you've got all the stories listed out, sort them into priority order. Get it estimated by the whole team, including the non-techies - the easiest way to do this is using relative sizes.

Once you have a prioritised and estimated backlog, spend some time ensuring that the items at the top of the list are small enough and complete enough that they can be worked on by developers and completed in 2-3 days - anything bigger than that should be broken down further.

Capture the other requirements too

User stories are a great way of capturing what the solution needs to do if it's going to work for users. However you also need to ensure you've captured non-functional requirements (NFRs). These can be written as user stories if you like, but I find they don't always fit well on the backlog - they can't be pulled into a sprint and worked on, as they will cut across the whole solution. As such you may need to document them elsewhere (we use Confluence to host project wikis).

You need to start understanding the NFRs early because they tend to impose design constraints on the system. As a simple example, if your system needs to be highly available you'll need to consider how you can build a system that can be maintained without incurring downtime. And there are substantially different design concerns for a system that will have 10 concurrent users and a system that will have 10,000. You may be operating in a sector (like travel or e-commerce) that experiences large seasonal variations in usage. All of these things will affect the architectural choices you make.

Look to the finish line

Try not to enter into development without having an idea about what your first live release looks like. Many Product Owners, especially less experienced ones, will want their first release to contain all the things. A much better approach is to look at the features that you'd need in a minimum viable product. Since your backlog is organised by priority this could be as simple as drawing a line at the point where you think you'll have enough features to go live. If it's harder to convince your Product Owner you could spend some time evaluating backlog items using the MoSCoW method or similar.

Make enough big technical decisions that you can get started

Chances are you already know what tools and technologies you'll be using to build and deploy your solution. Don't waste time trying to technically design everything to the nth degree, just make sure that on the first day of the first sprint you have made enough decisions that people can start writing code.

Face your fears

By this point you'll have a pretty good idea what the scary bits of your project are. Now is the time to think about what you can do to de-risk them.

Need to work with a third party library you've never heard of and where the only documentation was translated from Russian to English by someone who speaks neither language? Now is the time to get one of the team to spend a day or two getting stuck into it and finding out how it works.

Do the requirements mean you need to implement an approach you've never tried before? Spend some time on a spike to prove out your ideas.

Most projects have some areas you can identify as high-risk - if something goes wrong they will significantly impact the project. Spending time up-front to better understand them can significantly reduce the risk and give you a much better idea of what you need to get it done.

Once you've done this you might revisit estimates or, in conjunction with the Product Owner, decide to reprioritise the backlog.

Agree the ground rules

If your team has been together a while, chances are you already know how to work together. If not, it can be a good idea to agree things with the team. A good place to start is with Definition(s) of Done - formalise what it should mean when someone says something is "Done". Here's an example:

Development is Done on a ticket when....

• If necessary, any complex business rules finalised during development should be documented in Confluence.
• Code has been written
• Unit tests written and passing
• Basic browser testing carried out:
  • Check in the main browsers.
  • Use Chrome device emulation to check it works responsively where necessary.
  • User IE emulation to check previous versions of Internet Explorer
• Any necessary build/deployment changes made.
• Peer reviewed via a pull request (or produced using pair programming)
• Merged back to develop branch
• Successfully deployed and sense checked on dev test environment.
• Ticket updated with any details that would help the tester.
• Ticket moved to "Testing"

In addition we will normally have a Definition of Done that defines what it means for a ticket to be tested and ready for release to UAT, and a Definition of Ready that defines what a ticket needs to be considered as ready to include in a sprint.

Getting everyone in agreement on this avoids a lot of nasty conversations down the road that are caused when people mean different things by the word Done.

Automate all the things

Before the team gets busy adding proper functionality to the project, we like to have a minimum set of technical pieces set up and working. We're largely a .NET house, so it looks a bit like this:

1. Solution set up in Visual Studio with the main project (i.e. a web project if we're building a website, WPF app for a desktop site, etc.)
2. Git repository created on BitBucket.
3. C# test project with at least one passing test in place.
4. Any scripts we need in place to pre-process/transpile/combine our front end assets, e.g SCSS files or JS framework.
5. For Javascript heavy projects, at least one client side test.
6. Scripts that can run both back and front end builds and run both C# and Javascript unit tests.
7. A continuous integration build that runs the scripts from step 5.
8. A development test environment (usually on Windows Azure) that we can deploy our code to.
9. A deployment script that does everything from step 6 and deploys the code to our dev test environment.

Not every project needs all of those things. For example, our own website is essentially is a brochure site where the vast majority of the code is HTML and SASS, meaning there is little use for unit testing. However we still script our builds and deployments so that we can have confidence in our ability to safely deploy whenever we need to. There's nothing like deploying a new release to a site that has several thousand active users at the point you deploy to make you appreciate a good automated deployment script.

Marking time

Scrum has a standard set of meetings that take place every sprint - daily stand ups, sprint planning sessions, retrospectives and demos. Before you hit Sprint 1, make sure these meetings are scheduled in.

For stakeholders unfamiliar with Scrum, it might seem like you are deluging them with meeting requests. You'll likely also be asked to move meetings around to fit in with their calendars. Although it's tempting to make sure as many people as possible can attend, I would strongly recommend against varying the lengths of sprints to accommodate them for a couple of reasons.

• Variable length sprints make it almost impossible to judge velocity, without which you'll find it difficult to plan out future sprints and understand when you're going to be ready to release.
• Holding meetings at different times each sprint makes it hard for the team to settle into a rhythm. This sounds like a small thing for those who haven't experienced it, but it's actually a really big deal.

And.... Go!

The goal of Sprint Zero is to make sure you have a solid foundation for your project so that you can start delivering functionality to your client from the very first sprint. Without that foundation, you start the project already having incurred debt that you will need to pay down at some point in the future. However, it's also important not to try and do too much work - remember that agile encourages decisions to be left until the last responsible moment, so you don't need to make every call before the first user story is worked on.

And if you need any help then why not get in touch and see how we can work together to improve your projects?