This week I cover the same topic in a 2 minute video.

Which one has more impact in delivering the message? Which one captures my emotions about this topic? Text or video?

Be The Change You Wish To See – Project Shrink Episode 23

How do you get your team to do the right thing?

Show them. Do the right thing yourself. If you want to see some fabulous behavior in your team, be fabulous first.

Bas de Baar helps people find ways to enjoy the diversity of human interaction in their organizations so that they can get out of their own way and achieve their goals. - The Problem Might Be You – Comparing Text With Video is a post from: Project Shrink.

You can watch the episode below or follow this link.

Subscribe with iTunes to “The Project Shrink Podcast”
Full Video Version of Project Shrink videocast

Bas de Baar helps people find ways to enjoy the diversity of human interaction in their organizations so that they can get out of their own way and achieve their goals. - Personal Productivity – The Power Of Slow is a post from: Project Shrink.

Managing projects is all about finding balances, finding the right touch for the right occasion. Jerry has has identified 6 of these balances and calls them “gray areas”.

He answers the following questions:

• How can one meet the needs of individuals and the needs of the organization?
• How can you maintain a sense of order without compromising productivity?
• How much can you trust the people on your team to do what they’re supposed to do?

You can watch the interview below or follow this link to YouTube.com.

You can find more information about Jerry on his company website, or you can visit his blog.

New: Subscribe with iTunes to “The Project Shrink” episodes

You can subscribe to this (and all other) video(s) using iTunes. It is available as a full video version or audio (mp3) only.

	Subscribe with iTunes to the full video version of Project Shrink videocast
	Subscribe with iTunes to the audio only version of Project Shrink podcast

Bas de Baar helps people find ways to enjoy the diversity of human interaction in their organizations so that they can get out of their own way and achieve their goals. - Managing The Gray Areas With Jerry Manas is a post from: Project Shrink.

Next to “communication” the keyword is “transparency”.

What happens if you take this to the next level? What if the productivity of the developers is captured by a third party? What if the “know-how” of your team members is directly visible to your customers? Talk about Transparency!

Programeter has just launched their Outsourcing edition. As a service provider you use it to check in your code base and it provides you productivity and competence metrics. Now your customers can view the same metrics.

Image by Programeter.

“Look at contributions of your project team members while they proceed with development of your software product code, and mitigate project risks with an unmatched level of remote project transparency.”

Is this the ultimate transparency? Will this be a new prerequisite for service providers; “you have to be on Programeter to earn our business”?

What do you think?

Bas de Baar helps people find ways to enjoy the diversity of human interaction in their organizations so that they can get out of their own way and achieve their goals. - How Fast Does Your Vendor Go – Transparency In Outsourcing is a post from: Project Shrink.

1. Programeter is a tool that measures “meaningful” productivity metrics. What do you measure and why is it considered “meaningful”?

First of all, it is important to mention that Programeter is focused on measurement of teams and individuals. In contrast to many other measurement tools in software development we do not measure quality of the code. We try to provide information about the most valuable resource in the software development and it is developers themselves. There are two important aspects which Programeter is measuring. It is CONTRIBUTION and KNOW-HOW.

Contribution Indicators

• Contribution Size illustrates the size of code produced by the developer during the reporting period. Size is measured in lines of code and takes into account new lines added by the developer, lines that developer has modified and lines that he has deleted.
• New Code is the number of new lines of code that developer has added during the reporting period.
• Modified code is depicted by two indicators, namely “other” and “own”. These indicators represent amount of lines of code modified by the developer during the reporting period. If the developer has modified a line of code created by someone else, then the indicator “other” is increased by one. And if he modifies a line created by himself, then the number “own” is increased accordingly.
• Deleted Code is traced in a same manner as modified code, by two indicators “other” and “own”. They keep the count of lines of code deleted during the reporting period. Each deleted line increases either indicator “other” or “own”. If developer deletes his own line of code then the indicator “own” is raised by one. If the deleted code was created by someone else, then the indicator “other” is raised consequently.
• Active Days illustrates the number of days when developer was making code contributions.
• Activity developer’s or team’s activity during 1 month. It measures the number of components and frequency of modifications made to them by the given developer (or team).
  

Know-How Indicators

