The Early Days of Agility

Problem

Like many people in software development, my tenure goes back for more than forty years. In the early days, you could often produce a product that is buggy as all hell, but that people will still consume it regardless.

At one point during these early days, I found myself walking into a situation that involved a relatively small group of thirty or so who would be on my development team. It was absolute chaos. It was a task-switching environment. The Head of Engineering would move the goalposts daily, changing the structures of the teams within the group almost constantly. People were being thrown from assignments and tossed around needlessly.

The disorganized environment led to faulty work, and, when a bug was found by the testers, the engineers would be upset. The situation was, unfortunately, very adversarial. Our deliveries were one to two years behind where we wanted them to be. The list of defects was always growing.

We were utilizing the waterfall style of working. This was right when agility was being introduced to the world of tech. We were eager to incorporate this new way of thinking into our model of business and development.

Actions taken

I read the Agile Manifesto when it first came out — I even happened to know one of the people who had signed it. I brought him in to speak about agility at a networking event that I had brought together.

They began with a process called Extreme Programming. It involves two developers working simultaneously on a single piece of code. The idea is that you cleanse the code as you’re writing it, because both developers bring their own unique perspectives to the project at hand. They see the others’ issues objectively, and, together, they end up producing something superior than what they would be capable of individually.

We began to adopt the principles that the manifesto outlined in our own company in order to solve the problems that we were having. We changed the process and programming languages that we were using and initiated a paradigm shift in the environment of the office. We relaxed many of our office policies like our dress code and we offered new flex options that allowed our employees to work comfortably, on their own terms. We began paying people on a project-output and quality basis that rewarded ability.

The release that followed all of these changes did, in fact, end up being late. But the product that we put out ended up being of a much higher quality than what we were doing before. Our beta customers liked the offering so much that they ended up championing and selling the product for us. Every release to follow ended up hitting its mark within a week or two. From stagnancy, we were able to scale up significantly.

Lessons learned

• After having those experiences in the beginning, I started to pursue a policy of producing the highest quality of product possible. There is a false notion that says producing quality requires the investor to throw large sums of money at the project. Ironically, committing your efforts to producing something objectively worthy reduces costs by increasing productivity overall.
• Agile, if you do it correctly, helps you to focus on what must be done in the present moment, as opposed to what you see as being necessary months down the road. The idea is that if you try to pre-plan all of that, you end up dismantling half of it. You might as well build something that is actually relevant when the time calls for it. In the past, when things weren’t changing so quickly, a waterfall type of approach worked to some extent. Now, you need to be agile in order to keep up. Locking down requirements will have you building products that will not be relevant to the markets that they end up seeing in actuality.
• Integrated teams and integrated testing will increase the potency of your troubleshooting efforts beyond what independent testing can offer. The agile process amounts to much stronger production code in this way. Working in iterations that are reviewed frequently allows your developers to be more engaged with what they’re working to produce for the company. Your people become more excited about the project and will autonomously refine it.