Category: Dark-Scrum

Perhaps the biggest mistake in XP and Agile ...

One 'reason' why folx don't want to learn technical practices seems to be that they expect no benefit. Sometimes that's more about futility than actual benefit.

In my thinking about Strawberries, I'm wondering what issues folks have with Scrum, good or bad. Please tell me. I'll mention some ways here.

There are signs and portents. What are they telling us? Is this death--or is it perhaps a rebirth?

Today I learned a new term. Maybe better/worse than 'Dark Scrum'. (TL;DR: If it isn't joyful, we're doing it wrong.)

A Twitter exchange yesterday and today has given me today's topic. I love it when not having a plan comes together. (Hm. Societal impact is similar ...)

What's the deal with Jira? Is it a bad thing, or the worst thing?

Another in my continued attempts to come to terms with what Scrum is rather than what it could (and should?) be.

Satire? Idiocy? Monkeys? Why not all three?

Again today, I take my writing prompt from GeePaw. I have a good purpose in mind. (Added: Dammit. I didn't expect to end up here.)

Is it useless marketing BS? Certainly there are issues. [CW: language, systemic racism/sexism]

When someone shows you who they are, believe them the first time. -- Maya Angelou

I've had a reply from the Chief Product Owner of the Scrum Alliance.

I think that today I'm going to write about joy. I have no idea where this goes. Walk with me ...

I've think I've figured out the disconnect between my view of the Scrum Developer priorities, and those of the Refactoring Team who created the new CSD track.

Responses from Scrum officials to my recent Scrum articles here and on more private slacks have not been favorable. I think I'll sum up and move on for now.

I've chosen a large windmill at which one might tilt. Could we, of good heart and great skill and courage, fix Scrum? If so, should we?

The End Scrum Now site, a bit of a rant, raises important issues. Let's explore some of them.

Herewith, some remarks pro-Scrum, and a reminder that Scrum is not as good for developers as it might be. Even some advice to developers.

On June 19th, I sent this email to the CPO of the Scrum Alliance. I have had no reply. In a second article today I will offer some related ideas.

A week ago, I posted a Scrum-related survey. Today, the results of that survey, and my comments.

Those words came up in our Zoom Ensemble last night, and they're part of my theme this morning.

Scrum asks for an Increment every Sprint. Of all the Scrum rules, this one is most important for developer success and survival.

A few(?) more thoughts on the battle between Scrum and Software Development. A review of some past thoughts, and some of today's.

The Scrum Alliance mission? Let's talk about that. Fail better.

Every time these organizations stamp out a new ScrumMaster, there are programmers somewhere whose lives will be made worse.

A Medium article with an interesting mix of observation and questionable opinion inspires me to write what I hope will be the same. 😈

Despite my concerns about experienced coaches advocating against practices that are often quite useful, there are a few things where I'd at least advise great caution.

This article expresses, in written form, the talk that Chet Hendrickson and I gave at the deliver:Agile conference.

... to ScrumAlliance.org, Scrum.org, and the Scrum Community at large

I like to say that I may have invented story points, and if I did, I'm sorry now. Let's explore my current thinking on story points. At least one of us is interested in what I think.

YAGNI can be a legitimate way to go fast at minimal cost. Skimping on the practices that support YAGNI? That's a mistake. Technical Debt? Not the same thing.

Some words and pictures about the various notions of 'technical debt', or, as I like to call it, wishful thinking.

Scrum is founded in the belief that self-organizing teams can figure out what they need. When true, this is sometimes not sufficient. And sometimes, particularly in software development, it seems not to be true.

Let's talk about what responsibility we have for those who never take a course from us, read our books or web sites, or even see our tweets. I think we have rather a lot.

Another little tweet-storm about estimation. I think it's useful and not as easy to use as some people think it is.

Agile transformations have little, if anything, to do with Agile Software Development. Let me hook up some connections for you. Bit of a rant here ...

A short little thing that I tweeted recently. I think it's about transformation and 'Agile Leadership Training'.

Are Imposition and Dark Agile both bad? Yes. Are they the same thing? No.

I tweeted a storm about responsibility when 'Agile' doesn't go well. Here we'll unroll it and say a few more words.

There's a lot of whinging going on about imposing 'Agile' methods and practices. These whiners just don't know how to do imposition correctly. Me either, but here's what I'd try.

People have been telling me for years that Scrum is not an Agile Software Development Framework. I should have paid more attention. It's still good stuff, though.

A chapter from 'Software Development, How I'd do it'.

The above was the title of my talk with Chet Hendrickson at deliver:Agile. I'll update this with a link to the talk when it is published. Meanwhile, here are some thoughts.

I watch The Expanse to force myself to exercise. Today this quote hit me pretty hard.

Where do we place the responsibility–surely not blame–when things don't go well on a Scrum team? Who's responsible for taking action? (A bit of something I wrote on Twitter, lightly edited.)

Just a few words about why I publish all these words, going over and over the same topics again and again, repeatedly and repetitively.

I'm not finished ripping Scrum a new one, but I don't want to come off all negative. So let's talk a bit about what I'd like to see done.

We've spoken often before about the backlog. Let's get down and dirty today. Delenda est backlogus or something like that.

If your factory pollutes the river, you're supposed to clean it up. If you plant kudzu to combat erosion, you are responsible for its destruction of everything in its path. If you swallow a spider to catch the fly, and die when you swallow the horse, of course -- it's on you.

The Sprint causes serious problems in many Scrum installations. What are some ways to mitigate those problems?

Let's consider the Scrum Sprint. What's the strongest case we can make against it? It harms people, how's that for a case?

In the spirit of inquiry, fairness, and a generally bad attitude because it's raining, let's consider how strong a case we can make against Scrum. It might be fun.

These articles about hills to die on are in response to a continuing trope on Twitter and elsewhere, to the effect that X is bad, or Y is better than X, and therefore don't do X do Y. These are amusing, provocative, and rather frequently ... mistaken.

When are Sprints a good idea, when not so good? What are their values, and their costs?

Bashing of Scrum (and other methods) is a common form of Internet Entertainment, and not without reason. Some of the concerns are more accurate than others. Choose carefully which hill you want to die on. In this series we'll explore some hills.

To meet the deadline, all the software has to work on that day ...

There's a lot of noise going on on the Twitter just now, about starting with Scrum, with kanban, or with nothing. Here are some thoughts.

Mike (GeePaw) Hill storified about sense of urgency and an acronym RAMPS. I like what he said and will muse upon it.

You'll meet them where they are. You'll work with them where they are. And when you leave, they'll still BE where they are.

A couple of things passed by my Twitter last week and I'll try to comment briefly on them. For values of 'briefly'.

Thoughts on the state of Scrum and Agile. Pressing harder isn't the point at all. Bit of a rant, really.

If you're like me (as of last week) you haven't read this book. I recommend that you do so, right away.

Based on our Scrum Gathering 2017 talk, we discuss the impact on real software development of growing focus on the 'enterprise'.

Time was, you got a spec, got browbeaten into saying you'd do it in 6 months, then got mostly left alone for 6 months. Now, they get to **** with you every ******* day!

Good frameworks are deep. Quick-entry courses sell well. It turns out they sell TOO well.

Scrum is good, when done as intended. Otherwise it can be oppressive and dangerous to developers. Let's study: Defense Against the Dark Arts of Scrum.

All around us, Scrum and Agile are used, misused, and abused. How should we feel about that?

Development teams need help using the product increment as a center for making lives better. I resolve to work to fix that.

We're not blaming you when we say you're doing it wrong. We're trying to help you do it right.

We need to make Scrum and Agile safe for software developers. How should we proceed? (updated)

There's not much wrong with Scrum. Or is there? It depends what the meaning of 'wrong' is.

Many people assert that Scrum fails often. They say it's Scrum's fault. I'm still trying to understand.

Giles Bowkett has written some impassioned diatribes against Scrum on his blog. He raises some issues, which I shall try to discuss.