Breaking Through the Agile Development Jargon


Jargon. It is something that those of us who spend a lot of time writing absolutely hate. Jargon gets in the way of meaningful sentences that convey worthwhile ideas without unnecessary words. Yet every industry has its jargon. Pick your favorite industry; none are exempt.

The driving force behind this article is cutting through the jargon of agile software development. Agile development is the hottest trend in software development, as it should be. To be agile is to have the flexibility to develop software quickly, efficiently, and cost-effectively. It is to have the people and resources in place to allow teams to develop side-by-side for a much better finished product in a shorter amount of time.

Given the inherent strengths of agile development, you might be wondering why anyone cares about industry jargon. After all, what is most important is that agile teams get the job done. How developers speak to one another should be of no consequence, right? Wrong.

Jargon Matters to Customers

You could make the case that agile developers do not use a lot of their own industry jargon in face-to-face conversations. But even if they do, the real problem with industry jargon is that it shows up in blog posts, news articles, white papers, and case studies. That is not good from the customer’s point of view.

Let’s say I am a customer looking to have an enterprise-level app developed for my small business. Before I can begin looking for a development firm for my project, I have to know what to look for. So I begin consuming as much information as I can find. If I come across a blog post from one of your developers or senior managers and I cannot understand it because I can’t decipher the jargon, I am not likely to select your firm for my project. I am going to go with a firm that speaks language I can understand.

As Austin-based iTexico explains, the original Manifesto for Agile Software Development written in 2001 was written in language that even someone with no knowledge of software development can comprehend. Agile development was still a new principal at that time, so the jargon had not yet been developed. How things have changed. It is more common now to see things written about agile development that can only be understood by a small number of people who actually speak the language.

Here is just an introductory list of four terms used in agile development circles that mean absolutely nothing to paying customers:

  • Scrum – A form of agile software development based on an empirical approach that takes into account the fact that customers change their minds quite frequently.
  • Timeboxing – The practice of managing a project by allocating fixed amounts of time to certain tasks.
  • Mood Board – A visual representation of how development teams are feeling about their progress at the end of the day.
  • Burndown – The rate at which backlogged tasks are being cleared.
  • Burnup – The rate at which scheduled tasks are being completed.

All these terms are pretty simple to understand once they are explained. But the thing about jargon is that the terms are, in most cases, completely unnecessary. For instance, why use the term ‘timeboxing’? Is the word ‘scheduling’ too hard?

The whole point of agile software development is to create a more flexible, responsive, and efficient environment for developing software. Introducing an entirely new vocabulary of jargon only makes things more difficult for paying customers who do not live in the software development world. It doesn’t make a whole lot of sense from a business perspective.

Leave a Reply