Indien macht mich reicher

In Chennai hat der Tsunami 2004 viele Häuser schwer beschädigt und die "Strandvillen" der ohnehin unglaublich armen Leute hier gegenüber dem Fischmarkt wurden komplett zertsört. Die wiederaufgebauten und restaurierten Häuser sieht man jetzt auf dem Bild. Man beachte, es handelt sich um "restaurierte" Wohnhäuser. Ich habe aus ethischen Gründen dann bei der Durchfahrt durch die Gassen darauf verzichtet, zu fotografieren, was in den Hauseingängen zu sehen war - nur soviel: augesprochen konsequente Fortsetzung des Aussenbildes.

Die Trainings die ich hier mache, mache ich nicht des Geldes wegen. CSM Trainings kosten (und bringen) hier nur einen kleinen Teil davon, was in Europa üblich ist. Aber jetzt gerade komme ich mir schlecht vor, wenn ich durch die Gassen solch armer Leute fahre. Ich habe viele Länder gesehen, aber so etwas noch nicht. Es ist einfach traurig anzusehen, wie diese Leute leben. Dennoch haben sie Hoffnung und Lebensfreude. Ein Rikschafahrer fuhr mich für für 50 Rupies zum Fischmarkt, das sind gerade mal 75 Eurocents. Er bedankte sich 3x dafür, dass ich ihm heute "Business" gebracht habe. Ich habe ihm 100 gegeben, weil er mir etwas gezeigt hat, dass mich bereicherte. Am liebsten hätte ich im Tausend gegeben.

Arm und Reich wohnen hier Tür an Tür. Obwohl das Kastenwesen längst abgeschafft ist, lebt es noch weiter und die Menschen hier sind komplett verschieden. Ich habe eine reiche Familie in einem nagelneuen 550i BMW fahren gesehen, daneben liegen und sitzen Menschen auf der Straße und betteln um Essensreste und leben vom Abfall dieser. Ganz normal in incredible India...

Eine Frage beschäftigt mich während ich mich durch die Stadt fahren lasse, der stinkende Wind in mein Gesicht bläst und ich die Eindrücke dieser Stadt und dieses Landes auf mich wirken lasse: Kannst Du den Menschen hier helfen? Kann ich etwas von dem zurückgeben, das mein Leben so einfach und so schön macht?
Mit Geld wohl eher nicht. So wie ich die Wirtschaft hier kennengelernt habe, macht es die Reichen reicher und die Armen ärmer. Ich verlasse einen "iStore" in einem Glasbau mit Mamorboden, wo ich einen Mac-VGA Adapterfür 1.600 Rupies gekauft habe und nebenan sitzt im Holzverschlag eine alte Inderin und bietet mir zahnlos lächelnd eine Melone zum Kosten an, sie holt ein Schild hervor, wo vermutlich der Preis steht, wenn ich die Melone kaufen möchte. Leider kann ich den nicht entziffern, sie nimmt einen Kugelschreiber und schreibt 50 auf ihre Hand.

In den Shops der Reichen bekommst Du keine Kostprobe. Sie sind auch nicht besonders freundlich und zocken Dich ab. Aber sie machen Geld. 1.600 Rupies für einen Adapter und eine ganze Melone für 50 Rupies. Diese Wirtschaft ist knallhart. Das Marketing der alten Dame funktionert zwar, aber wird sie jemals ihre Waren in einem "Geschäft" oder etwas ähnlichem verkaufen können? Wird ihre Familie jemals so viel Geld verdienen, um ihren Kindern eine Ausbildung zu bezahlen?

Ich glaube schon. Man sieht in diesem Land eines ganz deutlich: Aufschwung. Jungen Menschen geht es gut. Auch wenn für unsere Vorstellung die Verhältnisse extrem sind, in welchen sie aufwachsen, es geht ihnen gut.

Ich gab ihr 100 Rupies und sie freute sich! Die Melone hab ich zwei Blocks weiter meinem Rikschafahrer geschenkt, der sich genauso freute. Der führte mich zum Abschluß meiner Stadtrundfahrt in ein Geschäft, wo sie Touris abzocken. Glasverbau, klimatisiert, chillige indische Musik, zu kaufen gibts: Inische Teppiche, millionen Shiva-Statuen, Elefanten- und ähnlicher Ramsch, sowie Schmuck. Ein gut gekleideter, überdurchschnittlich netter Verkäufer hätte es beinahe geschafft, mir ein 79.000 Rupies teures (knapp 1000 EUR) Stück Schmuck zu verkaufen. Beinahe. Da kauf ich doch lieber noch ein paar Melonen!

Nun sitz ich wieder im Hotelzimmer der Reichen und schreibe diese Zeilen, während der Upload der  Fotos zu Picasa vonstatten geht. Auch wenn in mir noch ein Gefühl der Leere und Traurigkeit herrscht, wegen dem was ich gesehen habe, so bin ich glücklich, so ein Zuhause zu haben und so leben zu dürfen! Ein Privileg, in so einem Land wie Österreich geboren zu sein. Arm ist bei uns niemand. Und ich bin soeben reicher geworden. Um eine Erfahrung, die ich niemals missen möchte.

Namaste!

Incredible India Part 2: Chennai

Chennai, or Madras as the Brits called it. Another metropolitan area with about 10 million people living in. India is really incredible! Despite the warnings, it's quite good climate here. I had a trip through the city and it was about 35°C with a gentle breeze from the sea. Fine, compared to Kolkata.

My Jetlag is still reaching back to Atlanta where I stayed for the Scrum Gathering not even a week ago. Today I have a free day and I slept until past noon, spending the rest with a trip to the city and preparing a little for the class tomorrow. I was told that we are going to have 34 people, so I will ditch my back-of-the-room training style and switch back to slides. It's impossible to have a highly interactive training with one trainer and 34 people. The only thing I need is a mini-displayport to VGA adapter, something I used to carry with me for years. As I do not show slides in my classes anymore, I stopped carrying those things with me….

I started my day with a late lunch in the hotel's restaurant with a view to the pool and green garden. Sipping ice tea and listening to cool goa-style chill-out music I relaxed. My meal was a murgh chicken starter and red fish curry. Again that mistake of eating original Indian food, but there was no choice (having a Burger meal at a fastfood restaurant is not an option). This is how hot it was: When you eat the onion that is there as a kind of decoration and it tastes as sweet as sugar, you can imagine how spicy the curry was… My stomach and digestion seem slowly to get used to it, but neither my mouth nor my palate really do like that spicy food.

Out of all I have seen so far from India, the most pleasant city, the climate is not that extreme and it's not that dirty as I saw in the north. Chennai's European influence is also visible. The Portuguese started a colony here long before the British and Netherlands came. St. Thomas Basilika is one of the best kept churches here and there are still Christians here.

My city roundtrip led me to the beach first. At least it was something that looks like a beach, but not quite that what we expect. People do not bath here, although it would be nice for sure. Unfortunately the whole beach was hit by the 2004 tsunami and large areas were destroyed. Life here seems to have all shades of grey. You see really rich people right next door to the very poor living on the street and begging for a couple of rupies. You see a rich man's house with quite nice exterior and a couple of blocks further housings that you would not like to enter. Plain bricks with some planks of wood sheltering palm branches, paper, metal and other waste to build a roof. Drapery and broken doors cover the entry, debris, bricks, waste and dirt is all over the place where those people live.

My journey continued to the fish market and I needed to return very soon. I could not stand the stink the air had despite the fact the fish was sold out hours ago. Hard to imagine how it smells in the morning… Anyway, I am not sure, if I should have fish curry anymore - don't really know if they get their fish from here, but I'd better not eat fish here - no matter how much spice they put into it.

Live in Chennai is as in all cities I have seen so far in India very busy. People are all over the place on the streets at any time. It is fun to see their Rikschas and that they really still have them in place. Those impressions make it hard for me to believe that again also this city has a large center of IT companies. Power faults, by the way are still common. In Kolkata I personally had three while I had breakfast, during the class I also had some there. Here in Chennai I had only one so far, but it's not even a full day I have spent in this city. Looking forward to the class tomorrow.

