Metrics & Velocity

I have received a few comments, both recently and in the past, that tell me some people are uncomfortable measuring velocity. And they are uncomfortable measuring the Team.

They are usually not that clear why they are uncomfortable.

Let me state my position, which I believe is also close to the position of Jeff Sutherland and Ken Schwaber.

First, as a memory device, I say: "Velocity: Don't leave home without it."

Second, any decent Team wants to know if they are really successful.

Third, the Team must measure velocity and it must aggressively be trying to improve it. Doubling velocity in the first 6 months should be a goal. In Scrum, the larger goal is to get the Team to be 5x - 10x more productive than the average Team. (Good data tell us that the average is about 2 Function Points per man-month.) Scrum does not guarantee that every team will get to 5x-10x. But none will if they don't go for it.

Improving velocity means removing the top impediment, one at a time. It does NOT mean working harder. In fact, often one of the top impediments is that we are already working too many hours per week. (To some, this will seem a paradox. Explanation another time.)

How do we use velocity? Many ways, but I will emphasize three. (1) In planning, to plan the release, for example. (2) To push back with a pattern of numbers when magical-thinking managers ask the Team to double their velocity in one Sprint. (3) To challenge ourselves, as a Team, to get impediments removed so we can enjoy some real success around here. (And often we have to ask managers and even senor management to get involved with the impediment removal.)

What are the push-backs that I hear?

Several. This post is getting long enough that I won't state them all hear.

But the cartoon represents one of the major ones, I think. People are concerned that we are putting human lives in the hands of some stupid bean counter (as we say in the South "bless his little heart"). Certainly not a happy thought.

So, a few assertions about metrics (not time here to discuss them):
* the Team does the metrics themselves, honestly because they want to use the numbers
* there should be no "managing from behind the desk" (as Lean would say)
* velocity does not reflect one single factor, but the result of all factors
* when the Team evaluates velocity, they use human judgment (Ex: "the velocity dip last Sprint was mainly due to Vikas being out sick 4 days; he's fine now")
* people want to see clearly and show that they are successful
* velocity is not supposed to be a tool for Dilbert managers to beat up the Team with
* while every metric will eventually be gamed (eg, due to Dilbert managers), these issues are part of the larger imperative of honesty and transparency in Scrum. Occasional gaming is not a reason to never do any metrics
* Velocity is not the only important metric

How Managed Service Provider Accreditation Helps Buyers

In today's changing volatile economy, companies find the predictable monthly service charges of a managed service provider (MSP) highly attractive. They can deploy technology, confident that they're not pouring money down a black hole. The problem is, scads of technology providers are now trying to recast themselves as MSPs.

How can you tell which ones are qualified?

That's Charles Weaver’s job. He's CEO of the 8,000-member International Association of Managed Service Providers. His nine-year-old group offers an accreditation program for managed service providers, and it's closer to a bar exam than a pro forma blessing. No MSP has ever received a perfect score, and it can take as many as three tries before a company passes. (For more on MSP accreditation, see When Selecting Qualified MSPs, Assume Nothing.)

Part Technology, All Business
The Managed Services Accreditation Program (MSAP) has two parts: a written exam and a physical inspection. The written exam is only about one-fourth weighted toward technology, says Weaver. The other 75 percent relates to the business. "It's not a technology certification. We look at everything from their financials to their facilities. We make sure they're a healthy stable company. We ask questions about disaster recovery and security, but a lot of the exam is designed to determine their financial stability."

The physical inspection follows, during which Weaver or one of the 15 IAMSP board members visits the facility. They check for physical security and process documentation, among other issues. "Documentation is a big problem at the small and midsize service providers," says Weaver. "They fail to write things down, and that puts their business at risk." If they fail the test, the IAMSP shows them how to improve, and they can take the test again (at a cost of $1500).

Dealing with Growth
The accreditation program has been so successful that Weaver is hoping to set up partnerships with consulting firms to help MSPs prepare. The IAMSP has already added sub-categories relating to accreditation for green IT facilities and master MSPs (those who lease services to smaller MSPs).

But keeping up with the growth in the industry is keeping Weaver busy. "Companies are demanding managed services because they're trying to cut costs. But they're finding very green, very immature vendors who say they're an MSP because they went to a seminar," he says.

If you're entrusting your company's technology to an MSP, then invest the time to determine whether your MSP is accredited, and what that accreditation process involved.

How to Enable the IT to BT Transformation

According to Forrester Research, as technology becomes integral to all types of commercial offerings and associated business strategy, the traditional model of IT as an independent and monolithic entity is clearly obsolete.

A proven Business Technology (BT) model will replace IT's legacy orientation -- with a focus on providing business value through process-governed services, measured in business-relevant terms.

Forrester believes that all business professionals should understand what is driving the shift from traditional IT -- as well as the key challenges around strategy, process, and culture when implementing BT practices.

So, how do you avoid the mistakes of the past, and pro-actively transform your IT capability to address today's apparent challenges? Forrester offers three key suggestions.

Deliver services and value, not hardware and software
IT's traditional focus on system components means that it has neglected to maximize business-relevant services for its internal customers. This piecemeal approach led to excessive complexity and redundancy.

In contrast, BT convergence is meant to align or better synchronize disparate processes and technologies into integrated services that provide value to the business user.

Organize around holistic processes and a lean culture, not silos
Instead of allowing low-level tactical responses to proliferate, BT relies on a broader view of IT processes in order to make decisions that maximize value for business users.

This process shift must often be accompanied by a culture change. Lean methodologies and behaviors shed the traditional IT use of one-off workarounds in favor of continuous aggregation, experimentation, and learning that keep sight of overall business objectives.

Measure performance with business-relevant metrics, not IT assets
BT also means stronger performance management systems. IT has traditionally focused on providing resources that sometimes don't have a clear impact on business outcomes.

As an example, server availability and capacity utilization, while important, are not relevant to business executives. By replacing technical benchmarks with metrics like alignment to business strategy and IT spend ratio, the BT model enables decision makers to objectively consider business cases for the inherent value they provide.