Unity Ads delivers targeted video advertisement to hundreds of millions of mobile phones at staggering rates. We have six teams building the plat...
For further actions, you may consider blocking this person and/or reporting abuse
This is something I've been wondering about. I've seen teams increasingly working on "visual" stuff so that checkpoints are all about delivering features. Not so bad on its own, but it's made me wonder: how do you manage tech-debt in that kind of environment?
You are right that this thinking could be abused. I'll make two points on this:
We trust our developers and encourage them to include technical-debt reduction and refactoring in to the stories. So if doing thing A properly requires that I start by improving the existing code base then you do it, we won't question you.
"What will I have to show" is just one way of teasing out the essence of what you are doing, it should not be the defining metric for prioritising your work.
But like with all in agile, we need to focus on honest communication between product needs and responsible development. Maybe I've been lucky but with the teams I've used it with it has worked well and people were not afraid to still pick "invisible" tasks when they considered them important.
Great article. On the point about frontend/backend separation I think it depends on whether the backend is an open API and a product in of itself. I.e. the API is value itself. What we have found is that shipping frontend and backend together often results in APIs that are too narrowly focused on a single frontend use case. Also when considering a distributed system where frontend and backend are often many separate physical systems deployed separately, you end up with dependency chains that make deployment more complex (not impossible though). We deploy many times a day and we try to limit a story to a single physical unit of release, this is a technical constraint but it makes deployments much easier to rationalise about and easier to manage dependencies.
We manage a distributed system with hundreds of separate services that interact with each other and creating stories that have no sympathy for this means our pipeline slows down significantly while teams rationalise about what has to ship together.
We have automated most of this but ultimately the dependencies need to ship before the dependants, even if this is seconds.
It does mean that we often write stories that are too technical in nature or separated on boundaries which make it difficult to see the value.
I'm wondering if anyone has any insights into these sorts of scenarios.
Our current thinking is that if you are doing microservices and aren't relying heavily on messaging, you are doing something wrong. In part exactly for the reasons you outlined above. Microservice should be deployable in isolation. So if it depends on bunch other services being available when it is deployed, it isn't "deployable in isolation". Crafting services with well-picked business boundaries and letting messaging be the transport layer, you get services that don't care if their "dependencies" are up when they are.
Yes, but what we are talking about here is frontend / backend separation, not inter microservice communications which I would agree are better served via async persistent messaging. Our frontends communicate with backends (microservices) via RESTful APIs and I was referring the trouble of creating a story that covers both vs separating the story to cover them separately.
Great timing. Was looking for some insight like this. Thanks.