For example, it’s never made sense to me to have a powerful product owner while treating the development team as N interchangeable workers who may have “areas of focus” but have no roles, responsibilities, or organization among themselves, smearing out any sort of power or responsibility for technical quality like butter spread on toast. And yet, the fact that Scrum says to do it makes me wonder if that’s why everyone does it. Reading Scrum’s idea of a development team made me facepalm.

I don’t think the article is attacking a straw man that Scrum can turn a bad team into a good one. It may be pointing out that Scrum is regularly used to turn a good team into a bad one. Because everyone wants to be “agile,” even if they never use the word Scrum, they are implementing bad Scrum or cargo-cult Scrum by default.

What it really means is, "I'm not really responsible for making deadlines anymore."

As SM, it's my job to ensure that not only will the PO listen to concerns from the team, but the team feels empowered to provide that criticism. If neither of those happens, I've failed.

A bad PO will RUIN a team. I've seen them do just what the blog entry claims. I've also worked with POs who don't do any of the bad things claimed.

I think the main issue is that people are doing scrum wrong, applying traditional management to an agile process.

For example, Scrum says responsibility for operations and testing are to be shared responsibilities; you don’t have an ops team or a testing team, or titles, or recognized responsibility. You might have a de facto ops team, but those are just some individuals who have chosen to carry pagers right now. I’ve seen things like this play out and been puzzled by it. I didn’t actually realize until reading this article that people have been giving talks and writing books saying that “subteams” are bad, but it makes sense now.

The point being, not having officially recognized responsibilities is a form of disempowerment.

I feel like that's a bit of an overstatement. While scrum advocates for shared responsibility, it doesn't demand no-titles, no-roles, or no-passions.

It's all about ensuring the entire team possesses 'T' shaped skills. Depth and expertise in some areas, but still generally knowledgable across all areas. My test engineer doesn't write much code, but in a pinch, she can. My PO is fully capable of "running" the team in my absence, as is the test engineer. All my developers know the full DevOps pipeline and can contribute to it, though none of them are DevOps engineers by title or primary responsibility. And I'm an ex-developer-now-manager who can do a bit of everything, though these days I'd rather go to meetings and play office politics so my developers can do their thing.

Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing, architecture, operations, or business analysis

Maybe T-shaped people are required to make Scrum work, or vice versa? Like if you are running a restaurant and your company process says “there is no distinction between waiters and chefs,” then your waiters need to be decent cooks, and your chefs need to be personable and presentable. “Passion” can be a liability in this environment, for example being passionate about great food or great service. The lack of specialization doesn’t seem directly related to how to do great work, or be really happy at work.

I recently quit a job because I was the only one on the team "capable" (or that felt confident/comfortable) saying "No."

As a "devops" (loosely defined on our team) I felt my focus was uptime and error rates which sometimes is counter to new features (what managers want)...

Then it's no longer Scrum, correct?

This assumption starts with one of the earliest Scrum pioneers, Jeff Sutherland. He writes quite clearly that he doesn't care about an individual's performance, but rather a team's performance. He also talks at length about how poor performing teams can be turned into high performing ones by the implementation of Scrum.

