The word “process” can put up the hackles of good developers. Images are conjured up of endless forms and quality gates, of endless documentation and worst of all, endless meetings.

 And yet…we want to know where we are. We want to know where we’re going. We want to assess our risks and we want to ship on quality, on time. We want to know what went into our last code push and whether the latest set of feature enhancements caused any performance regressions.

 We think of process as simply the things we do that record the past, our intentions for the future, and allow us to ask meaningful questions about the present. We take a minimal and iterative approach to process – Create and use the smallest amount of process that allows us to answer meaningful questions.
- By “meaningful”, we mean those questions that tell us what our risks are for any action: Schedule risk, quality risk, customer risk.
- By “iterative”, we mean that processes are constantly being tuned to better answer questions.

Elements of Agile and SCRUM are key here – Code reviews, stand-ups, 2-week sprints, triage, rapid releases, unit and automation test suites, daily builds, and so on. We have a tuned system that runs two parallel sprints at the same time, and we’ve created templates and systems that give us realtime visibility into the health of our sprints. The team is committed to this process because the team helped design it, and we have people in place who take on the project-management aspects of the process in order to free the developers to code, design, review, and otherwise engage in engineering.

 We also bring to bear a number of somewhat new techniques that guide how we design software. More on this in the next post.