Vorträge „Innovation – das wahre Bottleneck?!“ auf der OOP 2012

Auf der OOP 2012 habe ich einen regulären Vortrag sowie ein Pecha-Kucha zum Thema „Innovation – das wahre Bottleneck?!“ gehalten.

Die Folien für beide Vorträge finden sich inkl. Foliennotizen auf Slideshare:

Inhaltlich geht es darum, dass meiner Meinung nach viele Produkte / Systeme zu wenig Nutzen erbringen und wir dieses Problem nicht dadurch lösen, dass wir Anforderungen schneller umsetzen. Wir müssen es dadurch lösen, dass wir wertvolle Features entwickeln, auch wenn wir dadurch etwas langsamer werden.

Self selected Product Owners and ScrumMasters

One of my clients (serving several customers with custom made solutions) decided to introduce Scrum. They grouped people together that worked in the same projects or for the same customers. The result were three Scrum Teams. The next step was challenging. Who should be the ScrumMasters and who should be the Product Owners? Should there be full time ScrumMasters or would it be a better fit if the ScrumMasters were also developers? Who could be a Product Owner? In one team there were several options. Would one candidate be pissed off if the management chose the other guy? In another team there seemed to be no perfect match. Should the second Product Owner candidate of the one team be transferred to the other team although this would mean loosing his experiences with his existing customers?

I introduced the idea that self organization is a powerful tool to solve challenging problem. Here we were: We had Scrum Teams that could self organize and we had a challenging problem (filling the Scrum roles). So it was decided to let the Scrum Teams decide who would be ScrumMaster and Product Owner. This was done in a workshop with all teams. The result was to some extend surprising to the management but they stuck to their commitment to let the teams decide.
I don’t know how good the selected ScrumMasters and Product Owners will manage their jobs. Independent of their future performance I think there are several interesting aspects in this story:

  • The teams selected ScrumMasters and Product Owners in an hour or so. When management tried to select the roles it took much longer and provided no result.
  • The Product Owners and ScrumMasters were selected by the teams and not assigned by management. I think that will help development team, ScrumMaster and Product Owner to act as ONE team without some kind of boss.
  • If problems with the ScrumMasters and Product Owners would occur it should feel naturally for the Scrum Teams to select new persons for the roles.
  • The management demonstrated trust into the employees and empowered the teams.

When I mentioned the self selection on Twitter there was doubt that the approach would be suitable for the Product Owner role. I can understand the doubts but like to think along these lines (assuming that there are sufficient Product Owner skills in the Scrum Team):

  • If the Scrum Teams selects the person who would be selected by the management anyway, the management demonstrated at least trust into the team.
  • If the Scrum Team selects another person, things really become interesting and there is great opportunity to learn something. Why does the team have another opinion than the management? Which opinion is more relevant to the success of the team? Is there a need and the possibility to reach consensus between team and management?

P.S.: I think it is totally valid for the management to assign the Product Owner. But is that really the best option – especially for a mature agile organization?

The Shu, Ha, Ri of Scrum

Shu Ha Ri „is a Japanese martial art concept, and describes the stages of learning to mastery.“ (see [1])

Aikido master Endō Seishirō shihan stated: „It is known that, when we learn or train in something, we pass through the stages of shuha, and ri. These stages are explained as follows. In shu, we repeat the forms and discipline ourselves so that our bodies absorb the forms that our forebearers created. We remain faithful to the forms with no deviation. Next, in the stage of ha, once we have disciplined ourselves to acquire the forms and movements, we make innovations. In this process the forms may be broken and discarded. Finally, in ri, we completely depart from the forms, open the door to creative technique, and arrive in a place where we act in accordance with what our heart/mind desires, unhindered while not overstepping laws.“ (from [1])

Shu-Ha-Ri in Scrum

These learning stages can be applied to Scrum, too. A team starts with Shu. It practices Scrum by the book: the flow with the roles, the meetings/ceremonies and the artifacts. Premature adaptations to Scrum in the Shu stage often lead to the famous ScrumBut situations (see [2], [3]). A team enters the Ha stage only after it has shown its ability to use Scrum as it was intended and has achieved a deep understanding of the spririt of Scrum. Then it may (and I think it should) adapt Scrum on their understanding of the spirit of Scrum. After a team has been in Ha state for a probably long period of time it may enter Ri and dismiss all rules.

From Shu to Ha

Two interesting (and interrelated) questions arise here:

  1. How do you know that you have practiced enough in Shu state and you may enter Ha state?
  2. What are typical adaptations for Scrum in Ha state?
