Agile Mythbusters — The Five Most Common Misunderstandings (part 1).

Some time ago company for which I am currently working decided to establish cooperation with the local University of Technology. Thanks to this cooperation, we — as employees — were invited to prepare lectures and laboratories that would cover topics such as JavaScript, JAVA, GO, Functional Programming, cloud, DevOps and Agile. Our goal was to show the difference between practice and theory — basically, to share our experience with students.

One of many lectures was called “Agile Mythbusters”. Together with two co-workers, we decided to familiarize students with common misconceptions about Agile methodology (focusing especially on SCRUM).

But wait, what misconceptions? Would we just repeat the myths that already were described on the web and in the countless books? Oh, that would be too easy!

Solution?

Do you remember your first day at work, where SCRUM was used? Your fears and million questions swirling in your head? We did not :/

That is why after very short brainstorming session, we decided to ask students working in our company about things that were totally incomprehensible or just weird for them when they started their careers in our company. Here are the results:

Myth 1: “Demo” is about showing what we’ve done in the sprint

If you still think that “demo” is one of the Scrum Events and is used to show what was done in the sprint then… you’re just living a lie, my dear friend.

Let us open Scrum Guide and find Scrum Event that is named “Demo”. Can you find it? No? Me either!

What can you find there, is Sprint Review. According to Scrum Guide:

“S_print Review is held at the end of the Sprint to_ inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint.”

What is the result of this event?

“T_he result of the Sprint Review is a_ revised Product Backlog that defines the probable Product Backlog items for the next Sprint. The Product Backlog may also be adjusted overall to meet new opportunities.”

It seems to be pretty clear that the demo part is included in the Sprint Review. Still, it is just one of many actions that should be taken during such an event. We read mainly about adapting Product Backlog, that should be revised after such a meeting.

Why would anyone use term “Demo” instead of Sprint Review?

After thinking about it for a while, I understood that our working students weren’t wrong. In their eyes, it looked as a demo and nothing more. Why?

Many years ago SAFe was used across the whole company. It was implemented in a hurry, without proper standards. It was a time when “demo” sessions appeared in the company. During such meetings, we basically showed only the functionality that we have implemented. SAFe coaches failed terribly.

Since SAFe was hard in implementation and we did not like it, the next choice was SCRUM!

Old habits, die hard.

Demo stayed. Management liked it. Product Owners liked it. No one wanted to show his messy Backlog and talk about it aloud.

That was and still is the case in my company and teams that are surrounding me. We work hard to change it, but like everything else, it takes time…