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!
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.
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?
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?
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.?)
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.
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?
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?
Are tasks being worked to completion?
Are team members being routinely interrupted and/or pulled off to perform other work?