Joyful Change

Brian Marick challenged me for an expression of joyful change, especially related to software development, based on the teachings of Virginia Satir. As discussed in my previous post, he’s come to associate the combination of “Virginia Satir” and “change” with pain and the following:

…blaming… …placating… …anger… …guilt… …stress… …resistance… …denying… …avoiding… …blocking… …deny… …avoid… …anxiousness… …vulnerability… …fear…

This post is, in part, to demonstrate to him that the work of Virginia Satir is not focused on the negative. Mostly it’s to share, and rejoice in, the freedom we have to reach our goals. Read More

It’s Only A Model

We use models to help us simplify the situations we’re viewing, so we can reason about them more easily. I’ve often found this to be enormously helpful. It’s important, though, to remember that this is only a model. We can use a model for understanding, and even for making predictions.

We cannot substitute the model for the thing that it is modeling, though. The map is not the territory. When we use a model in contexts where it doesn’t apply, it’s likely to lead us astray. Similarly, when we mistake an illustration of the model for the model itself, we may make inferences that the model doesn’t support.

For example, a couple of my friends have recently tweeted complaints about the Satir Change Model in response to such misuses. I find the Virginia Satir’s model extremely useful, and would like to disassociate it from these misuses. Read More

Splitting User Stories

I’ve written about User Stories before and made available a handout that includes a page on splitting stories that, in addition to listing some splitting heuristics, includes several links to several lists of techniques for splitting stories.

What it doesn’t include is an even simpler way to split stories–the simplest way I’ve found yet. Read More

Agile In 6 Months

How long does it take to take a team from where they are to becoming an Agile team?  Of course, that depends on many things, including where they are and how badly they want to succeed at Agile.  It’s reasonable to think they can make a transition in six short months.

If you’d like your team to become Agile, give me a call to find out how I can coach the team to do that for about the same cost as contracting a senior developer.  If your team has already made a transition, but you find that you’re not as effective with Agile as you’d like to be, I can coach using the same framework to help you reach that effectiveness.

Iteration, Increments, and Timeboxes

Like many words, we often use “iterative” and “incremental” quite loosely. I’m OK with that, until that lack of precision causes misunderstandings, disagreements, or misdirection of effort.

It’s quite common for Agile teams to speak of an iteration as a synonym for the Scrum term sprint. Both of these usages really mean timebox. Read More

When something persists, some reward exists

Jason Gorman has just written a piece in defense of Software Craftsmanship that highlights how very dependent our world has become on software.  He offers Gorman’s Law Of Software-Dependent Business Evolution:

Software-dependent businesses can only evolve as fast as their ability to write and evolve their software allows them to.

I think this is not only true, but an incredible opportunity for businesses that understand that.  Let’s face it: most businesses spend an awful lot of time for a very meager increase in systems capability.  Companies that do better than average can shoot to the top.  Look at the spectacular successes of some of the relatively young internet companies, for examples. Read More

It is possible to fail in many ways

On Twitter, Alfonso Guerra (@Huperniketes) asked me, “Okay, tell me how [software] quality will improve by prog[rammer]s taking more resp[onsibility] for quality?” My response is longer than 140 characters, so I’m replying here.

For background, my involvement in the conversation started when he caught my eye with

The problem with the Software Craftsmanship movement is its attempt to create a race of superprogrammers who can save [software] from bad [project management].

Well, I don’t know anyone promoting Software Craftsmanship who thinks that. Read More

Trades, Crafts, and Certification

Dan North says that programming is a trade, and not a craft.  I agree with him that it’s a trade, like plumbing and wiring.  I’ve already disagreed with his definition of craft.  I’d say that programming is a craft only when it’s done well.  I’d also say that plumbing and wiring are crafts when done well.  Rather than a definition, how about a couple examples to illustrate the point? Read More

Software Craftsmanship

Dan North has created a bit of a stir with his declaration that programming is not a craft. Liz Keogh has agreed with him.  The funny thing is that most of what they have to say is not about programming, but about the Manifesto for Software Craftsmanship.  Well, writing is a craft, also, and I’ll agree with Dan that this manifesto is not “a call-to-arms, feisty, opinionated, brash and everything that a good manifesto should be.”  It never grabbed me the way the Agile Manifesto did.  Dave Hoover has taken this challenge as a call to improve the software craftsmanship manifesto.

I didn’t “sign” the Manifesto for Software Craftsmanship because I thought it was particularly well written, though.  I signed it because I support the intent (as I perceive it, and which Ade Oshineye defends) behind that manifesto.  Writing software is a craft, and there are far too many people who don’t treat it that way. Read More