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)

Video Interview: On Cultural Change

At the SQE Agile Development Practices (ADP/West) Conference last week in Las Vegas, Yvette Francino interviewed me on the topic of cultural change.  Here is the video of that interview. (Continued)

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

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

So you want to make your organization Agile

When I first discovered Extreme Programming a decade ago, I was a software developer wanting to produce the best, and best fitting, software that I could. In those days, it seems that most Agile adoptions were from the bottom up.

Now I find a lot of Agile adoptions are from the top (or, at least, middle) down. Managers have heard about the improved results that companies are achieving using Agile development, and they want some of that for their organizations. That’s not surprising, and it should result in both better results for the organization and better work life for the employees.

Unfortunately, it doesn’t always work out that way. What is it that goes wrong with these top-down Agile transitions? More importantly, how can a well-meaning manager conduct a successful Agile transition? (Continued)

3 Legs to Running an Agile Transition

A while back, I wrote 3 Legs to Standing Up an Agile Project from the perspective of an Agile team just getting started.  Lately, I’ve been thinking about the same sort of thing, but from the perspective of a coach or an executive that wants to transform the organization.  At first glance, this seems no different. Further reflection, however, reveals that this is less about “how to work in an Agile fashion” and more about “how to introduce change in the way people work.”  The earlier post was a description what an Agile project needs.  This one is a recipe for creating what an Agile project needs. (Continued)

The Limits of Energy

Sometimes people just won’t do what you want them to do—what they should do—no matter how hard you try to persuade them. Why is that? (Continued)

What does it look like from management’s side

Or the business customer?

As I talk with developers and team leads who are leading agile initiatives in mostly non-agile companies, I continue to hear comments about managers who “don’t get it,” and Product Owners who won’t participate, and other complaints that suggest that not everyone has reached the new status quo (per Satir’s Change Model). Sometimes communication issues seem to be delaying progress. Sometimes some of the participants don’t seem to be aligned with the goals of the agile team. At least, it appears that way from the developers’ point of view.  In all honesty, perhaps the agile team is not yet aligned with the business needs.

I’m trying to get the point of view from the other side. When these problems arise, I want to know how the Managers and Product Owners feel about the way things are going. Surely they see things from a different vantage point, and have different insights.  I’d like to know what those insights are.

I’m looking for real stories and feelings–not descriptions of the way things are supposed to work.  I want to know what you see happening (or not happening) around you.  I realize that such real-world stories may be a little too sensitive to post in public comments.  If you’d like, email them to me at blog-response AT and I’ll keep them in confidence.

And if you’re not an upper manager or product owner, but you’re having difficulty with one.  Please ask them how things look from their side and let me know.  Or have them let me know.  Or invite me to come and discuss it with both of you.  I’m really interested!


There’s been some discussion on the XP Yahoogroup about the practice of “blocking” in order to protect an Agile team in a non-agile corporation. I’d gotten rather behind in my reading, and came into the middle of the discussion. I’ve just now tracked this discussion back to a post by Scott Ambler, where he says,

This is a great example of something that I call blocking, where you produce the paperwork, attend the meetings, pretend to care, … to make it look as if you’re following the “official process”.

Scott is responding to a mention of the use of PERT on the Polaris submarine project. Scuttlebutt says that PERT was deemed a great success in managing the Polaris project, but in reality the PERT charts were reverse-engineered from more seat-of-the-pants management techniques. As the stories go, this “scientific” management technique wowed the Congressional oversight committees, and such techniques have been the backbone of government contracting oversight ever since. (Continued)

A story about statistics

Ron Jeffries, when someone asks for data to “prove” that XP or some development practice works, is wont to say that the person they’re trying to convince may be asking for evidence, but it’s not likely that the evidence will convince them. (Continued)