Hmmm… What does that mean?

On numerous occasions I’ve observed long-time members of the Agile community complain about misinterpretations of what Agile means, and how it performed. Frequently this is precipitated by yet another blog post about how terrible Agile is, and how it damaged the life of the blogger. Sometimes it’s triggered by a new pronouncement of THE way to practice Agile software development, often in ways that are hardly recognizable as Agile. Or THE way to practice software development is declared post-Agile as if Agile is now obsolete and ready to be tossed in the trash bin. (Continued)

Another Two Sides to Estimation

There are many ways to look at the issue of estimation. Everyone in the business of software development has had experience with wanting estimates, being asked for estimates, or both. That experience frames how they look at the issue. A considerable share of those experiences have been painful. I dare say that everyone in the business has had some painful experiences around estimation, and the painful ones seem to stick in our memory more vividly than the benign ones.

What makes these experiences so painful? Again, the causes are legion. One frequent contributor is well illustrated by a story my older brother taught me as a child.

(Continued)

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)

Specialized Skills

Whether we’re talking about revolutionary new web services, IT systems to automate internal procedures, or products to sell in boxes, there are many different sorts of things that need to be done. We need to envision the product, decide what’s required to be done, design it, build it, make sure it works, and put it into production where we can reap the benefits. Except in the smallest of circumstances, doing all of these things requires the work of multiple people. And, given that we need multiple people, and that we need a variety of skills, it’s natural that some people specialize in some thing and others specialize in different things.

But we can take that specialization too far. And if we over-specialize, then we do these different things in isolation. (Continued)

Agile Retroflection of the Day

Yves Hanoulle asks, “If you could change 1 thing today what would it be?” as the first question in his Agile Retroflection of the Day project. Today being the first of the year, it’s natural that I look back over the past year as I consider this question.  And so I answer,

That people could ask for, and could accept, the help they need and want. (Continued)

How to get people to do what you want

Back in March of last year, David Maister was interviewed by Wayne Turmel and he said some amazing things. I’ve been meaning to talk about this for some time, but the work of transcribing from audio has tempted me to put it off. I highly recommend listening to the whole thing.

David Maister is a business consultant, but what he says here is extraordinarily appropriate for most of us technical people, too. He describes starting out with the same vision of success that I had, and how completely wrong it was. (Continued)

Building Relationships

So much of life, even so much of software development, comes down to interaction with other people. And a big key (perhaps the big key) to this is building relationships. David Maister says some very interesting things on this topic–things that hit home with me. I’ve been meaning, for some time, to comment on an interview he gave on another site. While I’m waiting to get around to that, let me point you to this wonderful podcast (available in audio and video formats). Go watch it; I’ll wait. (Continued)