You can agree or disagree with him on this (I'm on the fence), but it's not at all weird that this idea is found within Scrum. It was there from the get go. It's there by design.

That is my key beef with Scrum here. I entirely agree that done well Scrum can be effective. But how it is often done is not well at all (e.g. the two day Scrum master training course.)

I'm criticising Scrum as it's widely implemented and how that is poisoning the groundwater for all agile methodologies.

And definitely I'll get on to how other processes can be better.

Same. This process takes work, requires buy in by all levels of the company and needs to be fully understood including its error cases. It takes time and requires course correct and attention. Its not easy but done right it is effective.

That is one of the problems highlighted in the article though, too. What is the appropriate level of training for a scrum master and scrum team? Should we read the Scrum Guide? Are we reading the Scrum Guide? Do we actually know what Scrum is? Do we even know that we are doing Scrum?

I am working on a young, small team, and we started with an expertly trained scrum-master about 30 sprints ago. She was so well-trained that she was promoted out of our team. Since we started, we've had about 72% turnover.

I'm the only original member of the team who is still on full-time except for the product owner... and reading this article, I am coming to find out that our product owner is not doing the job of product owner (mostly our new project manager is.)

And

> apparently it has to involve something called “Jira”.

hits me right in the feels! We have been working with one project management tool (not Jira) since the beginning, and we found another tool that we like (the dev team likes) better.

Doesn't matter what the tools are. Bear with me. The first tool is used to communicate with our product owner(s) or stakeholders, where we get their acceptance of stories, and the second tool was meant to be a place where we developers can own tasks and "blog" about our progress without adding noise to the stakeholder channels. A task list that we control. Again, neither tool is Jira.

We did a trial, and we quickly found by consensus of opinion and observation that it really helped us a lot to add this tool to our process, all of the developers were buying in! Brought it to management to get it added in the budget... really a nominal sum, but then we were told we had too many tools already and made to abort the trial.

I was devastated, but I played along. It was the wrong decision! I started using slips of paper to fill the void, a place where development issues that are not part of our product backlog can live outside of the backlog and the sprint, and now in my perception at least, we're more disorganized than ever as a team.

I believe you both, that Scrum can work well if done right, and I'm glad it's working well for you, but ... I think at least some of us definitely need to hear these stories, many of them are our own stories, properly articulated so we can understand what's going wrong in our teams.

As for training for the SM (or PO, or anybody else), it's a continuous process. The CSM is a starting point, a basic level of understanding. At my office, many of us have gone on to take the Advanced CSM course. Most of us attend meet-ups, conferences, etc. It's not a once-and-done thing - nothing in a professional career ever is - if you aren't learning and improving every day, you're not doing your job.

"72%" is really misleading... from the original team of 2 developers and one PM/Scrum-Master, the Scrum-Master was promoted to a newly formed team, and the other developer is still with us, but in a mostly consulting-only capacity, as she is focused on other projects in our team.

Nobody is quitting out of frustration. (Not yet anyway!) We've since added two new developers from other groups within our organization, and a new PM.

We're talking about a greenfield project with some inherited/appropriated/shared code from other projects on our (slightly larger) team, a mostly new dev effort, and we're approaching year 3 of development.

For a dev team this small and a project of this scope and duration, I feel like this is almost an appropriate level of turnover. We have to strike a balance between spreading the domain knowledge around, and keeping the expertise near the "most important project," which is obviously the particular one that we're working on. (/s) The big problem is training, or lack of... the SM that left our team was practically the only one of us with any formal training in terms of either development skills or Project Management. The rest of us have learned basically everything "on the job."

We've been exposed to some training opportunities for "business analyst" skills development, which is our organization's take on a little bit like "Scrum-lite" but I am not sure that's for all of us. (I'm working in higher-ed so there are a lot of training opportunities in-house. Just not sure they are the right ones. Most teams in our building just aren't doing product development, so we are special snowflakes.) I've taken some of those BA classes. We really need more technical training. We probably need a larger team too, but hiring is very difficult for us, and in reality I think we're going to have to cope with more of our team members being poached by other departments as we become more successful.

Some members of the team have participated in bootcamp-style training courses for our chosen framework. In every case, it was years ago, some time before I arrived on the scene. I have not had any of this, just some prior on-the-job experience and also have read a book or two to pull myself up by bootstraps! We're all learning on the job, and we have a conference budget so we're getting exposed to plenty of new ideas each year, but that's nothing like a formal training day where we all hammer a particular skill until we all get it, or even a sprint that's dedicated for training.

Second major problem is that we also usually don't have sprints or stories devoted to addressing technical debt. No refactor stories, basically ever. Basically all story cards must be customer-facing and represent some new, testable functionality for some functional user of the product. This part of the article also struck me as poignant:

> The items promoted in the backlog, combined with the schedule pressure set by the product owner and the business mean that the Development Team often are told how to create releases: quickly and exactly how we said. The lack of technical craft or development control means each sprint is launched as soon as possible rather than as soon as prudent, refactoring isn't done, and technical debt builds up, eventually choking the product.

When every story is a feature story or bugfix, this is what you get. When the team says "we need to learn this skill first, so we don't add unnecessary technical debt in the next sprint" and are overridden by the PM's boss and told to stick to the planned release timeline at all costs, we lose.

> As mentioned above, the lack of titles or specific responsibilities in the development team means no-one is empowered to advocate for development priorities, and also contradicts the typical implementation where there certainly are titles and hierarchies within teams

... exactly this. We're told that the development team as a whole is accountable for progress, but when everyone is responsible, nobody is. You can't call someone a technical lead and then confine their decision-making to minutia within the already-planned sprint work. That's not really how I feel about my team, but I feel like sometimes circumstances put the pressure in that direction.

This is getting too personal, but suffice it to say I really agree with this article about a lot of points.

Yeah, lack of buy-in from senior management is probably the biggest single problem with scrum, any other agile framework, and probably even non-agile frameworks.

Interesting that you're in higher ed. I am as well, thought it sounds like you're at a college/university and I'm at a software company selling into that market.

Just goes to show that wherever you look, you're going to find problems.

What is a manager but someone who has control over the controlled? I'm surprised with so many ppl nodding their head at this list of complaints about bad software processes at bad companies, masquerading as analysis. If you think it takes more than 2 days to learn _how_ to be a Scrum master, you don't understand the role. It's not complicated, difficult, and time-consuming enough to require a singular employee...unless your process is already screwed up. Good luck finding whatever magic bullet you think will save you that isn't Scrum-based teams.

Another way of putting it is that there are many good ways of doing project management, as many good ways as their are unique (team, circumstance) pairs.

Most people have an intuitive understanding of why some very low-overhead, low-formalism, "just get stuff done and be reasonable" workflow has worked really well in some specific (team, circumstance) combo situation.

If you want them to override their experiences with how those ad hoc, customized management processes worked well, and instead believe that a company-wide, one-size-fits-all approach that removes tons of workflow autonomy that could just be left up to separate teams to customize for themselves, then you absolutely have to have extremely convincing answers to address widespread bad experiences.