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

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  

|

Last week, I wrote a post about decisions that look only at easy-to-count costs and ignore hard-to-count benefits.

Here’s one method for estimating hard-to-count benefits, subjective impact analysis:

1. Identify the proposed course of action.
2. Determine what’s important to the person who makes the decision.
3. Ask that person who they consider credible sources related to the issue.
4. Create a short interview protocol.
5. Interview the people the decision maker identified as credible.
6. Summarize and present the results.

Here’s part of a subjective impact analysis I did for a client a billion years ago (suitably scrubbed).

The client was a VP in an IT operation. The business was livid about the production problems and outages that followed when the IT group installed new functionality.

When I looked at the data about outages, it was pretty clear that the worst problems came from the hand-off between the development folks and operations folks. I poked around, and found that the two groups weren’t working together.

So I suggested a little experiment: a “readiness review” prior to installing a change where the development people and the operations people would sit down together and walk through the installation. And I created a half-page checklist for the development people to actually write down critical information for the ops folks.

Then we tried the experiment. We held a "readiness review" for a smallish update to the production systems. The meeting took about 45 minutes.

After the “readiness review,” the IT managers told the VP they were concerned about adding another meeting that took away from development time. The developers complained about the burdensome documentation (half a page).

The costs were obvious.

The benefits were not so obvious.

So I did a subjective impact analysis to show the benefits (if there were any).

Here’s what the VP valued:
• Avoiding production problems
• Improving the application
• Taking a proactive stance

I asked a cross-section of the people who participated in the review these questions:

1. What gaps and issues came up in the review that could have caused problems had they been discovered in production?

• What was the biggest problem discovered in the review?
• On a scale of 1 – 10 (1 = negligible impact, 10 = disaster), how big would that problem have been?

2. What was the team able to do to improve the application because of the review?

3. What problems did the team fix before they hit in production?


Then I summarize the data and presented it to the sponsor. Here’s the data from the first question.

Problems Discovered in the Readiness Review
(1 = negligible impact, 10 = disaster)

10 ****
9 *
8 ***
7 **
6 *
5 *
4 **
3
2 **
1

(This represents each person's assessment of only the biggest problem, so it’s a subset of the problems. For the most part, the development folks identified lower impact problems, the ops folks higher impact problems. Very interesting...)

This little data table helped people see the benefits of the readiness review, as well as the costs.

(Obviously, there were lots of other issues with this organization. This was a starting point to bring the level of conflict down enough for people to look at underlying problems.)

I did this subjective impact analysis after the fact, but you could easily adapt it to estimate benefits before making a decision.

Labels: change, leadership, methods

posted by Esther Derby at 8:32:00 AM  

|

Via Testing Reflections:

Jared Richardson (co-author of Ship it! A Practical Guide to Successful Software Projects) explains how to do a quick peer code review.

Another low tech way to improve the quality of the software we deliver.

Labels: methods

posted by Esther Derby at 5:12:00 AM  

|

There's been a discussion going on the the Retrospectives list on how to do distributed retrospectives and planning meetings. The assumption is that it's cost prohibitive to bring the group together.

People always site cost as a barrier. It does cost money to bring people together face to face. There's lodging, airfare, time not spent on billable activities... and all these are easy to count.

But what this thinking doesn't take into account are the costs of not having the team face to face for planning and retrospectives:

Less collaboration, greater misunderstandings, continuation of us/them dynamics (be they ever so subtle there's always differences in access to power, information, and resources), miscommunication, etc.

And there's lost opportunity to build relationships and trust which short-cuts many of those problems.

But all those are hard to measure and quantify, and are almost always left out of the cost equation. People look at the costs without any of the benefits.

Even when you have access to great technology for planning, retrospectives or other forms of collaboration, face to face is still superior for communication and collaboration in the moment and in building a foundation for future communication. Face to face is superior in building shared commitment and infusing a project with energy.

Labels: communication, Retrospectives

posted by Esther Derby at 2:45:00 AM  

|

Every so often, I share my views on pay-for-performance and annual performance appraisals on this blog. My experience is that pay-for-performance and annual performance appraisals--contrary to popular belief--actually hurt performance and results, rather than driving higher performance.

So I was interested to learn, via Bob Sutton's blog, that Jeffrey Pfeffer (co-author of Hard Facts, Dangerous Half-Truths And Total Nonsense: Profiting From Evidence-Based Management and author of several other books on management)was called to testify before Congress on the matter of pay-for-performance.

Pfeffer's testimony walks through the assumptions underlying pay-for-performance,

Money is an important motivator.

Motivation is the issue for enhancing performance.

Individual performance can be reliably and unambiguously assessed.

Individual, rather than collective, rewards are important because of the need to overcome free-riding problems.

Differentiation in individual rewards, a necessary and frequently explicit consequence of individual pay-for-performance systems, leads to higher unit performance.

....and lays out the evidence related to those assumptions. (They don't hold true when you actually look at the evidence.)

He also points out that when the explicit and implicit message is that people (and their contributions) aren't valued, tweaking the compensation system won't overcome the depressive effects on performance.

If the senior managers at a company really want to improve performance, tinkering with the pay system isn't the way to go about it. Addressing the underlying culture and quality of management is.

Although the list of high commitment or high performance work practices differs slightly among authors and studies, most such lists include: a) sustained investment in training and development, including job rotation, both formal and on-the-job training, and a tendency to promote from within as a consequence of the successful internal development of skill and people; b) an egalitarian culture in which formal status distinctions are downplayed, salary differences across levels are less than in the general economy, and in which people feel as if their contributions are important and valued; c) delegation of decision making responsibility so that skilled and developed people can actually use their gifts and skills to make real decisions; d) high pay to reduce turnover and attract the best people, coupled with rewards that share organizational success with its members; and e) employment security and a policy of mutual commitment, so that the workforce does not fear for the outcomes of events over which it has no control and instead, feels reciprocally committed to the employer.

