Echo JS 0.11.0

Hi Tracker1 !
It's not the coming thing for me to put some comments but I've even registered account to make some appointment here.

Are you a programmer?

The article itself gives brief description of one or two cases 
as I understood from the text. But nevertheless it shows what exactly happen when then the team tries to keep good face while communication with the client and what it causes in the end.

It looks like you've read this articles too quick and try to judge on some points not on whole idea of it.

There is no importance how PM or Dev are good at their skills set but about the client who tells daily the team: I pay - you do. 

And what such behavior leading to. 

The article is not showing the full list of aspects of outsource development but gives clear view on problems with the customer. Good beginning of the full topic, waiting for the next one.

While this is wholly off topic for the site, want to comment here.  I don't think a lot of the conclusions are correct.  I think the problem is a failure to have ground rules in terms of work cycles and communication workflow.

If this project actually used a scrum process, where at the beginning of a work cycle the work was written in terms of user requirements as well as small enough chunks to ensure success of the sprint, then each sprint could/should have been successful.  Once the work cycle is agreed on, there should have been no changes in workflow or in-progress requirements mid sprint.

It is entirely on the project manager / client to establish the next top priorities/stories.  It is on the developers to give reasonable story points and to push back on those stories that are too big to take on in a given work cycle.  It is on the company to have enough operations resources to lay groundwork for necessary platform services and integrations to happen.

If this were Kanban, it would potentially be a tighter lifecycle.  But this is most often a breakdown of where the boundaries and responsibilities lay.  If the project is too big for 1-2 people to work on very closely with a clear communication and understanding of project requirements then it is on those involved.  This is where pre-panning and understanding of requirements, establishing common terms for things within the project and just understanding wholistically by the PM/Client, Architect and Developer Leads at the very least is required.

The fact that the platform in the example had to be rewritten multiple times is either a very good or very bad thing and probably some of both.  Either the underlying system was loosely coupled enough to have that flexibility while being small enough to do so easily or it was so inflexible to begin with that it needed to be scrapped multiple times.

It seems to me, that in this specific case that leadership was broken.  That there was no clear boundary of responsibilities established.  That there was no communication of real costs in terms of estimations and how changes in direction would affect those estimations and timelines.  That the project manager didn't know how to manage a development project, and that one should have been assigned by the stakeholder/client or the developer team's leadership.  Scrum, Kanban, XP and other processes are meant as a starting point and the key to continuing development is communication.  It is evident that this didn't happen at the start, and that the actual process itself was never adapted or reevaluated.  As the experienced consultants, it is up to you to guide and ensure that happens.

This article itself gives very little in terms of advise as to where these things broke down, or for that matter what should/could have been done to change things.  Laying it all at the feet of the client is disingenuous.  I've worked in grueling environments with so many shifting priorities and the organization so small everyone wears multiple hats.  That said, it's up to developers to estimate against unknown risk, if you don't know enough give crazy large estimates and ask for smaller units of work until you can give better ones.  Developer leads and architects should ensure that platform work like CI/CD, overall technology choices and direction are established as guides and that work that is too big isn't being taken on in a work cycle.  Project managers are responsible for coordinating the discussion between developer's assigned work and the stakeholders.  This includes allowing guided questions in terms of how the work can be broken down better, establishing common domain terms within the project and reducing confusion.  It's up to the clients to look at and establish "next" priorities in terms of deliverables.  If one piece is blocked/broken, it is up to the Project Manager to deliberate and/or communicate those broken/blocked pieces and negotiate a mitigation strategy.