Lot of people think resistance is the worst enemy of an influencer.

Over the years, I realized that resistance is really a bliss in disguise.IMHO

• Without resistance there might be only one side of the story
• Without resistance one might seize to find new, better ways of doing things.
• Without resistance the risk is completely on you. If anything goes wrong, it would be easy for people to just point at you saying it was her/his idea.
• The worst thing is without resistance I feel people are not passionate about the topic at hand and they are just indifferent. Which means they will not give in their best to make it happen.

Some people talk about healthy resistance and baseless resistance. Personally I don’t see these 2 forms of resistance. When something appears to be baseless to me, I think I’ve not done my job of actually understanding and seeing from the other person’s point of view. A lot of times doing so, provides very interesting insight to various other things as well.

As easy this might sound, dealing with resistance is quite taxing and sometimes the best policy is to let it go and then try to change it later from a different perspective. Influencing is a two way street and is a great opportunity to learn something new.

Clarity of Thoughts and Clarity of Actions is very important when it comes to influencing people around you.

The how do you get clarity of thoughts and clarity of actions?

Staying in the trenches yields insights.

Continuously reflecting yields clarity and fuels new ideas.

Trying to teach others help in formulating and articulating your thoughts.

Last but not the least, working with smart people helps you become a good influencer.

Working with smart people is very important because they don’t just ask you “Why?” but they also ask you “What is the alternative?” or “What are the trade-offs?”. Lot of times, I get into the mode of “This is THE way to do this”. And when faced with the alternative or trade-off question, really forces me to think. This really helps me find new, interesting ways to solve the problem or at least helps in clarifying my thoughts.

I find “Leading by Example” is a great way to influence others. I see a lot of people trying to influence others by pointing at their mistakes and trying to correct them. But they themselves don’t walk their talk. This form of influencing is very harmful and short-lived. Agile Consulting is a great example of this.

Existing literature on Agile seems to suggest that a team is self-organized when

• The team is cross-functional and is self-contained (has all the roles required to perform the team’s activities)
• The Pigs (team members who do the actual work) estimate and commit to work, rather than the Project Manager or lead developer.
• Team members pick the task they want to work on from the story board without, someone having to assign them a task.
• The team is able to take decisions themselves and accordingly adapt to changing situations. Decision making process is distributed amongst the team members instead of one central decision making authority.
• Team self-organizes based on its strengths and weaknesses instead of job titles to do the work at hand. If the testers are overwhelmed, developers may have to help testers
• Team members communicate more often and spread knowledge around much better and make decisions together

And so on….

While I truly believe in the importance of self-organization and how the above list ensures that teams are self-organized. I see a lot of teams struggle being truly self-organized and reap its benefits. Agile methods like Scrum and XP have been around for over a decade and they have many practices to help team self-organize. Still teams find it difficult.

What is missing? Why cannot teams easily self-organize?

• Some people suggest that you really need a mature team for this to work.
• Some people suggest “Self-organization rarely happens on its own” and hence teams need a good coach or Scrum Master to ensure they can actually self-organize.

Based on my personal experience, there is a key ingredient missing. If you want your team to self-organize give them the ownership. Without having a sense of collective ownership on the project or product, it is very difficult to achieve self-organization.When each member of your team feels like they own the product, there is a big shift in attitude. They collaborate more tightly and try different things to make it work.

Rights and Responsibilities go hand-in-hand. While you want the team to be responsible, you also have to give them rights (ownership).

Following are the code quality criteria I came up with and asked the team to rate themselves against it:

This list will only make sense if you’ve read the context from the previous post.

• Conceptual Integrity: Does the design of various components feels seamless? Do you feel the application is build out of random, incongruent components that have just been plumbed together?
  • Do you have odd ball solution smell between various components?
  • Consistent error messages are used throughout the application
  • Navigating from one part of the application to another part feel like one smooth flow.
