Embrace the Agile Mindset to Deal with Continuous Change

I recently visited a customer to discuss the next phase of their rollout. Having implemented Workday HCM, their project team is now focused on Workday Recruiting. The project leader mentioned that this time around the team is taking an agile approach to the deployment. We didn’t discuss what this meant in great detail, but he did highlight the deployment work would be organized in a series of “sprints” of one-month duration.

The conversation caused me to reflect on a key area of opportunity for all of us embarked on this next wave of enterprise solutions. As we rethink the technologies and delivery methods we want to use, there is also an opportunity to rethink how we deal with ongoing change more broadly.

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.

One of these projects involved changing the way every update transaction in Workday persists changes to the database. The old school way of doing this type of project would have been to fork off a “next generation” version of the platform, work on it for a year and a half, test it for six months to a year, and then figure out a way to upgrade the existing version to the next-gen version.

We found an agile way to deliver the new capability in a much less disruptive way. The large project was broken up into incremental deliverables. Each incremental change was “checked in” to the same codeline all our customers run in production, even as other developers were checking in new application features for Workday’s regular updates. When the new persistence approach had been developed and tested, features were incrementally turned on for all of our customers without any disruption to their use of the Workday service.

We’ve learned the importance of embracing change as we design and build our solutions, but like so many areas of this new world of cloud computing and next-generation software, there is still more we can learn. If a complex, multi-year software project that changes the processing core more than 1,000 customers are using for their mission-critical applications can be built and delivered in an agile fashion, why can’t the same approach be used to revolutionize other aspects of the enterprise solution lifecycle? Why can’t this approach be applied to how we implement or even sell our solutions, too?

I applaud the customer I previously mentioned for embracing agile techniques for their Workday Recruiting deployment. Imagine how quicker phases of a deployment—and a willingness to “welcome changing requirements” late in a given phase—will improve their end users’ ability to see where the project is headed and give feedback based on what they see. Imagine how much more likely it is that the end result of their deployment will meet their users’ needs.

My advice for executives trying to figure out how to react to ongoing change in their businesses is to embrace the agile mindset—and not just for software development projects. Understand that project requirements can and probably will change and that if you ignore important requirement changes for the duration of a monolithic project you often do so at your peril.

Instead, follow the model of agile software development wherever you can. Break any deliverable up into a series of quick “sprints” to deliver reviewable results in weeks instead of months or years. And, be open to changing project requirements which arise based on reviews of these interim results.

Embracing the agile mindset is not easy. It requires rigorous (and continuous) communication and testing to maintain quality. But, the results are more than worth it. Your project success rates will improve and so will your time to value.