A developers review and small changes to the 12 principles of agile.

Feel free to disagree with my opinions in the comments.

I have researched agile and similar methodologies over many years trying to find the best and easiest way to develop my apps. This comes from my laziness and priority to have a stress free experience as a developer.

Priority

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

The first principle is pretty straight forward and I really have no complaints here. I do want to bring attention to two parts; continuous delivery and valuable software.

I really think these two points are so easily forgotten once projects get started and overwhelmed with feedback and users. It is very easy to fill a kanban board with stories but very hard to find that one that adds the most value.

Overall I wouldn't change this principle much.

Revised

Our highest priority is to satisfy the customer
through early and continuous delivery of a valuable product.

I simply changed software to product, which just opens the door for non-software products to use these principles.

Note: This will happen throughout these posts.

Requirements

Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.

This principle comes as a direct comparison to waterfall methodologies.
Simply put, instead of taking all the requirements at the start of the project and keeping them until the end two or three years later, we want to allow changes at any time.

Unlike more complex methodologies like scrum or kanban, agile at its core does not suggest how to go about accepting these changes.
Therefore, it is up to us ( more accurately our team ) to decide how we go about welcoming these changes. ( This comes back to the core manifesto )

The second part of this principle speaks to the advantage of late changes. In that, if you create requirements and then develop for two years your requirements are now two years old. The market could be totally different by then, which would put our customers behind the curve.

Revised

Allow changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.

I again only changed one word, this time Welcome to Allow.
The reason is subtle, but changing directions is costly.
If a project manager sees a blog post from Github and suddenly wants to change everything that could be amazing for our customers.

But, it could also mean six months of redesigns and team changes.

So, instead of simply welcoming changes we allow changes that have been researched, fit our team, fit our product and add the most value.
Obviously, the specific rules will vary from team to team, but no rules create an atmosphere that churns out team members and causes high levels of burn out.

Delivery

Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.

Basically continuous delivery, which has grown into an entire industry on its own.

Revised

Deliver a working product as often as possible.

This was just a matter of scale, back when the manifesto was created teams would only deliver once at the end of years. So, for them once every few months was a big jump. Nowadays, delivering multiple times a day to production is possible.

Of course, it's not all sunshine and rainbows, so just deliver as often as you can.

That is all for this first chapter. Thank you for reading.