Tell Me Like I’m 12: What is Agile?

I’m introducing a new series today: Tell Me Like I’m 12.

This series will be about distilling down some of the common ideas, phrases, and words used within Agile, but explaining it like I might explain something to a 12 year-old. Why? Because if a young kid can understand it, hopefully experienced and new developers alike can understand it as well. We spend soo much time debating and misinterpreting these concepts, the we need to work towards a common understanding.

I know I know. Everyone already has the famous XKCD comic in their heads:

But my goal isn’t to throw out the baby with the bathwater. My goal isn’t to re-define Agile or try to convince you someone else’s definition is wrong. I simply want to try and take all of those fancy terms you have heard as a software engineer and make them, well, simple.

So… Agile

Some History

Agile is really just a short one-word substitute for Agile Software Development Lifecycle. While there had been different flavors or ideas of “iterative software development” before, the late 1990’s and early 2000’s really saw a surge in the ideas. Developers such as Martin Fowler, Kent Beck, Robert C Martin and others were really thinking hard about it and writing down their thoughts on emerging internet blogs. These writings (including my favorite The New Methodology) ultimately lead to the Agile Manifesto

The manifesto is really where the core values of Agile software development come from. If anyone is really looking to practice Agile, they should really take a look at the manifesto before anything else. While it isn’t a specific framework, the manifesto has some critical principals about what Agile is attempting to accomplish. The four core principles found in the manifesto are:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

I think these principles are spot on. Notice, velocity, iterations, sprints, or even team size isn’t mentioned here. Those ideas are the ones that have evolved over time. All that is really going on in these principles is trying to emphasize people, working software, collaboration and adapting to change.

But, to give some more concreteness still, lets look at to how those principles have evolved into a modern definition of Agile process.

Some Semantics

The Wikipedia definitions states:

Agile software development describes an approach to software development under which requirements and solutions evolve through the collaborative effort of self-organizing and cross-functional teams and their customer(s)/end user(s).

Geeez.. What a mouthful. This definition could use some simplified language don’t you think? Lets spend some time pulling it apart and trying to really get at the core and it relates to the original manifesto principles.

Requirements and Solutions Evolve

I think this is really the core piece that if you remember if nothing else. Agile software development is about embracing change. A good Agile team will relish learning that a software solution needs to change as more is discovered about how it is used. Maybe they aren’t excited about it per se, but they shouldn’t be afraid.

This doesn’t mean change is easy! It also doesn’t mean that you have an excuse to exercise poor requirements gathering or story writing. It simply means that you focus on getting right what you absolutely know and accept you don’t know everything yet. An implication of that also means that you should be paying close attention so that when something changes, you can understand why and learn about requirements quickly.

Collaborative Effort

If we are going to embrace changing requirements and solutions, we better be able to work together to understand how those things are changing. We need to be willing to say we don’t understand, and then find the person who does (if, in fact, some does know). We need to be willing to admit our approach to something that is no more complex than it was initially won’t cut it and we need other’s input.

At the heart of the need to collaborate is really the desire to deliver working, updated solutions after receiving new or changed requirements quickly. In fact, I’m sad that the Wikipedia definition doesn’t include this concept of frequent working software releases. Being Agile, but not delivering a working solution after the necessary changes have been implemented might as well be waterfall.

Why is it such a big deal? Because what seemed like a good idea might in practice not be really practical. Or maybe a glaring hole will emerge that was hard to see in the requirements documents. Either way, frequent releases allow for solutions to be re-evaluated quickly so that additional changes or implications can be understood just as quickly. How frequent is frequent? I won’t get into that here, but it needs to be agreed upon by the software team, product owners, and end users.

Which brings up the next few points…

Self-Organizing and Cross Functional Teams

More is involved in software development than just writing code. If you haven’t figured that out, well its time to wake up. There are requirements gathering, validation phases, deployments, communication to end users, planning, etc.

In order for a software solution of scale to be effective in its development, many teams elect to have dedicated individuals whose roles include performing some of the non-development things. You might be working on a solution that has very specific projects and thus have a project manager. You might be working on a long-lived product and thus have a product manager. You might even have both. You might be working on a complex enough solution that you need a lead or software architect.

All of these individuals have (and should have) meaningful input into your solution. Within the Agile mentality, this means thinking of these individuals as team-members instead of outsiders. This is where the cross-functional thing comes into play: you don’t want just a team of just developers, you want a team capable of performing all aspects of software development life cycle.

The Wikipedia definition uses the phrase self-organizing here, which is another loaded phrase depending on your understanding. I don’t think the intent here is that a bunch of people just decided to work together one day on a project and everyone just picked whatever role they wanted. That approach usually leads to a lot of confusion and power struggles.

What I think is that the team has autonomy to work together to decide who works on what and when. Sure, you might need a plan for large efforts, but instead of figuring out who works on what exactly, you enable your team to make those decisions as needed. This keeps with the same approach as adapting to changing requirements. The initial plan might have been great, but when it changes, the team needs to have the capability to adapt and shuffle who is doing what to best accommodate those requirements without a planning session.

Customer / End Users

One of the biggest drivers of the Agile development mindset was thinking about the customer or end user. Its hard to think of software development without considering these key stakeholders for me – I’m so used to involving them in the process that I forgot it used to be this group always “got what they got”. They weren’t involved in the process at all.

In reality, that was a silly approach. We write software for people to use! Even those users are other developers. Agile pioneers realized that this group was being marginalized and decided to bring them in. Get their feedback. Ask about what they wanted and if what was built met their requirements.

Involving your end users creates such a great feedback loop, I struggle to see how software was written without it. Requirements are often scrutinized earlier, are clearer and written in simpler terms. New features or bug fixes are validated faster and by real people using your software in real ways. And, from a non-technical perspective, you are telling your users that they are valuable.

How I Describe Agile When Asked

With all of that history and semantics out of the way, below is how I often describe Agile when asked:

Agile is a process by which people making something awesome work together with people using their awesome something to make that awesome something even better through frequent versions of that awesome something that adapts to changing needs of everyone involved.

Does that cover everything? No, I would think not. Is that comprehensive enough? Maybe not. What I do hope is that it is simple and plain enough that you can remember it and explain it to your 12-year old.

Be on the lookout for others like this where I try to explain some other Agile SDLC terms like I was telling a 12-year old.

Till next time!


Leave a Reply

%d bloggers like this: