Category: New-Framework

There was a thread on Twitter talking about Agile being anti-management. No, it's much more radical than that.

Sprints, Iterations, Cadences, Continuous Flow. Planning sessions, daily scrums, retrospectives, increment reviews. Are these all, in the end, overhead to be eliminated along the way to some Agile Nirvana?

A couple of people asked me to list all the technical skills required in order to do Agile Software Development. I can't do that, but I can do this.

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 ...

Some early unfocused thoughts around original XP practices and what I might say today.

I'm not going to define a new framework, and don't think I should redefine XP, as it's not my baby. But I was thinking ...

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.

On the Agile Mentoring Slack group, Jack Caine and I were discussing what it means to be Agile. I wound up writing something like this, and wanted to share it more broadly.

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.

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

I'm wondering, today, whether the Increment could be the driver for all 'Agile' software development.

Today, let's talk about cadence. Iterations, Sprints, to have them or not, that is the question.

I was asked a question about one of today's modern approaches to Agile software development. Here are some general thoughts.

What if I were to create a new software development framework? I'd never do that, but if I did, what might I do? Let's find out. Let's talk today about Whole Team.

Terms seem important to me today. (Revised 2017-07-05: Techniques)

Some Notes on the theme "If I were going to create a new framework, what would it be?".