For question 1 you could use the ScrumBut test defined by Jeff Sutherland on the base of work from Bas Vodde. Another option would be the Scrum checklist from Henrik Kniberg. Both focus in the practices and my miss checking the understanding of the spirit for Scrum but as a starting point both seem reasonable. At least if you score badly you can be pretty sure that you should practice more. If you adapt Scrum without having it mastered you normally end up with the so called ScrumBut (see [3]) – something that is similar to Scrum but only reveals a fraction of the possible improvement. Typical ScrumBut adaptations move in the opposite direction of the Agile Manifesto (see [4]) and the principles of Scrum. These are examples I have seen:
  • We don’t have that much time for talking face-2-face. Therefore the Product Owner creates a detailed specification of what has to be implemented.
  • We had problems that the Product Owner won’t accept the product increment during the Sprint Review. Therefore he has to comply to detailed checklist for new requirements.
  • We do the testing after the last Sprint of a release with a seperate QA team. Just to be sure.
  • We don’t have real users/customers in the Sprint Review because we want our product to work for thousands of users and not only the few that would be there.
  • The Product Owner does not participate in the Sprint Retrospective since that would discourage the team from speaking openly. During the retrospective the team creates a list of things the Product Owner has to change and the ScrumMaster has the job to force the Product Owner to comply to the list.
  • The team isn’t committed to the Sprint Goal and gets distracted from the project by doing other tasks (like preparing a presentation for the boss).
  • The Sprint Planning lasts far more then the recommended max. of 5% of the Sprint duration since the team tries to estimate the Sprint Backlog very accurately to guarantee that they would deliver the whole Sprint Backlog.
  • The team members don’t participate in the Sprint Reviews to save costs.
Don’t get me wrong. I totally understand the problems that occur when a team/company starts using Scrum. And during the transition it is often neccessary to do ScrumBut adaptations – and that is OK if you work on removing the Buts.
For question 2 I have seen very different things but I think there is a pattern. Teams in Ha state tend to work more closely together and do things more often, even in a continuous flow style. Some examples I have seen:
  • Do the Daily Scrum every 2 hours (and change pair partners in the same rythm).
  • Do the Daily Scrum continuously during the day (an observer may not even notice that you are doingDaily Scrums).
  • Do the Sprint Planning in only 15-30 minutes and only talk about the Sprint Goal (create user stories and tasks just-in-time during the Sprint).
  • Shorten Sprint cycles from weeks to days, to one day or to two hours. Notice that this is not only a question of releasing something. You also need to collect feedback and adapt to it in this short time frame.
  • Release within the Sprint and  do the Sprint Review on feedback of real users using the live system. (The definition of done would then include „released“, „feedback from live users collected“)
  • Working with Single Piece Flow (the whole team works on the same single story until it is done).
  • Stop using timeboxed Sprints. This is a tricky one since there is the danger of just stopping the Sprints because it feels more comfortable that way. Often the Sprint constraint is replaced with another constrain, like in Naked Planning (no Sprints but Single Piece Flow and release after every story/MMF).
  • Product Owner und Development Team write all user stories together.

But: If you just copy things from the above list you are definitely not in Ha state, you are still Shu! The point with Ha is that you create an innovation from practicing. But it can and should be part of advanced practicing to experiment for a defined period of time (e.g. one Sprint) with unusual things.

From Ha to Ri

There are very few – if any – people in martial arts that reached Ri level. I wouldn’t expect to reach Ri level in agile software development before doing it a really long time. I don’t think I have seen a Ri level team in the 11 years I am in the agile community. Therefore I can’t say much about it. I would expect absence of any regular meetings, roles and artifacts (except the product) and creating a very successful product in a sustainable way.


  1. Wikipedia article about Shu Ha Ri: http://en.wikipedia.org/wiki/Shuhari
  2. My presentation about ScrumBut and Shu-Ha-Ri (in german): http://www.slideshare.net/roock/scrum-but-agil-aber-xpdays-germany-2010
  3. ScrumBut from Ken Schwaber: http://www.scrum.org/scrumbut
  4. Agile Manifesto: http://agilemanifesto.org

Buchtipp: The Lean Startup

Wie können wir schneller lernen, ob Produktideen erfolgreich sein können oder nicht? Dieser Frage geht Eric Ries in seinem Buch „The Lean Startup“ nach. Er fordert sogenanntes „Validated Learning“: Man formuliert seine Annahmen in der sogenannten Customer-Problem-Solution-Hypothese (welche Anwendergruppe hat welches Problem und wie gedenken wir es zu lösen) und definiert ein „Minimal Viable Product“ (MVP, Minimal Brauchbares Produkt), mit dem man seine Hypothese überprüft. Das Ziel des MVP besteht darin, Annahmen zu überprüfen und lernen und das möglichst schnell. Man erstellt also ein MVP, dass so rudimentär ist, dass es fast nicht funktionieren kann – fast. Wenn wir (nach vielen Fehlschlägen) dann Hypothesen gefunden haben, die sich bestätigen, baut man das MVP schrittweise in Richtung eines richtigen Produktes aus.