• Appropriateness: How appropriate is the current choice of technology stack? Are we using the right technology for solving the right problem and are we using the technology appropriately. How well the software is using the supporting framework and underlying building blocks?
  • If its using a RDBMS, is your data really relational data
  • If you are using a framework like Wicket and not really using component based design for webpages
• Understandability: Is the code and the concept behind it easy to understand? Is the purpose of the product clear? Purpose of the product goes further than just a statement of purpose – all of the design must be clear so that it is easily understandable.
  • What do you think of the Code’s Complexity? (Are branch decisions too complex?)
  • Are variable names descriptive and representative of the right entity?
  • How much documentation is required to understand the code and its design?
• User Experience: Do the Users enjoy using the product? It is convenient and practical to use. This is affected by the human-computer interface, but goes far beyond just the GUI.
  • Is the user interface intuitive?
  • Is it easy to perform any operations?
  • Is the complexity of difficult operations hidden away from the user?
  • Does the software give sensible error messages?
  • Do the widgets behave as expected?
  • Is the user interface self-explanatory/self-documenting?
  • Is the user interface responsive or too slow?
• Conciseness: Is there excessive (redundant) information present? In other words, does it follow the DRY (Don’t Repeat Yourself) principle?
  • Code is easy to understand and has optimal amount of code (small well defined classes) and configuration.
  • Does the code have Dead Code Smell (Is all code reachable?)
  • Is any code redundant? Duplicate Code Smell
• Adaptability: Is the code nicely decoupled? Does it have any irreversible design decision? More generic solutions does not necessarily mean more adaptable.
  • Can we use a different database?
  • Can we use a different third party library or framework?
• Consistency: Conceptually and Semantically, is the code uniform? Does it have consistent notation, symbology and terminology within itself?
  • Is one variable name used to represent different physical entities in the program?
  • Are functionally similar arithmetic expressions similarly constructed?
  • Does the code have odd-ball solution smell?
  • Is a consistent scheme for indentation used?
• Maintainability: Does the code facilitate enhancing existing features or adding new features to satisfy new requirements? Are you spending a lot of time fixing bugs on the existing code?
  • Is the design cohesive, i.e. , each module has recognizable functionality?
  • Does the software allow for a change in internal data structures (encapsulation)?
  • Well modularized?
  • Does it have a Solution Sprawl smell?
• Testability: Is it possible to establish automatable acceptance criteria and evaluate its performance? Complex design leads to poor testability.
  • Are complex structures employed in the code?
  • Higher test coverage does not always necessarily mean testable design.
• Reliability: Can it perform its intended functions satisfactorily every single time fast enough? The extent to which a program can be expected to perform its intended function with required precision. This implies a time factor in that a reliable product is expected to perform correctly over a period of time. It also encompasses environmental considerations in that the product is required to perform correctly in whichever conditions it finds itself – this is sometimes termed robustness.
  • Are boundary conditions properly handled?
  • Is exception handling provided?
• Structuredness: Are all the building blocks architected well? Right behavior exists in right places.
  • Is the business logic bleeding into the UI?
  • Is the code tightly coupled and dependent on external sub-systems like type of Database.
• Efficiency: Can it fulfill its purpose without unnecessarily wasting resources? (memory, CPU, external sub-systems, filesystem, etc). A performant application does not necessarily mean that its efficient. For Ex: one might throw a lot of hardware or put a lot of caching to make the app perform better, but may be there was a simpler efficient way. Lots of time, premature optimization leads to less efficient complex solutions.
  • Are we using Connection Pools efficiently?
  • Is your use-case flow logical? (logically inefficient)
• Security: Is the data protected against unauthorized access and does it withstand malicious interference during its operations? Besides presence of appropriate security mechanisms such as authentication, access control and encryption, security also implies reliability in the face of malicious, intelligent and adaptive attackers.
  • Does it allow its operator to enforce security policies?
  • Can the software withstand attacks that must be expected in its intended environment?
  • Is the software free of errors that would make it possible to circumvent its security mechanisms?
  • Does the architecture limit the impact of yet unknown errors?

