Needles to say that these were two intense days of ongoing discussions and creation of new ideas. When great minds think alike it is amazing what the outcomes are. Overall, it has been very energizing.

Since the complete PSM material is rather large we weren’t able to complete it. Now, our colleagues will pick up our work at the next trainer gathering in Brussels and carry on the baton. Hopefully they will not only carry but also inspect our work and improve it.

So stay tuned for an improved PSM training – a training even going deeper and addressing the more challenging problems of today’s Scrum Masters.

Thanks to my fellow trainers at Scrum.org, I feel honored to call you my friends and to be part of this.

The one company which I never even put a foot in was Apple – I drove by twice a day – but 1 Infinite Loop is a black box for me. So how does Apple do what it does? How could this company recover like a phoenix from the ashes? I admire Steve Jobs. He does magic on stage when showing Apple’s latest products. He has a strong personality and there are quite some stories floating around about his famous tantrums. So, how did this man turn around Apple? Well, to be honest I don’t believe that it was a one man show completely; however this one man is in the exact right position.

Let me explain how I see the role of Steve Jobs though Scrum glasses.

Each Scrum team consists of one ScrumMaster, a Team and one Product Owner. For larger projects you can have more Scrum Teams working together, which is called a Scrum of Scrums. A company wide Scrum of Scrums enables the company to do agile product portfolio management , which is crucial to overcome the stasis of annual plans. At the very top of those Scrum of Scrums, you have THE Product Owner, the over-Product Owner, the one person responsible for what gets developed in which order. Steve Jobs is exactly this person at Apple. Sure, he is CEO and has absolute power. However, in contrast to other CEOs which are too far removed from the details, Steve Jobs is exactly interested in these details. He had the whole iPhone redesigned because it had more than one button. He decides to accept or not to accept the products. He gives the acceptance criteria and he has to like what he sees or it does not see the light of the day.

To me this confirms that one of the most critical roles in a Scrum Team is the Product Owner. Sure, the best Product Owner with a lousy team will not succeed either, but a great team can only be on top of the game with a great Product Owner.

The success of a project depends on the Product Owner, its role but more importantly the person, and definitely NOT how good or detailed the requirements are. A good Product Owner enables the Team to rise above and make a great product the right way.

How does this fit together with Scrum? Not at all! Scrum is built on three legs. Transparency, Inspection and Adaption. It is the Transparency part which is in conflict by not being able to tell the truth, the naked truth. All software projects will encounter problems and are predictable only within a short planning horizon. Most non-trivial software projects belong to the complex category according to the Cynefin framework. Complex projects cannot be managed by a defined approach but require an empirical process. It is the empirical approach that is based on Transparency, Inspection and Adaption. Empiricism wants feedback; this is why Scrum has Sprints, Daily Scrum, Review and Retrospective. They are the empirical process controls. They provide feedback about the product under development, the progress and the process. All of them are subject to change when appropriate. Inspect and Adapt!

Now, imagine a company which is run top down military style. You get your orders, don’t dare to even question them and then report back. Your reports are checked against the minutiae defined plan, often a Gantt chart. You cross your fingers that you will not be the first one to bring down the plan. You know what happens to the bearer of bad news! This is a very toxic environment for any kind of agile change effort. The moment you discover or run into some serious situations people tend to loose their ability to speak up. The situation becomes a problem and looses its opportunity for improvement. Forget all about Adaption and improvement. In short, the whole effort is futile.

A successful Scrum introduction needs an open management. A management that can let go of being in control and is able to change from

Command and Control to Leadership and Collaboration

This is the most challenging part for management. Essentially they need to make themselves obsolete and become servant leaders to their teams [1]. Until this happens, it is my job as external Scrum Coach and Change Agent to shield the teams I am working with. At the beginning of a Scrum introduction, it is much easier for the teams and the management if I – as the Coach – am the one stepping up, telling how things really are and even taking the fall out. It is not always fun but it is very rewarding as it builds up the trust between the Scrum Team and myself. The individuals on the client might risk their careers; but myself, in the worst case, I only get shown the door. I am a paid sacrificial lamb.

I am a European who has worked in Germany, France, England, USA and now Switzerland all along my career and based on my experience, I am sorry to admit that there is something about the term ‘Old Europe’. In continental Europe, there seems to be a lot of rigid top down hierarchies, still. Maybe this is the reason why the agile adoption takes longer to get going over here. However, I am happy to see dramatic changes this very past year.

Give me a call if I could be of help to you or your company.

[1] Dan Pink, Drive, Kindle Location 1275, […] Autonomy over task has long been critical to their ability to create. And good leaders (as opposed to competent ‘managers’) understand this in their bones. […]

The future is Lean-Agile

However, in that meeting the POs and SMs of the two teams were told that having different reports was not acceptable – that they could be confusing; which they weren’t because we had already moved people around – and that the company would mandate a specific tool enabling anyone to work anywhere without having to get any introduction. This might work if all the teams would do the same kind of work, however, in this setting the different teams do a different kind of work using  different technologies.

