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

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.

Interchangeable Project Lenses Can Reveal the Unseen

If you look at things from the same point of view all the time, you’ll tend to see the same things, and overlook the same things. I discuss on ProjectManagement.com how to vary your view to get a better overall picture.

Taking the Long View in Software Development

My article, Taking the Long View in Software Development, has been published on ProjectManagement.com. Free registration is required on that site.

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? (Continued)

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… (Continued)

Slowing Down to Go Faster

My article, Slowing Down to Go Faster, has just been published on ProjectManagement.com. It examines the questions of how can we go “as fast as possible” and how can we know that.

Free registration required.

Accomplishing Organizational Transformation

Scaling Agile across the Enterprise attracts a lot of attention these days. There are a number of models suggesting ways to organize Agile development inside a sizable organization with a lot of teams. I suspect that all of these models share the same basic flaw—that you can do something the same way across a large enterprise. Even if your policy manual says exactly how to do something, people are people and there will be variations in understanding and execution. And how does a team self-organize in a prescribed manner?

Beyond that, there’s the problem of getting from current state to a future state that resembles the model. It does not work to “install” a new way of working across a large system composed of people and their interactions. Some people suggest starting the transformation with management, as that’s the “highest leverage point” and the “system’s major influencers.” Others suggest starting with the teams, because without competence at building reliable software (or other systems) in short cycles of small steps, you’re not going to get the benefits of Agile Software Development. I don’t think that either of these starting points work.

“When we try to pick out anything by itself, we find it hitched to everything else in the Universe” — John Muir (Continued)

What is the Right Length for a Project?

I’ve seen many comments on the topic of estimation in the past year, and I’m starting to notice some trends and assumptions in them. One of the common assumptions is that, given a particular team and amount of resources, there is a correct length to a project. A twin to this one is that there is a correct estimate that contains the same end date as the subsequent actual project performance. (Continued)

Managing Risk With Estimates

Used with care, software development estimates can help you manage project risks. They let you peer into the future, though only as well as your current understanding allows. Estimating based on what you know is easy. Estimating based on what you know you don’t know is possible. Allowing for what you don’t know you don’t know is prudent.

Managing risk is a dynamic process. I’ve seen people document a risk in a “Risk Register” document and promptly ignore it. That’s not management. Instead, consider different ways a risk might be reduced in likelihood or consequence. When time or cost is of the essence, think about how you’ll determine what you can afford, and when you need to take a second-choice approach. (Continued)