Eine Besonderheit sind dabei die extrem kurzen Zyklen, die man anstrebt. Wir haben erst vor wenigen Tagen an einem halben Tag eine Customer-Problem-Solution-Hypothese definiert und ein MVP entwickelt.

Offensichtlich ist dieser Ansatz nicht nur dann sinnvoll, wenn man ein Startup gründet. Passend dazu definiert Eric Ries Startup als Produktentwicklung unter großer Unsicherheit. Das Buch adressiert als das Startup in der Garage genauso wie eine Produktneuentwicklung in einem Konzern.

Ich finde, das Buch ist sehr gut geschrieben und es stellt einen wichtigen Meilenstein in der Entwicklung unserer Branche dar. Allerdings fokussiert das Buch darauf, den Leser vom grundsätzlichen Ansatz zu überzeugen. Es bleibt manchmal etwas schwammig, was man konkret machen soll/kann. Außerdem handeln die meisten Beispiele von Internet-Anwendungen. Für andere Produkttypen ist etwas mehr Transferleistung notwendig. Bestimmt kommt demnächst ein Nachfolgebuch „Implementing the Lean Startup“ heraus, in dem konkret beschrieben wird, wie man es denn nun macht. Trotzdem ist auch dieses Buch absolut empfehlenswert.

G Forces, Release Cadence and Feedback Cycles

When I saw the G Forces presentation by Kent Beck at the Lean Kanban Central Europe conference  had an insights that wasn’t that clear to me before.

For those who don’t know the G Forces presentation: it is all about shortening release cycles from months to weeks to days to hours to minutes.

What became clear to me: The release cadence is not the real point. It is all about feedback. You have to be able to incorporate feedback according to your release cadence. Releasing every day doesn’t help too much if you need a month to collect feedback and react on it.

Perhaps we should reflect that with our metrics. What about Feedback Cycle Time and Feedback Coefficient as new metrics for teams?

Feedback Cycle Time would be the time you need from the release of feature A until you are able to release feature B that incorporates the learnings from feature A? For example: You release feature A to production on 1st of february 2012. Then you collect data from the production usage of B for 1 week. You discuss the findings for one week and take another week to redefine some of the features in the backlog. And then you need 3 weeks for implementation, test and release of feature B that incorporates the learning. In this scenario your Feedback Cycle Time would be 6 weeks.

The Feedback Coefficient would be Number of Features for which feedback was collected / Number of Released Features. For the Feedback Coefficient it doesn’t matter if the feedback was positive or not. The only important thing is the learning. When we are honest most teams today achieve a Feedback Coefficient of zero or very near to zero. The optimum would be 1.

I think both metrics would focus on a weak spot in many teams: The teams try to maximize throughput and minimize lead time but don’t really care about feedback from the market.

Open Letter to some of our Thought Leaders (regarding bashing)

Open Letter to some of our Thought Leaders

Dear Thought Leader,

I really appreciate what you did for our community and the progress of our industry in general.

But sometimes I am puzzled. That happens when you bash an idea or even worse a person. The ideas you had and the concepts you developed are great enough to stand for themselves. You don’t have to bash other ideas/persons to make your concepts look brighter.

Here are some examples that might highlight what I am talking about:

“X clearly didn’t understand what Y means.” How do you know? Did you do an in-person test with X to check his understanding of Y? How does it feel for X when you say that? What will be his reaction? Will he check his understanding or is it more likely that X just defends himself?

“In his blog entry X addresses Y but sadly stops at Z and didn’t thought of A.” How do you know that X didn’t thought of A? Perhaps he did and decided to leave it out to keep the article short?

„Y is a stupid idea. It would lead to (unwanted) Z.“ At least when people are involved how do you know that Y would lead to Z every time in every situation, especially when you tried Y never or only a few times? Do you think the advocate of Y is lying when he says that Y worked at his place?

I don’t suggest stopping arguing! Arguing is possible without devaluing other ideas/persons.

One could say “X wrote a nice blog post about Y. I’d like to add some thoughts on Z.” or “X presented Y in a way that puzzled me. I would rather think that …” or “Y didn’t work when I tried it. Therefore I tried something different that I’d like to present.” or even „Y simply does not resonate with me. Therefore I used Z.“

