Making conversations happen
Sep 21, 2016
The Agile Manifesto prioritises customer collaboration above contract negotiation — but how to get developers talking to clients? In this post I discuss how TrikeApps strives to add value to our client relationships, how that value-add is dependent on good conversations and what we’ve tried to do to make those conversations happen.
Our value proposition
At TrikeApps, our relationship with our clients magnifies their ability to improve the world. To make sure our clients are getting the best experience and value for money from us, we strive to give them an accurate understanding of the cost of any given feature, and help them compare the cost of delivery against the expected return. Because for us, a sign of good service is when we’ve convinced them to abort as many stories as we have completed. This means our clients are always getting the biggest bang for their buck.
Adding value beyond code-slinging requires a deep understanding of your client’s business. You cannot hope to accurately determine the expected return on a feature without understanding their customers, source of competitive advantage and pain points. Where this information is not explicitly written down, it is likely to reside in the heads of multiple individuals within the organisation who may even have differing opinions on each item. Failure to understand often results in rework and frustration for both sides. Read on to see our tips for gathering that information as if you had a direct line into your client’s brain.
Your client’s business strategy is not included as a footnote on a user story
Deep understanding of your client’s business is unlikely to happen without each of your developers engaging with the client. We found that our developers were more likely to defer to the Team Lead to have the conversations with the client; our Team Leads then became a bottleneck to our development process. As each of our clients grew larger and more diverse, it also became more and more difficult for one individual to keep all of that client domain knowledge in their head. Having developers specialise in various areas of our client’s business and form their own relationships within those areas was key. Pairing with another engaged developer may impart the domain knowledge specific to the feature being worked on, but is unlikely to lead to the same level of understanding that comes from frequent client conversations.
True client engagement requires conversations. It’s difficult to develop of a common vocabulary over text channels like email and Slack, especially when you have technical jargon on both sides. Both sides need to ask questions to clarify their understanding. Rework is inevitable if you build an information architecture that does not match the actual structure of your client’s business. We learned this the hard way, having to recently rework many of our models of Bellroy’s product offering in multiple systems. Conversations long after the project’s inception revealed some serious deficiencies with our class hierarchy which were about to become a serious hindrance to their strategic goals, and needed fixing immediately.
Getting developers to engage in regular conversations with clients is hard. Analytical developer brains tend to prefer well-defined problems with a narrow solution space. It’s so much easier for a developer to just build their interpretation of a user story than to muddy the waters by having a client walk them through the wider context. If the client has to drive conversations to get the results they want, it may eventually end up all being too hard — and there are a lot of other service providers out there.
Our approach to prompting conversations
We’ve improved the number and quality of our conversations by sending out low-interrupt-level notifications to both the developer and the client, providing relevant discussion points given the developer’s progress. The notifications take the form of comments in our agile project management tool (for the client) and a Slack notification in a public channel (for the developer and his/her team).
The overarching purpose is to manage client expectations of cost and give them an opportunity to pull the plug on a feature that looks like it’s never going to achieve a positive ROI. Our developers can revise the estimate on a feature until 20% of the original estimated time (budget) is expended. At 15% of budget a notification lets the developer and feature requester know that they’re about to hit this cutoff and advises the developer to spend a short amount of time re-assessing the estimate. Once the budget has been exceeded by 10%, a notification advises both parties to discuss a revised delivery date. Once the budget has exceeded by 50% a similar, more strongly worded notification is sent. Notifications are only sent for features projected to take longer than three hours. We think sending these notifications at these budget checkpoints hits the right level of useful, before reaching ‘too much noise’ territory.
Our approach has increased our velocity and dramatically reduced the hours Trikelings spend over budget, but it may be incentivising other problematic behaviour. With developers often in “the zone” and clients not physically present in the office, the notifications have prompted many just-in-time conversations and saved many hours of unnecessary work. We’ve been able to change our technical approach to a feature to achieve mutually satisfactory solutions when we’ve come up against unexpected complexity, instead of just toiling away at it indefinitely. However, with no place to hide, the temptation for a developer to clock time on an unrelated task — just to avoid a difficult conversation — can sometimes be too much.
Have you discovered a way of prompting conversations between developers and stakeholders that worked for you? What was your method? We’d love to hear about it.