Yet the solution is so simple. Let the them spend 20 – 35 % of their paid time on backlog. Let them refactor the architecture. Let them improve the code base. You know, that thing the Lean book talks about, the part that everyone overlooks, the part so critical yet so often overlooked that others wrote books that ride that one aspect home. Oh, unless you want them to spend overtime on a production problem whose root cause a scrum master added to the backlog 5 years prior to the incident, of course. Oh, unless you want them to give you one year estimates for changes as simple as translation changes 'cause the architecture is so ass-backwards and never improved upon that everything depends on everything and everything breaks with one simple change. And who needs tests, right? Waste of time and money! Just live in fear that one change can break the entire software, like a real man.
Backlog isn’t sexy. Management wants sexy. Nobody’s boss wants to hear about how the DB schema was improved - they want to see some new, flashy widget.
Yet the solution is so simple. Let the them spend 20 – 35 % of their paid time on backlog. Let them refactor the architecture. Let them improve the code base. You know, that thing the Lean book talks about, the part that everyone overlooks, the part so critical yet so often overlooked that others wrote books that ride that one aspect home.
But why do that when instead you can just pretend those issues don’t exist (or simply fail to understand them) and secure a bonus/promotion/personal favour by cutting “unnessecary” labour costs then celebrate by burbling on about how capitalism “maximises efficiency”.
Yet the solution is so simple. Let the them spend 20 – 35 % of their paid time on backlog. Let them refactor the architecture. Let them improve the code base. You know, that thing the Lean book talks about, the part that everyone overlooks, the part so critical yet so often overlooked that others wrote books that ride that one aspect home. Oh, unless you want them to spend overtime on a production problem whose root cause a scrum master added to the backlog 5 years prior to the incident, of course. Oh, unless you want them to give you one year estimates for changes as simple as translation changes 'cause the architecture is so ass-backwards and never improved upon that everything depends on everything and everything breaks with one simple change. And who needs tests, right? Waste of time and money! Just live in fear that one change can break the entire software, like a real man.
Backlog isn’t sexy. Management wants sexy. Nobody’s boss wants to hear about how the DB schema was improved - they want to see some new, flashy widget.
And the whole product line suffers because of it.
But why do that when instead you can just pretend those issues don’t exist (or simply fail to understand them) and secure a bonus/promotion/personal favour by cutting “unnessecary” labour costs then celebrate by burbling on about how capitalism “maximises efficiency”.