In mission-critical enterprise software, complexity is a given and quality is a requirement. In a previous era the need to deliver complex, high-quality systems led to processes that avoided ongoing change. For a major release, a development team would consider new requirements up front and then block out any discussion of changes to those requirements until the release proceeded through design, development, testing, and finally release—often 18 months or longer.
Just as there is a new attitude about what technologies to use in enterprise applications and how to best deliver them, there also is a new attitude about how to deal with ongoing change. The experience of waiting a year and a half to deliver customer requirements, and frequently finding that those requirements or even the best way to deliver those requirements changed in that time, has caused software developers to rethink how to deal with change. Most are familiar with the agile movement in software development that advocates for, among other things, embracing continuous change. The second principle in the agile manifesto is, “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”
At Workday we’ve fully embraced the agile mindset for the development of both our applications and the platform that supports them. I have marveled over the past three to four years as I watched projects that fundamentally changed our underlying platform get executed incrementally by releasing new solutions in a series of quick and continuous sprints across Workday updates, until the job was done and ready to be turned on for customers.