Consultant Frustration Coefficient

Talking to Joey B this evening about creating a tool that would measure how frustrated you may become with wanting to mentor a team on Agile development practices. I am calling this the Consultant Frustration Coefficient.

What you would do is hand out a short questionnaire that would ask varying questions to assess the client’s value system and the staff’s literacy level as it relates to development pragmatic practices.

The result would look something like this:

• Code: Staff shows a firm understanding of claiming to know OOP however certain frequencies indicate that staff view OOP as COBOL syntax with many function libs. Caution should be taken.
• Design Patterns: Staff shows understanding of design patterns relating to UML documentation. All indicators are pointing towards an automated code creation and wizard driven setup culture. Caution should be taken.
• TDD: Staff understands what Unit Testing is but does not understand why they should write test that QA should be writing. They do not want to use open source libraries. Critical deal breaker here! Extreme Caution!
• Paired Programming: Staff indicators show extreme frustration with one another and would rather work alone in their cubicles on development task. Caution should be taken.
• CI: Management indicators show reluctance to increased time spent outside of coding and server setup. Good luck getting it passed management. Staff may show resistance. Caution should be taken.
• Agile: Staff has the probability of buying into it but management value system does not lend itself to embracing agile. Caution, you may be wasting your time.

Any other categories that we should collect? 🙂