I was reading Agile Manifesto Principles. Everything seems clear and reasonable except for one point:
Simplicity--the art of maximizing the amount of work not done--is essential.
I dont understand this. Does this mean that the work that wasn't done should be somehow exaggerated? If so, it doesn't really make sence.
Remove the parenthetical comment. What remains is "Simplicity is essential", which by the way is an application of the principle to its expression itself.
Simplicity is essential, because you have distilled what you really need, removing what is making the task at hand heavier, less elegant: complex.
I have always interpreted in the sense of Pascal's take on brevity: "I would have written a shorter letter, but I did not have the time." You have to avoid what is unneded (from the letter, from the code) and this is an active task, and not an easy one. It is not something which happens by itself.
The idea is to avoid doing work that's not necessary, i.e. "maximize the amount of work not done".
So if in a traditional project you would plan and build a great abstract base system to allow for all your possible needs later one, you just skip that and build the simplest thing that can possible work for the current requirements. Don't build stuff that you don't need.
YAGNI is a related concept.
We used to call this "gold plating". The requirement for a hammer is that it can bash a nail into a piece of wood. It doesn't do the job any better for being a gold plated hammer.
Many times a developer would suggest using a new cool framework or adding features which though cool were not necessary. We would note this idea down, but for this version we won't do it. We will maximize the work not done. It is hard enough to deliver software on time, so don't deliver any more code than you need to. If it needs to be done, eventually it will get in the plan and be done at the appropriate time.
This idea is very similar to a concept from the Toyota Production System (TPS), which led to the more generic Lean Manufacturing and then the application of those techniques to Lean Software Development. The TPS significantly predates the agile movement, with its roots in manufacturing in the late 1950s.
The concept of maximizing the amount of work not done is similar to eliminating waste. In the manufacturing environment, waste includes things like overproduction of goods, waiting for resources, unnecessary movement of people or products, too much inventory, and defective products. In Lean Software Development, these wastes were translated into unnecessary functionality, delays in the development process, unclear requirements that slow the production of software, a lack of testing, and communication delays.
The overall idea of both concepts is the same - things that don't add value are wasteful and should be minimized. The ultimate goal is to increase quality while reducing time and cost to produce.
We apply this to code. Don't create needless abstractions, don't write code for hypothetical scenarios. If you don't need it, don't do it. If you need it later, do it later.
This applies just as much to processes. Are there things the team does because the team always does them? As an example, does the team create documentation no one ever looks at?
Regardless of what you do, ask what bad thing would happen if you didn't do it.
If there's a good reason backed up by evidence or experience, do it. If there's not, don't do it.
These are not good reasons:
That's it. Agile gives you permission to stop doing things you don't need to do.
