Agile Roles for Dummies

Agile Coach, Scrum Master, RTE, Project Manager, what’s the difference?

I am an Agile consultant, or Project Manager, or Agile Coach, or Agelist or Scrum Master, or Lean consultant or Six Sigma consultant or Kanban Sensei, or something else. I have helped companies with their projects and processes for many years and, it seems, every time I go to look for a new position, the names, used to describe my expertise, change. My work has evolved over time but this new craze of defining and redefining people is confusing to me, and recruiters hoping to fill real requirements. Perhaps it's all LinkedIn headlines where a typist is now a digital content transformation consultant.

There has been an evolution of the way we think about projects, even the nature of projects themselves. A project has a beginning and an end. A process is ongoing and can be repeated, improved and executed for as long as we keep it around.

What has happened, at least in the area of software development, is we have returned to a process approach (think iterative development) and away from a project based approach (here are the specifications, now go build it). This is a welcome change but it is hardly a new concept. Think a hundred years ago how you might be greeted if you presented your workers with list of specifications for a product and you get the idea. How we got to the state thinking that a product that does not as of yet exist can be completely specified before we begin is beyond me but I’m glad it’s an idea that is fading fast.

Twenty years ago some software developers got together (on a mountain no less) to bemoan the state they found themselves in. Management would give them detailed specifications of what they wanted along with a fixed budget and a schedule. The only thin they could do was to accept these terms but these fixed constraints were never met. They talked about searching for a better way.

This conferences spawned the idea of creating methodologies to guide management and the burgeoning concept of teams toward a collaborative and iterative mode of working. Of course each of the conference members set up their own consulting firm which developed its own methodology. This is where Scrum, XP or Extreme Programming, Crystal, FDD or Feature Driven Development, SAFe or Scaled Agile Framework, Kanban which is a methodology, philosophy and a tool, and other models came from. Consultants.

The most common team level set up is Scrum and Scrum has a few moving parts. The first is the team which typically consists of five to nine people who work together to move packets of work called user stories from an idea to something called done. The second is the product owner who takes everyone’s ideas, breaks them down into manageable chunks (user stories again) and puts them into order of immediate importance. The third cog is the Scrum Master. This is where the evolution of roles has happened and the source of this naming problem.

In the minds of those people twenty years ago this Scrum Master would facilitate the team to produce artifacts (read completed work and documentation) and conduct ceremonies (think meetings). But the Scrum Master was to do something more, and herein lies the problem. The other thing they were to do was to remove impediments. This could take the form of a reluctant manager, a sales manager who wouldn’t share information about or allow access to the customer, a finance department that would only provide funding in exchange for a big fat and detailed business case, etc. In short, the Scrum Master was to educate everyone in the company on the how’s and why’s of Agile and negotiate changes to the organizational structure to allow Agile to work. This was a tall order for someone who was hired (or promoted from developer) to manage the goings on of seven Java developers. In other words, Scrum Master was asked to perform using two very different skill sets.

Managers and HR people were quick to note that Scrum Masters were causing more impediments than they were solving by ruffling feathers with so managers who had perfectly good reasons for acting they they they were. So, customers, not consultants, invented the idea of an Agile Coach effectively splitting the role of Scrum Master into two. This made a lot of sense. The personality and expertise needed to help management change their ways of interacting with each other doing business is very different than the one to manage technical dependencies or help refine a backlog.

So, the Scrum Master is now two jobs. One, guess which one, commands a much higher pay rate in the market. What is the effect of this totally appropriate pay disparity? Remember, there is no distinction between Scrum Master and Agile Coach in any of the Agile Methodologies. One caveat, SAFe added Agile Coach to its complex and ever expanding role diagram several versions ago.

Well, a Scrum Master who deals with team level activities now calls him/her self an Agile Coach. An Agile Coach, not wanting to be confused with a strictly team level facilitator now calls themselves an Enterprise Agile Coach. Companies, looking to hire a Scrum Master now call them a Team Level Agile Coach and so on. 

One more thing, each of the methodologies I’ve mentioned have a slightly different definition of what a Scrum Master is and how they fit into their framework. No wonder these names all blur together.