What’s Agile Software Development?

For many complex processes, there are several ways to do them wrong and only one or a few ways to do them right. This is true with Agile.

Many organizations claim that they’re doing Agile, but they really aren’t. Many of these organizations are frustrated because they’re not getting the benefits they expected but that’s really no wonder because they’re not doing anything differently than what they were doing before.

Scrum is a useful methodology for planning and organizing work, but Scrum is a minimal framework and it says nothing about how to actually do the work. Scrum say for teams to self-organize and adopt the practices of Extreme Programming, but this often gets translated into “leave the team alone and hope for the best.”

Scrum software development does have something to do with software development. To really gain the benefits of Agile software development we have to do a bit more than just hold a good meeting. Planning sessions are valuable but the real challenge with software development is going from the plan to the product, which involves real technical work.

The Agile movement has made great strides in technical practices over the last few decades. The design patterns movement, the test first development movement, and most recently the dev-ops movements are really showing us how we can improve quality in our process that builds not only a better product but does so cost-effectively.

So, what really is Agile software development? Is it all about the daily standup meetings and estimating story points or is there something more to it? I know that everyone has their own opinion. If he were to ask the original authors of the Agile Manifesto, the guys who met at Snowbird in 2001, they would probably say that Agile software development follows lightweight processes to allow developers to apply their technical skills most effectively.

Back in the 90s, we were overwhelmed with software development processes. There was not only Waterfall but CMMI was starting to come on board and the Rational Unified Process and all of these software methodologies were heavyweight and development required a great deal of administration. Agile was a direct response to this. They wanted to come up with a lightweight process that would give developers more time to do development.

Agile was originally called the Lightweight Software Development Process but was renamed for obvious reasons. Who wants to do “lightweight development?” We don’t call it the lightweight software development process but that’s still the intention.

One benefit Agile gave us was the ability to measure our success based on working software. It doesn’t matter how pretty our plan is or how comprehensive our documentation is if our code doesn’t work. Customers pay developers to write code.

Before Agile, the time developers got to actually write code was a small part of their responsibilities. I know a lot of teams that spent less than half of their time writing code and many teams spend as little as 10% to 20% of their time actually coding.

What were they doing during the rest of their time? The answer is they were attending meetings, reviewing designed documents, writing documentation, etc. And while those things appear to be important, they actually detract from the primary value that developers create, which is writing code.

Agile simply says that the software development process should be primarily focused on developing software. We do this by removing extraneous distractions. We keep meetings to a minimum. We eliminate formal requirements and remove the overhead in creating, maintaining and interpreting formal requirements. We avoid batching up tasks into separate phases like analysis, design, code, and test because that is also highly inefficient when it comes to building software.

To the uninitiated, the Agile software development practices of Extreme Programming appear to be highly undisciplined but nothing is further from the truth. Doing emergent design takes great human skill and discipline. Developers don’t acquire the skills by osmosis, they have to study them and even more importantly they have to unlearn many of the practices that they were taught in school because schools don’t support iterative development techniques for Agile software development yet. But when teams avail themselves of the technical practices of Agile then they start to see the real benefits of Agile software development.