[openbook booknumber=”9025960251″]

[openbook booknumber=”0321603605″]

13 November 2009 heeft m’n auto weer een grote beurt gehad. Aangezien de prijs bij Kwik-fit aantrekkelijker is dan dezelfde handeling bij de dealer heb ik voor kwik-fit gekozen.
Een van de controlepunten was het oliepeil van de stuurbekrachtiging. Aannemende dat dit ook inderdaad was uitgevoerd, het stond immers netjes afgevinkt op de controlle lijst, verbaaste het me dat bij een controle door mijzelf deze ver beneden pijl was. Om hier zeker van te zijn ben ik naar de dealer gegaan om het nogmaals te laten controleren waarbij mijn bevinding bevestigd werd (en moest 0.25 liter bij).

Verdere inspectie leerde mij dat het vervangen van in de interieur filters slordig was uitgevoerd. De aansluitingen naar de cabine was niet juist bevestigd waarbij er lucht direct vanonder de motorkap de cabine in kon komen. Daarnaast was 1 van de bevestigings-klemmen voor dit onderdeel niet gemonteerd maar lag los onder de motorkap.

Ik vraag me af in hoeverre de andere punten wel correct zijn uitgevoerd…

Update: Na mijn beklag te hebben gedaan bij Kwikfit nederland is contact met mij opgenomen en zijn verontschuldigingen aangeboden. Oorzaak zou communicatie tussen werkplaats en kantoor zijn geweest. Ik zet hier zo mijn vraagtekens bij…

In scrum the ideal world would be a world where a team is homogeneous, fully commited and every team member is multi-disciplinary such that the behaviour of the team becomes more predictable. However in real life, and especially in a setting where waterfall is the fundament you have to work on, this is usually not the case, facing members working part-time, having holidays and getting sick sometimes but most of all having different backgrounds.

Your goal as scrummaster is to optimize the productivity of the team. This means you have to suggest and steer the team in the process where needed in order for them to work as optimal as possible. This suggesting and steering is probably based on intuition, best practices and so on. As scrum is just a set of guidelines and rules there is a lot of open space on how to cope and handle situations like these. One could jump into detail and/or work on a higher level, inspect and adjust, try new methods etc. etc..

The problem is that sooner or later some manager or CEO would like to know what is happening and in which direction the project is going or what can be done to improve the project.
Usually the velocity of the previous sprint will give a good insight on what can be accomplished on product backlog (remember in the ideal scrum world it would be). The uncertainty is that the balance between all disciplines of each story is different. Some are real tech stories and whereas some are design/user interaction stories. This makes it hard to predict the outcome thus increasing the risks involved.

Now what can be done to reduce this risk? The most obvious is knowing what is happening: who is doing what at which velocity such that team velocity becomes more predictable. This implies gathering data, analysing, reporting and so on.

As we start walking down this road i get the creepy feeling something is wrong since we like to keep things simple and cut waste (reports). Focus on being productive is what we want right?
Using this method also reduces the agility in which one assumes it is ok not to know everything right now.

On the other hand:
Knowing the velocity of each team member provides better individual feedback and enables adjustment on the velocity on each member as each team member should/could work on roughly the same velocity, making the team more homogeneous.

Probably the best option would be to apply the statistics when:
– You got the impression the balance between the different fields/disciplines is off
– There is a need to give a more accurate estimate on the product backlog and identify risks.
– More accurate estimates on a single story
– Times off fluctuation in availability (holidays)

If the outcome on the individuals shows big gabs, then perhaps it is time to discuss what the meaning of a storypoint is and what causes these differences.
-are too many disturbances?
-are some members working harder?
-is the concept of a storypoint still clear?
-are the estimates during the sprint planning correct?
-…..

Too be continued…

Weird phenomenon how people can become enthusiastic about something so common as the i-pad.

From wikipedia:

"In essence, RDF is the idea that Steve Jobs is able to convince himself and others to believe almost anything with a mix of charm, charisma, bluster, exaggeration, marketing and persistence. RDF is said to distort an audience's sense of proportion or scale. Small advances are applauded as breakthroughs. Interesting developments become turning points, or huge leaps forward. Impossible-seeming schedules, requirements or specifications are acceded to. Snap judgments about technical merits of approaches are sometimes reversed without acknowledgment. Those who use the term RDF contend that it is not an example of outright deception but more a case of warping the powers of judgment. The term "audience" may refer to an individual whose attitudes Steve is intending to affect."

To me the last big technical breakthrough for me came from Sony as they introduced the PS3.

Today i tried a new exercise for a retrospective. I name it the interview.
Setting: 1 team-member is interviewed by other team-members such that the interviewee wants to explain the sprint, process or something that needs to be discussed.

The point is that emotions and remarks from the interviewee should be captured as that is being used as input for the next exercise. Now in a small group you can assign a few people as a monitor group. while the others are taking the interview.

In this case the team was small so the interviewers also were assigned with the task of monitoring. As input for the interview i used the agile manifesto printed on small cards so each interviewer had to question the interviewee on this specific topic. After 5 minutes i would let the group rotate and thereby enabling everyone to once be the interviewee and interviewer.

The output was written on sticky notes so we could place them on a flap over later on.

The results: the quantity of the output was overwhelming. We had enough material to work on in deciding what to do and categorizing the items. Of course i was interested in the opinion of the team. Their remarks where that the technique for retrieving information was good, but the topics where to general for the sprint and therefor the topics where more suitable for a project retro.

Goals: Besides the obvious goal for this exercise was to retrieve information.
However i also had an hidden agenda.
First of all 1 wanted to make the team more familiar with the agile manifesto and
Secondly i wanted them to work together on their perspective on scrum.

So although i failed to do a retro for this sprint, i do feel the team learned something.