At my new workplace our team has recently started doing scrum. Our scrum master got his training just this week. When he came back we started discussion about what we are doing "wrong" and how we could improve. I commented how the idea of scrum is to have a prioritised backlog and team selects the most important tasks from it at sprint planning to work with during the sprint. I had some more thoughts about it and decided to write my first post.

In theory things are pretty straightforward. At the beginning of a sprint team selects from prioritised backlog items that it is going to work on next sprint. During the sprint team only works with those items. At the end of the sprint team reviews with product owner which items got done during the sprint. Product owner owns the backlog and has absolute power over it. They can re-prioritise backlog between every sprint in any way they want.

There was discussion about how there is too much work and how to communicate customers that there is only so much work the team can get done in a sprint and overwork will eventually backfire. In the end, that is PO's problem, not team's. Team should only avoid overcommitting and make sure that they get tasks they have committed to done. This "single wringable neck" approach gives PO complete control over communication to business side, which is very powerful if used correctly.

Problem is that usually business is used to traditional Waterfall projects and are trying to work in framework of schedules and deadlines. This creates situation where unstoppable force meets with immovable object, a singularity where neither rules of waterfall or agile apply.

Software development is traditionally illustrated with "iron triangle" of scope, resources and time.

Idea is that you can set two of three corners and third one then adapts to the changes in the project. Changing resources is hard because adapting to new resources creates additional load. That gives rise to Brooks' law:"Adding people to late project makes t even later". Traditional waterfall projects set the scope and then try to estimate time by planning a schedule. Since the requirements are not usually completely understood at the planning phase, the estimates never hold and project is delayed.

Scrum turns that idea around. Time is set by having fixed sprints and scope is then adjusted by changing priorities of items in backlog. Deadlines hold, you just don't know what will be done when it comes. By keeping the backlog in priority order you can always be sure that at least most important things are completed.

These two approaches are incompatible. That is probably the most common reason for failure of agile. The whole organisation has to adapt to the idea that scope is not set in stone, but timetable is.