后来，家父决定全职培训人们使用Scrum，遂创建Scrum公司。父亲留下的负责人让团队像时钟一样，每一个冲刺都准时培育出新的医院。两年后，那位负责人离职，首席执行官聘用一位不懂Scrum的工程主管来顶替离职者。不到一个月，团队就无法交付了。首席执行官告诉新来的人，如果再这样，你就要被解雇了。同样的情况再次发生，首席执行官决定亲自接管这个部门，并重新执行瀑布式管理模式，交付过程变得又漫长又痛苦。收入下降一半，患者守护员公司一瘸一拐，坚持走了几年，方才寿终正寝。这是一个伟大的公司因旧习惯而破产的好例子。
杰夫认为，原因不仅在于新工程主管个人不理解Scrum，还在于他们不理解组织需要不断改进以保持速度。杰夫在患者守护员公司倒下前一年看到了该公司的危机，并警告他们修复问题。但是管理层只是希望Scrum能继续工作，如果Scrum不能继续工作，他们认为那也不是管理层的错，是工程师们的错。然后，当然，工程师们纷纷跳槽。
这种情况我见过几次。一位高管将新东西投入某个业务部门，甚至整个公司，但没有来自高层的支持。一旦此高管晋升到另一个部门或跳槽加入另一家公司，新的工作方式就会分崩离析。领导层经常对此感到震惊。让同样的员工做同样的事情，怎么突然之间其工作方式就不起作用了呢？之所以会这样，是因为无论在组织层面，还是个人层面，都没有将向Scrum的转变内化。然而，他们领导的员工很少对管理风向的变革感到惊讶——改变并不鲜见，员工早已见怪不怪。