Agile development
June 2, 2016 Mainframe Agility

The Difference Between Agile and Waterfall: Movement and Inertia

According to Newton’s first law of motion, an object at rest stays at rest and an object in motion stays consistent in speed and direction—there is no change unless an unbalanced force makes change happen.

Like the objects in Newton’s law, software development under a Waterfall framework is unchanging—it remains at a slow and steady pace, or at stagnation. This doesn’t work for the digital economy. But Agile is like the unbalanced force in Newton’s law. The difference between Agile and Waterfall is that Agile is an efficient software development framework disrupting the inert processes of Waterfall, giving software companies the accelerated, innovative motion they need to more quickly develop and deliver software solutions in the digital economy.

What’s Wrong with Waterfall?

Josh Dahlberg, scrum master for Compuware’s iStrobe and Fault Analytics, understands well the difference between Agile and Waterfall. Before Compuware, he worked for an Agile company with Agile clients. But when he came to Compuware, it was still developing software under Waterfall with a year-long release cycle.

“The big change coming from Agile to Waterfall was the time it took for delivery,” Dahlberg said. “When I got hired at Compuware, it was nothing but meetings about new requirements. Inevitably people got into time crunches at the end of the year and things got dropped.”

Too much time spent planning forced important project components out of the release cycle, leaving customer needs unmet. For this reason, Dahlberg thinks “it’s an organizational imperative that people move towards Agile.”

“I don’t think as an organization you can maintain a competitive edge and wait a year to respond to changes in the market,” Dahlberg said. “Things happen so much quicker than that. By the time you even get around to that next-year mark the target might have moved from where you were aiming.”

Becoming More Efficient with Agile

Fortunately, Dahlberg had been with Compuware less than a year when Agile struck Compuware. Over time, development became more efficient than what Waterfall’s elongated trajectories had once allowed for. And today, Compuware develops software inside a DevOps lifecycle.

“Agile is a way to get your requirements, do your design and deploy at a more efficient rate than what Waterfall provides,” Dahlberg said. “You’re not burning a lot with Agile. You’re trying to be measured in the approach.”

This measured approach of carefully considering customer feedback and market demands allows developers to narrow their focus to building or adjusting specific software deliverables within a shorter timeframe.

“If we release something in July and customers don’t like it, we’ve got a shorter cycle length to make it better, as opposed to catching something in June from November’s release,” Dahlberg said.

That means customers are getting better results faster. In addition, Agile gives developers a more efficient way to catch and fix mistakes.

“Instead of coding away at something for six months then releasing it to find out it’s entirely wrong, you’re working in two-week sprints so you’re catching mistakes much quicker in your process,” Dahlberg said.

Agile processes like the 2-week sprint provide an iterative development approach that takes a large chunk of functionality and breaks it into smaller pieces. In time, the pieces comprise a bigger solution. The idea is to give customers a minimum viable product (MVP) that solves their most immediate needs, and then build on that MVP based on customer feedback. This is a core difference between Agile and Waterfall.

Agile Places People First

Looking at the difference between Agile and Waterfall, Dahlberg thinks the most important aspect of Agile is valuing people over processes, or as he says, “Appreciating the unique dynamic of a team and being able to own the process to fit within that team dynamic. The whole aspect of self-improvement, reflection on that and making changes based off of looking at things objectively—regardless of what your role is in an organization, there’s room for that process.”

Valuing people and how they use processes to function within their roles, rather than the inverse, includes empathizing with people who struggle to accept a process that brings with it a radical—and, for many, intrusive—cultural shift.

“Change is hard for people,” Dahlberg said. “Invariably, everybody wants things to change but they don’t want to change.”

And when people absolutely refuse to change?

“My approach is to kill people with niceness and keep driving at the fact we’ve got two weeks to commit something to delivery,” Dahlberg said.

Once people commit to change and work through the process of detaching from old constraints, with patience the benefits of Agile will unfurl for an organization. But organizations need vehicles for taking action to drive those benefits. The de facto framework for this is a scrum team.

To learn more about the connection between Scrum teams and how they operate within an Agile framework, consider reading these other posts: