Introduction to Agile

If you have looked for a software engineering position within the last 20 years, you have no doubt come across the word "Agile" in a job description. However, for people just getting into the field, this might be a foreign concept. If this sounds like you, you have come to the right place. I am devoting this week's blog post to the basic tenets of Agile project management.

So what exactly is Agile? According to https://www.atlassian.com/agile, "Agile is an iterative approach to project management and software development that helps teams deliver value to their customers faster and with fewer headaches. Instead of betting everything on a "big bang" launch, an agile team delivers work in small, but consumable, increments. Requirements, plans, and results are evaluated continuously so teams have a natural mechanism for responding to change quickly." You can also read the original Agile Manifesto here, https://agilemanifesto.org/. Agile is a deep topic, but at its core it values four basic tenets which are: individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a strict plan.

So what does valuing individuals and interactions over processes and tools look like? To me this means building projects around motivated individuals, and giving them the trust and support they need to do their jobs. It's not that there is no value in processes/tools, but when the two come into contact individuals and interactions should win out. An example of this might be that a team wants to use Node.js for their current project because they feel that it would be the best tool for the job. However, the project manager refuses claiming that the company is a "Rails shop." That is prioritizing process and tools over individuals.

In general, a lot of agile development is about removing the barriers between the developers, and the customers that they are building the software for. That's where valuing working software over comprehensive documentation comes in, or as I like to call it, "thin vertical slices." When we value working software instead of getting bogged down in waterfall bureaucracy, we keep the risk low and have it go with the value. With agile, we do some work which carries some risk, and then we deliver the value. After each new working feature is implemented the risk goes down because we have a working piece of software. This step by step, or thin vertical slices approach allows us to mitigate our risk by breaking it up into small and manageable pieces. This approach also allows for us to make changes to the project early on. Say you build out a feature, present it to the customer, and they completely change their mind. It's much nicer to find that out early on in the development process, instead of at the tail end of it. It's a lot easier to talk with the customer about what the software should be with the software right in front of you.

This segues nicely into customer collaboration over contract negotiation. What is meant by contract in this context is the actual contract between the client and the company, and also any kind of "get it writing" processes. An example of this would be a company that utilizes something like change request forms. Customer collaboration is the answer to this kind of telephone game. Instead of getting bogged down in an endless sea of phone tag and bureaucratic forms, the customer is in direct contact with the people building their software. The result is that while you are working with the customer they no doubt get new ideas. However, instead of being hindered by formalities, we value the organic evolution of the product with the customer in realtime. We want to be teammates with the customer, not micromanagers of every step of the development process.

I've saved the best for last. Responding to change over following a plan is the true heart of the agile philosophy. It's so important that you almost can't even talk about the the other agile tenets without talking about responding to change. To me this basically means that you have to address reality as you find it. A great example of this in action was when I was a student at the Flatiron School. Our lead instructor, who taught me everything I know about agile, would not plan the courses that he and the rest of the instructors would teach in advance. Instead, they would go into every standup completely fresh, and they would ask us where we were at, and what we needed help with. Only after finding out where we were on that particular day would they plan our courses for the day. The instructors may have had some ideas about what needed to happen, but they would throw those ideas out in a heartbeat the second that the reality of where the students were in their learning journey didn't coincide with their plans. That's what it means to respond to change over following a plan.

Agile is a deep, and very cool, topic. I hope this introduction has helped shed some light on the agile philosophy for those who may not have had any direct experience with it.