• Know-How Score illustrates the breadth of the developer’s knowledge in the project. The value is measured on the scale from 0 to 10. For example, the know-how score of 6.5 in certain project, means that developer is capable of working alone with most project components.
• Fresh Know-How represents the knowledge that was refreshed during the reporting period. For instance, if developer A has developed component “C” in the product and he has done changes to this component during last month, then it will be counted in his fresh know-how.
• New Know-How measures only knowledge that was introduced during the reporting period. For instance, if developer A has created new component “C” in the product during last month, then it will be counted in his new know-how.
• Unique Know-How similar to know-how score, but measures only knowledge that is NOT shared with other team members. For instance, if developer A has developed component “A” in the product and nobody else contributed to this component, then it will be counted in his unique know-how.
• Shared Know-How similar to know-how score, but measures only knowledge that is shared with other team members.

Why our metrics are meaningful? The key goal of our R&D is to make sure there is a way to apply our metrics in real-life. Instead of bringing mathematical proof I will give you an example:

Programeter has a metric called “know-how”. This give you the numeric representation of one developers breadth of knowledge in given product/project. We also can identify “unique know-how” which tells how much of know-how is unique to this developers. By unique we mean that only this developers to those components. Now lets imagine, there is developer in a team which has unique know-how 2.0 (20%) in project A. Now if the person with unique know-how of 2.0 goes away project and resource manager have good idea of how much they loose. They also turn to Programeter to find out which component were developed by leaving employee to make sure know-how transfer will happen efficiently.

2. Every team member can view the performance and contribution of the other team members. This can empower people to help each other out and focus on the overall team performance. What are the experiences so far? Does this actually work?

We are still in private-beta, so it is too early to do conclusions. Actually, that is the reason we wanted to outreach developers community so anybody could share their opinion whether it can really help you out.

One interesting example shared with us by one of the developers trying out the Programeter. He has used his profile reports to negotiate the salary with his manager. He used the report to convince his boss, that he deserves better salary. Without the Programeter reports he would lack any reasonable tool to proof that he is right.

3. Metrics can also be used to “do evil“. What are the characteristics of the companies / organization where this concept might not be effective?

There are so many tools that in hands of uneducated or inexperienced people that could be used as “weapons”. What we always tell to our users is that be sure to think carefully when interpreting the indicators. Metrics are often the reason to ask new questions. Those helps you to identify problematic situations, which you would miss otherwise.

So if you ask, which company would be the best users for our tool. It is the team with smart programmers, smart project managers and experienced top level management. They would get the biggest benefit. I would not suggest to implement the measurement system in a company which is stressed by low-quality, constantly missed deadlines and too emotional employees.

4. What is “The” story you tell at a diner conversation to illustrate the power of Programeter?

Imagine you have a big software development team. Lets say 100 developers. Would you agree that 20% of this team is not used to full-throttle? Usually the reasons for that are poor management, poor expertise, miscommunication, emotions, … Programeter would allow you to identify those 20% correctly and give them another project where they would be able to show-off the full productivity. So you can achieve the same result with smaller team. It give benefits both for programmers and managers. Programmers become valued at new project and managers can better manage the rest of the team.

More information about Programeter can be found on their site.

Bas de Baar helps people find ways to enjoy the diversity of human interaction in their organizations so that they can get out of their own way and achieve their goals. - How Fast Does Your Developer Go? Measuring Productivity Metrics With Programeter is a post from: Project Shrink.

So, the question if specifications are worth the effort is legit. Jeff Sutherland quotes some research in this area in his article Future of Scrum: Support for Parallel Pipelining of Sprints in Complex Projects

Two metrics are mentioned: the productivity of the development group and the defect rate. In a tongue-and-cheek definition, the productivity is the amount of features / lines-of-code build in a given time frame, and the defect rate is the number of bugs found per amount of features / lines-of-code.

The article of Sutherland mentions that there is a strong relationship between the completeness of the formal specification and the productivity. The better the sense of the developers is of the desired end product from a functional perspective, the faster the program.

The other way round with completeness of design specifications and the defect rate. The relationship between them is found very weak. So, writing more detailed designs before programming doesnt reduce the amount of bugs.

Leaving us with the question what can we do about defect rate and productivity. In the mentioned article the following options are provided for lowing the defect rate: early prototypes, design reviews and testing at code check in. Increased productivity is reached by early prototyping and daily builds of the software.

Bas de Baar helps people find ways to enjoy the diversity of human interaction in their organizations so that they can get out of their own way and achieve their goals. - Specifications and Productivity and Defect Rate is a post from: Project Shrink.