On March 14th and 15th Scrum.org had organized a get together for their trainers. On the agenda were several topics. The most prominent was to start updating the existing PSM material. Scrum.org added two new trainings. PSTM (Professional Scrum Team Member) and PSPO (Professional Scrum Product Owner). The PSTM is the fundamental training, teaching the basics of Scrum; no prerequisites are required. Whereas the PSPO covers the Product Owner site of Scrum. Those additions are making it worthwhile to look into the existing PSM content and to see what can be removed and what should be updated. On the other hand it was long overdue to meet the other trainers in person.

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.

My job as a coach and trainer gets me around quite a bit. It is always thrilling to meet new people and to learn about all types of industries. During those encounters, I often get asked how companies like Google, Apple and Facebook do work. Before I left the USA for Switzerland, I used to work for ThoughtWorks out of their San Francisco office. During that time I had the chance to peek under the covers of a couple of those well known bay area players. Pretty much all of those companies are agile, not necessarily in a Scrum or XP way but they surely value their people with trust and autonomy. Yes, these are exactly the most important ingredients for self-organization.

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.


Don’t shoot the messenger

In ancient times, it was not uncommon to kill the bearer of bad news. It was a matter of principle. “Don’t bring me bad news. And by the way, don’t fail with your efforts.” Luckily, in these days, the worst that could happen to you is to be fired – not much better in the current economy but, hey, who complains. However, still too many projects or companies are run in exactly that very 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

It is amazing, you can talk to someone, use words that make perfect sense to both parties and still, they don’t communicate at all. I had this experience last week. The Scrum Teams I have been coaching for some time now were scheduled for a meeting with a manager. It was about certain company standards in the area of reporting. The different Scrum Teams were doing the same thing in slightly different ways, no big differences but enough to be visible. Those differences had a good reason: Different preferences how each team wanted to work. Since the teams are self organizing, there is nothing wrong with this approach and either solution makes perfect sense in their given context.

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!!!

Nach langer Zeit schreibe ich auch mal wieder etwas. Sorry, dass es so lange gedauert hat, aber ich versuche mich wieder zu bessern – versprochen. Ich hatte letzte Woche ein sehr interessantes Gespräch zum Thema Lob. Die Tatsache das Lob motivierend sein kann ist unbestritten und grundsätzlich sollten wir alle viel mehr loben, denn Dinge als selbstverständlich ansehen…ABER…

…. 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 …

As mentioned in my earlier blog entry, I gave my first SID training in Bern, Switzerland on June 5th/6th.
The two days were exciting in many aspects. The audience compiled of ten managers, programmers and analysts from different domains was already well on its way to become agile. This meant that I had to answer a couple of tough questions. But hey, this is the spice I really like to add to my professional life, especially if the outcome is right. Also, I was concerned that I might run too fast through all the material. But, the opposite occurred – there were still slides left at the end of the first day. I was about one hour behind. The class was very forthcoming and gave me additional time on either day to catch up. So, next time I will have a closer look at the time to make sure that I keep my time box. Isn’t Scrum all about time boxing!
So overall, I am very pleased with how the first run went. I managed to communicate the meaning of being a ScrumMaster and what to expect when you roll it out. I got feed back from a couple of attendees that they passed the test. Again, this is like a high five for me as the test is not trivial and requires a deep understanding of Scrum basics and principles.
Best, I got tons of of great feed back — mostly positive😉 — which I will incorporate into future runs (Inspect and Adapt). In August I will meet with Ken Schwaber to address and clarify a couple of points.

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

PSD (Java) First Run

Most Scrum implementations fail or have limited success for one reason. The team is not able to really deliver a potential shippable product increment according to the definition of done. This causes all kinds of problems down the road. One of the main manifestations is that the the sprint cadence goes over board. By loosing this, you loose one of the main points of transparency.

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