The process of creating software is labor intensive. It can take thousands of dollars and hundreds of hours to create a simple web application. The reason the process requires so much work is that software is one of the few products that resists automation. From requirements gathering, to writing the code, to production, the entire process demands human attention. As a business, there has to be a way to maintain control of costs and quality. The good news is there is, and it’s called Agile.
Unlike traditional software engineering, Agile has rapid feedback cycles. We call these cycles sprints because they are short and expected to complete a small piece of work. At the end of the sprint, the client can review the work and see if we are moving in the correct fashion.
Large software projects in the past were run like a military campaign. Large groups of consultants were hired and thrown at a project. The project was supervised by a project manager and deadlines were set in an arbitrary fashion with no input from the people doing the work. The process was filled with waste and people worked against the clock to deliver value. After long hours and “crunch time,” the software was revealed to the executives who commissioned the work. These meetings were often filled with acrimony because what the executives were expecting and what was demonstrated did not match. Deadlines were missed, more money was spent, and the process would repeat until the project was canceled or the software was shipped. When the client did ship software, it was over-budget and buggy.
Software developers and executives nicknamed these projects “death marches.” The experience was punctuated with unnecessary toil and drudgery. The project did not have a clear ending and the careers of numerous developers and executives died along the journey. It is a disturbing and wasteful experience.
Agile is a response to the death march. Instead of long periods of work without feedback from the client, the software team and the customer work together in sprints. At the end of the sprint, the customer reviews the work and has the ability to make any needed corrections or improvements, understanding they will be able to see those changes in effect after the next sprint. Each sprint is like a new chapter in a novel. Together, these chapters make up the story, with the earlier chapters informing the later chapters. The team stops sprinting when the project delivers the value the client is expecting.
The reason sprints are successful is they epitomize the idea of empiricism, which is central to Agile. Author Hiren Doshi breaks this down into three pillars. The first is transparency, which means everyone involved in the project knows what is happening. Not only do they know what is happening, but they can measure what is going on in an easy to understand fashion.
The next pillar is inspection. At the end of the sprint, the team and client conduct a sprint review to double check what they have done. The sprint review candidly talks about what value was delivered and if it is going to meet market demands. It leads to the last pillar, known as adaptation, where the team and the client decide to continue going or change direction.
Questions about the project are answered in two week increments. Decisions about money, technology, and schedules can be made earlier in the project, before small problems become expensive. Thanks to the three pillars of empiricism—transparency, inspection, and adaptation—the chances of your project becoming a death march decrease.
Instead of trusting things will work out, a client sees the construction of their software each step of the way. Each sprint is a chapter in the story of delivering value to a customer. It is less wasteful and provides plenty of opportunities to adjust to changing market conditions. It also beats the traditional project management death march.