Agile Mind Tuning: Is it a Loss of Diversity

Orchestrating a diversified team can indeed enhance the higher level of harmony!


Agile philosophy advocates collaboration and “working together” to cheer customers. An interesting debate would be: Is it a loss of diversity as sometimes “working together” can be translated as “don’t make trouble for anyone than expressing conflict.” Or even “don’t take any risks, don’t come up with new ideas…”. Accepting that this is a problem for a moment, the next question is how big a problem is it?

Harmony is not opposite of diversity. In general, the overriding principle of agile practices seems to be "the customer may not always be right, but the customer is always first". Considering that to be the case, there is nothing wrong with the team being in complete harmony and thinking as one mind. In each of the cases, the customer or product owner has no complaints. Why would they? They are getting the product delivered. Orchestrating a diversified team can indeed enhance such higher level of harmony - the creative harmony through the diversified thought or thinking processes; the strategic harmony based on the alternative options or multiple choices; and the overall business harmony built through better integrating diversified functions and teams to run as a holistic organization which is optimal than the sum of pieces.

The team needs a challenge. If ideas aren't being challenged, it is likely they are sub-optimal. Faulty assumptions are unspoken and become a weak foundation for implementations. If there is no push back against the status quo, it becomes the stagnant quo. Perhaps the issues include: Would they be open to picking one for themselves, or would they need one foisted upon them from outside? Teams would think "nearly impossible"; treading the line between not getting buy-in and not making a significant improvement. In the spirit of “only the paranoid survive”, you likely have competition or soon-to-be competitor who is learning/advancing/improving more quickly than these teams and that is eroding your competitive advantage. Best solutions aren’t usually arrived at without some disagreement to drive the details. The problem might happen if you create a team of individuals who don't want to challenge themselves. You may want to move team members around until you create a team with at least few people who always wants to challenge themselves. Once all the teams have few members of that sort you will never face this particular problem. Why is it that they don't express conflict? Why do you assume they fear making trouble? Perhaps when they have, they haven't been able to resolve differences or expressing conflict had a negative effect on their career. Coming to a resolution in a conflict situation is a skill in itself. So take a look at how conflict is viewed in your company. Are they really afraid to make trouble? If so, why?

Building high-performing team: Innovation and high performing teams may not necessarily come from creative conflict, it can even come from motivation and willingness to innovate. The teams, regardless of the meeting, including retrospectives, seem more concerned about collaborating and "working together" (translated as don't make trouble for anyone) than expressing conflict. But what is really worse is that in what have been observed, there does not seem to be any conflict. They just don't take any risks, don't come up with new ideas, and don’t reach; they continue to do the same old in the same old way. The bottom line is that you are getting a routine set of features delivered in a routine way. However, the better way is to continue to improve and optimize solutions to delight customers.  

Diversity itself is not a goal; it is the means to execute strategy more effectively.  It is rather a means to get all specialists working together towards a common goal; to limit the communication issues etc. But if you have an issue in complacency, lack of creativity, lack of eagerness, or anything else, then it is easier to come up with solutions. Maybe it could also be worth looking into what you are afraid of that might happen. What is the outcome you do not want to happen? The central question remains: do you have a problem? And if so, what is that problem? This may lead you to some clues of what is really going on. Ideally, you could use some retrospectives for this. The retrospective *should* be the point where the team takes a step back and a look from a different perspective; it's there to try and find *different types* of the issue by thinking in different ways. Indeed, this discussion is all about one such issue, because one person took a step back and in doing so perceived a potential problem. It's not only okay, but *good* to ring the changes within the retrospective; and in keeping the "shake-up" there and more-or-less ring-fenced, you have much lower risk of upsetting the good parts of the status-quo. Ask the following questions: 
(1) Are more senior staff mentoring junior staff, growing junior team members skills and building leadership skills in senior staff? 
(2) Do you have cross team member collaboration, especially with senior team members where they can learn from each other? 
(3) Do you challenge and/or reward team members to excel or go beyond their daily role? 
(4) Do you have career paths clearly defined and all team members know what they need to get to the next level? 
(5) Are you following all software development best practices? If not, are you challenging teams to adopt them? 
(6) Is the team allowed to inject their own improvement ideas into the process, retrospectives? 
(7) Are the teams allowed to try improving ideas and fail? 

Diagnose the root causes for the lack of skill diversity: If you want to encourage skill diversity, streamline process to encourage collaboration, also provide an opportunity for members of the team to expand their expertise, perhaps in a different area. Be willing to provide the necessary training for them to expand in a new direction. And reward staffs who take advantage of the opportunity. Diagnose the issues upon business process, governance, talent management, or more issues such as:

     (1)   There is no technological or business need for much interaction with other teams. 

(    (2)   There is no formal process cross team collaboration.

(    (3)   Team members are not rewarded or challenged individually since this is deemed un-agile.    

(    (4)   No career paths. The companies lack talent management plan about what to do with the team members from an agile team when the project is over. 

(    (5)   Agile principles are not being followed in the right way: The process has varied from vanilla Scrum due to various improvements they made over the years through retrospectives and adjustments to their styles, but they might not follow good engineering and software development practices effectively

The general sense in the agile community is that diversity is good and creativity and innovation come out of the conflict. Improving is usually good. On the other hand, change for the sake of change is not good. There should be a reason for shaking things up. Certainly the fact that a group is harmonious and well performing is not a good reason for forcing them to change. One needs to understand the problem and the expected results before making the change.