Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

The Difference Between Agile Programming vs. Agile Project Management

DZone's Guide to

The Difference Between Agile Programming vs. Agile Project Management

What does (or should) a company mean when they describe themselves as ''agile''? We take a look at the different ways Agile is applied to development.

· Agile Zone ·
Free Resource

Download the whitepaper on Product Centric Agile Delivery. Brought to you in partnership with Jile.


Many software companies say that they are "Agile." But this can mean different things.

To understand the complex world of Agile approaches, let us travel back in time and see what brought about the paradigm shift that is now called the "Agile revolution."

In the beginning, computer technologies were developing slowly (compared to current development speed). Breakthroughs were few, albeit significant. The 1990s saw a systemic shift in technologies. Companies like Google, Netflix, and Amazon were founded in the late 90s, which coincided with the advent of the dot-com era. From 1995 to 2001, the World Wide Web experienced exponential growth and changed the global role of software forever.

The old ways of creating software were no longer suitable for the new situation. In 2001, the Agile Manifesto was charted, which put in words what many people have been thinking. It was a farewell bid to old bureaucratic processes for creating software and a postulate of new, "agile" development principles. However, that historic manifesto is just a set of guidelines. More specific methods followed afterward, such as Scrum, Kanban, Lean, and others.

Still, what could it mean when a company says they are "Agile"?

We're Agile = We Do Agile Project Management

There are certain Agile frameworks that can be used for managing a project on a high level (without going into technical details). These frameworks are not for developers — they are for Project Managers, Product Owners, tech leaders, and other roles who manage the process.

Scrum is arguably the most widely-used Agile framework. Or, if you are an enterprise-level company, it could be SAFe or Scrum of Scrums. The essence of these Scrum-based approaches is the same. In Scrum, the dev process is broken into two- to four-week iterations known as "sprints." A cross-functional team where you've got some developers, a business analyst, a QA, a designer, and possibly other professionals, tackles a finite pull of tasks during this time-boxed period.

There are other approaches to organizing the process besides Scrum. For example, there are Kanban and Lean development. While they differ slightly in how their processes are organized, the common denominator is that all Agile methods let you tackle a small bunch of development tasks at a time. This allows you to make changes to software more frequently. Usually, it means it will be better aligned with the latest product requirements and market demand.

We're Agile = We Practice Agile Programming

Low-level programming routines can be organized according to Agile practices, too.

The goal here is to produce higher-quality, maintainable software faster and easier. Agile propagates co-located teams and effortless communication. It is believed that you can't really over-communicate in Agile. Working in your own isolated bubble is considered un-Agile.

Agile is also about collective code ownership and cross-functional teams. Which means you should write code and code comments that will be clear not just to you as the author, but to other developers as well.

There are specific approaches to Agile programming such as eXtreme Programming (XP), Test-Driven Development (TDD), and others. In XP, you are supposed to practice certain routines (pair programming, unit tests, continuous refactoring, etc.) to improve the quality of your code and advance your skills faster. Research shows that teams that do pair programming tend to be more productive (although it depends).

There is also TDD (Test-Driven Development), which is an XP practice. TDD consists of a developer writing a test for a small chunk of functionality before they write any functional code for it. While doing TDD, the developer may be tempted to skip the test and write a function first. That's why TDD may be slightly easier for teams that practice pair programming, and it could make sense to combine these practices.

We're Agile = We Are Agile HRs/Marketers

And this isn't a joke. Since every software development company has an HR and a marketing department, some people there have clearly been inspired by the Agile spirit and charted their own manifestos!

Here are two examples of how to bring this practice into action: Manifesto for Agile HR Development and Agile Marketing Manifesto (okay, the former one looks a bit like they are trying to sell it to you — they're marketers after all.)

In these manifestos, you find similar/overlapping principles of transparency, the ability to adapt, and human-centeredness that are also present in the original Agile Manifesto.

In Conclusion

So, what does it mean when someone says, "We are Agile!" As you may see, it can be so many things. The company could be doing Agile project management or Agile development, or both. Their HR department may be run according to Agile principles! We, for one, also practice Agile marketing here at ObjectStyle among other things.

And what is your Agile story?

Please enable JavaScript to view the comments powered by Disqus.

Download the whitepaper on Five dimensions of Scaling Agile in Large Enterprises. Brought to you in partnership with Jile.

Topics:
agile ,agile practices ,project management ,agile leadership ,agile methodologies

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}