Incredible India: Kolkata - where cooling the datacenter is the least problem

My third day in India. Yesterday I arrived in Kolkata, formerly known as Calcutta with a domestic flight from Delhi. Luckily I was able to see the "Skyline" of Himalaya on the horizon right out of the plane window, although the mountains are far away one was able to see the mountain summits clearly.

When I stayed in Delhi, I always thought it was really hot, but I've come to see the master of heat. Stepped out of the plane in Kolkata it felt like hell. From the pilot's announcement I knew it was 42°C - something we know from southern European summers, but humidity adds to it, feels like almost 100%. I have no clue, but not only my glasses grew damp within seconds, also my iPhone!! A driver caught me directly at the exit and drove me to the hotel, where I will stay and also my first CSM class in India will take place. My first impressions out of the well air conditioned cab was awesome. You see more construction going on than anything else. And traffic jams all over the place. Kolkata is a 14 million people metropolitan city in West Bengal very close to Bangladesh, a formerly Indian part.

I hoped to see something, but air pollution seems to be extremely high here, added the extreme humidity and dust from countless construction work making it a huge swomp. The hotel is in Kolkata's IT-district, where the world's major IT companies seem to have their indian subsidaries.

Turn left, there's IBM and look to the right, there is Wipro. I can't really believe people like to be here. I did not like to go outside, stayed in my hotel room. The heat and hunidity is unsustainable and insufferable, a pain in the ass. Wherever you go they cool down like hell, the hotel lobby seems to be at 20°C and the rooms are chilled to 17°C - at least the AC is set to that. The classroom where we run the CSM is very large, about 80 sqm and has multiple air condition outlets, where really cold air is blown out. With me complaining about that, we found out that it is a binary setting: To cool or not to cool, that's the question. So we decided to run it like a proportional controller, when too cold we had it turn off by some staff and turned it on again unless we no longer felt comfortable with the raising temperatures…

I wondered what makes people do such things as outsourcing to such places. Cooling the datacenters here seems not to be the biggest issue. I wonder if they have air condition for the workplaces of those thousands of people working here in IT. Given that, I wonder what the CO2 footprint figure is about considering the thousands of offices they have here.

The CSM class itself was quite fun. People are really interested in Scrum and most of them seem to really understand that the move to a knowledge society also changes the way we manage organizations. IT companies as all companies in India have the reputation of being strongly tayloristic and hierarchical. As this may be true to a certain degree, I felt that there is a change of mind going on when talking with people over here. Although I strongly felt that many people still are looking for a certificate in the first place and a training in the second.

I had same bengal food with the guys organizing the trainings here and while it was delicious, it was very spicy. I truely can not get used to the indian food. I do like Indian food as I knew it from Europe, but honestly that was not like it is in reality. Looking forward to my next move: Chennai. People say, it's even  hotter and more humid than here. Can't wait to experience this.

Namaste!

Mein neues Buch "Scrum - Schnelleinstieg" is erschienen

Nach doch deutlich mehr Zeit als ich gedacht habe, ist es nun endlich soweit. Mein neues Buch "Scrum - Schnelleinstieg" ist erschienen und ab sofort im Handel erhältlich. Es ist einfach online, z.b. bei Amazon bzw. auch als E-Book beim Verlag direkt erhältlich.

Worum geht's in diesem Buch? Na um Scrum natürlich! Und zwar für Einsteiger und auch für diejenigen, die zwar schon Scrummen, aber immer wieder nach neuer Literatur suchen. Das Buch ist aktuell und umfasst die Neuerungen aus dem 2011 Update von Ken Schwaber und Jeff Sutherland sowie eine Menge eigener Erfahrungen und Wissen aus der Community.

Das Buch gibt zunächst eine ausreichend kurz gefasste Einführung und beschreibt das Wesen von Scrum, beschränkt auf den wesentlichen Kern. Gleichzeitig gibt es basierend auf den Erfahrungen vieler Jahre Coaching und Training eine Starthilfe, um einfach mal loslegen zu können ohne dabei auf jene Gesichtspunkte zu verzichten, auf die es ankommt, um mit Scrum erfolgreich zu werden.


Neben Hinweisen auf gute und etablierte Praktiken gibt das Buch auch Antworten auf häufig gestellte Fragen. Die kompakte Form wurde absichtlich gewählt, um auch mit wenig Zeitaufwand die relevanten Informationen für einen Start mit Scrum zu erfassen, zum Beispiel an einem Wochenende. Das Buch zeigt damit nicht die gesamte Welt von Scrum auf, sondern vermittelt gemäß den agilen Prinzipen, den kleinsten gemeinsamen Nenner an Wissen und Hinweisen, um mit Scrum zu starten.

Happy Birthday, Linux!

So, Linux - you are 20 by now - happy Birthday! You did run a lot of my and our company’s systems so well for so many years. 20 years to me look like an age to be treated as an adult, even in OS-land!

The project Linus actually started on this day, 20 years ago did not mention the name Linux itself (actually he would prefer to call it „freax“, luckily it has been renamed by the guy who created the directory on the ftp server).

IMHO that day was a milestone in the history of computing, and it was probably also the event that gave push to the open source movement! I’d like to apreciate it. See yourself:

From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)

Newsgroup: comp.os.minix

Subject: What would you like to see most in minix?

Summary: small poll for my new operating system

Message-ID: 1991Aug25, 20578.9541@klaava.Helsinki.FI

Date: 25 Aug 91 20:57:08 GMT

Organization: University of Helsinki.

Hello everybody out there using minix-

I'm doing a (free) operating system (just a hobby, won't be big

and professional like gnu) for 386(486) AT clones. This has

been brewing since april, and is starting to get ready. I'd like any feedback on things people like/dislike in minix; as my OS resembles it somewhat (same physical layout of the file-sytem due to practical reasons)among other things.

I've currently ported bash (1.08) an gcc (1.40), and things seem to work. This implies that i'll get something practical within a few months, and I’d like to know what features most people want. Any suggestions are welcome, but I won't promise I'll implement them :-)

Linus Torvalds torvalds@kruuna.helsinki.fi

New Scrum Guide by Ken Schwaber and Jeff Sutherland

The two creators of the Scrum framework, Jeff Sutherland and Ken Schwaber have released a new version of the Scrum Guide, the document they call the official body of Scrum knowledge. You can download it from here. Let’s run through it and let me give you an idea what has changed since its first release in 2010.

1. First to mention, there is now much more clarity on the formal definition of roles, artifacts and meetings, such as the term „team“, self-organization and cross-functional, to me this makes absolute sense.

2. „Commit“ is now "forecast". Good, now we don’t need to answer the silly questions anymore about the old joke of Ken about chickens and pigs. I see quite value in removing the pressure that came in from the word "commit", especially in it's german translation "Versprechen", which is even harder. I agree, in most cases even a sprint of two weeks can be complex enough not to be able to commit a certain set of features. It probably was seen also as a guarantee to receive something by stakeholders. But I do see value in keeping the word commited to do good work (...) - but still, there’s the agile manifesto’s principle #5 - build projects around motivated individuals (...)

3. The Sprint Goal is still described to be discussed after the team has chosen the product backlog items it wanted to deliver. In my last post I discussed this topic and I am still sticking to the idea, that the product increment (hence „the goal“) should be designed in the planning meeting but the PO should have an idea of it upfront.

4. The "Sprint Backlog" is now defined as the list of backlog items the team has selected for the sprint plus a „plan“ for delivering them - excellent. I did never teach anything else. The disambiguition maybe came from the whole commit thing, which was actually no problem at all - given „common sense“. All trainers I have worked with including me taught that there is a sprint goal and the team commits to the goal, not the sprint backlog - so, the very exact definition of what the sprint backlog actually is nice, nothing more.

