Agile should never be applied 'by the book', every team is different. Agile works best when it is...actually agile. Moulding and fitting a team of varied individuals with enough compromises to make them all work together better.<p>That's why Agile boards can be lists, or Kanban, or cards, etc. That's why there are dozens of task estimation systems from points to T-shirt size. You find the one your team vibes with the most, and you run with it.<p>I've worked within several project management systems now and Agile has been the best of the bunch when it has team buy-in. It's limited to teams that have can safely predict their workload ahead of time (i.e. agencies can't predict client requests so they can't run Agile, i.e. helpdesk, marketing teams, etc). But development teams can thrive on the structure, tools, and problem-solving workflows Agile hands to its users.<p>Just don't buy into the cult of dogma and strict adherence that the sits on the extreme end. That's either coming from someone who is selling Agile consultancy/certifications, or it's a user of Agile who fits the process personally in every way but can't see why others may struggle with aspects (lack of empathy).<p>A scrum master for 10 people isn't crazy. But scrum masters are hit and miss. Their job is to make agile work, some take that to mean drilling in the dogma, others take it to mean bending the rules responsibly. I've seen SMs who are totally superfluous, and ones who truly add value like a good PM. Personally, I'd avoid an SM if the managers can handle project/product management well enough already.