As a tester, I've spent most of my professional career in a split role talking actively to business and talking actively to developers. These two groups sometimes seem to speak a completely different language, to an extent where it is hard to get the communication to work. Agile and developers caring more for value and business has been a great help, but still there's time when translation is clearly needed.
One of those moments of need of translation repeated again in my project just a short while ago. My team's developers were full of anger and frustration while the business people were absent, on the fact that business people had again sold a feature that does not exist in the product and after selling it, came back to ask development if it would be available in March as they had already promised. The developers were raging on changes of priorities as whatever we thought would need to be done until now would have to wait, as this important already-sold feature allows us in development to drop all other work if need be.
In midst of negative emotions, I offered another viewpoint. We are looking at it wrong, this is a great, positive news.
Being in a position to know a little of both worlds can have a significant impact in how we understand each other. And what I love most about being in this position is that is has a visible impact on how much and with what quality we deliver. I know something about our business and it shows in how I test, not only in how I talk about what we're developing.
One of those moments of need of translation repeated again in my project just a short while ago. My team's developers were full of anger and frustration while the business people were absent, on the fact that business people had again sold a feature that does not exist in the product and after selling it, came back to ask development if it would be available in March as they had already promised. The developers were raging on changes of priorities as whatever we thought would need to be done until now would have to wait, as this important already-sold feature allows us in development to drop all other work if need be.
In midst of negative emotions, I offered another viewpoint. We are looking at it wrong, this is a great, positive news.
- A feature sold is a positive thing for us and schedules are not absolutes
Our team - business and development together - is like a startup. Lean startup ideas - finding the business model that moves us as quickly as possible to sustainable product - are very relevant for us. We need to test our assumptions by going out of the building, validating with real customers and the news we just got is a positive result of one of those tests. Someone wants to pay for our product.
The feature business sold was not something completely off the product vision, but it was clear feedback on the vision of what types of things would make it worthy to pay for. Clear as in signed contract, not just kind words promising possibilities that might not realise.
The revenues pay the costs. We should, as a development group, care for the overall sustainability of our product, since we do want to keep delivering great features into it. And that is only possible if the things we develop are things someone will want to pay for.
More than once we have complained on an opposite problem. Business asks for a feature that no one uses over 6 months after it has been available in production. We had implemented something that wasn't providing value, not because we did not implement, but because we had chosen to implement something where the need of the feature was theory that wasn't tested in advance.
When the business sells a feature to be delivered in three months, we should learn to trust them on the fact that they did not just do an estimate for us. They did an estimate of what their customer find acceptable for now. We should look at history and remember that this schedule too is flexible. If we deliver half of the promised feature in a way that delivers half of the value it is easy to get more time negotiated without losing the sale. - Our team is perfectly equipped to changes in business needs with continuous delivery
We already work in a way that supports this and we have no need to resort into the old school development thinking, where we're opposing sides with the business. We use Kanban with Work in Progress limits, and we can always move away something else to focus on the new thing. We are good, even great at that, and should take pride in the fact that we are responsive to business without giving up on our idea of technical excellence in particular in maintainability. We always find the good ways to do things, in collaboration.
Sure, the roadmap that gave us an idea of what would happen this year will change. But the roadmap was a theory of what we'd work on, not a commitment into us delivering this. Our team sets the goal we're rewarded on for the year when most of the goal has already been delivered - we're already tweaking the rewarding process to support the real way we should be rewarded on, our excellence in delivering value and flexibility of what the value actually is.
I know remembering this is hard, and I'm here to remind us on this. I'm here to suggest we celebrate how great we are in being able to do this. And I'm absolutely delighted to realise that looking at this as testing of customer needs is a helpful way for me to communicate it further, for both sides.
Being in a position to know a little of both worlds can have a significant impact in how we understand each other. And what I love most about being in this position is that is has a visible impact on how much and with what quality we deliver. I know something about our business and it shows in how I test, not only in how I talk about what we're developing.
