With a new topic we need to dig into it somewhere and where better then at the beginning. So like the creation of the world we will begin, in the beginning, agile principle 1 was created. Lets dig into shall we?
Our highest priority is to satisfy the customer
https://agilemanifesto.org/principles.html
through early and continuous delivery
of valuable software.
Like most things that are suppose to change the world, the concept sounds simple but has many ideas packed into it. Lets break down what we are trying to do.
- Satisfy Customer
- Early Delivery
- Continuous Delivery
- Value
- Software.
There are five concept hidden in this easy sentence. The first is the main goal to satisfy the customer. Next is how we get a satisfy customer. We get that through delivery of software. But how to we quantify the deliverable? We need to deliver value. How do we maximize value in software, its through early delivery and regular delivery of software corrections and improvements.
Thanks for re-quoting the quote for me. You have a future in self help.
Yes, but we need to unpack it before we can talk about it. Missing in the snark is the understanding that comes with grokking something. You miss the message with the literalness.
Lets look at what I mean.
Early and Continuous Delivery
Why would this support providing value to the satisfied customer? Everyone has ideas. The problem with ideas is they sound great because in your brain there are no implementation details.
Those minor issue that you dismiss while it stuck in your brain are the thing that kills a product.
One way to combat that issue is early delivery of small things. That early deliver lets the idea person, the customer, realize that what they want to do will not work or would be better if we did it another way. That hands on, tangibility is crazy valuable to the customer trying to bring their idea to life.
For instance, I have a client that is dreaming on a product. With regular, fast deliveries he can dream further than I can programming it. That dreaming is not wasted. With small deliveries he would become un-grounded from his own product.
He wants a lookup system.
Then he wants a look up system with note.
After that he wants a look up system with notes that can be loaded from an Excel file.
As the ideas churn in his mind, he refines it more and more. Each refinement provides more value that can be delivered. By giving his something to play with, he is able to dream in a more realistic and guided fashion. This makes the product more valuable because he can see what exists and dream off a foundation of concrete rather than sand.
An example where we did not do small, early deliveries was a game we tried to design. The game designer would not stop changing the rules. He rebalanced the game this way, creating new exploits in the process. He literally could not hold focus for more than a week. This is a problem in the waterfall method where everything has to be laid out before work can begin. If we had been using agile back then, we might have had a game out in the market 5 years ago. Instead we got a $500 buyout. A painful underpayment of the time and effort that went into its design.
Both these concepts create the value. They are not the value but they create the value. With these concepts we can then look at the manifestation that sits in the implementation of all this, it is the software. It makes sense since this is programmer-centric in it statement.
Universal Truth of Software Engineering
Another value that is created by early customer exposure is as a developer there is one rule that is universal. You are stupid. You know little to nothing about the customer domain. All your assumptions are wrong.
I’ll give you a second to let that one quit stinging. Compared to someone who makes a living at thing x, you will never really understand it as a consultant. It take time and dedication to get that feeling that your instincts are correct. And it be true.
This was an incredibly painful realization when I started consulting. I know nothing about what I am trying to design. Without early and regular touches to the concrete of code, both the programmer and the customer will float off creating a masterful POS that can never work.
I built one system for an petro company. it tracked the process of sample analysis of petroleum products. It was perfect. It did it well. At its core, it was flexible.
Unfortunately, it was also totally wrong for the domain. They approved every sprint without looking at it. It took too long to play with so they checked out.
When finished, it didn’t actual solve all the problems it needed to because time marched on and new business pressures developed. In a waterfall approach, a March success was an October failure. We needed the system to be able to adapt. The waterfall approach delayed that adaptation and made the project a beautiful failure.
How to execute Agile Principle 1?
First you must keep the project between 20-80 man hours. Do not use days. Do not use hours per employee. Keep it simple. Just how many hours does it take to make. If the system is too big. Work with the customer to get that MVP (minimal viable product). If the MVP is too big then divide it into its subsystems. Get that project small.
Build the system in the time above. After that then show the customer and expand to another 20-80 hours worth of corrections and expansions. Your customer is the subject matter expert. They will know what wrong is in their bones. Finally, Trust in their knowledge to guide you and in return have them trust in your execution of bite sized pieces. You are their hands, not their brain.
In conclusion, this will give you both the flexibility to build the system that will actually work and a happy customer. This is agile principle 1 in action.