Abstract :
In 2008, our team at NASA Ames Research Center launched a five-year project to deliver a user-centric software platform for mission control. We began with a six-month delivery cycle. Within two years we were delivering functional software every three weeks. Our evolution from traditional, to lean, then agile, did not happen because of a focused goal to become lean or agile. Rather, we responded iteratively to problems, we were disconnected from our customer, the long delivery cycles created issues with testing and verification, and we were unable to effectively measure our progress. We changed our delivery cycle first to six weeks, then three, with the team focused on the highest-priority features and bug fixes. Our one measure of progress became working code. We delivered a nightly build to our customer. Our QA team tested features as they rolled out. In our journey from traditional to agile, we tailored our processes to our team culture and our context of work. We found that agile methods increased customer and team satisfaction, and enabled us to use limited team resources where they were most effective -- the design and development of the software.
