Category: success

Markus Gärtner interviewed Ron Jeffries, co-author of the Agile Manifesto and Coach of the first Extreme Programming team. Ron reflects back on the past 20-or-so-years of Agile Software Development and dares to look ahead on things to come.

We spoke of Sudoku at FGNO, and my 'failure' with it, and with me, apparently, the failure of TDD, Extreme Programming and all of Computer Science.

It's OK to care about programming. It's OK not to care much about what your company is trying to accomplish. No, really, I'm serious.

I do not love that phrase, but I do love programming.

Does everything have to be easy? What about hard things?

First, some thoughts on TDD.

Some Twitter chatter and a moment of not knowing what I wanted to code this morning has led me to think about what people should do.

Oddly, I take as today's writing prompt, a strange tweet from a person of curious name.

Try again. Fail again. Fail better. Been down so long, it looks like up to me. Summary: Much better.

So many good ideas. But we need to ship it. We'll talk about that—and get ready to do it! UPDATE: Walking skeleton works!

Here, some thoughts raised by yesterday's Agile Alliance Zoom thing.

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

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.

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

As often happens, this article didn't go where I expected. I hope you like where it went.

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

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

The Agile Manifesto says that working software is the primary measure of progress. What does that mean?

This morning, rather than toil over the scattered bodies of evil but admittedly cute space invaders, I'm minded to talk about privilege.

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

Adam Savage (@donttrythis) posted a marvelous video of his attempt to build a giant brass nut and bolt. It reminds me of software.

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

Some thoughts from Twitter on 'technical debt', what it is, what it isn't, and why we avoid it.

Why do we do that? One word: Productivity

A number of blogs, tweets and emails have crossed my 'desk' lately, gently or strongly advocating against some generally well-thought-of practices. I'm troubled by that.

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

A private note from GeePaw Hill, and a tweet from Brian Marick inspire me to mumble a bit about mindfulness and collaboration.

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.

If you are not producing working, running, tested usable software in every single Sprint or iteration, you are not [yet] 'doing' Agile, you are not [yet] 'doing' Scrum.

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.

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

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.

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.

Probably not a good thing to say. Possibly a good thing to think about.

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

This is a small excerpt from The Nature of Software Development. It's a good reminder of some ways to think about value.

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.

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

Another tweet-storm, this one about slicing from top to bottom of the software. Slicing provides value, and information, sooner.

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

I was asked on Twitter what I meant when I said 'Simple, not easy. There's a difference.' I have no idea what I meant then, but here's what I think just now.

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.

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.

Responding to a mistaken TDD flowchart.

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.

An innocent email question leads me off into wildness and chaos. What's new with you?

In which a really fascinating little study piques our interest and suggests some thoughts. Please, I mean no harm here.

A number of tweets and posts this week point out, correctly, that if we don't think about what we're doing, Scrum and Agile won't work. Apparently people need this reminder.

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

I've been trying to learn a 3D drawing program. Yesterday I noticed that I was working but not learning.

Possibly not the best stance to take on, if you can manage it.

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.

A twitter conversation got me thinking about the extent to which Agile ideas are intended to support small improvement, or to disrupt things.

Some interesting tweets make me wonder: if I were creating a method today, what would it be?

Over the past few days, an ancient twitter thread accidentally revived, talking about how you don't need quality code when you're just validating assumptions. What do the ants have to say about that?

I was asked a question via email and liked my answer enough to write it up. I hope you like it too.

Some tweets inspire me to write a bit about management in Agile.

Bob Martin has published the Programmer's Oath. What do I think about that? The answer may surprise you.

It's common to tweet things objecting to high automated test coverage as if it's irrelevant, incompetent, or stupid. I suggest otherwise with a thought experiment.

In which we discuss the technical debt metaphor, bright code, and the inevitable decline of civilization.

Mistakes, I've made a few [thousand], but then again too many to take personally. – not Frank Sinatra

Let's try this again. The previous article was not clear to all readers. I suppose this is often the case with my work but in this case I thought I'd try again.

At the time of the Agile Manifesto, we all did the best we knew. Here's something I wish we had done. (Revised)

The Backlog is an essential artifact in Scrum. It may also be the root of serious dysfunction.

Generalizing from a few results isn't proof. In this article I'm going to prove that by generalizing from a few results. Wait, what?

Let's look at what Agile-focused individuals can do to improve their own lives, and, through interacting, help their colleagues and their organizations.

I've been a bit disappointed lately by the state of Scrum in companies, and rightly so. But there's another way to look at it.

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

You have to either laugh or cry. -- Wm. M. Rogers

You people could help me by doing a better job and making fewer mistaks.

One great way to remove an impediment is to replace an old idea with one that's better. Let's give that new idea a new name.

I haz one.

Many individuals are creating new, marvelous, incredibly valuable Agile contributions. These were inspired by the Manifesto. They are not updates to the Manifesto, they're founded upon it.

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

A recent Twitter conversation bugged me (and bugged Clarke Ching even more). Here's why.

Privilege. No privilege. Screw it, improve your situation. Or don't. It's up to you.

A Twitter conversation got me thinking about how often teams or organizations fall away from their process, when it happens, and why.

Theory, Practice, Received Wisdom, Certification. These are not the things that make things work. Good people make things work.

Keep seeking better ways.

Deciding what kind of tests, and what tools, would be good for a payroll series, if I continue with it.

I love computers! Trying to set up Fitnesse and landing squarely on rspec.

Every minute we spend just thinking and talking, and not programming, is wasted!

Chet and I just ran an Agile Skills Workshop last week. It was great fun. We were asked for a description, and here it is.

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.

I had occasion to look at a couple of articles from 2010, and things don't seem to have changed much. Should we be concerned?

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

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.

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)

It's not up to Scrum or "Agile" or XP to make you successful or happy. It's on you.

We don't want just a "Product Owner". We want a Product Champion!

They shipped the software, therefore what they did was best. It ain't necessarily so.

Jonathan Rasmusson wrote an interesting article. I agree. It's not about unit tests. It's about skill and understanding.

Giles Bowkett invited me to discuss another article he wrote. For some reason I'm willing to do that.

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

Scrum's job ends with the problem. Your job begins with the problem.

Many teams seem to get in trouble because they do not have good technical practices. In Scrum terms, they can't get "Done". Is Scrum flawed because these teams do not "discover" such practices?