If you refactor part of the application, you go all the way. Is there really any value in shaping it up? How do I explain this value to the developers? For them it might seem like needless overhead that does not impact the scope of work
If you refactor part of the application, you go all the way.
Not necessarily. Big refactoring projects can end up taking forever, so it can certainly be useful to add some constraints on what you’re expecting to get done.
Is there really any value in shaping it up?
I’m assuming you’re talking about a fairly substantial bit of work here, so I’d say it’s worth doing some form of shaping: Set Boundaries → Rough out the Elements → Address Risks.
Clearly not worth doing this if you’re talking about routine refactoring-as-you-go. That’s more of an organisational skills and culture issue.
How do I explain this value to the developers?
As a programmer, I have never complained about making code easier to work with!
For them it might seem like needless overhead that does not impact the scope of work
If you truly want it done, then it’s part of the scope of work. You need to convey that the refactoring is part of the foundation needed for this or future work, and needs to be done now for reasons X,Y,Z.
We don’t shape tech debt and there are a few ways to deal with it.
- The conservationist view: Leave the land better than you found it.
- 25% of engineering time is spent under the cool-down umbrella where they choose what to work on. Tech Debt can definitely be handled here.
- DevOps, Fidelity, etc. type teams working out of cycle to ensure the core teams aren’t introducing tech debt in the first place and have the knowledge required to build and maintain stable applications
- Tech debt shouldn’t exist (Yup). Reframe your thinking on how we got here and whether we have Tech Debt or we made Trade Offs. If you have tech debt, something went wrong along the way and it can be fixed. Tech Debt isn’t a must have. I wrote a thread on this reframe here: https://twitter.com/JuJoDi/status/1313976116068089856?s=20
As a CTO I like having two separate teams, one focused on support/incremental work and one focused solely on bigger Shape Up like projects. For the most part we’re able to make good progress on tech debt on the incremental team (client demands not withstanding), but there’s always one or two longer tail refactor projects (e.g. API or data model refactor, DevOps rearchitecture) that warrant a dedicated project. We treat this roughly the same as any other Shape Up project, with the project owner/stakeholder typically being myself presenting to the business, with input from my lead architects and a balanced approach to the bottom line reality of what we need to do.
I’ve been running my own flavor of Shape Up for the past year or so and my team has strongly embraced it. Our main focus is identifying the scopes of each project and working on them in chunks collaboratively. Moreover I’ve done away with daily standup and have more freeform checkins 2-3 times a week with the understanding that most synchronization happens in real-time and as needed over slack or video. I think this combined with other tech choices has helped our team be productive and enjoy the work we’re doing.
I think there is value in shaping large* technical debt work. First, to put some guardrails on time/appetite (the circuit breaker) so a two-week refactor doesn’t become two months. Second, shaping tech debt to help prioritize what matters to the customer/end user. Fixing tech debt that affects hundreds of users may (or may not!) be more important than addressing tech debt that affects 1 user. Explaining the downstream effects of their work may help them see the value a bit better.
*I added this to clarify after re-reading your question. For “small” refactor work (e.g. a few hours to a few days) we usually let devs pick and choose those items (with suggestions from the team) during the cool-down. We usually don’t shape that type of tech debt unless we have enough to bundle into a “themed” batch of work that spans at least a week or more.