One of the fundamental roles in Agile Software Development is that of the “Scrum Master.” At its basic and theoretical level, this person provides a few functions for the team, they are:
- The Chief Impediment Remover
- A Facilitator between the roles of Product Owner, Stake Holders, & Development Team
- The Protector, a buffer between the team and the mountain of crap & distractions that threatens to derail the team everyday
- A Focus & Productivity Facilitator, regularly trying to move the team towards their goals
- A Master Software Organizer
- An Expert in Agile & Scrum Process & Practices (some would say a rule enforcer, ack), and
- A Sponsor of the Team Values – such as accountability, delivery, craftsmanship, etc.
A Scrum Master typically has lots of responsibility, no authority, and is usually held accountable for things outside their control. Often a thankless role, they are frequently regarded as some sort of obligatory project manager; and the reason for those useless meetings, planning, and other lame stuff. A great candidate to get thrown under the bus. A tough task, it’s usually the personality traits and disposition of a person than can overcome mediocrity. It’s not simply training and knowledge about software / project management methodologies, they are someone who:
- Deeply believes in the principles of collaboration, and therefore
- Takes pride in discovering better ways to build software and build software teams
- Doggedly pursues issues until completed
- Focuses on the successes of the individual & team – considered a “Servant Leader”
- Influential throughout the organization
- Is considered a “General Specialist,” with plenty of experience in other roles building software
- Balances their knowledge of technology and the business domain
» for more information: An Overview of Scrum for Agile Software Development
I’ve been around the block in just about every role in the software development lifecycle (I’m not saying I did any of them well). I’d have to say that the Scrum Master is the most challenging. Let’s face it, they get beat up – and that’s when it occurred to me that being a Scrum Master shares a lot in common with some aggressive sports, namely Cage Fighting. Let’s explore that,
- Cage Fighting and Scrum (agile) both use “time-boxes” to produce results quickly
- They both embrace the practice of “responding to change – over following a plan“
- They both “welcome changing requirements, even late in development“
- The both depend on face-to-face interactions
- Both borrow liberally from other sources – but without any rules
- They both rely on having motivated experts
Now that’s a rosy picture that makes it sound like computer geeks and tattoo covered bruisers would make good roommates.
- They both have the illusion of structure and rules
- Even when you “win” you still get the crap beaten out of you
- There’s no way around confrontation if you want to be successful
- It would be an understatement to say that they both have stressful jobs
- There are fouls – but who cares if you gain a point if you get kicked in the nuts
A great Cage Fighter follows a set of personal, experience-proven techniques – and can quickly take down a bigger opponent. A great Scrum Master also follows a pattern of proven principles and techniques that allows him to “take down” a much bigger project than you may think. Maybe they both share a common link of “Pankration,” the original Fight Club established at the Greek Olympic Games in 648BC – a martial art that blended boxing and wrestling with the purpose of killing on the battlefield.
Keep in mind that while both of these disciplines share some things in common, it’s probably not a good thing if you approach your next Daily Scrum with a Cage Fighting attitude.
Unlike SCRUM, it turns out the some form of Cage Fighting has existed for centuries…