Scrum Managers: are they the worst?

State of Practice: Scrum

I participate in a number of forums where I am happy to help people understand agile methods and practices. I see dozens of questions every week asked (and often answered!) by people who are operating in a system they simply don't understand.

For instance, one very well-intended manager called a meeting with HR and consultants and leaders of teams to decide what a scrum master's duties are, and what a PO's duties are. Only the consultant had ever read the scrum guide; the rest were going to invent roles to match their current job titles. Not understanding that people can rotate roles (and roles can even evaporate), the HR wanted to make the roles have specific meaning benefit-wise and hire specifically for some of those roles.

In an online forum, a manager asked "since release schedules are fixed, how do you make up for slippages in sprints." This belies that the project plan was a big-project plan (BDUF-style) divided into sprints.  The premise behind the question is non-agile.

I am a consultant, and my clients often have a scrum-ish implementation they're trying to bootstrap, or re-bootstrap, or re-re-bootstrap. Often they reach a state I call "compliance scrum" they may never make any real improvement whatsoever in their quality or productivity. They frequently "optimize out" retrospections after the first few sprints.

They accept the earliest plateau as the limit of the process. It is probably worth noting that no agile method describes a final end state; they are all about continuous improvement forever.

Shallow adoption of scrum leads to people basing their work on a sound bite from a page on a slide, or some word-of-mouth from a manager who has an employee who once attended a conference talk. They tend to feel that is enough exposure to be able to lead because doggone it, they're busy.

As a result of the process being sold to management and adopted by decree, many scrum practitioners are operating from obligation and compliance. That's not how the process is supposed to work, but it does drive adoption and sales.

Sadly, a similar fault is present where people become certified scrum masters in order to get certain kinds of jobs, not because they use, understand, and value the process. It is me-too-ism at its worst.

This is different from XP shops.

State of Practice: XP

XP practitioners tend to have read XP Explained and XP Installed and a few of the other very good (and surprisingly short) books by Jeffries, Beck, etc. Many of them have read other books about managing and agility as well, like Shore & Warden''s Art of Agile Development.

I suspect it is because XP people tend to be interested in programming in a new way, curious about the lessons learned and techniques developed, and typically more involved in choosing their process for themselves.

Of course, there are far fewer XP shops, because people opt-in instead of being pushed in. It is not sold to managers, doesn't have dues, and doesn't have people who don't understand it selling it. It is quite intentionally a process, not a product.

So What? 

I'm not saying all scrum projects and practitioners are ignorant hacks. Sadly, however, I find that many people "doing scrum" are woefully undereducated and disinterested. I think this is a correctable problem which occurs naturally enough, not a personality or character fault.

The biggest issue facing scrum teams I meet is merely that they don't understand the axioms of the system they're operating. This is easily remedied.

Three Easy Steps

Read something. I have given four good links on this page. Read the XP materials even if you are doing scrum. These books are all quite small (The Scrum Guide is about 16 pages in a free pdf file, XP Explained is under 250 pages, Art of Agile Development is the largest at 389 pages).  You don't have to read any of them in a single sitting.

Know the manifesto. Read the manifesto. Read the principles. Don't ask questions in forums about how to most effectively violate the principles and values. Instead ask your company how you can adopt these more fully.

Finally, stop trying to not be involved in the process you're using. If you're going to do it, do it all the way. The indecision of being half-agile is going to ruin your transition before it has a chance. Jump.

Want some help?

At Industrial Logic we are well-acquainted with many agile methods, including Lean, XP, Scrum, and Kanban we can easily teach them all.  Our people are pioneers with long and deep successful experience in both practicing these methods and teaching them. 

If you need some training or a short-term coach, we can show you how we do it and we can tailor your approach to give you quick results.