What is Agile?

I have found myself, more often lately, being asked “What is Agile?” I have answered this question a number of times and a number of different ways trying to find the short answer. I have recently come to find myself pulling from people like Woody Zuill, Fred Zuill, Kevin Meadows and Dave Thomas. My current description is as follows:

“Agile != frameworks, estimates, events and metrics. Agile = kindness, consideration, respect and continuous steering.”

Yes there is a lot in there. And yes it requires a conversation. How about that.

Right now I don’t think I can give a more concise answer though. I guess some of the “!=” can be swapped out for a bunch of things that provide nothing really good. But I think I’ve captured the big ones for me and most of the people I have worked with over the years. And most often the people asking me this question are looking to hear a textbook form of framework buzzword answer. To this point at least when I give this answer, it sparks some genuine questions that allows us to explore the topic to gain a shared understanding of what each of us refer to as agile.

Using this shared definition of agile, why would we choose to work with it? Why would we choose working with agile over the traditional or conventional methods of software development. Why would we choose agile over the frameworks and “best practices” we find in these framework shops?

Allow me to take this back a ways to explain.

When we begin our learning journeys we are bright, inquisitive and engaged. We choose things that interest us. That capture our attention and curiosity. And we are hyper focused on learning.

We enter the workforce with this same learning mindset. Lets refer to this as our light. We may not all remember this feeling, or recognize it in others joining teams. Some even look at this light as someone is just very young and naïve. We hear others or even ourselves say things like:

“They are young, they will learn with experience how this all works.”

I provided this image in an older post and it is the best thing I can use to visualize this in a sort of demented double loop cycle.

This is when the indoctrination begins. That cultures mindset is unrelenting. Until eventually this very bright, inquisitive and engaged persons light starts to dim. You can see it in their eyes. Yes, even remote with cameras off, you can pick it up with their changing tone, drop off in questions or sharing of ideas. This persons light or inner-fire is eventually extinguished.

Our ability to provide fuel to that persons inner-fire, to keep that light bright, is for me a core difference between agile and traditional/conventional and yes even “agile framework” software development and organizations.

Traditional/conventional software development and organizations far too often take the approach that people need incentives to continue learning and growing their skill sets and to get the work done. They offer bonuses and promotions for extra hours worked, working while sick or on vacation. Or not taking time off at all. And that is if you are lucky. Most often it is a mention in a company news letter nobody reads or a comment on an all hands call nobody is listening too. And if these incentives don’t work, no worries, we have punishments in the form of performance improvement plans, reviews and meetings with human resources about your performance.

Agile frameworks the likes of Scrum, ScrumBan and the scaled frameworks such as SAFe, Scrum@Scale, LeSS and the latest Autoscrum have fire extinguishers that put those traditional/conventional software development methods to shame.

And when these frameworks are installed during “digital transformations” or “Agile transformations” these engaged, bright, talented and inquisitive people are now consumed with making sure they are following the rules of the framework. All for the very false sense of control these frameworks provide.

How many times have you heard something very similar to this:

  “Ok, we have a PI Planning the next 3 days to figure out what we are going to deliver this next quarter. Our front-end and back-end teams will identify dependencies between enabler stories and feature stories via a red connected line. Each team will run on a two week sprint cadence that must include a sprint planning, backlog refinement meeting, daily standups, sprint review and a sprint retrospective. Your scrum masters will tell you how to do all of this. Let’s make sure that we all have our tickets updated daily and in the right status on the scrum board in Jira. Keep in mind that we need to ensure enough time for QA’s sprint and a hardening sprint for our DevOps team. It is vitally important that our release train leaves the station at the end of the quarter. If your stuff isn’t on it, it is not going and we will have to complete a post-mortem retrospective to identify who and what failed where.”

Shivers and flashbacks for me just writing it out.

After being in that type of environment. These very brilliant, engaged, inquisitive people didn’t just let their inner-fire go out. It has been extinguished.

Agile approaches take the opposite stand point. People do not need to be forced or incentivized with bonuses or titles to learn or get the work done. People do not need a framework to follow. When a team doesn’t have a process in place, they will create one that works for them. People are naturally interested in learning. This is true even from a very young age. Even before you get into school you learn how to walk, talk, go to the bathroom, read, ride a bike, dance and make jokes. People who learn software development typically aren’t doing this so they can complete the most amount of backlog items in a sprint. They want to help people. They like solving problems and learning new and interesting things.

Agile promotes hands-on, collaborative, challenging and joyful ways of working. Agile encourages divergent thinking instead of convergent thinking. The value is focused on innovation rather than standardization. On continuous learning and continuous steering.

Agile organizations do this in a couple of ways. They have mixed skilled teams. You know those teams we refer to as cross-functional. With a range of experience. The skills and experience mixed in the teams help to form natural leaders and mentors. And the less experienced team members get the benefit and experience of working with people who have been there and done that. These leaders and mentors help guide the rest of the team to avoid some of the painful pitfalls they experienced and in return this frees us up to bring new thoughts and ideas to the way we work and the work itself.

The team doesn’t rely on a project manager or scrum master or product owner or tech lead to explain every detail to them. The team relies on collaborative working to solve problems together. Sharing knowledge and experience as they go.

Another way agile organizations promote learning is by grabbing a persons interest while they are interested. If someone shows an interest in learning something new, they are encouraged to do so and supported in that learning. That interest is what keeps that inner-fire lit. That learning allows us to keep innovating and steering ourselves and our organizations.

You may not agree with me. And that is fine. We all come at things from our own experiences and with our own skills. But my preferred way of working, with agile, is going to accept your experiences and skills. Try to draw knowledge from it for all of us. And we are going to value your perspective. I am not so sure you are going to have that same experience with traditional/conventional or framework driven organizations.

In closing, I have found agile ways of working to help people with leadership, mentorship, kindness, consideration, respect, quality, innovation, initiative and a love of learning.