If you defined something very clear and X presented it just plain wrong you could just call or email X and make the correction. Don’t spend your previous keynote time correcting one person. There are hundreds in the audience who want to learn something from you.

My wish for the future is that we all learn to become better at arguing without bashing and devaluing.

Yours respectfully,

Stefan Roock

P.S.: I am am sure that I bashed other peoples/ideas as well but that doesn’t make it any better.

Scrum, Kanban and Naked Planning

Some teams start with Scrum, excel with it and then adapt Scrum to go even further. Some of these teams dismiss interations and claim to do Kanban.

Other teams start with Kanban, eliminate columns of their Kanban board, reduce WiP and increase teamwork.

The results are very similar: There is a short backlog of things that create customer value (sometimes called Minimal Marketable Features, MMFs). The team picks the item with the highest priority and splits it into smaller User Storys or Tasks. When an MMF is completed it will be delivered. That’s it. The would result in a 3 column board: ToDo, Doing, Done. This board design is similar to a Scrum taskboard but the „process“ is different. Since there are no iterations there is no distinction between a product focused backlog and an iteration focused backlog.

The interesting thing here is that this is mainly what Arlo Belshee named „Naked Planning“. He did that already in 2007 (perhaps even earlier) but only few people recognized it! Nowadays Naked Planning is sometimes reframed to be simplified or small Kanban.

Perhaps both of the above teams should say they are doing Naked Planning (or trying to do) and try to improve even further by having a deeper look at Arlos work (like doing Single Piece Flow for MMFs and limiting the number of MMFs in ToDo zu seven).

As far es I know this video is Arlos first description of Naked Planning (2007): http://www.youtube.com/watch?v=6t4bZtnnQJA

Vom Entwickler zum Berater und glücklich dabei

Anfang September auf der SoCraTes-Konferenz stellte sich ein Teilnehmer mit diesem Satz vor:

„I love to code, but I have to coach.“

Viele Anwesende stimmten durch Gemurmel oder eindeutige Gesichtsausdrücke zu. Es findet sich hier ein durchaus gängiges Muster. Ein sehr guter Entwickler wird zum Coach, weil nur so höhere Gehälter zu erzielen sind. Und so landen Entwickler in Coaching-Jobs, die sie eigentlich nicht wollen.

Ich selbst habe mich auch immer – zumindest zum Teil – dazu gezählt. Ich hatte aber auch immer Spaß beim Coachen und Trainieren. Vor ein paar Jahren habe ich versucht, das für mich klar zu kriegen und dafür eine Vision für mich geschrieben. Hier einige Auszüge daraus:

Ich möchte mich in meinem beruflichen Leben kontinuierlich weiterentwickeln und wünsche mir Anerkennung meiner Arbeit und meiner Person. Dazu möchte ich in motivierten agilen Teams anspruchsvolle Software-Produkte entwickeln. Dabei spielt für mich ein großer Gestaltungsspielraum eine ebenso wichtige Rolle wie der enge Kontakt mit den Kunden/Anwendern. Meiner Meinung nach können nur im engen Kontakt zu Kunden/Anwendern Lösungen entstehen, die die Bedürfnisse der Kunden/Anwender befriedigen.

Das in den Projekten Erlernte möchte ich reflektieren und vergegenständlichen, als wichtige Elemente meiner Weiterentwicklung. Für das Vergegenständlichen funktioniert das Schreiben von Artikeln und Büchern sowie das Halten von Vorträge und Schulungen gut für mich.

Wie man sieht, stand das Programmieren im Zentrum. Alles, was sich um Coaching und Training drehte, war ein Anhängsel oder gar nicht erkennbar. Als ich die Vision aufgeschrieben habe, ist mir natürlich aufgefallen, dass diese Vision nicht wirklich zu meinem Job als Coach passte. Aber irgendwie fühlte ich mich mit dem Coaching-Job dann auch nicht so unglücklich. Tatsächlich war es sogar so, dass ich für Coachings und Trainings viel mehr Anerkennung erhalten habe als jemals zuvor für Programmierung.

