My last post about Agile software development processes and corporate culture addressed one of the major challenges of adopting Agile within a company: the need to get the buy-in of other stakeholders, such as sales, marketing, and the executive team, who think in terms of specs-as-contracts rather than features as conversations. I got feedback from at least one reader who said, quite rightly, that this is very hard to do on both sides. It’s hard for developers to be open and transparent with sales and marketing, and even with product management. I’ll talk a little bit about the second challenge today, and circle back around to the first one another time.
Why should developers have difficulty achieving transparent communication with product management? It shouldn’t be hard, right? After all, product management is the face of the product to the rest of the company, and the face of the market to development. It’s a role that is accustomed by definition to speaking to multiple audiences, and spends more time than just about any non-technical role in communication with engineering. So it should be easy to build that conversation, right?
Sadly, all too often, this isn’t true. Product managers, as has been said eloquently by others, are detail oriented and prone to micromanaging. They tend to stomp on the engineer’s turf by talking implementation and second-guessing the developer’s expertise. Worse, product managers force firm commitments with outside stakeholders on delivery dates for functionality of uncertain scope; often, they actually make the commitment without consulting development. Then when reality strikes, the project becomes a deathmarch and the developer is working nights and weekends trying to make an unrealistic release date that the product manager casually committed to. Lastly, remember that Agile as a whole came out of a deep dissatisfaction with the way that software development projects were relating to the market, and for some product managers were the embodiment of that problem—feature creep, churn, deal-driven “vision” that whiplashes development according to the whims of the latest sales prospect.
Building trust between developers and product managers is really hard for both the structural reasons cited above, and any trust that’s built is going to be fragile at best. So how do you get over these hurdles?
That’s a little like asking, How can I be a good spouse? Because the relationship between product managers and developers has to be a long term one. It’s built interaction by interaction, by showing that one party can trust the other to do its part, by sharing responsibility. And by being open: about the market challenges, about the problems faced by sales, about the competitive landscape, and about the technical challenges that stand in the way of success.
One very simple way to build trust and get to a shared understanding of goals is to build in frequent working meetings. Many Agile processes, such as Scrum, have these built-in already in the form of daily or thrice-weekly standups, where developers can articulate progress and discuss challenges. If your team is doing this, participate. Make sure that you communicate an appropriate level of detail about what you are doing about the release. Often times, developers have no idea that you’re off talking to customers about the features that they are working on, and many find the opportunity to get detailed feedback helpful. But save the discussions of features outside the iteration, future roadmap concerns, and other things for other meetings, probably with the dev manager and maybe an architect or a designer. Keep focused on the business at hand. But even more than talking, it’s important to listen. I found the most satisfactory standups to be the ones where I actively listened, maybe asked clarifying questions, but mostly communicated to the team that I respected their time and energy and judgment. Once the developers see you in that context and get that you really understand where their challenges are, there will be one less barrier between you and them.