Indeed, going for scrutiny on made up numbers probably won't get us nowhere. Tweaking them won't help either. It's the shared goals which matter most.
Lots of food for thought in here. I really appreciate how Kent Beck's thinking keeps evolving. This Explore, Expand, Extract curve is indeed a good way to frame things. It is a good base to know what to put in place or not.
Interesting set of follow up questions during a retrospective.
Nice little article about Conway's Law. Shows nicely all the ramifications it has.
Wording matters, and framing things differently can free teams from the Scrum limiting views. This is required to find a path towards improvements.
Very interesting! This is really old wisdom which should be more widespread. A few words of caution in there for everyone, me included.
Good piece on how to reduce uncertainty before something is built and ready to be in front of users. It starts with prototyping but goes all the way to feature flags and deployment
Nothing really new but well written. This highlights fairly well the importance of decomposing projects, having at least the broad strokes of the architecture laid down and how automated tests help drive the progress. It's nice to see it all put together.
A good reminder that there is life outside of Scrum... I especially like the framing of Scrum as training wheels. When you learned biking you outgrew the training wheels, didn't you?
It's a bit a "yet another article" about estimates. Still there are a few good points in there, they're harder to apply than it sounds though.
Interesting train of thoughts. Indeed we should keep in mind that large scale software is almost always a complex adaptative system, even more so if we don't forget the people developing it and not just focusing on the code. This can give us guidelines on how to organize the development.
Also does a good recap about what a complex system is and how it behaves. Definitely worth a read at least for this.
Very good advice: stop, status, selection, focus, finish, next. If it feels like "stop starting and start finishing", it's probably no surprise.
Technical debt was an interesting metaphor to kickstart the conversation but has been overused. It can still be useful, especially with the proposed approach here to make it intentional and explicit. This can be factored in how to drive the project.
This is a good summary of the most important points in the PMI body of knowledge. If you dabble in project management it's worth looking at it.
Definitely this. Having "heroes" brings obscurity and hide the problems, this prevents management from knowing and handling the issues. This also create lots of missed opportunities for collective learning and improvements.
Interesting to see the beginning of Kent Beck's thinking about scaling Extreme Programming. This was clearly missing. First by looking at dependencies which are definitely a problem which arises quickly at scale.
This can indeed quickly become a problem. This slows down everything and can bring with ot a silent killer: context switching. It is avoidable though, there are good strategies to prevent WIP to go out of control.
Interesting points about agile and lean approaches. In my view they tend to complete each other, that said the diagnostic of Scrum as practiced in most places today is not Agile is very true. So beware about what you're doing, is it folklore? is it dogmatic? or do you really apply values and principles?
Interesting approach regarding estimates. Might especially make sense combined with kanban like project management.
It's coming from the job interview domain... but I wonder if it could be more largely useful due to how simple it is (but not easy mind you). I guess I'll experiment with it for my next project postmortem.