He ends his testimony with this statement:

We should implement what we know, rather than what we hope, or wish, might be true.

Read the full testimony here.

Labels: management

posted by Esther Derby at 7:50:00 AM  

|

I wrote a little article on dealing with co-workers who annoy you. (Not surprisingly, the solution starts not with the co-worker, but with you.)

Labels: personal effectiveness

posted by Esther Derby at 6:41:00 AM  

|

From an interview on Workforce.com.

Ram Charan defies traditional notions about leadership. It’s no longer enough for leaders to be charismatic and courageous to be successful, he says. Instead, they need to hone their skills to address the needs of their organizations...

Workforce Management: What is new about your perspective on leadership?

Ram Charan: In the past, most people have talked about personality when they talk about leadership. They think that leaders are born. My view is that once you are 22 or 23 years old, you have a basis of who you are, but you don’t have the skills yet to be a leader. Many leaders today are great communicators and are charismatic, but that’s not enough. If they can’t perform, they are out. To learn how to perform as a leader, they need to practice through real-life experiences.

WM: How does one "practice" leadership skills?

Charan: You practice the ability to handle diverse experiences. You move from one business to the other and develop your skills as you move along. You learn how to work in a team and how to create change.

Leadership isn't about personality or charisma. It's about understanding and skills. That means leadership can be learned, and that leadership looks different in different circumstances.

Labels: leadership

posted by Esther Derby at 6:29:00 AM  

|

Via Frank Patrick, Mihaly Csiksczentmihalyi on the componenets of enjoyment and flow:

Eight Components of Enjoyment

1. Confronting tasks that we have a chance of completing.

2. Concentration.

3. Concentration is possible because the task has clear goals.

4. Task provides immediate feedback.

5. A deep, effortless involvement removes from awareness the worries and frustrations of everyday life.

6. Enjoyable experiences allow one to exercise a sense of control over one’s actions.

7. Concern for self disappears, yet paradoxically the sense of self emerges stronger after the flow experience is over.

8. Sense of time is altered - hours pass by in minutes.

Labels: personal effectiveness

posted by Esther Derby at 6:15:00 AM  

|

George continues the exploration of the Prime Directive.

Labels: Retrospectives

posted by Esther Derby at 7:46:00 PM  

|

I came across a spate of articles lately proposing different reasons why some managers fail. The reasons ranged from rising to their level of incompetence, becoming corrupted by power, promotion by favoritism, and not being a "born leader."

I suspect the reasons are less nefarious.

I suspect managers fail because they haven't developed the skills to be a good manager.

I don't buy that successful managers are "born leaders." I believe that successful managers have skills and abilities related to both management and leadership behaviors. And, my experience is that except for those rare birds who just don't like working with other people--people can learn the skills and develop the abilities to be successful managers. (Assuming reasonable emotional adjustment, self-awareness, and the ability to inspect and adapt their own behavior.)

Of course, it's harder to learn those skills and develop those abilities when there aren't good role models, and when a new manager doesn't have coaching and support to improve.

So if you or someone you know would like to work on their management skills and abilities, consider coming to the Managing One-on-One workshop Johanna and I are offering April 23-25, right here in lovely Minnesota (the show should be gone by then).

Labels: management

posted by Esther Derby at 8:13:00 AM  

|

Via Johanna: The Rules of Office Romance, on Information Technology Dark Side.

Most advice regarding office romance will tell you to be discreet, steer clear of your managers and subordinates and review the HR policies. That advice assumes you are going to stay with a company and can successfully navigate the political hailstorm you will fall into. The better advice – advice that is both easy and foolproof – is just don’t do it.

And if you fail to follow this clear cut advice...

In the mean time, you will have to deal with increased HR scrutiny, jealous coworkers, office rumors, productivity losses, suspicion of favoritism, potential career damage, loss of power and the threat of sexual harassment lawsuits.

That's while you are dating. When you break up, it gets really ugly.

The original post also includes a handy chart to help you determine when to pursue an office romance.

Labels: personal effectiveness

posted by Esther Derby at 6:14:00 AM  

|

Diana Larsen has an article on Appreciatative Retrospectives posted on the AYE Conference site. Appreciative retrospectives build on strengths and look to create the circumstances that enabled people to be at thier best.

(Diana will be one of the guest presenters for the 2007 AYE Conference.)

Labels: Retrospectives

posted by Esther Derby at 6:06:00 AM  

|