"Poor management can increase software costs more rapidly than any other factor." (Barry Boehm)

I have been unable to post to my blog since last Sunday.

I haven't made any (intentional) system changes.

Some thing ain't right.

posted by Esther Derby at 7:23:00 AM

Tweet this Post | |

When companies adopt Agile methods, management roles shift. Team manages their own work and managers focus on system problems. The manager's stance toward the team moves to facilitative leadership and away from hierarchical leadership.

For managers who have been schooled in command and control, the shift is uncomfortable.

Some managers have trouble believing that other adults can actually manage their own work. They seem to have some confusion between the role of manager and the role of parent.

For me, the struggle was feeling like I wasn't doing enough. The team was doing some of the work I had done as a more traditional manager -- tracking progress, making status visible, solving problems, etc.

As a facilitative leader I learned to look inside and see if the need to do something was coming from me and my need to feel useful, or from the outside -- some event or situation in the team that needed a light steering touch.

Managers who do out of their own need to feel useful seem to muck things up as often as they help.

That doesn't mean managers abdicate all responsibility toward the team. A manager still needs to observe, pay attention, be available to coach, and intervene with a light touch when necessary.

Actually, I find facilitative leadership is more effective for all teams not just those using Agile methods.

To get a picture of the contrast between facilitative leadership and two more common models, read this article by Don Gray and Dan Starr.

I posted a bit about the differences between hierarchical leadership and facilitative leadership a while back.

posted by Esther Derby at 7:14:00 AM

Tweet this Post | |

Johanna wrote about the interesting rumor I heard at the STAR conference. (It's not true.)

When people lack information, they fill in the blanks--sometimes with something titillating, and sometimes with what they wish were true.

In situations of stress or change, though, they tend to fill in the blanks with their worst fears. That's one of the reasons it's so important to communicate during periods of organizational change.

During a period of change,

tell people as much as you know
tell them when you'll know more
tell them when you'll be coming back with more information
tell them what won't change
tell them that, in some cases, you don't know the answers.

Talk to people more than you think you "should" have to.

Then listen (and listen and listen).

And empathize, because change isn't about logic, it's about emotion.

posted by Esther Derby at 9:03:00 AM

Tweet this Post | |

I'm just back from the Scrum Gathering. Wednesday's sessions focused on introducing Agile organization-wide and organizational change.

We heard from executives at three companies who have adopted Agile methods. For these companies, Scrum is the starting point -- from there they address engineering practices by bringing in XP. What was interesting to me is that they described three different models for implementing change (none of which match the anti-pattern I described last week).

One company introduced Scrum when it was clear what they had been doing wasn't working any more. Pain was the motivator. That company started top-down and engaged middle-management and developers. The VP of engineering was in the thick of it, and provided on-going vision, coaching and support for the middle.

This company is delivering the software their customers desire with very, very few defects. They've also improved the work-life of the developers: sick time is down by 50%.

A second company introduced Scrum top-down in a classic re-engineering model. They're getting great results improving the financial picture for the company. Employee satisfaction is going up. It looks to me like they've realized the benefits through fixing workflow -- but they aren't yet looking at supporting teams to self-organize. They may not get there, because the results they are achieving now are good enough for them, at least for now.

Both of these companies are relatively small and started pretty much the entire development group with Scrum at once.

The third company is huge. They're adopting Scrum using pilots and working by attraction. They are gradually infusing new practices by showing people they can succeed, learning from each pilot sprint, and giving skeptics room to change their minds. This company is also providing on-going coaching support and training to the pilot teams.

I also hosted a panel on organizational change at the Gathering. Panelists were Tim Bacon, Jeff McKenna, and Diana Larsen.

There is no "one right way" to introduce Agile methods -- or any change. Some strategies work better than others (and some hardly work at all); it depends on the context.

Change isn't a process of logic -- it's a process of communication, emotion, loss, and practice. People are at the center of any change, and change happens one person at a time.

Mishkin Berteig posted his rough notes from Wednesday's sessions.

posted by Esther Derby at 7:17:00 AM

Tweet this Post | |

When I talk to groups who have been using Agile methods for a while, most of them report that the development groups started with Agile.

Now that Agile is becoming better known, senior managers are latching onto Agile as a solution to slow delivery, missed deadlines, and poor quality.

So they decide to implement Agile methods organization-wide.

Here's one popular process to implement Agile methods for the entire organization.

Have a senior manager announce that the organization will "go agile" on __________ (fill in the blank with an arbitrary date). Announce that 20+ teams will go live in less than 3 months.

Make the announcement at a big meeting where most of the people are asleep, because in the past 10 years nothing significant has been said at one of these meetings.

Appoint a team of the "right" people to work out the details. Make sure to staff the team with "subject matter experts" like HR people and configuration management experts. But go light on the people who will be doing the work.

When the developers ask to be involved, tell them they aren't the "right" people.

Implement by command and control ("They'll use _______ if we tell them to." Fill in the blank with Scrum, XP, TDD...)

Blame the developers (for "resisting change") and Agile methods when it all falls apart.

Oh, you wanted a way that worked?

Sigh.

Changing the organization to Agile methods means that managers have to change, too. And letting go of the old top-down, command and control model of change is the place to start.

posted by Esther Derby at 8:48:00 AM

Tweet this Post | |

Becoming consciously competent

I've noticed that my blog posts have been errr... infrequent lately. You may have noticed, too.

I've been pretty busy: writing one book, editing another, creating a new workshop... So I've been telling myself that's the reason.

But it's not.

I've been this busy before, and still managed to blog.

When did a little detective retrospective, I realized that something was missing.

In the past when I've been this busy, I've been on the road. When I'm on the road, I write in my journal while I'm sitting in the airport lounge waiting for my flight. Then when I'm near an internet connection, I look through my journal, find a snippet and shape it up for my blog.

Now I can apply this helpful practice consciously... which is one of the reasons to hold retrospectives. They help us become conscious of the practices that support our success.

I'm headed for the airport, and you can bet I'm taking my journal!

posted by Esther Derby at 11:15:00 AM

Tweet this Post | |