anchor.diff:  
   I think it is better to talk about actions and situations:
   
  -**Situation #1.** You look at your task in Trello, Jira or any other kanban tool like you use (because the **tool should not matter** remember?), code it, commit it and more the card to the next stage on the process and feel satisfied for the job well done. So smooth...
  +**Situation #1.** You look at your task in Trello, Jira or any other tool that you use to manage tasks (because the **tool is not important** remember?), code it, commit it and move the card to the next stage on the process, then you feel satisfied for the job well done. So smooth...
   
  -**Situation #2.** The Scrum Master of your team calls for the daily meeting and you basically present yourself at it feeling like how this is a waste of your precious time and how this will compromise the delivering of your work (yeah I know!), don't really listen to the others talking and talk about a report of the all tasks that you finished the day before and how awesome you were. Then you just rush back at your computer and you successfully remembered whare you stopped.
  +**Situation #2.** The Scrum Master of your team calls for the daily meeting and you basically present yourself at it feeling like how this is a waste of your precious time and how this will compromise the delivering of your work (yeah I know!), don't really listen to the others talking and talk about a report of the all tasks that you finished the day before and how awesome you were. Then you just rush back at your computer and you successfully remembered whare you stopped. Success.
   
   **Situation #3.** At the Sprint Planning meeting you notice a task that can be much bigger than the what the team and keep quiet so you don't look incompetent in front of the Product Owner. Now you're safe.
   
  -**Situation #4.** You are the P.O and the developer starts talking about his problems with the automatic testing and how this cannot be avoided, so you take your Smartphone to look at the news, after all you are not concerned on developer problems, your only concern is when it will be ready.
  +**Situation #4.** You are the P.O and the developer starts talking about his problems with the automatic testing and how this cannot be avoided, so you take your Smartphone to look at the news, after all you are not concerned on developer problems, your only concern is when it will be ready. Then you leave the meeting with the set of tasks to be done and a deadline.
   
   Looks familiar?
   
   So, surprise! **You are not being Agile!**
   
  -Everyone in an Agile Team has communication as a priority. 
  -That means that everyone has to **talk about anything that can affect the project** at any level and do it clearly but most of all, if you at the at the listening side of any conversation - be it im a meeting or in a one-to-one conversation - **it is your obligation to listen very carefully** to everything that is being said.
  +Everyone in an Agile Team must have communication as a priority. 
  +That means that everyone has to **talk about anything that can affect the project** at any level and do it clearly butm most of all, when you are at the listening side of any conversation - be it im a meeting or in a one-to-one conversation - **it is your obligation to listen very carefully** to everything that is being said.
   
   As hard as it looks like, we basically have to talk about what we're doing, what we're building and what we're thinking and we must listen when anyone talks too.
   
  
positive.code: 
  Before anything it is important to note that Agile Software Development includes several development methods that share a **set of principles**, so there is no "one way" of being Agile.
  
  So, we need to focus on this set of princiles stuff to understand what exactly means to be agile.
  
  Lets look at the agile manifesto (yeah, again):
  
  
negative.code: 
  That's so cool right? We can now trash everything that we hate about project management: processes, documentation, contracts and plans and start doing what is really important.
  
  We all know that this is wrong, Agile is not about no planning, no processes and tools, no documentation and no contrct. Is about keeping plans, processes, tools, documents and contracts to the minimal necessary. But let's not focus on that, I'm sure everyone already read about it somewhere and knows how this boring stuff is still important on an Agile project.
  
  But let's say that we somehow could avoid completely the boring part.
  
  We would still have the left part, the important one, to be reaaaly good at, otherwise we would not be Agile, we would just not do boring stuff.
  
  So, let's look at them with a little more care.
  
  