Being open from start to finish changes the game in how we build software and what we learn along the way. We use openness to cultivate an iterative approach to developing software and addressing complex technology problems.

We’ve refined our agile strategy through years of experience building open source, highly performant web applications like data.worldbank.org, open.undp.org and the new healthcare.gov. As we’ve shared before, there are four key principles we follow to achieve efficiency and success in project management, communications, and development.

1. Use integrated teams

Integrated teams of subject-matter experts, designers, developers, and strategists are highly effective at producing results. Having multiple perspectives and experiences creates an environment where problems and challenges are collaborative and creatively solved. We often work right along side our partners in iterative development sprints, with frequent check-ins, so that we’re working as one larger team with a common goal.

Isolation breeds desperation, and that’s no way to run a project.

2. Work iteratively and get feedback constantly

Part of working as one team is regularly showing your work. We usually build in two week sprint cycles. This means we cut out enough work to keep us busy for two weeks and immediately start building.

We do daily check-ins that should last no more than 15 minutes. Each person answers three questions, and then we move on to the next — any follow-up discussion is handled after the meeting.

1. What did you work on yesterday?

2. What are you working on today?

3. Are you blocked by anything or anyone?

These questions keep a focused discussion that allows us to remove obstacles to progress and keep working fast.

At the end of the two week sprint, we package up our work and ship it to the partner we’re working with. We do a quick briefing meeting to show them what we did, and they immediately start using what we built. We then kick off our next two week sprint and incorporate feedback from their testing in our next round. This keeps us moving and focused on shipping real code that works and getting instant feedback. Trying to bite off a thousand rows in a requirements spreadsheet at a time does not work. You need to test and adapt your needs and goals as you build.

3. Stick to the basics

We are not wedded to a particular tool or technology. We are committed to a culture of showing results (shipping) and communicating openly, with each other and with our partners.

When we approach a problem, we try to distill it to its basic components. We don’t want to see PDF architecture diagrams of zones and servers. We want to know what you need the software to do. We will work backwards from there. As we saw on healthcare.gov, this drastically reduces complexity, and cost, and allows us to build light-weight and scalable systems. This is why the home page and informational content of healthcare.gov has never gone down.

4. Use open standards

Just as it is important not to overbuild systems, we want what we build to last long after we’ve finished the project. As soon as a major delivery is complete, we want our partner to be able to run with the software and start using the code on their own. To do this effectively, we adhere to open standards and open source. We try to do as little proprietary work as possible, and we document everything, even code that will never be released, as if it was an open source project. This makes it easy to train our partners to support and enhance the work we start for them. Making money off of vendor lock-in is not OK, and that’s not the kind of company we want to be.

Putting a focus on open standards and open source also helps us to leverage expertise and keep in touch with developers outside of our team. Some of the most useful code has been written outside our team, and in the same way we’ve contributed code back to other open source projects. This is how collaboration around code happens.

Open source culture

These principles come from years of working on open source projects. When working with a distributed, often volunteer team, you need an open culture and good structure to get things done. This is a proven methodology that’s practiced by the best development teams.

Even if you’re building a project that will be completely closed and private, you can still establish an open source culture. It will make you much more effective by focusing on concrete deliverables and realtime user feedback. It also keeps you flexible to the changing needs of a project. When you work in an open environment, there’s no need to wait for things to be set in stone to get working. Building trust with your partners gives you the space you need to positively direct the project, and you build trust by being responsive and shipping.