Wednesday, October 31, 2007

Training - Agile Architecture

I am going to participate Agile Architecture training. If you will be there, please don't hesitate to poke me ;)

If you cannot participate, but you are interested, stay tuned as the follow up will be posted to this blog.

Tuesday, October 30, 2007

Common Scrum Pitfalls - Weak Product Owner

Few days back I was giving "Applied Scrum"-training to Finnish consultancy company and later on I shared my views on one gaming company that I am working for besides Huitale. One the discussions with the gaming company's teams concluded that the challenge in taking the scrum into use is not the team nor even the ScrumMaster but actually Product Owner (PO); missing Product Ownership to be exact.

I started think about it more, and I figured that in old days (tm) stakeholders (anyone with money and power) had plenty of time to make their decision regarding the project at hand. After some analysis there was moment to say "go" or "no go" and then you just followed the Gant charts that never reflected the reality or were updated every 3 months or so. You had plenty of time to react and gather enough intel for making so called "good decision".

Think about scrum-world; if you are PO, you should first of all be available all the time and secondly be able to answer any business / product functionality related question almost on-the-spot. If you don't know the answer, the team will be impeded and won't work until you have it. You are ultimately in charge, responsible and you "ought to know". This creates huge pressure on PO and according to my experience most of the POs cannot handle it. Why?

PO may not actually be correct PO; he may not have big enough stake (he is just a random manager that got the job and actually is more busy with something more important), he might not have the "money" involved (so why should he care that much), he might not know what it means to be PO ("why these guys are bugging me all the time, just do your job, I trust you, you are smart guys...") and so on.

Let me give you one "bad example" based on real life.

Mr Old Requirement Engineer (lets call him Jack) was called to be Product Owner for a product that he was working with previously. In the past Jack had collect customer's wishes, made Requirements Specification document out of those wishes and then discussed with the customer about the requirements. Jack did not know anything about scrum but Product Owner sounded nice title (yes, title, not role) so he took it.

Let me emphasize that Jack is your average "Junior Developer" who never got to develop anything ("You better get some experience first, so we put you just with the customer talking about the software you may some day start develop with the senior developers"). He is a bit introvert, silent, shy but still jolly guy, who likes everybody and wishes that everybody likes him.

Once Jack meets the team he starts seeing that PO-role is something really serious in this "scrum"-thing. Well, he has already taken the title (& role) and he does not like to go to tell his boss that he is not up to the job (Mr Boss is one of those good old Mr Strong Project Managers); so instead of making the issue visible he just continues and hopes that everything goes smoothly. Team still likes him cause they go out every now and then and he still is a jolly fellow.

So the team is established, protected by fresh ScrumMaster (lets call him Sam) (no earlier experience, but has his certification) and Jack acting as PO. Since one of the team members (call him Fred) has some idea about scrum methodology he starts to create Product Backlog for the product for Jack as reference that then Jack should start filling up with real items. However, as Jack is busy guy and Sam is pushed by the boss to start the "new scrum" the teams starts working straight away without prioritized and estimated backlog (ouch).

I (as outsider) tell Fred that he cannot do the backlog, it is not his responsibility and he cannot take the responsibility away from Jack. I tell Fred to contact Sam (ScrumMaster) to tell that they cannot continue until the backlog is sorted out. Fred does it and Sam understands. However, Sam feels that they should not push Jack too much so he tells the team to continue.

Jack is busy guy, he has other projects (old requirement engineer hat) and he does not understand why he should be that interested about Sam & Fred or their project. He starts gathering some backlog, but he feels uncertain since the initial backlog (created by Fred) is so technical that he cannot really do anything about it. He is also feeling a bit guilty and he is afraid of Fred as Fred seems to understand these scrum concepts and all that.

After 2-3 sprints (team has done the items that were put into the backlog by Fred) there is Sprint Planning where Jack should present his backlog items (stories) to the team. In the meeting Jack is really afraid as the team starts asking all these questions "What do you mean by transaction history? What are the visible elements in this history? can it be sorted list? ..". He has no answers as he has not gone trough these with the real customer. He is feeling like a proxy without giving any value. Anyway, he has to shield himself so he asks the team if he can come back later with the answers and the team would just start off. Team declines as they cannot estimate nor understand and therefore not commit. Sam as the ScrumMaster calls the meeting off and says to Jack that the team is not working at all before Jack has the answers. Jack is nervous and confused; why he is pushed around, he is not the customer!?

Boss comes few days later to visit the team and Sam tells him that they are just hanging around, waiting for Jack to finish the backlog. Boss gets furious! "What the heck you guys are up to??!", Sam responds that they cannot commit to anything as everything is so vague. Boss asks what's the problem, as we are all smart guys and we can work things out.. Sam explains the problem of responsibility, the team cannot be responsible of defining what the customer wants; that would just lead to other problems.

Boss goes to Jack who is already wrecked. Jack promises that he will do the backlog so that the company can have some visibility (burndowns). He is still afraid to tell the boss that he cannot do this job, he is the wrong guy to do the ownership...

The story continues due to the fact that this is a real story. Lets see how it ends. :)

Anyway, I think that this demonstrates quite nicely the problem of product ownership and how companies misunderstand it. Imagine if the ScrumMaster would have let the team do the calls; end product would contains tons of features that are not used nor understood by the customer (sounds familiar eh? 45+% features implemented that are never used, Toyota calls this waste).

Till next time..