# Agile Manifesto

## About

* <mark style="background-color:yellow;">Individuals and Interactions</mark> over processes and tools.
* <mark style="background-color:yellow;">Working software</mark> over comprehensive documentation.
* <mark style="background-color:yellow;">Customer collaboration</mark> over contract negotiation.
* <mark style="background-color:yellow;">Responding to change</mark> over following a plan.

## Agile Mindset

Not explicitly presented in the agile manifesto.

* <mark style="background-color:yellow;">See setbacks as LEARNING OPPORTUNITIES</mark>.
* Adopt
  * <mark style="background-color:yellow;">SHORT DELIVERY CYCLES to be able to do rapidly</mark>,
  * <mark style="background-color:yellow;">COLLABORATION between business and technical</mark>,
  * <mark style="background-color:yellow;">AND CHANGE, handle changes not seeing them negatively</mark>.
* <mark style="background-color:yellow;">Focus on DELIVERING VALUE, what the customer needs</mark>.

We focus on these thing, and everything else is waste.

## Agile Values

<mark style="color:red;">**Individuals and Interactions**</mark>**&#x20;over&#x20;**<mark style="color:blue;">**processes and tools**</mark>

<figure><img src="https://3254186584-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FA9AaxvoNFpTEwZ12nTvp%2Fuploads%2F6Qx6p1zrS0jYLIN8EUOT%2Fagile-values-1.png?alt=media&#x26;token=8f735307-2c57-4b7a-8d95-671e183b564c" alt=""><figcaption></figcaption></figure>

All of them are touching some part of the elephant and thinking something, but they are all wrong.\
But if they share their knowledge, they will most probably guess the correct think.

This is a analogy of a complex problem.

* A massive problem to be identified.
* People with different set of skills, experience, view points.

And <mark style="background-color:yellow;">only working together they can work efficiently</mark>.

<mark style="color:red;">**Working software**</mark>**&#x20;over&#x20;**<mark style="color:blue;">**comprehensive documentation**</mark>

<mark style="background-color:yellow;">Remember IKIWISI, if the problem is complex, the customer needs to see something tangible</mark> so they can have an authentic experience using it, and give back their feedback.

<mark style="background-color:yellow;">So focusing more on delivering the product, and less on documentation</mark> also increases our responsiveness to change.

<mark style="color:red;">**Customer collaboration**</mark>**&#x20;over&#x20;**<mark style="color:blue;">**contract negotiation**</mark>

We don't know precisely what the customer wants. Thus we need them in our side, to help build the right product.

<mark style="background-color:yellow;">The idea here is having the customer as part of the team.</mark>\
But must require good faith and commitment from both parties.

<mark style="color:red;">**Responding to change**</mark>**&#x20;over&#x20;**<mark style="color:blue;">**following a plan**</mark>

Close related to values 2 and 3.\
We present a working product to the customer, they see it, touch it, uses it, and gives us feedback. (Collaborate with us)

<mark style="background-color:yellow;">This feedback might lead to changes in the original plan, and then we respond and change.</mark>

**Conclusion**

<mark style="background-color:yellow;">The important thing, is that you must VALUE more the thing in the</mark> <mark style="color:red;background-color:yellow;">left side</mark><mark style="background-color:yellow;">.</mark>\ <mark style="background-color:yellow;">But you also do the things on the</mark> <mark style="color:blue;background-color:yellow;">right side</mark><mark style="background-color:yellow;">.</mark>

***Being agile is not an excuse for not doing the things in the\*\*\*\*&#x20;**<mark style="color:blue;">**right side**</mark>**.***