I knew that that specific meeting was scheduled to address that very topic. So, on purpose I did not mention this beforehand to neither of the SMs and POs. I was curious to see how they would react and how they would argue. I wanted to see if I was doing a good job as a coach. It was a textbook show. They simply said: ‘No way! We have delivered working software on time since we started with Scrum, this is how we agreed to work in our Scrum Team and it works great for us. We had people moved around and nobody was confused. Last, there are more pressing issues than how certain reports should look like!’.  Of course, the manager was not pleased. He argued that this had to be done in order to align the whole company and lay a foundation for future improvements. The Scrum Teams replied by explaining some principles and practices of Scrum. They also described how it makes sense to keep on working the same way and that they would be open for some changes when both teams would see the need for it – however, right now they do not welcome it.

This went on for the best part of the hour. Sadly at the end we were told that we would have to obey with whatever decision the management would come up with. Our reasoning was not understood – we had failed.

What had happened? Each party was perfectly able to follow and understand each word of the discussion. However, the management side did not extract the same kind of information. We had a semantics disaccord. They understood each single word but did not get the meaning of what we were trying to communicate.

I’ve come to the conclusion that this could be explained with the Dreyfus model of skill acquisition.

• Expert
• Proficient
• Competent
• Advanced Beginner
• Novice

The Scrum Teams each had about 6 months of hands-on Scrum experience and discovered first hand what it really means to walk the agile walk. They learned a lot about agile and enhanced their theoretical knowledge with hands-on practical experience. Their limited explicit Scrum knowledge became tacit and abundant. Tacit knowledge is knowledge that is difficult to transfer to another person by means of writing it down or verbalising it. It was exactly this tacit knowledge that was missing on the managers’ side to really understand what we were trying to explain. Same words, total different meaning.

The Scrum Teams have moved up the Dreyfus model and are around the competent or even proficient level, whereas the management is still novice, advanced beginner at best. We had an interfacing problem and did not communicate on the same skill level. The risk with that is that you think you understand, but don’t understand without realizing it.

I am convinced that this is one of the main challenges when communicating certain topics. You cannot assume that everyone has the same tacit knowledge and thereby the same skill level then you. You need to find a way to describe matters to a novice as tangible as possible. Not an easy feat but a necessity.

Consider the Dreyfus Model whenever you head to a meeting where you have to do a lot of explaining. If you are too far apart on the Dreyfus model, the others won’t be able to understand even if they think they do!!!

…. wenn man nur lobt und negative Dinge nicht gleichermaßen anspricht, kann dies genauso kontraproduktiv sein, wie wenn man nur kritisiert. Warum? Ganz einfach – weil der normale Umgang mit Kritik verloren geht und Kritik sehr schnell persönlich genommen wird. Darüber hinaus wird eine Gruppe in der es nur Lob gibt rascher “satt” und hat mehr Probleme schwere Phasen zu durchlaufen. Die Lösung kann daher nur heissen: Loben wenn es angebracht ist, aber genauso konstruktive Kritik äußern, wenn dies von Nöten ist. Viele werden jetzt denken, dass dies völlig normal ist – aber sorry, das ist es definitiv nicht.

Ich habe beide Fälle erlebt und ganz ehrlich – ich weiss nicht was besser ist. Wenn man gesagt bekommt “Du machst alles falsch” oder wenn man gesagt bekommt “Du machst immer alles ganz toll”…Natürlich ist Beides verheerend und endet auf kurz oder lang im Chaos.

Daher: Funktionierende Teams müssen eine Feedback-Kultur besitzen. Schwächen müssen genauso angesprochen werden wie Stärken und zwar auf Augenhöhe. Selbstverständlich ist es einfacher etwas Positives schnell daher zu sagen als sich ernsthaft mit einem Problem oder einer Schwäche zu beschäftigen, aber hilft das dem Team(-Mitglied) weiter? Wird sich der Einzelne und die Gruppe weiterentwickeln? Wird es aus den Fehlern gelernt werden? Wird das Problem auf Dauer behoben? Nein, Nein, Nein und nochmals Nein!

Daher kann ich mir nur wünschen, dass sich Chefs und Projektleiter mehr um Ihre Teams kümmern sowie ehrlich und offen mit den einzelnen Mitgliedern umgehen und dafür sorgen, dass genau diese Kultur auch innerhalb des Teams gelebt wird. Denn nur so wird ein Team auf Dauer erfolgreich sein.

Ich würde mich freuen mehr über Eure Ansichten und Erfahrungen zu diesem Thema zu erfahren …

For me, everything is working out great right now. Scrum.org is an excellent organization which is absolutely committed to high standards and quality. Working with Ken turns out to be great fun and best, I really love to spread the Agile/Scrum gospel.

You can check out my upcoming trainings at http://courses.scrum.org/about/ralph-jocham
or drop me an email for special arrangements ralph (at) jocham (dot) net

