All too often, we encounter so called Scrum teams with huge numbers of stories,even many projects, all going on at once. This never goes well, and it is counter to even the most basic principles of Scrum, Agile, even common sense.

….

….large amounts of work in process will damage, possibly kill your project.

Excessive work in process causes defects. CAUSES defects. When people switch tasks, they lose context and more defects appear. Defects require rework. You get a defect-filled product, and you get it later. Not a good plan.

Worse yet, even if magically you could avoid having more defects, you still deliver everything later. Task switching takes time. The more you switch, the slower you go.

Still worse, even if you could switch tasks seamlessly–and you cannot–you would still deliver everything later. Look at the following picture:

 

Switching between features means that every feature is delivered, not a just bit later, but many times later! And they are delivered with more defects!

….

i agree with most of this.

but actually, it’s counterintuitive to not keep everyone busy working all the time.

and when you keep everyone busy all  the time, you cause multitasking and the ill effects described above.

Whether or not programmers take steps to make their code reliable and easy to change will show up on the balance sheets of businesses of all sizes.

….

Practices that were known to produce more reliable software, and that make software easier to adapt and evolve, have been understood for decades.

software of good quality is:

reliable code, easy to change – adapt and evolve.

i.e., to become more agile.. is to improve quality of software.. is:

to produce more reliable code, make it easier to change, easier to adapt, easier to evolve