anchor.diff:  # 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?
  +More than that, are we actually acting accordingdly to the Agile principles?
  +
  +In this article we will try to understand and reflect about some of our day-to-day situations and analyse if we're doing it the Agile Way.
   
   ## Definitions, definitions...
   
  
positive.code: 
  This is looking like a mexican novel already, right?
  
  ### 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.** 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.
  
  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
  
  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)
  
  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.
  
  
  
  
negative.code: 
  **Situation #3.** The Sprint ended up too big and the team is overworked with the features, you call the team and suggests to remove automatic testing from this last tasks so we can deliver on time. The team agrees and the sprint was a success, but on the next Sprint you couldn't convince everyone that the team should take less tasks this time. The team ended up developing lesser tests and, after 3 Sprints, the code starts brake at almost everywhere, so now you advise for a "Unit Testing Sprint", the problem is that the code created with no test has to be refactored and it should take at least 2 Sprints and the budget can't handle it. The team will have to do it in 1 Sprint only, making you call an internal "I told you!" and think on how awesome it would be if they listened to you for a change.
  
  Believe it or not... **You are not being Agile!**
  
  Everyone has to be concerned on having a stable software after every increment. Your good individual work means nothing if the product increment does not run. Fitting more features means nothing if the team has to neglect testing hoping the bugs doesn't get found by at the Sprint Review.
  
  