BLOGas.lt
Sukurk savo BLOGą Kitas atsitiktinis BLOGas

First pancake theory

Unevenly colored first-batch pancakes are caused by cooking on an improperly heated and oiled griddle, says Jon Liss, the corporate chef for the Original Pancake House Franchising Inc.

CHOW’s Nagging Question column - December 16, 2008

We knew it and we blew it.

For some unknown reason (most probably the main one - only POs were involved) Planning Phase (or pre analysis) wasn’t handled as a Sprint and due to that (or due to other reasons) we encountered quite a few problems.

So if You are only interested how we deal with SCRUM, you can skip this post. But I will try to put some findings I did during first two weeks and maybe they will help You in general.

The background

We planned 2 weeks period to have workshops with the client. The idea was to get familiar with their processes and high level requirements, map it into User Stories and create Product Backlog to be able to proceed with first Sprint.

So how I saw it in my head: First week will be full of workshops and User Stories will be created and the second week will be for estimating and planning + having few short meetings to prepare detailed User Stories for first sprint and answer questions that will appear.

Sad Burnt Pancake

Problems

Multitasking, Multitasking, Multitasking…

Most of people understand multitasking as working on a few different not related tasks at the same time. Of course that stays unchanged (in case You thought I am planning to deny it), but I have discovered another type of multitasking. Well, ok - can’t say that I discovered it, as I kind of knew it and it’s widely known by Agile community. Just I had a chance to feel it on myself: do not start another task while the current one you are work on is not finished. Ok, I know what will You say and I am not in the position to argue with your mind. But at least do not have it as a habit. This habit is very harmful. You ask WHY? The answer is simple.
As a manager I knew what topics my teams have covered during the workshops, but I had no clue how far they are in discussion and due to that I had no clue what current status is… And I will tell You, I hate it badly. So that’s actually the biggest lesson I wrote down into my log: have as little open tasks as possible. On top of that, it could have helped me to prevent the second problem as well

Communication

Another thing I have learned: do not assume that everybody reads your mind as in most cases it can turn against you. As I have mentioned, I planned that first week will be for major workshops and writing user stories and the second one will be for planning and additional required information gathering.
After first week when I finally started to talk to my team regarding what we have and where we are I found out that people are still planning meetings to discuss different topics. And in the end, on Friday, I missed the information required to prepare a report that had to be provided to the client on Monday. Nothing new You will say? I would say that it was simply pure planning due to my assumptions that the team will know what I want + of course multitasking story.

So maybe the first pancake wasn’t the best one, but it wasn’t totally burned. We ate it and already started our first sprint and that’s about what I will be talking in my next post. Stay tuned!

Patiko (1)

Rodyk draugams

2 Responses | “First pancake theory”

  1.   Vaidas Adomauskas rašo:

    Great post! it seems you are getting your hands dirty with Scrum!! Keep it coming!

    If I may, i would advice is to have retrospectives about what happened with all your team. They might (and i believe they will) have different insights into possible solutions to such cases. Most importantly, they will start seeing that they can shape up the process themselves and get more commitment. Then you are not alone when identifying possible risks, but you will have all team to help you. Don’t leave them to “read your mind”, ok, your blog in this case :)

  2.   mcekutis rašo:

    Thank You Vaidas for reading my blog, heads up and advices You give.
    That’s 100% true. As I said, we were not using Scrum for planning, but when looking back I see that most of the problems could have been addressed much better if we did. And yes, if I had retrospective after a review meeting (as we actually had a review) I would know more of what’s on my teams mind and vice versa.

Leave a Reply