Do the logistics of how a team works and interacts with external stakeholders, really matter? Of course! So how do you decide on the correct approach? With stereotypes in mind, it is easy to draw hard lines between the external customers and the internal team. The dev teams need their secluded space to work. Other non-engineers can handle the communications. The engineers should not be bothered by anyone. They need to focus on churning out code and testing it to get a feature out as fast as possible.
Following this chain of thought, some teams may even restrict customer – internal team interaction. This may remind some of a long-gone era; for others, it may sound like the way to go. Another approach is that the internal team rolls out feature increments to internal stakeholders. Then, the stakeholder and another "communications" team handles delivery and subsequent customer feedback.
Without debating correctness, I can see that the intent behind either approach is positive. We want to provide value, and we want to do so as fast as possible. The success of the execution may depend on the project. If the project has fixed scope, undisputed requirements, and a matching amount of allowed time/effort/money then this approach may work, keeping external factors aside. In today’s turbulent software industry, either of these approaches can be expensive while delivering relatively lower value. Longer feedback cycle time equals more expensive product.
What can be done?
Build, Measure, and Learn.
An obvious (now) but not common approach to problem solving. Eric Reis describes this approach in The Lean Startup in detail. We may revisit the specifics at a different time, but for now, let us see what this means in context of using Agile beyond the team and company boundaries. One of the goals of this approach is to cut down the customer feedback cycle time, thereby allowing faster delivery. Doing so would mean engineers must often step outside of the comfort cubicle, meet the customer, and understand the value they want. The cycle time only grows larger when more people and mediums are added between the origin of feedback and the intended recipient. Tesla’s six day turn around on a “bug-fix” request is an example of how teams big or small can act upon quality feedback, granted the intended recipient has an ear to the customer.
So where do we go from here?
Include every team member in every customer call? Provide the customer engineers’ phone number and addresses?
No, overcompensating can also hurt the team. Too much noise can stifle team momentum. For a team to eliminate noise, members must understand the value of each feedback item as it pertains to the product or service, and recognize the ones who would be effective in eliminating the noise. As a first step, identifying the methods by which a team can enable positive customer interaction, and address as many communication breakdowns as possible will certainly help. Next steps include the goal of becoming a Well-Formed Team, which understands the cost vs value of a customer feedback item. More reason for teams to continue their quest of becoming one, while working with customers along the way.
Check out our other posts on agile teams, and stay tuned for an upcoming post on specifics of how a team may become more Agile in its interactions with customers!