Most of us have a reasonable working definition of what “agile” means in a software development context. We all know what it is SUPPOSED to mean, what it means when implemented correctly, and we even probably have some expectations when another developer uses the term. But when talking to a non-technical person, especially someone in an upper management role, we often have a hard time articulating it. And the results of this can be disastrous. There are plenty of magazines, websites, and podcasts that delve into what agile can do for an organization from the executive perspective. And because these are often written by people who stand to make a great deal of money if someone hires them, they can often veer into showing agile as a “silver bullet” for all the organization’s problems. Furthermore, developers can exacerbate this by assuming that management understands the word the same way that they do.

One of the greatest weaknesses that developers have is a bias towards assuming that other people have the same knowledge as we do. This, by the way, is a very common and normal human failing, and it’s something you’ll see in any group with specialized knowledge. Developers who find themselves in non-agile (or fake agile) environments are often quick to complain and suggest doing things in a more agile manner. While this is fine if you explain exactly what you mean, it is absolutely NOT FINE if you don’t. It’s best to be aware that there are a lot of misconceptions going around about what agile is and what it is not. You really, really want to avoid having management try to implement “agile” in the way that they understood it from an article they read in a business magazine (ask us how we know).

Explaining agile to non-technical people, especially executives, is difficult. It’s also something that you are likely to have to do, especially as some segments of the business press do so in an incorrect fashion. If a non-technical person has heard of agile, they probably have misconceptions about it that aren’t going to help. Well-implemented agile will make most organizations more responsive to change and will allow for quicker delivery of working software, but the way that that happens is a bit counter-intuitive. If you aren’t used to it, it’s easy to get the wrong impression of what should be happening at th earlier stages of the process. Worse still, if a non-technical person is in a decision-making position for the agile team, they may force agile to be something that it is not. It’s important that we explain these things correctly, otherwise agile-gone-bad has the potential to be as bad or worse than any other methodology.

The post Explaining Agile To Non Technical CoWorkers appeared first on Complete Developer Podcast.