ScrumBut: Method Picking

After two conference days I attended several sessions and talked to lots of people. It is amazing how many claim to do Scrum but mention following typical statements:

"How should I change Scrum to fit into my organization?"
"With which part of Scrum should I start?"
"There is no Product Owner in our team, we don't need one."
"We don't do Sprint Planning because we planned all project phases at the beginning and execute that plan in 3 week sprints."
etc.

This is the wrong way! If you pick a few single methods or practices of Scrum the result will not be Scrum.

Or as Jeff Sutherland said: "You may change anything in Scrum but don't call it Scrum!"

One may argue this is just another dogmatic restriction of Scrum. Let's find out why it makes sense to leave Scrum as is.

Think generally about your team's definition of done. Everyone of your team is able to understand what you mean by saying "this story is done." It is just useful to have such a common basis of understanding. Now replace "done" with "scrum" and extrapolate your team to the rest of the world. The definition of Scrum is based on its roles, activities, and artifacts as described in the Scrum Guide or any other serious book on Scrum. Everyone in the world with such knowledge of the Scrum framework will understand what you mean by saying "we're doing Scrum." Take a look:

"done" = done

"Scrum" = Scrum

"not done" = not done

"not Scrum" = not Scrum

"I'm almost finished with this task" simply means "not done".
"We're using only a few things of Scrum" simply means "not Scrum".
It's that easy.

There is no binary black-white scale, of course. In the beginning of your transition to Scrum you will see many things that won't work as scrummy as intended. The important point is not to exclude these things right from the start of your transition. Always start with the full Scrum set even if nothing is working well. Go on, learn, inspect and adapt - with good mentoring and coaching your team will improve soon enough even if you think that is not soon enough.

Lose Customers with Disorganized Workflows

Last week my wife and me went to the traditional Saint Martin Procession with our son. It was a nice walk with all those gleaming hand laterns of the kids. The walk ended at a school were the local music society had prepared some food and beverages. Ordering and delivery was organized as follows:

• At the cash desk customers have to buy vouchers for specific food and beverage
• One person works at the cash desk
• Left of the cash desk all beverages are handed out
• Three persons are in charge of handing out the beverages
• Right of the cash desk all food is handed out (french fries, German "Bratwurst", stuff like that)
• Four persons are in charge of handing out the food

When we arrived at that location I hurried to the cash desk only to append myself to a long row of approximately 50 people waiting. After 5 minutes there were still 40 people in front of me.

There were several severe problems in the way of organization:

• Only one person at the cash desk. Maybe a single resource would have been able to handle the queue of people but unfortunately this person was the slowest imaginable.
• No team work. All the resources had been strictly assigned to their specific stations. No one was able or willing to help at another station to deal with overloads.
• No one-way routing of customers. After the cash desk first you had to decide to move left or right and cross the row of people in front of the cash desk again to go to the other side.

It really was a mess and I analyzed all these problems within the first minute of waiting. If they only would have organized their work order with a simple kanban, everyone would have been happy with a faster delivery of finished orders to the customers.

We finally decided to abort this experiment after 15 minutes, walked away and got something to drink at home. So my conclusion is: disorganized workflows loses customers.