Der oben zitierte Ausspruch auf der SoCraTes-Konferenz hat mich erneut an meine Vision erinnert und mein zwiegespaltenes Verhältnis zum Coaching. Ich habe das zum Anlass genommen, nochmal über meine persönliche Vision zu reflektieren. Dabei ist mir klar geworden, dass die Anerkennung nur eines meiner Bedürfnisse ist. Das andere Bedürfnis schien bereits in der originalen Vision durch: „Bedürfnisse von Anwendern befriedigen“. Tatsächlich geht mein Bedürfnis noch weiter: Ich möchte Fußspuren hinterlassen, etwas verändern, einen Impact haben. Das geht über die Entwicklung von Software. Aber wenn ich ehrlich bin, war das meistens nicht der Fall. Die meisten Systeme hatten keine nennenswerte Auswirkung. Das geht viel einfacher, wenn ich als Coach und Trainer arbeite! Tatsächlich glaube ich, dass ich durch meine Arbeit nicht nur Unternehmen wirtschaftliche Vorteile sondern nebenbei auch die Arbeitssituation vieler Entwickler verbessert habe.

Seit mir das klar geworden ist, fühle ich mich viel besser in meiner Rolle als Coach und Trainer. Trotzdem habe ich auch weiterhin Spaß am Programmieren. Nicht umsonst investiere ich viel Zeit in CodersDojo. Ich würde aber nicht mehr jedes Programmierprojekt machen wollen. Es sollte schon herausfordernd sein und in Clojure oder mindestens Ruby entwickelt werden. Und wahrscheinlich würde ich mich auf jeden Fall in die Product-Owner einmischen wollen. Wer so ein Projekt zu bieten hat, kann sich gerne bei mir melden. Solange mache ich meine Hobby-Projekte und bin als Coach und Trainer glücklich.

P.S.: Ich weiß von Beraterkollegen, dass sie nicht sehen, dass sie Anerkennung für ihre Coaching-Arbeit bekämen oder wirklich etwas verändern würden. So ging es mir am Anfang meiner Beratertätigkeit auch häufig. Mit der Zeit sind diese Situationen aber immer seltener geworden. Vielleicht muss man nur lange genug durchhalten, bis man die nötige Erfahrung hat 🙂


Single Piece Flow in Scrum Teams

Here is an easy to apply tip to improve your velocity: Focus on the User Story with the highest priority using Single Piece Flow (aka One Piece Flow) on a team level.

How it works
Single piece flow means that the whole team works at one User Story at any given point in time. Only when the whole User Story is done the team moves to the next User Story.

Why it
Single Piece Flow works due to several positive effects:

  1. Single Piece Flow forces the whole team to cooperate continuously.
  2. This ensures that every team member is informed about state and progress of each User Story. Furthermore the team members learn from each other through intense cooperation.
  3. On this basis it is easy for team members to help each other.
  4. Point 3 together with the fact that a team generally is faster in implementing a User Story leads to a shorter lead time of the User Story.
  5. Shorter lead time and reduced Work-in-Progress means for the team that it has to remember only few things for a short period of time. And this fact reduces the number of bugs and decreases the time needed for bug fixing.

You may doubt what I wrote. Perhaps Single Piece Flow reduces the lead time per User Story. But does it enhance overall throughput or does it lead to under utilization of the team members and higher costs?
Maybe… Luckily it is easy to check. Just try it for one Sprint and then inspect&adapt. You are welcome to share your findings in the comments of this blog article.

S.O.L.I.D. for dynamic and functional languages at SoCraTes 2011

At the SoCraTes 2011 conference I facilitated a session about applying the S.O.L.I.D. design principles to dynamic OO languages and to functional languages.

I prepared some Flipcharts with the SOLID principles (Slideshare), code examples for Java, Ruby, Scala and Clojure (GitHub) and a paper with a description of the SOLID design principles and some thesis about their application to dynamic OO and functional languages (PDF).

I am not sure if the session can be counted as a success. We had three groups. One was working on the application of SOLID to dynamic OO languages with the Ruby code examples. The second group was working on the application of SOLID to statically typed functional languages with the Scala code examples. The third group worked on the application of the SOLID principles to dynamic functional languages with the Clojure examples.

The results were ambiguous and we didn’t find final answers. What became clear is that the SOLID design principles can be applied to all these types of languages. What stayed fuzzy was the question if that application would be useful for the everyday work with these languages. While I tend to think that in fact not every principle is useful in every languages there were others having the opposite opinion.

One of the problems within the workshop was that today OO thinking is baked into out heads. And so the Scala and the Clojure group created designs in OO style. And if you do that with a functional language of course SOLID is applicable and at least to a certain degree useful 🙂

In the end of the session we had a discussion in a smaller group of people if it may be to misleading to apply SOLID to functional programming. Perhaps it drives our thinking in the wrong direction. Perhaps it would be better to go back to the underlying principles of cohesion and coupling and creating new design principles for functional languages on top of these. And perhaps such design principles already exist and I am just to blind to see them.

So: There is still a lot to learn and a lot of experiments to do. If you like to contribute I would really much appreciate it.