Don’t Measure. Diagnose!

March 11, 2011

I’m growing less found of the term metric. Particularly in how it is typically applied: as a measurement that leads to a judgment. And while some judgments are certainly a good thing – like recognizing improvements and/or excellence – there needs to something more to the equation than management simply measuring and judging.

Software projects always face a number of challenges, and management should be playing a supporting role with autonomous teams to help them reach their goals. There are ways the managers can do this, but measuring and judging alone won’t create a “partnership effect.”

Adopt the mindset of using diagnostics to pinpoint specific areas where you can help relieve pain, similar to a physician who is diagnosing a patient’s problem. And this won’t prevent you from noticing things that are particularly strong and worthy of recognition, either.

This might sound like semantics, but I feel that the difference between a metric and a diagnostic it is an important distinction.

For the purposes of this post, I challenged myself to list six key diagnostics off of the top of my head, ones that I use almost unconsciously, so this list shouldn’t be considered comprehensive. Each diagnostic is considered “good” if you are in the green zone, and a pain point you are in the red zone. The assessment is totally subjective, but if you are uncomfortable and can point to things that have definitely gone awry, you’re in the red; if you are confident and can point to specifics that support your confidence, then you are in the green.

I’m definitely interested in your list!

Communication is the foundation that brings a team together and is the means by which information is exchanged. People on teams need to be working well together to solve problems as well as raise issues related to how they are challenged, ideally working to resolve those issues within the team. This means that there should be open, honest communication where team members feel free to state their thoughts and opinions.

There should also be clarity in communications to the team about product features and answers to those inevitable questions that arise during the development cycle. Other communication involves outward communications to stakeholders who are interested in a project’s progress, challenges, and if there is anything that they can do to support the team.

Key Questions:

What mechanisms are being used to communicate product features, and is the team clear about what needs to be built?

Are questions being answered fully, completely and timely?

How much is the project team interacting amongst itself in the development of the product features?

Is the project progress known by all stakeholders?

Are concerns, challenges and issues being raised by the team?

This begins with a clear, compelling vision or purpose (which must be communicated). Each team member must also buy into that vision or purpose. And when they do, they will become energized, make strong personal commitments and proactively seek to contribute and add value.

Key Questions:

Does the team understand the project charter and objectives of the project?

Does the team appear divided or confused about its purpose?

Does the team identify more with achieving results than it does with following procedures?

Is everyone making a personal commitment and holding themselves accountable for delivering to the team?

Is there a lack of urgency?

Does there appear to be enthusiasm, or is everyone working in isolation?

Are people silent in meetings?

Are people not taking responsibility for their actions?

The fine print in every guide to running a successful software project – regardless of the methodology – is always stated along the lines of, “…staffing the project with good people.” (Yes, this is stating the obvious, but too often the approach gets more attention than the people.) Not every project has the same needs and you will need to bring junior-level people along, so balancing definitely comes into play.

Key Questions:

What is the technical level of competency required to meet the project’s objectives?

Does anyone on the team have prior experience in building something similar?

Is the project team staffed with team members that have the requisite skills and expertise to accomplish the work?

Are there people in over their heads?

Is the team approaching its work as disciplined professionals, applying practices and craftsmanship to their work that will produce sustainable results? (Is there a rush to begin coding with a lack of design? Is there an absence of code reviews, unit testing, continuous builds, etc.?)

Lyssa Adkins, in her book Coaching Agile Teams, points out the difference between cooperation and collaboration as follows:

Cooperation yields the sum of the individual parts.

Collaboration yields a whole that is greater than the sum of the individual parts.

Collaboration is particularly useful when dealing with complex problems because multiple people can generate more options and find a creative path – either solving a difficult problem or by introducing innovative ideas to meet a business need.

Collaboration on Agile teams requires that teams avoid putting too much work in process at any one time. They need to avoid the “swim lane” problem where individuals are working on tasks versus the team collaborating together on a subset of those tasks.

Key Questions:

Do teams have worked tasked out at an individual level?

Do teams use collaborative techniques like pair programming?

Is there a collective code ownership present?

When there is a difficult problem or complex programming task surfaces, do team members work together?

Relying on continual overtime indicates a scheduling problem. At best, overtime should be used to contend with an occasional challenge. Using overtime simply to meet an existing schedule will create problems downstream because the very things that contribute to well-designed software will get short-changed. That, and tired people make mistakes, which translates to more defects and more time and attention required to address those defects, which in turn impacts the schedule even more…

Key Questions:

Is the project team working overtime on a regular basis?

Does the projected schedule appear to require overtime to meet the project objectives?

Are people in on weekends and odd hours in addition to the regular work day?

Are there expectations that continual overtime is required?

Focus is important to productivity. If developers are pulled off of one task to work on another task, productivity will be lost because it takes time to recover from an interruption. Studies have put the cost of an interruption at roughly 20 percent, productivity-wise. Depending upon the complexity of the task being interrupted, the cost can be even higher.

Key Questions:

Are tasks being worked to completion?

Are team members being routinely interrupted and/or pulled off to perform other work?