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: 
  Let's go to the situations:
  
  **Situation #1.** You completed all your tasks in the Sprint a little earlier than expected and everything works fine at when you merged to the master branch. You noticed that are still a few tasks being finished so you go home early to preserve energy fot the Sprint Review next day. When you arrive, you see that one of the features that you implemented turned up broken by one of the latest commits and there will be no time to fix it before the meeting. You look angry at the team and wonder how they would survive without you. The software broke at the Sprint Review, but it wasn't your fault so you internally blame the commit author who did it.
  
  **Situation #2.** During the the Sprint Planning you look at the Spring Backlog and the Increment look so small that you feel that you can push the team a litte harder, you don't really remember all the tech talk but just feels like they are being overcareful. So you convince the team to add a few more tasks to the Sprint because of the tight budget hoping to see thenk working harder, this way you could show the investors how fast you were. The sprint fails because of a bug that prevents the user to sign in. You look at them with reproval eyes and hope this makes the work harder.
  
  **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!**
  
  
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.
  
  