January - 1st Agile Principle
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
The year has 12 months and agile development is based on 12 principles. Today, let’s start with the first agile principle. It is about customer orientation, perhaps the main motivation for agile development. Some of you might know, that it is now 18 years ago since a group of software engineers came together in Snowbird, Utah for a brief winter conference on project management. The result of that meeting was the well-known Agile Manifesto. It had a big and lasting impact on the software industry. Somewhat later the Agile movement started out and today, agile methods can be considered mainstream. However, back then things were different.
At university and during the early years of my career I learned that software development is divided into six stages. It starts with requirements analysis followed by three production phases, followed by deployment and maintenance. It was understood that the software development lifecycle (SDLC) phases are strictly linear and sequential. One is completed after the other. The customer is only involved in the first and the two last of these phases. Software companies spent enormous efforts on analysis, planning and documentation in order to get cost and time estimates right. Customers had to be enormously patient to wait for functioning software and they had no say in its production.
This process carried significant risks and turned out to be frustrating for both parties. Although customers initially received detailed contract specifications and a fixed price offer, the product was regularly late and below expectations. Even worse, some requirements changed during implementation and thus the software was already outdated at the time of delivery. Another costly change order was then inevitable. Things weren’t much better for developers. Unforeseen events and technical difficulties led to exceedance of cost and time estimates. In the worst case scenario, these circumstances left the developer unable to fulfill the contract and pushing towards bankruptcy. The client received either no product, or an unusable product for their investment.
In 2001, I was managing my second startup company and had no intention of repeating past mistakes in project management. Like many others at the time, I used a homegrown set of lightweight methods for SDLC management. I had acquired these during the late nineties in my practical work with different clients. I knew nothing about the Agile Manifesto at the time, but I found that the traditional waterfall approach didn’t work for us. Instead, I visited my clients every two weeks. During a long meeting which often took the larger part of a day, I would first present the new features that my team and I had developed. I would then install the pdate on my clients’ servers (this was well before the time of Internet-based deployments). Finally, I would discuss the most-wanted features and changes for the next cycle. There was an understanding that if the client found any bugs, they would be fixed immediately within a single release cycle.
Why did this work so well? Because the customer was always kept in the loop. They received usable software every two weeks that provided actual business value. They could control and even participate in the design process. They could correct mistakes early. Last but not least, their financial commitment wasn’t burdened by huge risk, because they paid monthly installments. This way of working puts the client in control and keeps them happy. And this is exactly what the first agile principle is about. I learned about agile project management only some years later and I found it to be an excellent fit for what we were doing. It confirmed our practice as a development company and it also broadened and enhanced our methods.
The reason why the this principle is the first, is given in the beginning clause: our highest priority is to satisfy the customer. Fundamentally, the agile methodology is about customer satisfaction. Normally, the customer is thought of as a third party outside the software company, but it could very well be the same company doing in-house development. It doesn’t matter. In the latter case, the customer role is filled by another department within the organisation. It is important to note that neither technical goals, nor abstract principles of management provide the foundation for agile development, but business goals. The middle part of the sentence mentions early and continuous delivery. This makes perfect sense from the perspective of developers, because software artefacts evolve and grow in small incremental steps. It also makes sense from the perspective of the customer, because they can begin using individual features before the entire package is completed. Even more benefits are reaped by early and continuous delivery. The customer can control and prioritise the development of individual components. Mistakes can be corrected cost-efficiently at an early stage. The customer can verify or invalidate concepts in practical application. Developers are able to create proof-of-concepts without committing to a specific design or technology too early. Finally, the
first agile principle speaks of the delivery of valuable software. The value of software is what clients and developers ultimately aim to realise together. This always translates into some sort of business value. For example, the software might enable the client to respond faster to their own clients. Or it may automate some task which previously had to be done in a tedious manual way. Or it may enable the client to gain deeper insights into markets, opportunities, and risks. The possibilities are endless. The sooner the software enters production stage, the earlier the customer can reap its benefits.
In summary, the first principle encapsulates the motivation and mission for agile development. It’s all about customer satisfaction and providing business value through software.