Release First, Develop Second

A new team, a high-profile project, and a commitment to doing the best. They build software that delights people in their demos and sprint reviews. Every project status is green. Until the end. They are months away from getting their code into production. They don’t have time.

When the project idea was first brought up, management created the best development team they could. They got the strongest scrum master and the most capable product owner. They put a project manager near the team to help them with any other incidentals and to track the overall project.

The team started their sprints, a little heavy on design and prototyping at first. They needed to make sure their fundamental approach would work. They engaged other departments to ensure their ideas and designs were satisfactory to the architects and security folk.

Soon the began developing features. The first demo they showed people already had managers and stakeholders excited. In just a few months they had working software. It looked good, it worked well! The budget was looking good, and the timelines were all in check.

After a few months, the team is coming up into the end of where everyone thought the project would run. They’ve course corrected, they’ve incorporated feedback, and their code works relatively bug-free.

There’s one problem: They never shipped their code to production.

All of their work happened in combinations of development and test environments. In the very beginning, it happened off their local workstations.

By the time the project was winding down, it became obvious that the path to production was far longer than they had time. What was to become of all that software? What was going to happen to the story management was telling everyone that this team had built great stuff on time and on budget?

They have meetings, they extend timelines, they secure more budget. Do they get it into production this time, or do they add a few more features first?

If this story sounds something like one you’ve seen or been a part of there’s a better way. Put your code into production first.

When the project just starts and the team has nothing more than, “Hello World,” put it into production. All those design meetings and prototypes they did to ensure their technology would work was wishful thinking. They never saw it work in production. Push it into production first.

Solve the problems of getting the code out into production when there is no configuration, no data management, no libraries, no external pieces. Put it into production when it is the easiest.

From then on, there will be a path to push code out as often as the team can, every time they go down that path they’ll make it smoother and smoother.

The alternative for the team I wrote about would have meant maybe they shipped fewer features. They may not have been on time. They may have run over budget, but there is something they would have done.

They would have delivered value.

Next time you start a project, put your code into production as soon as possible. Do it when it is the simplest to do. Keep shipping. Don’t wait until the end to find out all the hard work won’t go anywhere.