test.ical.ly | getting the web by the balls

Feb/13

6

When you need to bend your processes and pull together

6 Comments · Posted by Christian in Outside the box

to-pull-togetherYesterday I went to a pub with friends. One friend arrived late after the rest of us had already eaten. She ordered something to eat anyway and about 40 minutes later she asked for it again only to find out that the waiter forgot her order. So he was send to the kitchen and within just under 10 minutes her food arrived.

I instantly had to think of the company I work for.

Imagine what happened behind the scenes. The waiter is responsible for forgetting the order and now rushes into the kitchen not only to place the order but to make it highest on the priority list. The chef at that point can not be amused as he now has to do the forgotten meal while still doing all the other orders as well. He can not make this one customer wait any longer just as he can’t delay the others. He can not prepare only half of the meals, nor can he save on the quality.

He can not scale on scope, quality or time. Instead he has to work twice as hard. Take that scrum process by the book!

It could’ve gone totally wrong though.

Imagine the chef arguing that it wasn’t his fault to not place the order and that he would either put it in the queue or do it now and delay the rest of the orders keeping his processes in tidy order. He’s not to blame after all so why should he be the one to deal with it.

In that case they would probably have lost customers.

Imagine further that maybe the customer didn’t place the order in the first place but only thought she did and the waiter was just polite enough to take the blame. It’s still not the chefs fault but still his responsibility to not loose any customer.

In any company mistakes are made and have to be dealt with. Especially when dealing with customers there is only one importance: to serve what was ordered in the quality expected and within the acceptable time. If you’re behind schedule for whatever reason you need to speed up.

I imagine the waiter later excused himself with a round of beers in the kitchen. The food was nice and my friend forgot about it soon and will come again.

·



  • http://www.facebook.com/nils.langner Nils Langner

    I guess scrum isn’t the right framework for a restaurant. Kanban would be much more suitable. Problem solved.

    But let’s play it with scrum. If this happens once I guess it should be no problem to stop the sprint if the business value is high enough. If it’s not, why stop?

    In my opinion it’s very important to stick to the process. There must be a barrier for the customer to chance their focus during a sprint. If not there will soon be chaos. Play it hard and in the end both sides win.

    If everybody understands the ideas behind scrum they will agree. But I know that this is not easy, I’m scrumming since 5 years and still learn every day.. Many companies started to coach their product owners instead of the development teams, because *there* often is the lack of understanding.

    Working twice as hard should never be the solution.

  • caefer

    Sticking to the above story stopping the sprint would mean to delay all the other customers. Not stopping it would mean to piss this one off. Either way you risk loosing customers.
    As long as the people paying for your business to run with their purchases and bookings are not part of your company they won’t care about your processes but about the result in scope, in quality and in time. In my case that’s how it is.

  • http://www.facebook.com/nils.langner Nils Langner

    But what are the implcations if you fix the “problem” at first?

    Team commitment gets demaged, the team is commited to reach their goal. Perhaps that’s not possible anymore.

    The customer knows he can put give new stories to the team anytime he wants. The team isn’t protected anymore for one sprint.

    Working twice as hard want fix anything. Quality will be affected.

    But there are other ways. If it is realy important than stop the sprint. If it happens often use a spike. Tell the team they should keep 10 story points free for such situations. This will help and you have a process and not freestyling around.

    All these problems are solved, as they occur in every project but I guess doing whatever the person that pays wants is not an option.

  • caefer

    It is. It’s called customer centricity.

  • http://www.facebook.com/nils.langner Nils Langner

    Customer centricity is part of the requirements engineering process not the development process.

    So yes, you’re right. A customer that pays is allowed to define what to build. The team and the project should define *how* to build it.

  • caefer

    Totally agree. As a customer I give the budget, define what I want and set a deadline. After negotiations reach an agreement I expect whatever process is used ot make that happen.

<<

>>

Find it!

Theme Design by devolux.nh2.me
To top