Agile.

To some, it's the manifesto by which they live, to others, it's the promise of denied efficiency. I've been a senior web developer for a couple years now, and at both orgs where I've held the title, I've gotten the same question: "Hey Ryan, in your agile experience, how did you solve this problem?"

It's a complex question, regardless of the problem that's being addressed. The real question they're asking me is "Hey Ryan, is there an 'agile' silver bullet that could address the issues were facing?" Truth be told, the answer is always, emphatically, no. Now wait! Before you roll your eyes and think, "another developer, hating on agile," that's not what this is. Agile has its merits. Thinking about the way things are done has its merits. However, I don't believe in silver bullets, and neither did the authors of the original agile manifesto.

As a matter of fact, I could point out ways that that very manifesto has been completely deconstructed by "agile" thinking throughout my career. I won't get into my personal story (that's a post for another day), but I will share how I think that the manifesto should be implemented within organizations, since I seem to get asked quite often. I'll cover each point of the manifesto and what it means to me. As a disclaimer, I don't hold any of the certifications you can get for agile frameworks, and I haven't worked as a scrum master, a project manager, or anything like that. I just get asked about this a lot. Take what I say with a grain of salt (as always)

People Over Process

The first line of the agile manifesto reads as follows:

Individuals and interactions over processes and tools

This has been shortened to the oft repeated, rarely understood "People over process" mantra that we've all heard within the software industry. The problem is, every person you talk to seems to think this means something different (myself included). When I hear "people over process," I immediately think "great, fewer meetings and more focus on the people who work here". However, this isn't quite what I've learned people over process should mean.

First thing's first, process doesn't have to mean meetings. This is a common misconception when implementing any kind of process. "Great, more meetings." seems to be the gut reaction for technologists when you tell them you're implementing process. This decreases the time they could spend being efficient and flies in the face of "people over process". So what does people over process really mean, if so many agile frameworks seem to go against this pillar of the manifesto?

First things first, this has to do with empathy. When an organization outlines a process, it's important to remember that it's extremely rare that anyone is trying to waste your time on purpose (that doesn't mean it's unheard of). Most of the time, everyone has the same vision. Rapid development of quality products. The famous Skunk Works was one of the earliest organizations to champion the agile methodology. Their chief goal when creating the P-38 Lightning was, above all else, Rapid Development. However, they couldn't sacrifice quality. These were aircraft that were going to be flown in a war over Europe, they couldn't afford mistakes. Everything they did, everything they tried, was in service of the goal of rapid development of a quality product. Today, most software teams want the same thing.

The reason it feels like our time is so often intentionally wasted is because PEOPLE have been forgotten. The needs of the people within your organization need to be considered. To sum it up, I think all project managers need to ask themselves the same question: "How can I maximize the efficiency of the people I work with?" This is opposed to "how do I create the most efficient process?". Process can be an impersonal, one size fits all approach to the eternal need to increasing efficiency. However, when you prioritize the people within your process, when you empathize with them, you see much better results.

I'm not saying that process is the bad guy here either. As per usual with everything in the manifesto "there is value in the items on the right, we value the items of the left more." Process can maximize efficiency, but not if it doesn't work for the people you are implementing it with. My final suggestion is this. If you're implementing new process at your organization, collect feedback, and do it in a way where those you manage can be open and honest. If something isn't working for the people, you'll know it.

Working Software Over Documentation

Oh boy. This one is contentious. It's no secret that writing documentation is not every engineers favorite activity. Truth be told, I rather like it (as you may have been able to tell from the article), but I'd almost always choose writing code instead. While many believe that this pillar of the manifesto means eschewing documenation altogether, it actually means focusing on getting your software to a functional state as quickly as possible before focusing on complete documentation.

When you think about it, it makes sense for a couple reasons. When developers don't need to pause write documentation, they can implement features in a minimum viable product much quicker. When your MVP is ready for release, and code has been tested and verified, it makes sense to have developers start their documentation at that point. It also saves time for any technical writers that may be involved in the project. If the code and feature set of an MVP is constantly changing, technical writers are constantly going back and revising what they're created.

