anchor.diff:  
   This is looking like a mexican novel already, right?
   
  -### Customer collaboration
  +## Customer collaboration
   
   I can almost feel the big "sight" coming. Yeah, you have to collaborate with the customer, even if he understands absolutelly nothing of techology and coding.
   
   I will just cite a few situations, but I absolutelly KNOW you are already thinking about tons of them:
   
  -**Situation #1.** The customer was very specific on some features he believes as critical and won't sign a contract unless you add these features to the contract, but he likes the term Agile so he also wants you to use it in his project. You know this is not the best scenario but agrees with it and sign the contract.
  +**Situation #1.** The customer was very specific on some features he believes as critical and won't sign a contract unless you add these features to the contract, but he likes the term Agile so he also wants you to use it in his project. You know that talking about features on the contract is not the best scenario but agrees with it and sign the contract with the intention of proving the customer how wrong he was. The project fails miserably.
   
  -**Situation #1.** You developed a beautiful code, full of patterns and well named variables for a feature that the customer now wants off the product. You actually agrees with it because that feature is almost never used by the users. The problem is that you didn't plan for it be remove so, right now, it is ultmost difficult because one of the patterns that you used here is used elsewhere and it is too much coupled. So you come up with difficult terms about how this could compromise the product and convince him that this feature must stay as it is.
  +**Situation #2.** The customer wants to implement a feature that is nowhere near the current best practice in UX for the product platform and have nothing to do with it's value propostition. You try to argue a little bit on how this can be complex and won't add value to the product but the customer seems irredutible. You give up knowing that the project will take at least a Sprint more without adding real value to the user, but since the money is coming from him, that's no big deal.
  +
  +Guess what? **You are not being Agile!**
  +
  +Customer collaboration doesn't mean to do everything the customer wants. It is about using your expertise to help on the improvement of his project. Sometimes it means to have harsh conversations with him and prove your point, remembering always that what you're doing is delivering real value to the user, not to inflate the ego of yourself or the customer.
   
   The thing is, the Team (and by Team I mean every human on the Team), must have close contact to the end customer (a human too!). Everyone must understand the why's of the product you are building and for who (humans again) you're building and finally who will actually use (surprise, more humans) what you're building. There is no espaping that, no matter how we try or how we would like it. If you want to be a sucessful team member, you must collaborate with the customer at every level. So you, as a human must collaborate with other humans.
   
  -### Responding to change
  +## Responding to change
   
   This is one of the most beautiful things on paper, because everyone knows that things can change overnight so a 12 months  project is just a thing that will have exactly 365 opportunities to change and this cannot be avoided.
   
   But what is your Team doing to be responding fast o changes?
   
  -(Situations)
  +**Situation #1.** You developed a beautiful code, full of patterns and well named variables for a feature that the customer now wants off the product. You actually agrees with it because that feature is almost never used by the users. The problem is that you didn't plan for it be remove so, right now, it is ultmost difficult because one of the patterns that you used here is used elsewhere and it is too much coupled. So you come up with difficult terms about how this could compromise the product and convince him that this feature must stay as it is.
  +
  +Altogether now! **You are not being Agile!**
   
   So, basically, we need to be flexible and build flexible software.
   That means that everyone in the team must never twist their nose on changes. They must embrace it.
  -This also means to create modularized (so we can change only what is needed), unit tested (so we can be confident to change it) and beautiful code. Because everyone on the team will work on it during ltos of hours, so it is really important that the code is pleasant to work with.
  +This also means to create modularized (so we can change only what is needed), unit tested (so we can be confident to change it) and beautiful code (so everyone actually wants to work on it).
   
  +## What to do next?
   
  +I believe that if we train our Agile behavior - working on our communication skills and how to suppress our egos, reminding to deliver real value to the end user at all times, focusing on building things that we are really proud of - we can lead software projects to success.
   
  +The Agile Way is not so obvious like we would like and sometimes we will have trouble convincing people that this actually deliver more results than the PMBOK-like management, but it is our job to find ways of doing it.
  +
  +Happy Agile training.
positive.code: # Agile methods and where (not) to find them
  
  Being Agile is popular these times. But what "being Agile" really mean for us, as software people?
  
  ## Definitions, definitions...
  
  
negative.code: 
  So, let's look at them with a little more care.
  
  ## Individuals and iteractions
  
  This means we have to communicate and interact with other **people**. Yeah, people.
  
  