The topic of shifting to an agile software development methodology has come up in a few of my conversations with field service leaders recently. I’m no software developer, so I first had to learn exactly what an agile approach was and how it differed from some more traditional development methodologies, such as waterfall. Using a traditional approach, such as waterfall, the project is put into sequential, predefined phases and worked to completion before being fully deployed to the user base. The agile methodology is built on the concept of giving a self-directed team broad goals and then allowing them to work to meet those goals. Agile uses incremental planning whereby detail is added and revisions are made throughout, versus identifying all of the detail of the project from the outset.
What is the value in trading a traditional software development methodology for agile? Johnny Johnston of National Grid, whose story begins on page eight of this issue, says, “Traditionally, we would deliver programs using a waterfall delivery approach. With waterfall, there tends to be quite a long time between gathering the requirements and implementing. So you’re asking users, ‘What functionality would you like in three years’ time?’ They tend to ask for every bit of functionality imaginable because, if they don’t get it now, they’re never going to get it. The result is really complicated solutions that take a little bit longer to develop and are less likely to fully function and work when they go live. Agile enabled us to break huge, complicated programming into some much smaller chunks and stacks, so we can work with the business on developing the simplest solution acceptable and then get the feedback from the users using the tool to build the new features and enhancements based on that experience. Being able to start from scratch and implement something in less than six months is unheard of in our business, and the learning that we’re going to get from that first go live will help improve the solution from there. Using agile, there is much closer partnership between operations and IS. The IS team has a much better understanding of the business, and with that understanding come better outcomes.”
Is The World Outpacing Traditional Software Development?
Jamie Smith, CIO of ServiceMaster, whose story was featured in our last issue, says, “The ServiceMaster journey to agile began out of the necessity to move faster and deliver more. While I think everyone tends to focus on the messy, iterative nature of agile, what we found most transformative was simply making all work visible across the organization. This ensures that everyone is rowing in the same direction. Also, the move to smaller, self-contained and self-organizing teams has fostered a culture of focusing on business outcomes instead of technical deliverables. The previous attempts were large, multiyear, big bang implementations. The world just moves too fast to wait two years for a new system. We knew we had to start small and deliver incrementally to get value into our customers’ hands faster. We also moved to a culture of experimentation to let data tell us what worked and what didn’t instead of clinging to whatever requirements somebody thought was a good idea at the time. This created a culture focused on solving customers’ problems versus simply delivering a new IT system.”