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

A friend forwarded this email to me:

I just wanted to share a tip that has made a world of difference for our scrum. I read through this book about 4 months ago



And have implemented some of the practices in it. This has taken our retrospectives from being a 1 hour meeting where we went around the table and said what was good and what wasn’t (and then never really changed anything) to a full 3 hour incredibly productive conversation that the whole team participates in and we actually implement the changes that we propose in! It’s been a complete 180 from a meeting that was a waste of time to something the team looks forward to doing at the end of each sprint.

So if you haven’t read this book, I really recommend you do and try out some of the things in it (even if you think they are a bit cheesy and that the engineers will never tolerate it). It’s a quick read (3 hours tops for the whole book) and will at least give you some ideas for improvement of your retrospectives.

Woohoo! This is the highest praise an author can receive. (I don't think the activities are cheesy!)

And, for your reading pleasure, two recent articles on retrospectives:

Making Retrospective Changes Stick

Eight Reasons Retrospectives Fail (And What You Can Do About Them)

Labels: agile, Retrospectives

posted by Esther Derby at 9:15:00 AM

|

Most of the time I hear people talking about trust, they are talking about trust between team members. It's equally important to have trust between managers and team members. In fact, the relationship between an employee and his/her manager consistently shows up as a key factor in retention.

One of the ways that managers in the middle of agile transitions break trust is by giving a decision to the team and then taking it away, as in Tale of a Yo-Yo Manager.

Labels: agile, management

posted by Esther Derby at 5:51:00 AM

|

Diana and I have one space left in the December 11-13 Secrets of Agile Teamwork in Portland, Oregon.

SAT is three days of experiential learning and practical tools to help you and your team reach the next level of collaboration and productivity.

Be the first to fax your registration and the spot is yours.

After that, its the waiting list.

Labels: agile, personal effectiveness, workshops

posted by Esther Derby at 10:06:00 AM

|

An interesting interview with Jerry Weinberg here, at the Citerus site.

Some excerpts:

Q: You must have seen a whole bunch of ideas, about how to best do software development, grow and die over all those years. Do you see the agile movement as a pendulum swing or is it a move in a new direction?

A: How about a pendulum swing in a new direction? It's a pendulum swing because approximately every decade, there's a fresh movement to "solve the programming problem." High-level languages, structured programming, object-oriented programming, ...

But it's a new direction because it's the first movement to focus largely on social processes rather than purely intellectual ones. For that reason, I believe, it has more hope for success than the earlier movements, each of which made a little progress, then largely ran out of steam before achieving its grand promises.

Of course, agile won't achieve all its grandest promises either, given the conservative nature of human beings, but that's all right. After another dozen decades or so of incremental improvement, we'll begin to see some really fine software development. Well, I shouldn't say "we," because none of us will see them, but at least our great-great-grandchildren will be able to look back at us and laugh at our crude methods.

Q: If you're the J.K Rowling of software development, who's Harry P then?A: Well, first of all, I'm not a billionaire, so it's probably not correct to say I'm the J.K. Rowling of software development. But if I were, I suspect my Harry Potter would be a test manager, expected to do magic but discounted by software developers because "he's only a tester." As for Voldemort, I think he's any project manager who can't say "no" or hear with Harry is telling him.

Labels: agile, management

posted by Esther Derby at 12:04:00 PM

|

I've been watching a discussion on the Agile Project Management yahoo group, which poses the question, "Does everyone in agile need to be above average?"

The question behind the question is, "Does agile need extremely competent people in order for it to work?"

When I read stuff like this, I wonder "What method of building software works without competent people?" It's a puzzle.

Which brings me to this snipped from Bob Sutton (via Jason Yip):

Great systems are more important than great people. The notion that you are doomed to mediocrity if you can’t hire the very best people has little empirical support. Yes, there are big differences between the most talented people and the next level down in most occupations. But systems are more important. Toyota beats the competition as a result of a superior system; Men’s Wearhouse and McDonald’s don’t hire people that are much different from their competitors, but their systems explain their long-term dominance more than their people. As Jeff Pfeffer says, many organizations seem to have “brain vacuums” to turn people who seem to be smart into bumbling fools. Even the most brilliant person is doomed to fail in a bad system, and seemingly mediocre people can become stars in a great system.

Agile methods are a system that can help people perform better.

One agile coach I know tells a story about the first agile pilot in her organization. Someone in senior management didn't want the pilot to succeed. So he sent her all the "poor performers" for the pilot team. But they ended up outshining expectations and did a fine job of delivering valuable working software.

Further, focus on individual talent (and focus on individual performance management) takes focus off improving the system.

(I'll say this now, because someone always asks at this point "So you're saying we should hire incompetent dodos?" No, I'm not saying, "hire dodos." Hire competent individuals who are a good fit for the organization's culture. Focus on improving the system to improve results. Focus on individual performance for career development. Give feedback to help individuals become more effective.)

Labels: agile, management

posted by Esther Derby at 2:12:00 PM

|

Diana and I are offering Secrets of Agile Teamwork this June 5-7, 2007 in Portland, Oregon. This is a public workshop, open to 12 people.

We'll be focusing on the interpersonal skills that enable people to be effective team members. We'll be looking at communication, conflict, shared leadership, and forming and nurturing teams.

If you want to be the best team member, ScrumMaster, or coach you can be, join us for three days of learning and fun. Download a registration form here.

Labels: agile, self-organizing, teams

posted by Esther Derby at 8:55:00 PM

|

When I talk to teams about self-organizing, people worry about what to do when some one on the team isn’t working out.

If we’re a team, they posit, we have to work things out so we can work together. Not necessarily so.

Teams need to manage team membership so that they can achieve their goals. There are times when teams can work things out to work together. And there are times when someone needs to go.

I see four common reasons to move to move someone off a team.

When a team member doesn’t have the skills needed to do the work and can’t (or won’t) learn them in the timeframe needed by the team and the business. This can happen because of a hiring mistake, when the company moves to a new technology, or when the focus shifts from one type of work to another (e.g., from manual functional through the GUI testing to automated testing through APIs).

This is really hard when it’s someone who has contributed and now can’t make the learning curve. If there’s no other way for the person to contribute, it’s time to move him off the team. In the long run, though, allowing the situation to continue doesn’t do anyone favors. The team may start to resent the non-contributing team member. The non-contributing team member doesn’t have the satisfaction of pride in work and making a contribution. Everyone suffers.

When someone can’t or won’t work collaboratively. For example, when a person focuses on completing his tasks at the expense of completing the team’s iteration goal, or the rest of the team agrees to share code-ownership and he refuses to relinquish control over “his” code. Or when an individual doesn’t communicate with other people on the team.

On a team with interdependent goals, having a member who refuses to collaborate (for what ever reason) makes it harder for everyone to do their work. It also creates a dynamic where team members focus time and energy on the behavior of one team member rather than on building working software. It’s futile to try to convince someone to work collaboratively when he doesn’t value collaboration.

When the person challenges efforts to move forward that aren’t perfectly aligned with his ideas. Sometimes an individual sees risks in an option and has a hard time talking about it in a helpful way. Usually this comes as “that will never work here,” or “we tried that and it didn’t work”. This is irritating; AND there’s often useful information behind the objection—when you tease it out. (And you can coach the person to modify their style.)

On the other hand, some people challenge efforts to move on a philosophical basis—they call into question whatever the team proposes on the basis of an abstract notion of how-things-should-be. It’s really easy to get hooked on the content and get sucked into discussions about why some action is or isn’t pure and correct.

There is a place for “devils advocating” and vetting actions against fundamental values. That’s an important function on any team and I’m not talking about eliminating it. However, when one member has a pattern of challenging efforts to move forward, not letting go, and killing new ideas with criticism, its a problem. Especially when the challenge shifts to meet each new proposed avenue of progress that doesn't meet the purity test.

When someone has a fundamentally different vision of where the team should go. A few years ago, I was traveling from Amsterdam to Copenhagen by rail. My route required that I change trains twice. As I settled in to my seat after the first train change, a nice German woman asked me where I was going. “Copenhagen,” I replied. “Oh, no, my dear,” she said, “you are going to Berlin.” I guess I could have argued, but instead I got off at the next station, back tracked, and got myself onto the train that was going to where I wanted to go.

It’s like that sometimes with teams. Most of the team wants to go in one direction, and one individual wants to go in a dramatically different direction. And he argues for that direction, well after the majority of the team has expressed their commitment to go another way. The team spends lots of time trying to convince the one person, and that person spends a lot of time trying to convince the team. At a certain point, it’s time to say, “This is where we are going. We want you to come with us. If it doesn’t fit for you, we understand. And you’ll need to go your own way.” Early in the life of a self-organizing team, the coach may have this conversation. Some teams reach the point where they have the conversation amongst themselves.

There’s a risk that the individual has the right of it, and the team is headed in the wrong direction. But if the team makes some movement, they are likely to discover that, and then they can make corrections. As long as the argument continues, no one is moving at all.

Excluding some one from a team is difficult. Most of us want to feel included and part of the group. That’s a potent trigger for most of us. Some people feel overwhelming anxiety over excluding someone from the team. For others the need to belong is equally overwhelming. Helping someone move off a team is seldom easy. And when it’s done—and handled with respect and caring for the person who is leaving the team—it’s doesn’t have to be a traumatic event for anyone.

Labels: agile, self-organizing, teams

posted by Esther Derby at 8:00:00 PM

|

Every so often someone asks what the title ScrumMaster means. Some assume it implies mastery of a subject, such as a Zen Master, or a master carpenter.

My friend Bryan Stallings gave the best answer I've heard so far:

When I work with those new to Scrum I explain this subject as follows...

I ask them to tell me what a Master-of-Ceremonies does. They tell me about events such as the Oscars and explain that an individual with this role is responsible to ensure that the event progresses as planned, that they facilitate the transition from one phase of the event to another, and that they step in should anything unplanned occur.

I then ask that they describe to me the responsibilities of a Quartermaster in the military. They explain that a Quartermaster provides the troops with all that is required for their success and comfort, and sets-up suitable circumstances.

I of course agree with them and then I proceed to explain that like a Master-of-Ceremonies, a ScrumMaster is responsible to ensure that the Scrum process progresses effectively from event to event, that a ScrumMaster also steps in should an obstacle to success be encountered. Additionally, I explain that like a Quartermaster, a ScrumMaster shoulders the responsibility to provide the team with all that is necessary to ensure their success, comfort, and suitable circumstances.

Obviously, mastery of coaching a team to self-organize and helping teams and learn how to deliver working software every iteration is a study that can consume an entire career. In the meanwhile, Bryan's definition gives a good place to start the journey.

Labels: agile

posted by Esther Derby at 2:24:00 PM

|

I find that breaking working into iteration-sized chunks is one of the areas where many teams struggle as they start with Scrum or other agile methods. It's particularly hard for team who have been organized by component or layer (GUI, middleware, backend...).

Now Brian Marick has posted a nice example of how to break a feature down into stories on his site. This is the sort of concrete example that helps people translate the concept to their own context.

Labels: agile

posted by Esther Derby at 2:04:00 PM

|

A while back, someone told me that they were having trouble with their daily stand up meetings.

"What's the issue?" I asked.

"People don't like standing for such a long time," came the response.

I was puzzled. Fifteen minutes doesn't seem like such a long time to stand for most people.

So I asked more questions.

It turned out that the stand up meeting was lasting nearly an hour. The standup meeting started with one team, and as other people heard about how effective the meeting was, they started showing up. And talking. Pretty soon there were 40-some people at the meeting. So this meeting was something, but it wasn't a daily stand up (and it wasn't effective anymore, either).

All of which leads me to Jason Yip's article, It's Not Just Standing Up: Patterns of Daily Stand-up Meeting.

Most of what you need to know about stand up meetings. Thanks Jason.

Labels: agile

posted by Esther Derby at 6:22:00 PM

|

We've all heard the jokes about consultants who answer every question, "It depends."

Actually, it often does depend on the context. Not this time.

Someone asked me recently if ScrumMasters (or other agile coaches) should be involved in yearly performance reviews, ratings, and rankings.

You can read my unambiguous answer here.

Labels: agile, annual reviews

posted by Esther Derby at 10:18:00 AM

|