In Scrum training I was taught that Scrum teams are small, self-organizing, egalitarian, cross-functional, and atomic. There is no manager responsible for the team. The team is responsible for the team. When in doubt, I was taught, ask the team. While, in traditional, waterfall projects, a project or portfolio manager manages the team.

But I think we can all agree that neither the team nor the PM is the boss. The Product Owner or Major Stakeholder is. The difference is how the boss makes their wishes known.

In a waterfall project the process often looks something like this:

1. The stakeholders define a need.
2. The business analyst and architect schedule meetings with the stakeholders to understand the requirements.
3. The stakeholders show up to half the meetings and are preoccupied during most of the other meetings.
4. The business analyst and architect decide the only way the project will ever get done is if they document what they think and then get the stakeholders to accept it.
5. The business analyst and architect present the requirements to the stakeholders.
6. The stakeholders either rip it apart and berate the business analyst and architect for being incompetent; or they accept it without hardly looking at it.
7. The project either spirals out of control in an infinite series of design/reject cycles, or gets half finished before the stakeholders realize the team isn’t building what they need.

I will pause here before I describe the Scrum process to guess what you are thinking. You are thinking I just described the worst-case scenario and now I will compare it to a best case scenario in Scrum. Well, congratulations, you are correct. However, I submit that a worst-case scenario in waterfall is fairly common. In fact, Dr. Winston W. Royce stated in his 1970 article that introduced the waterfall process to the world that the team should plan on doing the project twice. Once to figure things out and again to actually do it right.

So, while my example might be worst-case, it is also extremely common. Ok, back to the comparison.

A true Scrum project looks something like this:

1. The stakeholders define a need.
2. A product owner is assigned to be responsible for defining the requirements.
3. The team builds according to the requirements.
4. Everyone is happy.

Ok, that was just gratuitous puffery. All Scrum project don’t end in lollipops and rainbows. But, having a full-time product owner from the business on the project eliminates a huge amount of risk and makes Scrum project success extremely common.

But I digress, the point here is that the product owner is the boss in both, Waterfall and Scrum projects. The real difference is the product owner is present and available in a Scrum project and absent and unavailable in the typical Waterfall project; and that is no small difference.

See you next time…