This problem was described by Martin Fowler in his Flaccid Scrum article and by Ken Schwaber in an interview. Ken, then left the ScrumAlliance to found Scrum.org so that he can address exactly this problem. Professional Scrum Developer (PSD) is the result. There are two tracks, one for .Net in C# and one for Java. I co-developed the Java course which is build 100% on open source tools. It is an intense five day class in which the developers are exposed to a real live scenario, in which they have to deliver working software according to the definition of done in 4 mini sprints. It includes all aspects of Scrum like, sprint planning meeting, daily scrum, review and retrospective. The five days are very intense. My goal is to provide each participants with the feeling and experience what real Scrum feels like. Once, you have experienced this, you know exactly what you should aim for. You want that feeling again!

The first Java PSD was held in Zürich, Switzerland from June 4th-10th. Ken Schwaber attended the first day and really liked what he saw. The overall feed-back was very positive and I am happy to know that there a eight more ‘real’ agile developers in the field. I believe that the earlier you get a change to work with programmers the more they get out of it. Therefore, I am wondering if it would be possible to even integrate that training into the curriculum of computer science studies.

If this sounds interesting, the go to Scrum.org and check out the available training side. Also, I will be giving a Scrum in Depth (SID) class in Bern, Switzerland on June 5th-6th.

The future is lean agile

Stay tuned for more trainings and do not hesitate to contact me — Ralph Jocham

I am looking forward to working together with Ken Schwaber and to pursue the success of Scrum.

Cheers,
Ralph

Wie setze ich das Alles in die Realität um?

Wer beschäftigt sich mit diesen Themen? Firmenchefs und Manager? Ich denke, dass dies nur in wenigen, seltenen Glücksfällen die Realität widerspiegelt. Gehen wir doch einmal davon aus, uns weder in einem super-dynamischen web 2.0 IT-Unternehmen zu befinden, noch mit einem Management konfrontiert zu sein, welches nicht an den guten, altbewährten Methoden festhalten will. Wie argumentieren wir? Wie überzeugen wir einen Patriarchen eines mittelständischen Unternehmens davon, nicht mehr der Alleinherrscher zu sein? Wie überzeugen wir Ihn davon die Transparenz in seinem Unternehmen zu erhöhen und hierarchische Strukturen abzubauen? Wie bringen wir ein Management dazu diese “radikalen” Methoden umzusetzen und sich – in Ihren Augen – damit gleichzeitig selbst zu schwächen?

Als ich auf meinem damaligen PMI-Vorbereitungskurs war, fragte mich der Trainer, ob meine Chefs auch schon diese Zertifizierung haben. Auf meine Frage des warum’s, antwortete er, dass ganzheitliches PM nur funktionieren kann, wenn das gesamte Unternehmen dahinter steht – mit allen Konsequenzen. Wie wahr. Aber dieses Bewusstsein auch an den richtigen Stellen zu schaffen halte ich für äußerst schwierig, weil dies oft Verzicht bzw. radikales Umdenken erfodert. Über zahlreiche Meinungen zu diesem – meiner Meinung nach – sehr diffizilen Thema wäre ich sehr dankbar.

Nehmen wir doch mal meinen Lieblingsverein, den 1.FC Kaiserslautern. Einst ein Bundesliga-Urgestein tümpelt er seit mehreren Jahren in der zweiten Liga herum, hoch verschuldet und vor knapp 2 Jahren nahezu insolvent. Das Stadion verkauft, die Fans blieben weg, sportlich am Ende und, und, und….Dann kam Stefan Kuntz, der heutige Vorstandsvorsitzende, er hatte eine Vision, er integrierte die passenden Leute, holte Sponsoren und Fans zurück und verpflichtete Spieler und Trainer die seine Philosophie mittragen. Heute steht der FCK auf Platz 1 in der 2. Bundesliga und die Euphorie ist riesig.

Münzen wir das Ganze doch mal auf IT-Projekte. Projekte können nur von Erfolg sein, wenn ein Projektleiter ein Teamplayer ist und sich nicht permanent in den Vordergrund drängt. Wenn er die Gruppe bzw. das Team – unter Berücksichtigung kultureller Unterschiede – homogen hält und mit dafür Sorge trägt, dass die Arbeit Spass macht. Wenn er alle relevanten Stakeholder integriert, um eine gemeinsamen Zielvorstellung zu entwickeln und diese auch gemeinsam zu vertreten. Wenn er flexibel und effizient mit dem Team gemeinsam auf Unvorhersehbares reagiert. Wenn die “Vereinsführung” 100% hinter einem Projekt (bzw. Projektleiter) steht und es auch tatkräftig unterstützt und, wenn der Projektleiter ausreichend fähig und befähigt ist Entscheidungen zu treffen und dies auch tut.

Den nächsten Post  gibt’s wieder englisch und trotz Olympia ohne sportive Aspekte – versprochen.

]]> http://jobo2010.wordpress.com/2010/02/08/fussballprojektmanagementtrainer/feed/ 0 chbotta