"So what do technical writers do while code is being written?" you may be asking. Simple, they are spending time with the development team and product owners, learning about the product being developed. This makes it much easier for them to write comprehensive documentation when the project is ready to be documented.

Developers SHOULD do their best to write documenation and to assist technical writers, but not at the cost of rapid development. Remember from the "people over process" breakdown: Rapid Development of Quality Product is the goal!

Customer Collaboration Over Contract Negotiation

Contracts rule the world. They keep us safe from clients who may decide to change the parameters of an engagment, and they protect consumers from malicious business practices. However, spending all your time negotiating contracts, or trying to create the perfect contract, can be counterproductive to both you and your customers. Agile is all about moving fast, and you can't do that without feedback to iterate on.

If you want to collect this feedback, you need to talk to your customers and stakeholders. You need to work with them, throughout the process. Communication must be help open, and my preferred approach to user acceptance testing is early and often. The client or customer may not like what they see at first, but working with them to create the perfect product as a team is a much better approach than creating something you think is perfect, only to get to the end of the project and learn that there is something(s) missing.

I can't tell you how many times I've gotten to the end of a project and a client says "well what about XYZ feature?" The quick response from the powers that be? "There was nothing in the contract about that." This isn't a problem that is exclusive to client/customer relationships either. A "contract" doesn't have to mean your were contracted. I've been on internal teams where there was the exact same outcome. You present your first pass that you've spent months developing to the stakeholders, and you're presented with a myriad of questions about something they thought was going to be there that wasn't. It's frustrating for developers and stakeholders alike, and easily avoided when you spread communication over the length of the project.

Responding to Change over Following a Plan

The final pillar. The big bang that we go out on. This one is the one that everyone seems to forget. As Churchill said:

Plans are worthless, but planning is everything.

Okay, that one may be a little dramatic, let me go with something a little more fun. As Todd Howard, project lead of the critically acclaimed, fan-adored Fallout and Elder Scrolls series said:

Games are played, not made.

Games aren't made? Well of course they're made, what does that even mean? Video games don't just appear in our steam library. They need to be developed. Of course they do, but what Howard is saying here is in the context of huge, elaborate design documents for games. You can have a bullet proof design doc. You can plan to your hearts content. You can have the best idea in the world. Until you build it an start playing it, it doesn't matter.

Plans are important because they give us a rough idea of direction, but they are almost never going to pan out. The best planss change, and change they must. When design isn't met because something doesn't go according to plan, it's important to pivot. It's important to collect feedback and continue to iterate. To move, to grow. And it's imperative that this is done quickly. This is what agile means. Agility comes from the speed at which you can move, and moving in a straight line that you've plotted is going to work zero percent of the time. Organizations must be able to change and adapt.

This pillar is the most self explanatory, but it's the hardest for people to change (ironically). I've observed there are three types of people in the world. Dreamers, planners, and executors. Furthermore, I'd say it's about a 10, 45, and 45 percent split, respectively. This pillar flies in the face of planners, because it's where they must relinquish control to executors. That loss of control can be hard for those who self prescribe as "type a". There is a lack of flexibility, and so, despite these people being "the planners" they lose their capability to plan, because something unexpected has happened. However, the likelihood of this happening in an agile organization is near 100 percent. If you move fast, plans change, and if you can't change, you no longer move fast.

As much as we all want to have this moment:

It's more often than not that it's going to be more like this:

And you better hope you can find the fire extinguisher.

Wrapping it Up

As I said in the beginning, I'm not an expert in this stuff. I'm just a developer who has worked in agile environments for a good chunk of time, and I wanted to share my perspective on these things. If you think I'm dead wrong, just let me know wherever you found the link to this article. I'll try and respond to the feedback with...agility.