Category: Responding to Change

Another Visualization of the Satir Change Model

Some years back I had a conversation with Bas Vodde about the graphical way that the Satir Change Model is usually represented. If you search on the internet, you’ll likely to end up at Steve Smith’s description, which is very good but shows “performance” as if it’s a measurable thing. While at the UNC Satir Summer Intensive workshop in 2018, I thought about a different way to view the process of change. This view is less from an external point of view, and more from the point of view of the person going through the change. Rather than a graph, it’s a map of the journey from the Old Status Quo to the New Status Quo.

Late Status Quo

Imagine you’re sitting at home, minding your own business. It may not be the life of your dreams; it may not even be without pain and annoyances, but you’re accustomed to the way things have been going.

Read More
1 Comment

Categories: Responding to Change

Tags: ,

Accommodating the Unexpected

As I write this, much of the world is in a state of disarray. Many businesses are shut down for fear of spreading the Covid-19 virus, and others have suddenly switched to distributed work over the internet. Most software developers are working in physical isolation. Even those accustomed to working remotely are reporting that the current situation is affecting their ability to get things done.

I think it is safe to say that no software development organization expected this to happen. No IT department accounted for the disruption in their estimates and plans. While epidemiologists could predict that there would eventually be a worldwide pandemic, even they could not predict the severity or timing of such a disruption.

How has this affected your work? Are you still expecting to meet the plans made before this happened? Have you given up planning altogether, just trying to get something, anything, done? Or have you looked at how things have been progressing in the last 2 or 3 months and adjusted your expectations?

Read More
No Comments

Categories: Responding to Change

Tags: ,

I’m late, I’m late!

Even when you’ve done something many times before, sometimes you forget something or make a mistake.

This morning I was on my way to visit a client and realized I’d forgotten something. It seemed to me important enough to do something about it, so I went back home and got it. The unanticipated delay threw my schedule into disarray. I wasn’t going to arrive by the time I wanted. I was frustrated and unhappy with myself.

I see similar things happen all the time in software development projects. Something throws off the schedule. People get unhappy. Read More

3 Comments

Categories: Responding to Change

Tags: ,

No Time to Learn

The number one problem I see at clients is that there is no time to learn. Without time to reflect on how things are working, we don’t notice the things that we’re accustomed to not working very well. Without time to research what others are doing, we can’t make informed choices about things we might want to try. Without time to try experiments, we can’t find out if a different approach will work better for us, or not. Without time to try multiple experiments, we can’t evaluate what works for us over a broad range of situations rather than latching onto the first idea that appears to work at all.

To a large degree, Agile software development IS learning. We try things mindfully, watch the results we get, reflect on why we get those results, and adjust. We do that at multiple levels of granularity, from choosing what products to develop to writing code that works reliably.

It takes time, but it pays off over time. To keep doing the same things in the same way suggests that we know everything there is to know about it, and there are no improvements left to make. That we are already at top speed. That we can only do worse than we are right now. I find that highly unlikely.

There is always more to learn. There are ways to learn better ways to learn.

3 Comments

Categories: Responding to Change

Tags:

Interchangeable Project Lenses Can Reveal the Unseen

When we see the same view every day, we get complacent. We no longer notice certain details. Habit, rather than choice, controls many of our behavioral responses. We may be doing fine, but such a limited view doesn’t promote getting any better, and leaves us vulnerable to changes outside our control. Or we may be missing points that are essential to the success we want. Read More

No Comments

Categories: Responding to Change

Long-Range Planning with User Stories

I frequently hear or read people suggesting using User Stories for relatively long-range planning. Sometimes they mean something as short as a release in a few months. Sometimes they’re talking about multiple releases over a year or two. In all of these cases, they’re talking about breaking down the work to be done into small slices so that they can better measure it’s perceived size for predicting the future.

What are the implications for doing this? Read More

No Comments

Categories: Responding to Change

Tags: , ,

Best Practices

A colleague’s statement, “In fact my tip is NEVER do a MoSCoW prioritisation,” caught my eye. “The implied fixing of scope makes change very difficult. Order things instead.” That bold NEVER waves a red flag. The following exhortation to order the things to do is also troubling to me.

I don’t know what prompted the statement. I can certainly envision situations where I think the advice to order requirements or backlog items, rather than prioritize them in buckets, makes very good sense. There are other situations where MoSCoW prioritization (“Must have,” “Should have,” “Could have,” & “Won’t have) is good enough, and situations where linear ordering is inadequate. Let’s look at it more closely… Read More

No Comments

Categories: Responding to Change

Tags: ,