Scrum Gathering Lectures Part II

   It was particularly interested to see Danilo’s presentation. Having some inside information because Concrete is one of the IT suppliers of globo.com, it was with curious eyes that I saw it.

   I was particularly interested in how much detailing there would be.

   I think that Concrete was luckily to take part in some of what he was talking about. And the process of adoption in globo.com definitely was decisive for our adoption of Scrum. As soon as we heard about their adoption and started learning what it was all about, we were sure; we had to do it to!

   I particularly liked when he mentioned “Kaisen Mind”. I must confess to be a sucker for some of the Japanese way of thinking. 

   This was a strange lecture. Not because the idea isn’t seductive, using Scrum as tool for strategic decision is sexy. The reason I think it was strange is because it never looks like Scrum at a higher level in companies. Directors are usually out to get each other, there are a lot of politics going on, and the whole team looks like chickens.

   In most places, at the executive level, what really drives people are the bonuses and how these are achieved. It is very, very hard to get them to think like a team. At the end of the day, it feels like you have a backlog and a few meetings to see how things are going. Getting them to work together without a change on how you reward an executive is imho wasting time.

   Unless you are in Japan or some other special condition is found in a company, such as weak executives vs. strong CEO, it looks like Scrum can only surface by doing a deeper change.

   This change would require “team work” to be rewarded and that transparency could be a rewarded in some manner.

   I think it is a very good initiative to try (applying Scrum at the exec level). But at this point impossible to achieve as a model.

   It was a very good presentation and certainly brings to the table a lot to ponder.

   This presentation was the one I liked the most and lighted up some starts in my mind. First of all, we consider them competition, and they do many things similar to us.

   As us, to them the PO is a client (as I think it should always be). And there was a good discussion on what kinds of problems they have to deal with because of that. Also, there was talk on how to deal with the old management and how they collaborate to spread the knowledge of Scrum within the client.

   A very hot subject was the possible recertification as CMMi 5 while using Scrum and their fear that the evaluator might influence too much the result. Traditionally, to prove reaching certain criteria, the evaluator requires documents, and some of the kpi are addressed in Scrum with meetings.

   If you have the time, check out this presentation.

   This lecture was a mystery to me. Every time I talk about distributed version control, the discussion always gets down to backups and making the programmer more prone to committing the source often.

   Distributed source control gets the programmer in a mindset to synchronize with the server less often because he doesn’t have too. He only has to synchronize to get into an integration test or a specific build.

   I was wondering how did they embrace it and live with this? And the answer was: they do not. The distributed versions all reside in a central server, so the commits are all done in the server as well.

   They also demand that the stories are shorter in terms of time so the programmers have to synchronize more often.

   What I got out of this presentation is that GIT (or Mercurial) have better features to deal with merges, diff , etc, nothing more.

   I liked very much to finally meet Boris Gloger. I have heard a lot about him from the guys at globo.com since the time they started Scrum adoption there and I was curious.

   The presentation was very good, I think I know little about retrospectives and I think the presentation brought us very valuable tips. I used some of it on the very next day when we had a Retrospective here in Concrete.

   I was somewhat disappointed with one of the side discussions during the presentation. When talking about quality items on the making of the product, using refactoring as an example, he said that the team should just do it and there was no need to tell the PO about it.

   I asked him directly about transparency, and what he said was that the PO cares about “Done” and this does not concern him (or something in this line of thought). There was also a quick suggestion about telling the PO you’re working on some of the items of the Backlog.

   I understand that sometimes the team can do some tasks underneath the PO’s radar and that it can be easier than having to explain to the PO what is going on, but, imho, a lie is a lie, and even those tasks should be discussed with the PO openly.

   I think nothing should be hidden whenever possible. And if the PO, having the ability to choose, chooses wrong, it’s our job to live with it. To try to help him make better decisions and not deciding it all for him in the shadows is our role.

   I would rather tell the PO that the refactoring is necessary, why it is necessary, and let him know we are doing it.

Tags: , , , , , , , ,

One Response to “Scrum Gathering Lectures Part II”

  1. Boris Gloger Says:

    Hi — you are right, it is necessary to be honest.

    But what you still do not see. Refactoring is not and ADDITIONAL TASK that we need to justify. REFACTORING is a part of developing as bug fixing and testing, developing and writing the documentation. Doing code comments, unit testing, writing a flow chart or discuss our solution within the teams.

    As long as DEVELOPERS believe they have to justify refactoring as something additional we will never get good quality.

    As long as DEVELOPERS believe that REFECTORING is an add-on, they do not understand that to be do good development it is as necessary as getting some air.

    An author of a book does not say rewriting an paragraph is refactoring and and add-on. It is part of the process or writing a clear and good book. You do not ask the editor for permission to do so.

    Refactoring is therefore nothing I need to discuss with the product owner.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: