As engineers we like to speak in tickets and stories and bugs IDs etc - those units of currency we find easy to grok; they're usually finite, easy to define, narrowly scoped, and uniquely identifiable.
Our customers - for the most part - like to speak in outcomes and business plans and commercial objectives and projects. The longer term, more vague, abstracted-from-the-work things that we like to digest by breaking them down into those stories etc that we're so comfortable with.
This can lead to a weird situation where you have all your iterations scoped out and your releases forecast (with painstaking detail in every story) yet the business still lacks clarity about what's being delivered by who and when. Hmmm.
I think a bit of generalisation can help us to understand this. Lets appreciate that engineers, for the most part, are deeply practical people who are comfortable handling actionable tasks. Since we're also geeks - again for the most part - this descends quickly into technical details. You'd be surprised how unintelligible this can all be when you're not a developer.
What I've learned over the years is that stakeholders are interested in the meta problem, the commercial plans and outcomes, not the tangible problem, the technical tasks and code which need to come together to solve it. As technical leaders we need to talk about the meta problems with the business, and the technical problems with the engineers.
This comes with two obvious challenges - whenever we're talking about the same things but using different currency we rely on a degree of interpretation and some things can be lost in translation. This most commonly surfaces as that old "unclear requirements" thing. The other challenge is making sure that, as we solve our technical problems, we're solving our meta problems. This isn't easy and this is why great product managers are so crazy hard to find!
This kind of interpretation of work - the aggregation of agile units into bigger picture project plans - is usually an early casualty of agile adoptions. It is reminiscent of waterfall so we label it bad. But it is a helpful mechanism which bridges the gap between agile execution and regular business planning. It gives you both currencies.
Get awesome product people - they are the only other ones who live in this gap with you and have to speak both languages.
No comments:
Post a Comment