Why I’m an Agilist

 

Someone asked me “How did you end up loving all this agile stuff?” and I answered, “Agile is common sense to me”. Immediately after I said that I felt like it was such a snobbish answer after all its almost like saying that everyone who doesn’t get what it means to me agile lacks common sense but I never really meant it that way. A more eloquent way of saying it would have been that the agile manifesto is a reminder of why we build software to begin with.

The original programmers were really good mathematicians and generally very smart people. They had to be because the first computers were made to crunch numbers. At that time the value that computers brought were the number of operations they could do per second and how much faster it was than doing by pen and paper. In the many years that passed, we’ve seen the humble number crunching computer learn many new tricks like store data, show fancy user interfaces and even make itself available over the internet. All of that growth was fueled by the need to solve more complex problems. With all of the growth that happened its easy to lose track of why we do this to begin with. We build software to solve problems. The agile manifesto reminds us of that.

Individuals and interactions over processes and tools

We write accounting software for accountants, banking software for bankers and inventory system for store owners. The problem to solve may be too big for one man to fix on his own and that’s why we have software teams instead of rogue programmers. We may not know the business domain perfectly as there are very few programmers who also happen to be bankers or accountants so we may need some requirements specialists or business analysts to help bridge the gap. We might not be very good businessmen and entrepreneurs so we don’t know how to charge for our services and that’s why we have management and managers. More people means more personalities and interests and those lead to more processes. Its too easy to get caught up debating and defining what a story, task or subtask is or setting up arbitrary rules, procedures and processes to get people to play nice with each other. When the real goal is to get people sharing expertise with each other to help us get the best possible software out the door. The first goal should be to get a team in place and not to get processes in place, the interaction within the team should be the process and not the other way around.

Working software over comprehensive documentation

One misconception is that agile is against documentation and that’s because one item in the manifesto is dedicated to it. What its really against is useless documentation, it’s simply a reminder to ask ourselves why we write anything. Phone books were written down because we couldn’t remember everyone’s phone number, waiters write down orders because it’s hard to remember everyone’s order and we write down requirements because it’s almost impossible to remember the 300 different things your accounting software is supposed to do. We write things down under the assumption that it would be important to have access to that information in the future. This is why we write down documents saying what software should do because it would be disastrous for us to deliver the wrong features. Writing down documents listing down everyone’s favorite outfit in the office is only valuable if you plan to sell them clothes to replace those outfits later on. While we’re not opposed to writing things down that matter, we don’t want to get distracted from why we’re here it’s to deliver software.

Customer collaboration over contract negotiation

This item in the manifesto is one that isn’t talked about much and that is with good reason. As the software industry has grown there have been different contract schemes that have been adopted by people and companies like the fixed income contract scheme or those who adopt a time and material kind of agreement. I often see this item as a reminder of why software is built, it is to help customers.

Responding to change over following a plan

If I were to pick out one item from the manifesto to be the heart and soul of agility it would be this. The manifesto talks about uncovering better ways of delivering software and this is it right here. People have described “agile” as a mindset or a set of principles but to me, it is simply how we respond to change. It’s not about using story points, sprints or time boxes. It’s about remembering the most important thing and that’s delivering software. It’s important to write down plans and get organized but it is equally important to know when those plans are slowing you down instead of speeding you up. It’s important to evaluate your plans and adjust as the times change.

This is why to me this is all just common sense. Everything we do, we do with a purpose. That purpose should be getting good software to our customers. Everything else is secondary to that goal and the manifesto encapsulates those thoughts perfectly. That is why its common sense and that’s why I’m an agilist.


Originally published at https://www.linkedin.com on April 17, 2017.

 

Leave a Reply

Your email address will not be published. Required fields are marked *