Category: increment

I'm taking a couple of on-line comments as writing prompts today. Let's see what we get.

Let's consider the implications of small-step development on our three shadow views of the program. (Includes Sarlacc.)

Working software is at the core of success with agile methods. Let's remind ourselves about that.

We're here to replace raspberry jam with strawberry jam. We need those delicious nodules of flavor and value.

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

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

A Slack conversation brought up the question of why I do ... the things that I do.

In which our intrepid author makes a grievous error: disagreeing with Kent Beck. Or does he?

When I was blurting about the Increment as the most important thing, just the other day, GeePaw Hill mused about collaboration as the most important thing. Today, I'll muse on that and his notion of makers-making-made.

We're here to discuss whether Agile ideas fit in with fixed-scope efforts. We'll look at Agile values, principles, frameworks, and practices. The answer is that Agile works just fine.

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.

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.

A lovely post by GeePawHill led to a Twitter conversation about up front design, inspiring this article.

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

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

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

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!

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.

Chet and I were talking about the importance of the Increment and the Sprint Goal. Herewith, some musings.

If we can't build software well, all our Agile is for nothing.

A brief um discussion about the Increment and how it might help you change culture.

I guess today I must write about the Scrum "Definition of Done", which is neither a definition, nor done. Is it a Scrum Artifact? I'd rather not.

For success with Scrum, we need the basics, our expertise, and to improve our culture. To improve the culture, we need the Product Increment.

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

Jeff Sutherland said today that it's not done if it's not tested. You won't believe what happened next!