I always find it very difficult to rate something using an absolute scale. Not sure if this is 1 or 2. Personally I prefer using a relative rating scale. Hence I came up with the following scale for the teams to use while they rate themselves on various criteria.

Recently @ a client, I was trying to figure out which product team needs immediate help/attention. Since I have limited time available @ the client location, it would be best to come up with some plan of how I’ll go around the various teams and help them. Trying to fix all the issues of all the teams is impractical. Once a team is identified, I can use Theory of Constraints (ToC) to figure out their biggest bottleneck and work my way up from there. Similarly I can use ToC to identify the biggest bottleneck team (Team which is doing critical work and is slowing other teams down). To be able to come up with an initial plan, I wanted to get a feel of how each team works and each team’s code-base and its design.

I started off by spending about 2-3 hours with each team. During this visit I was playing “health-inspector”:

• I asked the team to explain the product they were working.
• After understanding the product, I took a few relevant scenarios and asked the team to help me build a Value Stream Map.
• I asked the team to share with me what was causing most pain for them and what they thought was working well.
• I asked the team to walk me through their code-base by focusing on one specific feature.

At the end of this meeting we really did not come up with any action items (would be premature at this point). All we had, was a list of observations with the value stream map on a wiki-page. This list can be considered as an initial Debt list. This gave me a decent feel for how the team was working and the kind if issues they were facing.

(One thing I’ve learnt in my previous consulting life is, never take personal notes while people are talking to you on sensitive topics. If taking notes is important because you have been bombarded with information, open a simple text editor or wiki and ask them to summarize after they have explained a point.)

After series of meetings with various teams, I talked to the Business Sponsor and share my concern about the code quality. Trying to explain the details with off-hand random examples from the code was getting difficult. Reading through each team’s observation on the wiki-page was helpful but the results were very subjective. It was not clear which team needs immediate attention. So the Business Sponsor asked me if I could come up with some code evaluation criteria and rate various team’s code-base.

While this made sense, I was concerned that it would be difficult to come up with objective criteria which can then be used to identify which team needs immediate attention. Urgency of attention is to a great extent influenced by soft things that cannot be easily externalized in a metric. Even if we came up with some criteria, the value assigned to the criteria in some context is only relevant in that context. Each team might have a different context and comparing the teams in different context using the same criteria can be error-prone.

Anyway I decided to give it a shot. Worst case, we at least would have some baseline for each team that they can then refer back to as we starting resolving issues. But the question was who should rate the team against these criteria. Personally I’m very uncomfortable rating others. I also think it’s not effective. It encourages the wrong behavior in teams. So I decided to have the team self-rate them by having an open discussion within their respective teams. At least this will ensure everyone in the team is on the same page. And then if there was any difference between what the team rated themselves as and what I thought the rating should be based on my short meeting with them, then it could be easily resolved with an open discussion about it. In some cases I don’t have enough context as the team has.

Refer to How to Rate a Product (its code and design) for more details on the quality criteria and their rating scale I used.

Once I identified a rating system, I created a page with a simple table on the company wiki. Each quality criteria was listed as a Row heading and each team’s name as a Column heading. Each team was requested to rate themselves. After the teams rated themselves, in a couple of cases, I had a discussion with them about rating of specific quality criteria and came up with mutually agreed numbers.

Something very interesting (unexpected), happened once all the rating was done. Seeing all the teams’ rating on one page helped me identify trends across the company. For example Testability was an issue on most teams. This helped me come up with some basic training on Testability which most teams could attend.

It is not fair to compare one team’s rating with another. But certainly a team which has a lot of 1’s is in more need of attention than a team which has 3’s and 4’s. Again, just because a team is in need of attention does not mean one needs to jump straight into the team. We need to figure out where on the critical path of the organization this team lies. If this team is not on the critical path, may be investing time on another team would be fruitful (at least in the short run).

This approach really helped me come up with a 2-prong strategy.

• Define general training requirements for the whole organization which will help each team improve.
• Identify the team that needs immediate attention (bottleneck) and coach that team.