5. The new Scrum Guide states that the Scrum Master enforces the rule that only Development Team members participate in the Daily Scrum (...) - I guess it’s still meant, that Scrum Master and Product Owner are present, but the meeting itself is only for the members of the Development Team.

6. The Release Planning Meeting and the artifact „Release Plan" has been removed, while monitoring progress towards a goal over the series of sprints remains. There is no definition when and how this has to be done. Typical burndown or -up charts are useful. The new Scrum Guide puts inspect & adapt into focus again.

7. The „Sprint Burndown“ is no longer a required artifact, while monitoring progress towards the sprint goal remains. So, there is no presciption about how to do this. Taskboard and Burndown are still best practices but not prescribed by Scrum.

8. The Product Backlog is now an ordered list and no longer „prioritized". This is probably a language issue but in my understanding there was no difference in what the 2011 guide says now. If you have been to one of my trainings in at least the past 2-3 years, you probably remember that I used the term „list of deliverables“ and by „list I mean it in the computer science way“ ... I think this is what’s meant (priority still allows for 10 items being top priority). Roman will have to use DEEO instead of DEEP ;-)

9. Ha! And finally, the chickens and pigs thing is no longer part of the Scrum Guide. Thank you so much. I hated this stupid joke and so did many others. Afaik most of the trainers did not tell this joke and the story anymore. So let’s go ahead and never ever again compare individuals in organisations with animals. There is still a meaningful distinction between members of the Scrum Team and others, makes sense, right?

So, finally - what do we have? A whole bunch of clarification, some cosmetic and language changes and smaller adjustments on things that a majority of the trainers and Scrum community at large did already practice. Except the renaming.

I honestly whish the Scrum Alliance did this work.

Planning for Product Increments

With good development practices in place*, a Scrum team is able to deliver valuable, working software - a shipable product increment at the end of a sprint (I personally prefer to call it without the word „potentially“, „shipable“ is enough conjunctive to express the fact that it does not have to be shipped or deployed). What I have seen from my coaching experience it’s less a problem of working software, development teams can do this after a while they do Scrum.

But what about the „valuable“ part from the agile manifesto’s principle #1 and #3? In Scrum theory we have the product backlog prioritized by business value, so it should not be a problem to deliver a valuable piece of software at the end of a sprint. In theory. In practice, from those few teams I have seen that are really able to deliver a shipable product increment at the end of each two week sprint, most of deliver something that I call a „working intermediate development result“ - without much value. In the course of a couple of sprints they typically can make it also for something valuable.

„Why is this so?“, I was puzzled for quite a long time, until I have tried something. I was looking at the way the Product Owner and team typically worked with the backlog - in a way we told them to do. It was by breaking things into small and very small items at the top of the backlog. That’s correct. The items that feed the next sprint(s) were small and detailed enough - hence „ready“ - to be taken into the sprint, but for a vast majority of the teams I see, those items are very small and the valuable attribute of INVEST diminished a little bit, at least in the sense of being part of a valuable increment.

A second thing, I could see was the fact that during sprint planning, teams are very much focussed on discussing user stories, item by item. After they are done, the „formulate the sprint goal“ and that was the point, where it happens. The goal they formulate typically is something that probably gives some context to the sum of the user stories they selected, but never shaped a meaningful whole that provides value. Regardless the fact that all of the user stories they select are all valuable, the increment is not what I would like to give to a customer.

What I did, was trying to focus on the increment early on, during backlog grooming, preparing and shaping the product backlog by the Product Owner. Furthermore, especially during sprint planning we put an emphasis on the product increment. The sprint goal is the increment which in turn is a valuable meaningful whole. We discussed the sprint goal, say increment first and the user stories prepared for the increment secondly. Same thing with Sprint Planning part 2, discussing a design for the entire increment before focussing on the detailed user stories.

As a result to this, this first sprint of doing so and even more the subsequent sprints were delivering a more valuable product increment than before. The team was much more focussed on value than before. The Scrum team is about to learn what size such an increment can be of, so related to Scrum terminology, its velocity. The Product Owner prepares goals (visions, increments) for upcoming sprints as part of his work with the backlog and learns what the team is able to deliver in a sprint.

