Estimating effort in a fully loaded system
is a poor man’s try of achieving predictability while eroding trust and jeopardizing psychological safety.
»If it takes me 5 minutes to rename a method
and 1 hour to get a review and PR approval, that means the wait to processing time ratio is 60/5=12, and flow efficiency is only 7.7%.
»When it comes to the way of working, there's one small difference that can make a huge impact on your teams and organization
With Pull Requests you see just a polished and thought-through end result.
»Do you need to measure wait times and flow efficiency
if everyone that is needed is immediately available to respond (by #mobprogramming for example)?
»If developers in your team have to repeat their asks or even worse beg 🙏
for reviewing their PRs (or any other help they need), your problem is not people not prioritizing other people’s work and lack of “team player spirit”.
»If an organization compensates for ineffectiveness
by hiring more people, don’t be surprised to see the culture of ineffective parts of the organization eat away the culture of effective parts of the org, which doesn’t have a need to scale at such a rate.
»The expectation that senior developers should be able to work independently is killing the team's ability to collaborate
The more they ask for help the less they feel they are meeting that expectation.
»Measuring Accelerate metrics in XP teams is as redundant
as measuring code coverage for a team doing TDD.
»Reducing transaction cost is necessary, but not a sufficient condition for reducing the batch size
Very often, for a mindset that emerged inside environments with big batches, it takes increasing the holding cost of inventory to start changing the belief system that was created as a workaround for the limitations of the system and served as its governing constraint.
»You might think that small PRs are good
because you see more feedback and quality being built in than on big PRs (‘LGTM + Approve syndrome’).
»