romannikolaev

4 ms·

1.
by romannikolaev 10mo ago
Yes, it sounds very familiar. Scrum is not really designed for this mode of operation. It works well when there are no interruptions, and the team knows the code and domain area inside out. To be honest, I was only once in this situation. I
2.
by romannikolaev 10mo ago
When work is connected to outcomes—when you can see how your efforts contribute to the business - there’s a natural tendency to focus on the most important things and approach them in the most effective way. I suppose the larger the organiz
3.
by romannikolaev 10mo ago
To be fair, I have the advantage of being part of the leadership :) (CTO at a startup). I think this style of delivery is fine as long as both management and the teams are comfortable with it. The only thing that frustrates me in this setup
4.
by romannikolaev 10mo ago
We spent more than a year failing nearly every single sprint goal. It was beyond frustrating. Our estimates were constantly wrong because our understanding of the system was just incomplete. Something we thought was a 5-point story would tu
5.
Quitting sprints cleared our technical debt and sped up delivery(highimpactengineering.substack.com)
3 points by romannikolaev 10mo ago|7 comments
6.
We dropped sprint commitments for weekly priorities and continuous delivery(highimpactengineering.substack.com)
1 points by romannikolaev 10mo ago|1 comments
7.
by romannikolaev 11mo ago
We usually use this before tickets are even created. In many cases, an RFC can lead to an epic-level ticket that includes multiple user stories. In other cases, it can be very tactical. I think you are right, probably it can be expressed di
8.
Internal RFCs saved us months of wasted work(highimpactengineering.substack.com)
102 points by romannikolaev 11mo ago|70 comments
9.
We eliminated manual regression testing after three years of test automation(highimpactengineering.substack.com)
1 points by romannikolaev 11mo ago|0 comments