Or rather, not so much "non-coding" as "never-coded".
I came across this phenomenon during a recent brush with "Enterprise Agile".
In particular, the notion of "Agile", or more specifically "Scrum" as a skill distinct from software development, was an entirely new one to me.
This notion has given rise to individuals, and indeed teams of individuals, who are entirely conversant - and expensively trained, by "boutique" consultancies - in the terminology and rituals of Scrum and its "Enterprise" cousins - stand-ups, grooming, planning poker, retrospectives, release trains, the all-important "velocity", the list goes on and on.
However, these same individuals are not at all familiar with the daily grind of merge conflicts, broken dependencies, technical debt, and off-by-one errors that make up the life of a modern software developer, as their training and experience is purely in "Agile" and "Scrum", to the exclusion of any considerations relating to the actual writing of code.
In many ways, the "Agile Capability" has come to resemble a tight-trousered, plaid-shirted version of the venerable Project Management Office, or "PMO", with its colourful "information radiators", issue-tracking spreadsheets, and remarkably granular organisational structure - "Junior Product Owners", "Product Owners", and "Senior Product Owners", anyone?
In the interests of disclosure, I should perhaps state that I myself am a Certified ScrumMaster® , a by-product of having attended Jeff Sutherland's course on Scrum a few years ago.
One of the many interesting things he pointed out on that course was that when they were codifying what we now call "Scrum" back in the 1990s, they never envisaged that "Scrum Master" would become a job title. Now, in 2018, it seems to have transcended the job title and become an entire career path.
Is it just me who is a little sceptical about all this, or is this the way of the future?
Top comments (8)
I don't think you have to know how to code to manage people who code. In fact it's arguably an asset -- it removes the temptation to jump in and fix things yourself. You do need to understand the process and establish mutual trust with your team so they can help you get your head around the technical issues they encounter and in turn organize things to help them avoid those problems in the future. But you don't need to have written code to know what a merge conflict is or how technical debt impacts team velocity.
The single best product manager/scrum master/whatever you want to call it I've ever worked with didn't write a lick of code. He understood his job was to facilitate the development process and relied on us to help him understand what worked, what didn't, and how to keep things moving forward.
I don't think you have to know how to code to manage people who code.
Interesting. I'm not sure the role of the scrum master as originally envisaged involved managing the people.
Maybe this is something else that has changed over the years.
Maybe using "direct" instead of "manage" would have been clearer. I'm not talking about where people are on the corporate totem pole.
Good point, but for me, this seems pretty normal.
I am myself a Scrum Product Owner and Project Manager and I am one of the very view Product Owners who can code. And I know a lot of Scrum Masters who cannot write a single line of code, even do not understand what a variable is.
For me, a Scrum Master is a coach and the main task is to ensure, that the scrum process flows and the scrum team can work without impediments. And most impediments are not of technical nature I think, but more a problem of processes, psychology, social components and over all wrong business objectives. Of course it depends heavily on the individual situation, of the team and the company, but in most cases, technical skills are not required for a Scrum Master in my eyes.
But anyway, I think Scrum is not the only key to improve software development. In my eyes, interdisziplinarity is more important and pretty underrated. In publishing companies there are sometimes job descriptions like "editorial-dev" and the task of this job-holder is to mediate between editors and devs. Not the topic of this post, I know, but I would always vote for interdisciplinary teams of devs and non-devs and more communication between them ...
Yes, I share some scepticism about Scrum as the cure for all evils, but let's put that aside for the purposes of this post. In fact, one of the other takeaways from that course was that given a sufficiently effective team, the much-debated differences between competing "Agile" methodologies don't really amount to much.
Agile is an idea that originated for software development but can be easily adapted to other types of teams. If you take the Agile Manifesto and its principles, only a few reference anything related to software. Any team, be it a software, marketing, or finance team, could benefit from focusing on individuals and interactions over processes and tools; on customer collaboration over contract negotiation; etc.
One of the functions of the Scrum Master is to be a change agent for the organization to adapt to a different way of software teams do their work. After your software department matures in agility, other departments become impediments (I'm looking at you, finance department, and your budget-requesting process). The SM role includes helping other teams to also be agile. After that, the whole organization can become agile.
So you agree that any work environment that is not "focusing on individuals and interactions over processes and tools" is not practicing Agile Scrum, but another form of Project Management or something else entirely
My view is that it's just like the old job titles like "project manager" or "program manager" minus the "manager" title part. This eliminates direct reports and other HR-ish manager duties (hiring, firing, etc) along with a matching reduction in pay.
I think it helps if your organization has the budget to hire someone to do things like managing project workflow, dealing with Jira or whatever, insuring meaningful user stories and epics are put together and so forth. It's easy for a developer to get overwhelmed by this if they have to do this in addition to regular coding duties. Of course, this depends on the size of the project.