My friend and former colleague, Alexandra Hurworth wrote this excellent article that was posted on LinkedIn that I read earlier this week. Besides it being wonderfully researched and written, it illustrates how professionals from different disciplines can enhance the overall work and product development experience by getting outside the bonds of their core disciplines (and training). Alex points out that stretching one’s skills and knowledge and taking risks to understand the perspective’s of other disciplines within an organization can be very beneficial overall.
Alexandra paints a vivid picture of how one can reach out and experience the thoughts of team members and managers from other disciplines. This dialogue and education can enhance the product that results from a multi-disciplinary effort. Besides enhancing the efficacy of the deliverables, Alex points out that one can grow and push their own boundaries of competence, enhance their stature within an organization, and strengthen the human capital of an enterprise by daring to collaborate. This comes about by stretching the “breadth” and “depth” of knowledge that one is willing to research and bring to the collective development “table”.
Alex stresses three things in her article (explicitly or implicitly): “constructive listening”, “organizational empathy” (a true desire to understand another discipline’s point of view) and having an intellectual curiosity or an “honest desire to learn” (at least at the level required to grasp important points made by the experts in another discipline).
This really resonated with me and motivated me to make some further observations about professionals working in a multi-disciplinary environment. Many times within a cross-functional team one set of professionals is tasked with “taking the lead” and “running the process” and they do so without listening to all stakeholders and allowing the best ideas to come forward. This lack of organizational empathy can happen with any group representing a functional organization.
This emphasis on process over cross-functional dialogue and “common sense” often happens with the Agile process administrators (scrum masters) who are tasked with keeping track of projects.
The Agile process emphasizes “rituals” that promote brevity and structure over cross-functional dialogue and understanding. Therefore a team is often forced into a situation where they cannot work together to solve problems constructively. The team is basically required to attend meetings where someone without much knowledge of the tasks at hand (usually the scrum master) requires team members to make brief observations about what work might be required to get something done.
If the team members are engineers, often “brief observations” are “wild guesses” that become hard and fast commitments as far as scrum masters are concerned. This can be very stressful to engineers or UX designers or others who need to really contemplate what they are being asked to build. They don’t want to guess and be wrong and have to live with the consequences (and criticisms) that will inevitably result from quick uninformed judgments. This adherence to ritual can be exactly the wrong thing to pursue if developing rock-solid and innovative products is the goal of an organization.
During the execution of these rituals the responsible professionals (again usually engineers or UX designers, etc.) are required to guess at how long it should take to accomplish the tasks they have not been allowed to really understand. In these cases the ritual did not allow the team to interact and promote the best way to accomplish the work. The ritual was more important than the project and this caused a lot of frustration and ill-will among the team. It undermined the team’s faith in its management because management was seen as empowering the ritual over best practice and understanding.
Even though some executives who embrace and promote Agile methodologies rightfully state: “we need to fail faster so that we can fix our mistakes sooner”, they don’t need to allow the process to almost require failure in the first place. My argument has always been that it is fair to allow failure but it is not intelligent to plan it into the process by rigid adherence to an incomplete and rigid methodology.
Again, ritual for rituals sake can be very frustrating to engineering and design people who may need to have useful interaction to get the tasks defined and understood. The bounds of the process don’t always allow for proper understanding of the tasks and thus doom the team to unnecessary failure.
As Alex pointed out in her article, everyone grows when they can collaborate effectively and learn from one another. A team of well meaning professionals will generally pick the best path to getting the work done if they are allowed to interact and achieve results. When they are forced into a ritual that is not promoting dialogue and understanding, results will be constrained and morale will suffer.
The best of the scrum master class can sense when a team needs to discuss things and let them “break the ritual”. If an engineer is taking ten minutes to discuss a tough problem instead of the two-three minutes the ritual has allotted, then the wise scrum master lets the team have the time. In these cases it is best to allow the team to get the job done correctly. Letting the team work together instead of rushing to get items crossed off the task list is always the best course of action. Adherence to ritual is almost always a sub-optimal course to pursue.
Many scrum masters I have known would prefer an engineer to just state that something is done than to find out that it had been done completely, was tested and known to function correctly. These types of scrum masters are more concerned with their “velocity” and “burn down rate” than in getting the correct answer. So in these cases the ritual and process can produce a poor product. The team can never be proud of a poor product.
One particular example I can share is that on my last (very large and complex) project one of my engineers (probably the smartest one I ever worked with) needed to discuss some very important items. The Agile process person kept interrupting very important discussions that had to be undertaken for the project to succeed. This process person did not understand what was being said and in stifling discussion of a very intelligent person trying to do the right thing was causing incredibly bad feeling to develop on the team.
As a result the project was a lot harder to complete than it should have been and it was hard for me to keep the team working toward our goals. The team lost a feeling of accomplishment and I had to hold a lot of “side-meetings” where we discussed truly important things in advance of the “team meetings”. It was tense and hard but we did get the product built correctly. I bought a lot of pizza to make up for the lost camaraderie we had at the expense of dogmatic rituals. I have often wondered how much quicker we could have progressed and how much more we could have added to the project if we had been able to discuss ideas freely and learn more easily from one another.
So when structuring a project and thinking of team dynamics it is best to read Alex’s article and think through how one wants to manage the efforts of a team. Factoring in how a group of people will grow and learn from one another is often a function of how management decides to govern the project. Allowing time in the process for useful dialogue is key to team success and overall morale.