This is accurate in my opinion. Engineering and product teams need to properly negotiate, otherwise quality will suffer.
Interesting guidelines idea to help teams manage the priorities themselves. It's written in the context of a product manager but I think it is lightweight and generic enough to apply in other contexts.
We keep saying they're not the same. This article does a good job highlighting the differences and explaining why you need both.
When I read the content of this article I wonder how useful the metrics really were. I mean clearly they helped the team realize which changes to bring... but the practice changes were all somewhat conventional in a way. You go a long way when you focus on quality and create the space for it.
He is spot on again. The scope is what will allow to create flexibility in a fixed price project. This is what leads to the necessity to work incrementally.
A bit long and a couple of mistakes when pointing out the flaws of story points. Still, it's definitely a worthwhile read. Quite a lot of the criticism of story points is warranted and the proposed approach based on queue theory is welcome. This is stuff you can find in Kanban like approaches and mature XP.
A nice collection of versioning schemes. I definitely didn't know them all.
Interesting musing about the concept of friction in strategy. There are indeed a few lessons to learn from it in the context of software projects.
This is definitely an ambiguous term. You need to know where stand the people employing it in order to figure out the exact meaning of "root cause".
This is indeed an important aspect of estimating work. The smaller you manage to break down tasks the easier it will be to estimate. Breaking down work is a skill in itself though.
Definitely this. The distinction between stories and tasks is an important one. Don't confuse them.
There's some truth to this. Shorter optimized iterations with no good learning opportunities lead to busy work.
A few points to take with a pinch of salt, especially regarding the proposed solutions. Still it makes a very good point that most transformation failures toward agile organizations are due to lack of trust and the swapping of one bureaucracy for another.
To take with a pinch of salt since it has a couple of biases (most notably it focuses a lot on satisfaction) and the sample size is a bit small. A few interesting insights nonetheless. In particular it hints at autonomy, transparency, technical skills and vision as being the most important factors for satisfaction and success within teams. The applied project management method? Not so important it seems if the other factors are satisfied.
Looks like a nice way to automate the creation of changelogs.
Definitely true. This is why I refrain from using the term nowadays... this allows to focus on the principles instead. Takes more time to explain but allow for slow and steady change management. Indeed it's not perceived as an all or nothing situation anymore.
Good approach for tackling it indeed. The crux of the issue is really measuring the tech debt since it's still a fuzzy concept and we have no good metrics for it.
An interesting interpretation of what was behind the "move fast and break things" motto which is nowadays blindly followed by some. A bit of a long piece but does the job and propose a more complete view and an alternative approach.
Interesting set of advices for better communication and more sustainable production of software.
Very good piece. Explains why postmortems are important. It also explains how to prepare your organization to conduct them and how to do them properly. This is important since a lot of pressure will happen in case of a failure.