As a result to this, I started thinking about some radical changes. First to mention, the product backlog may not need user stories in the form we are used to now?! Probably it could just contain product increments? All of which with different levels of detail, the format of user stories (who, what, why) could of course help with that. Sprint Planning could be much more of discussing and shaping an increment as a collaborative event without the use of “classical” user stories.

Secondly, can we get rid of estimates at all? Or at least use multiples of “increments”? Probably with a nonlinear number sequence, just like the modified fibonacci to cope with uncertainty.

To be honest, I did not find a team until now within my coaching engagements that I dared to propose these changes to their normal course of work. Until now! A team I am coaching these days is willing to give it a “try & inspect & adapt”. So, while I will keep you posted here, please comment on how you like the idea and also what your experience with value of product increments is.

* did I mention, that there is great book on this topic, called „Agile Developer Skills“ - get it from here.

Buch "Agile Developer Skills" erschienen

Das Buch, das ich gemeinsam mit Krishan Mathis geschrieben habe, ist diese Woche erschienen. Es handelt sich um Scrum, Kanban, agile Vorgehensweisen und vor allem Developer Skills hierfür. Enthalten sind neben Kapitel über Srcum und agile Entwicklung für Teams, insbesondere Konfigurationsmanagement, Continuous Integration und Continuous Deployment, agiles Testen, Clean Code, Refactoring, emergente Architektur, Aufgaben und Situationen im Projekt etc. Das Inhaltsverzeichnis kann hier heruntergeladen werden.

Das Buch ist im Handel, online bei Amazon oder beim Verlag selbst sowie als E-Book verfügbar. Das Cover-Bild wurde übrigens von meinem Blog-Post über unsere Objectbay-Summit voriges Jahr inspieriert...

Planning Poker® is Knowledge Management

There is a kind of magic happening behind the scenes when a team plays Planning Poker®. Here’s what: First, the game play forces people to think about a user story for themselves by aksing each player to select a card representing an estimate. The „poker“ part of it is what it makes this work: people need to think on their very own, it’s not allowed to cheat - they come up with their own opinion.

Secondly, they now need to „defend" their opinion when we flip cards. When you have just made up your mind, you for sure will have some points in a discussion, where people are saying something different - right? Having different numbers is great, it shows we have different knowledge and different views about it. That’s why we discuss it. This discussion is the „2.0“ or „wiki“-part of Planning Poker® — we are just about to create more knowledge and share all of it among the group. There is a natural point in the discussion where everything is said - maybe not by everyone ;-) - the knowledge creation saturates. The team now goes into the second round of poker.

The process repeats, people are again forced to think about it on their own with respect to what they have learned right now, out of the last discussion. Again, people come up with their (probably changed) opinion by putting their card face-down on the table. When everybody is done, flipping the cards reveals probably still different levels of understanding of a user story. Great, we again discuss it. The process will come to a global saturation as no new knowledge can be won anymore in this group. But that’s fine. We are done for now. The result could tell us, that we need to dive deeper into the topic and learn more about it (split the story).

If by then, there is still different numbers on the table, it will show us that we still have uncertainty or no common understanding. That’s ok - higher numbers in the non linear number sequence - such as the fib(n) - are there exactly to reflect greater uncertainty. I do recommend to my teams in this case that it is ok to go with the higher number. This tells us that the story is still too unknown, it’s probably just too big.

The non-linear number sequence we choose also is an excellent means to keep discussions short as their numbers represent a category. So the reasonings in the discussion can always be tightened to a certain class of problem and why one thinks, a user story should belong to one or the other.

Java Magazin Artikel "Agile Developer Skills" online

Wir haben die Erlaubnis vom Verlag erhalten, unseren Artikel "Agile Developer Skills" aus dem Java Magazin Ausgabe 01/2011 auf unseren Webseiten zu veröffentlichen.

Das PDF kann von hier heruntergeladen werden - viel Spass beim Lesen ;-)