Why do you assume that its devs who are slacking in waterfall? Devs enjoy deving, usually there are either discoveries during execution or change of mind of client or pms figure out that their guestimation for year ahead was not exact. Surprise, surprise and who is going to have crunch time? Devs of course.
I didn't say they were slacking, but they may be working on the wrong things, or prematurely optimizing things at the expense of other priorities. Ironically, it's the author who suggests implicitly that devs can slack more in waterfall ("Sprints never stop").
Since the client is involved in every sprint, any change of mind they have during the development process (and keep in mind that changes of mind are a virtual certainty in either case)is at least better informed than if the touchpoints were much less frequent (or as is too often the case in waterfall) all back-loaded towards the end of the project.
Does scrum eliminate crunch time? Of course not. But if it's done well, the impact is minimized because there has been so much more opportunity for course correction throughout the project.
It’s that culture of fear that I don’t understand: devs working on the wrong thing. More often than not, it usually means: Is the dev spending more time than me (who is not doing the work) is willing to give him? Every professional understands priority and expectations. And communication is all that is required. But PM usually don’t understand the nature of software development and fear of losing control (the bad ones). The good ones just let people work after they made it clear what should be worked on.
>Every professional understands priority and expectations. And communication is all that is required.
Sure--the kind of communication that is ensured by a brief daily standup (communication within the team) and a regular progress review with the stakeholders, like say, a sprint review every few weeks (external communication).
While it's true that every professional understands the idea of priority, the global priorities of a project may be very different from the individual priorities of a developer. A diligent, conscientious developer can still get caught up in a narrow problem that doesn't really move the project forward, even after the PM has "made it clear what should be worked on." Fire-and-forget is not a strategy for project success. Continuous communication and regular reviews/resets are a better way.
