Understanding comics – Storytelling

again this video as a post. Have a look, it is worth the 18 min.

SBQS in Ouro Preto – Going Large by Staying Small

The SBQS, this time in Ouro Preto, Brazil, is one of the most important Software Quality Events that Brazil has. A lot of people from whole Brazil are here. I am especially happy about meeting Jan Bosch. The leading expert in Software Product Lines. We had an interesting chat about the problems of co-ordinating large software development by enabling self-organization but also enabling long term strategic planning.

Today I did the presentation I did a couple of month ago. Thanks to Katrin Dietze, Vienna this presentation is now much better designed and has less typos.


Next CSM Training in English | 22+23. Juni at Lipno Lake, CZ

faciliteitenLakeside view – this will be an idyllic place for a training!
To support the young Czech Scrum Community there will be a Certified ScrumMaster Training to a very affordable price at Lipno Lake (~1h from Linz in Austria) in the Czech Republic. Because the location is a Holiday Resort, accomodation is included in the overall price of €900 excl. VAT. We hope to meet you there! Register here >>

Scrum Gathering Brazil Review

This review was written by Luciano Félix in portuguese and translated to english. The orginal text can be accessed here.

After losing my flight, thanks to the heavy rains in Recife, I get straight from the airport to the first Scrum Gathering Brazil with great expectations. Everything was very well organized. The Hyatt hotel was a great venue to the gathering. I’d like to congratulate JimCundiff, Jodi Gibson and Alexandre Magno for very successful event.

Project Management as a Strategic Competency – Ricardo Vargas, PMI

I believe Ricardo faced some disadvantages because a great part of the agile community doesn’t get along with the PMI and Ricardo didn’t have a deep knowledge about Scrum, so I think because of that he took a more political and defensive strategy. On his presentation Ricardo said that thePMBOK should not be followed blindly, that’s is just an umbrella, a set of what they think are good management practices and should not be used by the book. “ThePMBOK doesn’t born to be respected”, he said. We noticed an attempt from the PMI to get closer to agile process, creating study groups and awarding paper about it. Ricardo insisted in the idea that the Scrum and the PMBOK have the same goal, deliver value to the customer, sincerely I don’t know any process that want to do the opposite, the goal may be the same, but the chosen path is quite different and it’s get clear when someone asked about the project management importance and the idea of self-organized teams. Ricardo told us that he still sees the PM as something essential to the project success and that he doesn’t believe in self-organized teams. Even with the differences I believe and can’t close ourselves to the PMBOK completely, the dialogue is always important.

Contracts and Scrum: The Good, the Bad and the Ugly – José Papo, BRQ

Jose Papo did a very good talk about contract models, which he called, Good (Open Scope), Bad (Close Scope) and Ugly (Progressive acquisition and by Metrics). Papo shows a great knowledge about the matter, discussing the upsides and downsides of each model, how to apply them, how to workaround the demands of a closed scope contract. It was really interesting, lately I talked to him about the metrics contract, basically function points, and how they will match with the team estimation. It really worth a look.

Virtual Keynote – Ken Shwaber, Scrum Alliance

Unfortunately I couldn’t watch too much form Ken’s Keynote because my presentation would be immediately after Ken’s. He begin with some Scrum concepts and talk a little about Scrumbut. At this I had to leave, but I knew that he perform an activity o illustrate the difference between a command-and-control culture and the idea of self-organization, but the polemic arose when he announced a certification to developers, CSD, Certified Scrum Developer, focusing on engineering techniques, what causes the polemic was the decision to uses Microsoft tools to support the certification.

Using the DoD to improve the product quality – Gustavo Coutinho, Provider e Luciano Félix, Especializa

To start I was very surprised with the amount of people how attended our talk, at least 80 people were there, i was really happy. Gustavo and I tried to show why is so important to have a good and visible definition of done and what kind of benefits it can bring to the project quality. Gustavo also presents how the ProviderSistemas are using the DoD and which king of gains they are getting since. At the end of the session we get a lot of question, that we hope we have answered satisfactorily. We also get a great feedback from a lot o people after the talk and we were able to extended the discussion on the breaks, no doubt it was a great experience.

The challenges to scale Scrum – Danilo Bardusco, Globo.com

Danilo shows how the Globo.com scaled Scrum on the projects they have, He talk about the initial difficulties, which strategies they used to implement the necessary changes.Danilo let it clear the importance to apply good engineering techniques and implement the management within the teams. I will say it again, is incredible how the Scrum culture merge in theGlobo.com DNA.

Creating a Scrum User Group – Igor Macaúbas, Provider

Arriving for the second day, I went straight to the Palm I room to help Igor set everything to his
presentation. Igor did a great job and his presentation deserved to be watched by more people.
He showed a little bit about the Recife Scrum User Group background, which challenges we faced on the beginning, the ideas that worked, that didn’t worked, etc. It’s interesting to see that the group are becoming a source of information about Scrum, not only in Recife, but nationally too. Besides that, Igor have been contacted by professionals from different locations and having the recognition from JimCundiff himself.

How to present Scrum to the customer – Fabiano Milani, Adaptworks

Fabiano’s presentation was not exactly what I was expecting, but was very interesting anyway. He shown how Adaptworks sells the Scrum idea to their customers. Fabiano insist on the importance that the customer understand how Scrum works so he can have a better dialogue with the supplier. I completely agree.

Good things and bad things on our Scrum adoption – Paulo Silveira, Caelum

Paulo’s keynote was really short, he shown a little bit about the Scrum training evolution on Caleum, before and after Alexandre became a CST e and little about the difficulties they faced on the Scrum adoption. The motto was that Scrum is easy to understand but hard to implement.

Game Development with Scrum – Diego Asfora

Unfortunately I didn’t see the beginning of Diego’s presentation, but I saw that he presented his experience as a mobile game developer when he was working on C.E.S.A.R.. Diego talked the problems he had to create multi-functional teams and get them to plan he sprints together, specially when it concern tests, always tricky when it comes to mobile applications.

6 Secrets for running to a good retrospective – Boris Gloger

As expected the room was crowded and even tough I already knew most of the content is always nice to see Boris in action. He started discussing about the human learning process e how we already use the retrospective concept on many areas of human knowledge. Boris showed how important retrospective really are and gave some very useful advices. I really worth a look.

After Boris presentation, We had to leave to no loose our flight and we end up not seeing a final round table, but with no doubt I was a great event. The opportunity to meet a lot of people from different places, exchange experiences and participate on debates was incredible. See you on the next Scrum Gathering.

Scrum User Group in Düsseldorf trifft sich am 3.Juni

Scrum User Group around Johannes Geske is meeting again!

Everybody practicing Scrum or interested in Scrum is invited to join us: 

VENUE: Sapient GmbH, Düsseldorf (map)
DATE: 03-June-2009

– Report of Munich ScrumDay on 6-May
– Distributed Scrum: Lessons Learned 
– Discussion about Scrum info event in North Rhine-Westphalia

Please feel free to propose additional agenda items. After the “official” part of this meeting, we could visit one of the many bars / restaurants located in the Düsseldorf Media Habour.

read more>>

Looking for Scrum Coaches in Europe

Well, this is not a professional job advert, but maybe I can find some interest.

I am looking for people who look for a contractor job as a Scrum Coach working for boris gloger consulting.

I offer:

Very exiting projects in Germany, Austria, Europe and Brazil. I will you to become a good Scrum Coach.

I expect:

  • A CV that shows clearly that you are self-motivated, that you have run a team as team leader and/or ScrumMaster.
  • You are already a Certified Scrum Practitioner or CSC.
  • You have at least 3 years of professional background in Software Engineering.
  • You speak English and German fluently. Portuguese is a benefit.
  • You have read my book and liked what you have read.

If you do not fullfil not one of the above criteria DO not contact me.

In case you do fulfill and you are interested I am happy to receive your

  1. CV
  2. a letter why you would like to work with me.
  3. a recommendation letter of your boss, or a customer you worked for.


Boris at the SBQS 2009 in Brazil

Boris Gloger marca presença no VIII SBQS – Simpósio Brasileiro de Qualidade de Software. O SBQS e um simpósio tradicional no Brasil cuja edição será realizada este ano em Ouro Preto nos dias 2-6 de junho. A maior participação do renomado CST do SCRUM acontecera no WDRA – Workshop de Desenvolvimento Rápido de Aplicações, onde será key-note speaker e participará de uma mesa redonda que discutira experiências praticas da industria brasileira usando SCRUM e modelos tradicionais de Qualidade de Software (como MPS.BR e CMMI).

Vale a pena conferir.

Site: http://www.sbqs2009.ufop.br/

Dia 03.06.2009

Palestra – Going LARGE by Staying Small – Running Large Projects and Companies Using Scrum

Tom Peters called it – “Crazy times call for crazy organizations” (The Tom Peters Seminar 1994) We are in crazy times. The bubble bursts and capital gets destroyed in larger chunks than any time before. Obama tries to help his country to survive this crisis and one thing is absolutely clear – going large was a mistake. Ford, GM, Toyota, Chrysler, Siemens, Infineon, Nokia, Sony all are in big trouble. Open the newspaper and you get scared. What happened? Large organizations – like dinosaures survive just because they are big! They can effort to be ineffective, dull and slow because they are large. As long as the equilibrium in which they can exist does not change – they are the kings.  But – Napster and iTunes changed the Music business, the game industry is hit by self publishing game developers like tellgate, and the first line of defense of the big ones was to by the small ones. But – if you do not have big pockets anymore? You can not assimilate the smaller, the more agile companies. What will happen? The smaller will survive – and the big ones will die. This talk will not explain how Scrum works – it will show you – What you MUST do to become flexible and competitive again and how Scrum can help you to achieve it.

Mesa Redonda – Abordagens Ágeis e Modelos de Qualidade de Software – este Casamento e Possível??

Esta mesa redonda visa discutir como abordagens ágeis e modelos de Qualidade de Software tradicionais (como MPS.BR, CMMI, ISO12207, ISO9000) podem ser conflitantes ou combinados para apoiar programas de melhoria em empresas de software. A mesa redonda será dirigida por Ana Rouiller e Boris Gloger e contara com a participação de pessoas que trabalham em empresas que passaram/estão passando por esta experiência.

Dia 04.06.2009

Minicurso – Scrum Introduction Tutorial
Scrum …. transforms the way of working of software development teams around the world by strictly following the PDCA cycle of Deming.
In this 4 hours session you will learn about the new mindset that Scrum brings to people: The art of the impossible. Deliver very high quality and working software at every milestone: The Review at the end of every interation (Sprint).
You will learn also how the people in Scrum work together: The Product Owner, the Team, the Scrum Master, the Customer, the End-User and the Manager. And how all these roles work together to deliver results every couple of weeks.

Scrum Teams – No Part Time!

Last week a attendee of a CSM training was upset that I said that I do not like part time team members in my teams.

She said this is ridiculous. Scrum would be so extremely hard on rules. All the benefits that people got during the last years: part time, working from home, going into the office when you want does not get valued by Scrum.

My answer was: “That is not what I said — I said: I do not like the idea of part time people in my teams. I tried to explain for two days that Scrum-Teams can do what ever they want, as long as they are getting more productive!”

People still believe that being flexible and not committed to the team, means: “I am more important than the team success”, is a useful work ethos.

Is is not! A football team goes together on the field! A surgery team works together, a delta force team works together.

A team based framework (Scrum, Scrum Alliance Websites) has as prerequisite: A Team!

A bunch of individuals who go to work — is not a team, they are only a bunch of workers!

Kanban or Scrum? – First Generation Agile Methods

I found again some very interesting wrong interpretations about how Scrum works.

Kenji Hiranabe and I discussed this point over a year ago before his second Kanban articlefor InfoQ. I argued and I believe Kenji concurred that Agile methods like Scrum are really small batch transfer push processes. There is no explicit pull system within a Sprint and it’s a stretch to suggest that the batch transfer at the beginning of a Sprint – the selection of the backlog – is a truly “pull” process. It is never described this way. It is described as a negotiation where the team estimate a set of stories that the product owner wants done. They compare the estimate with the previously achieved velocity and decide what can be fitted into the available time in the Sprint. If it were truly a pull system then there wouldn’t be any negotiation. The product owner would have a prioritized backlog and the team would simply pull the top (however many) stories from it and start work. (more …)

I do not want to argue about, if Scrum is a pull system or not – because everybody who does Scrum correctly knows it is a pure pull system and if you understand to what every Scrum teams evolves it practices than you will see that there is absolutely no difference between Kanban ideas and what Scrum does. The real point is:

They are both on different levels. Henrik Kniberg, has written an excellent article about Scrum and Kanban and does a really interesting mistake in this article:

Scrum and Kanban are both process tools

Tool means “anything used as a means of accomplishing a task or purpose” (dictionary.com). Process means how you work. Scrum and Kanban are process tools in that they help you work more effectively by telling you what to do. Java is a tool, it gives you a simpler way to programming a computer. A toothbrush is a also a tool, it helps you reach your teeth so you could clean them. (Henrik Kniberg, Kanban vs Scrum -A practical guide)

Although Ken always refer Scrum as a framework:

Scrum is a framework for developing complex products and systems. It is grounded in empirical process control theory*. Scrum employs an iterative, incremental approach to optimize predictability and control risk. Within each iteration, Scrum employs self-organizing, crossfunctional Teams to optimize flexibility and productivity (Scrum Guide, Scrum Alliance)

Scrum is much more than a tool. And Scrum is definitely not “only” a tool. Scrum is a mindset, in the same sense as the Toyota Production System was always a mindset a philosophy and not only a tool:

What is the secret of Toyota’s success? The incredible consistency of Toyota’s performance is direct result of operational excellence. Toyota has turned operational excellence into a strategic weapon. This operational excellence is based in part in tools and quality improvement methods made famous by Toyota in the manufacturing world, such as just-in-time, kaizen, one-piece flow, jidoka, and jeijunka. These techniques helped spawn the “lean manufacturing” revolution. But tools and techniques are no secret weapon for transforming a business. Toyota’s continued success at  implementing these tools stems from a deeper business philosophy based on its understanding of people and human motivation. Its success is ultimately based on its ability to cultivate leadership, teams, and culture, to devise strategy, to build supplier relationships, and to maintain a learning organization. (The Toyota Way, Liker, p. 6)

You can translate / rewrite this whole paragraph for Scrum:

What is the secret of Scrum enforcing companies. …. This operational excellence is based in part in tools and quality improvements made famous by the agile software development movement: test driven development, continuous integration, pair programming, one-story-at the time, the task board …. the continuous success steems from a deeper business philosophy that is embedded in Scrum: we value transparency, honesty and  courage and we believe in people are adults, they can make decisions, they want to achieve things and  a lot of more things.

People who want to see Scrum as a tool, do not see that all these tool thinking leads again and again back to the idea that Scrum is a silver bullet or a methodology or a process tool. It is NOT!

The second thought I want to make clear here:

Scrum like all early (first generation) Agile methods really do not change the project management paradigm very much. They still use projects as the frame of reference and still have the triple-constraint (iron triangle) of scope-schedule-resources as an underpinning. (more …)

That is wonderful: The whole idea is incredible: Scrum is a first generation agile method! That is b….t

Scrum is now the de facto agile software development standard as it has evolved from the idea from managing a project to managing whole enterprises using Scrum. Scrum always talked about value adding, Scrum brought the whole flow idea into the agile community. Lean is a subset of all this – as we learn in Likers, Toyota Way that Lean is only a subset of the Toyota Way.

So comparing Scrum with Lean is nonsense as Scrum is lean by definition.

To enhance practices of people that try to develop software within Scrum by using some more clever ideas how to use a taskboard (btw, it was invented by the XP people and then transformed in the de facto work standard by Tobias Mayer and me) for Scrum teams are fully embraced by all Scrum people.

Because — Scrum teams use what works to make them more successful. They want to become truly knowledge based teams using all ideas about how to establish a the learning organization (Senge).

Nächstes Deutsches CSM Training | 8.+9. Juni in Wien

090426_postcard_scrum-starts-here-011CSM Training in München nächste Woche ausgebucht!

Die nächste Gelegenheit für ein
deutsches ScrumMaster Training gibts am 8. und 9. Juni in Wien!

Natürlich – weil in Wien – inkl. dem famosen ScrumCooking und Jürgen Margetich!
Umgehend für das Training registrieren! https://scrum4you.wordpress.com/trainings4you/ 
Nur ScrumCooking? Für eine Einzelbuchung des Kochevents inkl. Gast zum Essen am 8.6. ab 17.00Uhr kontaktieren Sie uns bitte direkt unter office(at)borisgloger.com. Preis € 250€ inkl.

Schon aktiver SrumMaster und immer Mühe mit Ihrem PO? Leben Sie Scrum – remove an impediment – und kümmern sich um die Weiterbildung in Ihrem Team – wäre das ein Verbesserungsvorschlag?!

Certified Product Owner Training
13/14. Juli   CSPO (deutsch) in Berlin 

Scrum — eine Revolution (6)

Scrum in Organisationen
Die Ideen die Scrum-Consultants über das Führen von Organisationen und großen Teams erarbeitet haben,  sind in den letzten beiden Jahren vermehrt, auch in deutschen Unternehmen angewandt und dabei erfolgreich eingesetzt worden. Einige Beispiele:

Da gibt es ein Unternehmen, dass ein „Programm“ durchführt in dem alle Entwickler, alle Business Analysts, einfach alle an einem Produkt arbeiten. Insgesamt mehr als 120 Mitarbeiter. Hier habe ich erfolgreich die Sprint Planning Meeting mit allen 120 Teammitgliedern in einem Raum durchgeführt. Bereits nach dem ersten Mal, waren alle Beteiligten mit dem Ergebnis so zufrieden, dass sich die Stimmung im Projekt verbesserte und das Meeting in dieser Form bis heute weiter geführt worden ist.
Nach ersten Schwierigkeiten, die bei der Größe dieses Projektes unweigerlich sind, ist dort auch das Konzept des Product-Owner Teams erfolgreich eingesetzt worden. Es hatte bei der Größe und Problematik des Projektes einige Zeit gedauert und viel Überzeugungsarbeit seitens des Managements, aber am Ende würde deutlich, dass dieses Team und das Product Owner Daily Scrum, die beste Form zum Managen dieses riesigen Projektes darstellte. Besonders gefreut hat mich, vor ein paar Wochen zu erfahren, dass man mittlerweile auf die zuvor eingeführten elektronischen Tools verzichtet: Das Storyboard liefert alle Informationen, die benötigt werden.

Ein anderes Unternehmen hat sich auf die radikale Umgestaltung des Software Lieferprozesses eingelassen. Wir haben in nur zwei Wochen Vorbereitungszeit ein Produkt Backlog für die gesamte Organisation erstellt. Nach etwa zwei Stunden gemeinsames Arbeiten wurden circa 160 Backlog Items identifiziert. Diese wurden dann in zwei weiteren Sitzungen á 1 Stunde priorisiert und geschätzt. Das Top-Management nahm danach noch einmal  Einfluss darauf und der erste Sprint wurde on-time um 09:00 Uhr morgens mit 6 cross-funktionalen Teams, 6 Product Owner und circa 40 eingebrachten Backlog Items gestartet. Das Sprint Planning dauerte genau 2 x 3 Stunden und alle gingen hoch motiviert in ihren ersten Sprint. Dieser war dann so erfolgreich, wie ich es erwartet hatte: Es gab keine offenen „Defects“, alles Vereinbarte wurde geliefert und ausnahmslos alle im Unternehmen waren zufrieden.

Aber damit war die Arbeit nicht abgeschlossen. Mit den Product Ownern zum Beispiel daran gearbeitet, dass die Product Backlog Items sprechender werden. Wir wollten erreichen, dass die Teams in Zukunft mit  User Stories konfrontiert werden. Wir wollten die Funktionalität als solche darstellen und jegliche Designaspekte herauslassen.

Daneben, war hier die Aufgabe, das Top-Management und das Mittlere Management so auf ihre neuen Aufgaben vorzubereiten und deren Tätigkeiten umzudefinieren, dass sie die Teams optimal unterstützen.
So wurde u.a. Aus den Teamleitern „Domainleads.“ Eine Namenskonvention, die ich von einem anderen Kunden übernommen hatte. Die Domainleads haben einerseits die Aufgabe die „Domain“ zu betreuen, also für die technologische Richtung der Firma zu sorgen und sie sind andererseits fachliche Führungskräfte, die die Karriere ihrer Mitarbeiter fördern. Sie sind fachliche Führungskräfte, ohne Managementaufgabe auf der täglichen Ebene. Sie steuern die strategische Ausrichtung des Unternehmens und sie stellen sicher, dass „ihre“ Mitarbeiter die notwendigen Skills haben oder entwickeln. Zusammen mit den ScrumMaster, die die Teams betreuen und sich darum kümmern, dass die Teams ihre Arbeit optimal bewältigen können, bilden die Domainleads den mittleren Management Level.
Die ScrumMaster organisieren sich als Team und die Domainleads selbst sind ebenfalls als Team organisiert. Die Produkte und Produktlinien werden durch die Product Owner vorangebracht und weiterentwickelt. Auch diese sind in einem Team, dem Product Owner Team organisiert.

Der Beweis ist also auch in Deutschland mittlerweile erbracht: Ganze Organisationen lassen sich nach den Prinzipien von Scrum steuern. Der Umbau zu einer Scrum-Organisaton ist jedoch nicht einfach, oder nebenbei zu erledigen. Sie benötigen tatsächlich Mitarbeiter, die sich diesem Ziel verschreiben und sie benötigen die Erfahrung eines Menschen, der das schon einmal gemacht hat. Meine Praxis zeigt mir immer wieder, dass vollkommen unnötige Fehler bei der Umgestaltung von Abteilungen oder Firmenbereichen gemacht werden.

Meist liegt es dann daran, dass nicht an die Möglichkeiten geglaubt werden, die entstehen, wenn man die Menschen einfach nur machen lässt:

Scrum ist nur ein Weg, der einem hilft einem Weg zu finden, die Dinge richtiger zu machen.

Scrum User Groups in Deutschland

Ich habe auf der Scrum Alliance Website nur diese User Group in Deutschland gefunden:

About This Group

German user group dedicated to Scrum since 2006. Past events include:

– June 2006 (Frankfurt, organised and sponsored by Joseph Pelrine)
– July 2007 (Munich, organised and sponsored by Christoph Mathis)
– December 2007 (Walldorf, organised by Chrisitan Schnidkonz and Christoph Mathis, @ and sponsored by SAP)
– July 2008 (Munich, organised by Simon Roberts and Chistoph Mathis, @ and sponsored by Allianz)

Wie wäre es, wenn alle anderen User Groups sich auch registrieren? — Boris

Scrum — eine Revolution (5)

Fortsetzung von Scrum — eine Revolution (4)

Sind die ScrumMaster an allen scheiternden Implementierungen schuld?

Obwohl ich der Meinung bin, dass eine gute Scrum Implementierung mit guten ScrumMastern steht oder fällt, ist es natürlich falsch, den ScrumMastern die Schuld am versagen der Scrum Implementierungen zu zu schreiben.

In letzter Zeit fragen mich zum Beispiel mehr und mehr Teams und Manager, was denn das Entscheidende bei der Einführung von Scrum sei? Meine Antwort ist immer gewesen: “Am Ende einer Iteration funktionierende Software vorliegen zu haben!” Dieses Grundprinzip muss von allen verstanden werden. Dem Management, den ScrumMastern, und den Teammitgliedern. Ein Management, das von vornherein mitteilt, dass es natürlich nicht möglich sei, innerhalb von 4 Wochen etwas zu liefern, oder das einfach nicht gewillt ist, einmal 2 Wochen auf eine Lieferung zu warten, ist selbstverständlich ein Problem. Denn es steht dem Hauptgrundsatz von Scrum, alle 4 Wochen vollkommen funktionierende Software vorliegen zu haben, vollkommen entgegen. Hier muss ein ScrumMaster in der Regel am härtesten seine Ansichten vertreten. Wenn dieser aber selbst nicht daran glaubt, dass man User Stories funktional so klein schneiden kann, dass man sie in zwei oder vier Wochen liefern kann, dann werden die Teams auch nichts liefern.

Seid dem Scrum Gathering 2009, in Orlando, möchte ich die obige Forderung, dass man am Ende eines Sprints etwas zu liefern hat, gerne anders formulieren und durch zwei weitere Aspekte erweitern:

1)    Deliver every month
2)    Inspect and Adapt
3)    Ask the Team

So klar mir diese drei Aspekte selbst immer waren, es bedurfte einer kleinen Bühnenshow von Alistair Cockburn und Ken Schaber in Orlando, um mir diese drei Aspekte deutlicher ins Bewusstsein zu bringen: Alistair schlug bei der Erwähnung dieser drei Punkte immer verschieden tönende Gläser an, so dass beim Anschlagen der Gläser ein Dreiklang entstand. Eindrucksvoller konnten die beiden nicht verdeutlichen, worum es geht:

Deliver every month
Ken und Alistair machten wieder unmissverständlich klar, dass es bei Scrum um das Liefern von Funktionalität geht. Jeden Monat. Jeden Sprint. Jede Iteration. Wenn es dem Team nicht gelingt, etwas zu liefern, dann muss offen und transparent darüber diskutiert werden. Wir, das Team, oder die Organisation müssen etwas verändern, damit es gelingt, am Ende eines Monats etwas zu liefern. Zur Erreichung dieses Ziels ist dabei alles zu hinterfragen: hat das Team die notwendige Unterstützung, oder wie sieht die technische Ausstattung aus? Was immer geändert werden muss, das muss geändert werden.

Im schlimmsten anzunehmenden Fall, liefern Teams immer wieder nichts. Sie liefern nicht und die Organisation und die Teams werden ungeduldiger und demotiviert. Ausreden, warum diese Teams nichts liefern, gibt es dann sowohl auf der Seite des Teams, als auch auf der Seite des Managements. Alle fühlen sich schuldig, als wäre es ein Versagen und reden sich dann die Situation schön. Dabei ist dieses „Versagen“ keine Katastrophe, sondern eine transparent gemachte Erkenntnis: „Hier läuft etwas nicht so, wie es laufen sollte!“ In diesem Fall ist es tatsächlich angebracht offen darüber zu reden, ob wir das Team nicht verändern und die Teammitglieder auf andere Teams verteilen. Dieses Team ist ja offenbar nicht in der Lage etwas zu liefern. Oft ist es geradezu heilsam, die Teamstruktur dann drastisch zu verändern.

Inspect and Adpat
Läuft es nicht, dann muss etwas geschehen. Darum geht es bei Inspect and Adapt. Wo stehen wir? Was haben wir erreicht? Stehen wir da, wo wir hinwollen? Wollen wir noch dort hin, wohin wir letzen Sprint wollten? Wenn diese Fragen geklärt sind, dann können wir die notwendigen Maßnahmen treffen und die Dinge so verändern, dass wir das nächste Mal unsere Ziele erreichen. Inspect and Adapt heißt nicht, einen Schuldigen zu finden und dann dafür zu sorgen, dass dieser alles richtig macht.  Inspect and Adapt bedeutet, wir sind da, wo wir sind, als nächstes sehen wir zu, was wir tun können, um uns zu verbessern. Dieses Prinzip gilt für jede Wissenschaft, für jeden Prozess, der sich nur durch empirisches Probieren und durch anpassen an die Realtät verbessern lässt.
Ist erst einmal erkannt, dass wir etwas verändern müssen, dann können wir nach Möglichkeiten der Veränderung suchen.

Ask the Team
Aber wie gehen wir dabei am Besten vor? Fragen wir einen Manger oder einen Experten, wie es gehen kann und geben dann diese Dinge dem Team vor? Sagen wir also dem Team, was es zu tun hat? Sicher nicht.

Wir Fragen das Team, was es tun will, um die Veränderungen einzuleiten.  Wieder geben wir die Verantwortung an die Menschen, die die Arbeit tun müssen. An die also, die am besten wissen sollten, wie wir das gesteckte Ziel erreichen. Veränderungen sollten vom Team aus gestartet werden. Sie haben die Aufgabe, den besten Weg zur Zielerreichung zu finden.

Wichtig in diesem Zusammenhang: In Scrum behandeln wir die Menschen als „Erwachsene“. Wir schreiben Ihnen nicht vor, wie sie zu leben haben, wir schreiben ihnen auch nicht vor, wie lange sie zu arbeiten haben. Aber wir entlassen sie nicht aus ihrer Verantwortung, einen Weg zu finden, am Ende eines Sprints zu lieferen, was miteinander vereinbart worden ist. Etwas, was manche Teams erst lernen müssen. Zu schnell wird gesagt: „In Scrum darf man ja das Ziel nicht erreichen, es ging halt nicht!“ Nichts daran stimmt. In Scrum hat ein Team den selbst gesteckten Auftrag auch zu erreichen. Daher wird ein freiwilliges Commitment erarbeitet.

Komplexität und selbstorganisierende Teams

„Der Berater, den wir da hatten, war der Meinung, dass man in Scrum dem Team alles überlässt. Seine Meinung war, dass sich das Team schon selbst organisieren werde. Das war ein Fiasko, wir sind wieder zu einer traditionellen Teamstruktur mit Teamleitern zurück und seitdem funktioniert es einigermaßen.“ So ähnlich war die Geschichte, die mir ein Kunde erzählte. Das ist haarsträubend. Sollten Sie einmal einen Berater da haben, der ähnlich unverantwortlich mit ihren Mitarbeitern umgeht, setzen sie ihn bitte sofort vor die Tür.

Sich ein Team selbst organisieren zu lassen, hat nichts mit Zugucken oder gar Wegschauen zu tun. Gerade das Gegenteil ist der Fall: Selbst-Organisation funktioniert nur, wenn der Rahmen, der Container, in dem sich das Team befindet, klar definiert ist. Dieser Rahmen muss vom ScrumMaster gesteckt und aufrecht erhalten werden. Innerhalb dieses Rahmens, wird dann dafür gesorgt, dass die Selbst-Organisation in Gang kommt. Oft reicht es den Standard, den Scrum und die Tools, wie zum Beispiel das Taskboard, bieten „by the book“ einzuführen, damit die Teams beginnen können, sich selbst zu finden und zu organisieren. Aber – sollte das Entwicklungsteam auch nur den Anschein bieten, dass das Ziel gefährdet ist, dann wird sehr bestimmt und klar, aufgezeigt, dass da ein Ziel zu erreichen ist, und dass die Entwicklungsmannschaft gewisse Zusagen getroffen hatte. Oft reicht es in der Mitte des Sprints noch einmal die Ziele aufzuzeigen, oder ein Meeting einzuberufen, in dem noch einmal klar gestellt wird, um was es geht.

Viel öfter aber funktioniert die Selbst-Organisation deshalb nicht,  weil die Menschen in den Teams nicht mehr gewohnt sind, selbst Entscheidungen zu treffen. Dann, ganz plötzlich in Scrum, sollen sie das tun. Für viele eine Überforderung. Wieder kommt es auf den ScrumMaster an. Er wird in einem solchem Fall das Team enger führen, als es ein scrum-erfahrenes Team benötigt. Er wird dem Team Fragen stellen, es provozieren, Anregungen geben, Gespräche und Diskussionen moderieren und im Notfall auch für das Team Entscheidungen treffen. Eines darf nämlich nicht passieren:  Das Entwicklungsteam darf auf keinen Fall „versagen“, es darf nicht nicht-liefern. Wenn es dabei Hilfe benötigt, dann ist das eben so!

Der ScrumMaster wird über die Zeit hinweg immer und immer weniger eingreifen. Im Idealfall dauert es nur ein paar Sprints, bis er sein Team so weit hat, dass dort weitgehend selbst-organiserend gearbeitet werden kann.

Scrum Gathering Day2

Scrum Gathering Day2 049, originally uploaded by lucianofelixns.

Luciano took a great photo 🙂 It was so much fun to give this presentation about Retrospectives.

6 Secrets to Run a Retrospective Successful – Brazil Scrum Gathering 2009

The Future of Management — by Gary Hamel with Bill Breen

The Future of Management by Gary Hamel with Bill Breen

• Management science stands on the brink of a paradigm shift.
• Classical management theories were very successful, but have run their course.
• Management is the most profi table area in which to innovate and it desperately needs to change.
• Try to create a democratic organization where workers are largely self-managing.
• Establish a multidirectional information fl ow rather than a strict vertical hierarchy.
• Get everyone involved in innovation and give people time to follow their own interests and ideas.
• You can shape your management innovation in line with four different models. For example, model it on successful political systems, such as democracies and cities.
• Model management innovation on evolution: Try many experiments, learn from your failures and see what works.
• Model innovation on the free market: Harness collective wisdom and capitalize on individual passion.
• Model management innovation on spiritual practices: Use a higher purpose to drive change and inspire your organization.

— stolen from [getAbstract]

Scrum and CMMI at the Brazil Scrum Gathering 2009

Scrum – eine Revolution (4)

Fortsetzung von: Scrum – eine Revolution (3)

Die Wette, die ich immer gewinne

Leider haben viele Organisationen, viele Teams und viele ScrumMaster nicht erlebt, was jede Scrum Implementierung, die ich bisher durchgeführt habe, aufzeigt.: Nach drei bis vier Sprints haben die Teams in der Regel nicht mehr viel zu tun. Die Wette, die ich zum Spass mit meinen Auftraggebern eingehe, dass die Product Backlogs in der Regel nach 3 Sprints leer sein würden, gewinne ich fast immer. Das heisst nicht, dass diese Unternehmen nichts mehr zu tun hätten, obwohl das in einer der oben genannten Firmen kurzzeitig auch geschehen ist, sondern es ist in der Regel so, dass die Menschen auf der Produktseite, nicht in der Lage sind, die neue Art und Weise des Arbeitens mit Teams, mitzugehen.
Dort, auf der Businessseite werden weiterhin lange Diskussionsrunden gedreht, bis alle gehört worden sind, bis sich jeder in einem Projekt oder in einem Produkt wiedergefunden hat. Oder es wird versucht, das Produkt erst vollständig zu verstehen, bis es dann an die Teams weitergegeben wird,  bevor sie mit den Teams reden, oder die Produkt Manager sind in politische Aspekte so tief verstrickt, dass sie nicht in der Lage sind, die Backlogs vorzubereiten.

Dann gibt es zwar „große“ und wichtige Projekte, und Vorhaben, aber es gibt keine Backlog Items, an denen man als Team arbeiten könnte. Aus der Notlage heraus übernehmen dann die Teams, dass erarbeiten von Produktvorschlägen, weil sie etwas zum Arbeiten haben wollen.

Hier entsteht dann oft eine sehr interessante Dynamik. Da in den meisten Firmen, das Business in der Regel die „Macht“ hat, wird durch das Aufzeigen des Versagens, der Businessstrukturen klar, dass hier etwas nicht stimmt. Etwas, das in vielen Firmen gar nicht gerne gesehen wird. Im Grunde werden die Produktverantwortlichen auf diese Weise blossgestellt. Es wird transparent, dass sie nicht wirklich wissen, was als nächstes benötigt wird, oder dass sie nicht die notwendige Entscheidungskompetenz. Sie sind nur Handlanger des Managements. Wenn also deutlich wird, dass man dort weder eine Strategie für die Produktentwicklung hat, noch genau weiß, warum gewisse Funktionalität eingebaut werden soll, dann wird sehr gerne dafür gesorgt, dass Scrum wieder einschläft. Eine klare Logik der Macht: Die Transparenz, die aufzeigt, dass gewisse Personen Jobs durchführen, für die sie nicht geeignet sind, mag für die Ausführenden, also die Entwickler, gut sein, aber doch bitte nicht für die Anfordererseite.
Eine Konsequenz dessen war, dass in den letzten beiden Jahren, der Ruf der ScrumMaster nach Product Owner Schulungen lauter und lauter geworden ist. Eine Forderung, der die ScrumAlliance mit der Auflage des Certified Product Owner Trainings nachgekommen ist. Nicht, dass ich dieses Training grundsätzlich ablehne, ich gebe diese Trainings selbst, aber das Motiv für dieses Training ist faszinierend. Die ScrumMaster, sich ohnmächtig dem Business gegenüber fühlend, können jetzt die Verantwortung für das Versagen von Scrum an die nicht geschulten Product Owner abgeben.

“Die Scrum Implementierung würde ja funktionieren, wenn die Product Owner funktionieren würden.” Dabei haben die ScrumMaster allerdings vollkommen vergessen, dass es ihre Aufgabe gewesen wäre, die Product Owner in die Lage zu versetzen, ihre Aufgaben zu erledigen. Es war und ist die Aufgabe des ScrumMasters, Scrum in den Unternehmen zum Laufen zu bringen. Er muss dafür sorgen, dass jeder seine Rolle und die damit verbunden Aufgaben kennt.

Nächstes deutsches CSM Training | 19/20. Mai in Linz

logo_deIn der nächsten Woche — Scrum Training in Europas Kulturhaupstadt 2009.
Noch einige Plätze sind zu vergeben. Jetzt anmelden! 

Die perfekte Gelegenheit Ausbildung mit Kulturgenuss zu verbinden und den Geist gleich doppelt für neue Eindrücke zu öffnen, zB. “Unter dem Dach eines französischen Holzzeltes werden in den kommenden Monaten an die hundert Musikaufführungen stattfinden – größtenteils eigens komponiert oder arrangiert. Am 11. Mai geht es los.” Mehr Infos: www.linz09.at

Updates: Scrum Gathering Brazil

brazil_gathering_sidettScrum in Brazil!
Boris will report live from the actual Scrum Gathering in Sao Paulo!

The conference starts 9:30 (BRT) = 14:30 (MESZ) with a Welcome Remark from Jim Cundiff, Managing Director – Scrum Alliance. See Agenda >> 

Follow Boris on Twitter — http://twitter.com/borisgloger
and stay up to date what’s going on at Brazil’s first Scrum Gathering.


Scrum Tools | VersionOne | Review

VersionOne is one of most well-known tools to manage agile projects on the market. With a great amount of functionalities VersionOne can be used with many agile flavors, Scrum included. With some many features, as you can imagine, VersionOne will require a significant financial investment to use it, so is recommended that you try the 30-day evaluation available on their website until you decide to purchase it. At first we may be overwhelmed by the amount of features and configuration possibilities, so it’s a good idea to watch some video training also available on VersionOne website. For the propose of this review we will be using the Enterprise edition.

Getting Started

A good way to start using VersionOne is on the Admin section. Here you can create projects, members, sprint schedules and a long list of possible configurations. You can define custom fields for your objects, define the possible values for backlog item status, type,  etc. After being comfortable with your customizations and created your project, it’s time do build your backlog. On the Product Planning tab you may notice some different information in addition to the normal backlog feature. On VersionOne you can register things like Customer Requests, Strategic Goal, Epics, Themes,Issues, etc. So you can do a lot of work on it even before you start building your real backlog. Luckily all things thing isn’t mandatory, so use them as your needs require.


There are different levels of planning on VersionOne, Product, Release and Sprint. As we said earlier, the product planning is where we can maintain our backlog. There’s a lot a information that you can define to a backlog item, like Complexity, Requested by, the Theme that the item is related to, etc. but you don’t have to worry about all that, there’s a in-line add feature where you can provide only basic information like priority and estimate and quickly create a lot of items.

Let’s talk more about priority and estimate as usual. You are very free to estimate your items on VersionOne, that’s not a defined unit of measure and no defined scale. So if you work with Planning Poker or a different technique, you need to enforce a scale outside the tool. On the priority feature there’s a interesting thing, you can define a value to the priority property (High, Medium and Low) but you also can drag and drop to do a finer prioritization, the problem is that you can put a Low priority item on top of a High priority item, which can be a little confusing. To me the drag-and -drop makes the priority field a bit obsolete and should be the primary mechanism to prioritize. On the Release Planning, you can create you releases as child projects form your main project, define a date range and drag the item you choose to be part of it. The Sprint planning is similar to Release planning, create a sprint and drag the chosen items to it, and now you can create tasks to our items at this moment, you could have created them before, but we assume that the sprint planning should the appropriate moment to do that, and again VersionOne has the common bad habit to enforces task estimates in order to have a working burndown chart. To track the work during the sprint, there’s a nicely done taskboard feature. You can also create special tasks to test, where you can define tests details.

Tracking and Reports

On the reports tab you can see a big list of reports where you can track more statistics about your team than a baseball scout. There’s burndown charts to sprints, releases, project, parking lot charts, velocity charts, retrospective reports and a lot more. It’s a very rich set of reports, so rich that I seriously doubt that a team can use it all for real, but of course even if not use it all, you can find some good things in there.


There’s many more good things and bad things about VersionOne to fit in this review, but there’s no doubt that VersionOne is one of the most complete tools on the market, but even with all the additional features it brings, there’s not a  breakthrough feature, something that really sets the tool apart from the various competitors and you always expects something more from the big players. Although VersionOne has a great number of features it’s not the most expensive tool on the market, so if your company are willing to invest on a tool that brings many features, integrates with other tools, and a good support structure, VersionOne could be a choice.

When Should a Process Be Art, Not Science – Review

“The movement to standardize processes has gone overboard. Some require an artist´s judgment — and should be managed accordingly.” Joseph M. Hall and M. Eric Johnson.

Two well known teachers wrote an article in the Harvard Business Review that I want to bring to your attention: When Should a Process Be Art, Not Science by Hall and Johnson.

There are some processes that naturally resist definition and standardization—that are more art than science. Helping executives understand which should not be standardized and how to manage artistic and scientific processes in tandem is the purpose of this article.

Scrum was designed to “control chaos” and to establish a way of working in a high demanding, chaotic environment: Software Development.

As I always try to explain: Scrum can be used in any environment that needs a huge amount of judgment in which you need to adapt to new aspects with very high frequency: Software Development, Marketing management, Campaign Management, Business Development, Sales, Customer Service, System Administration and and and …(Side note: That is the reason why Kanban is not the right tool for this – Lean management needs stable environments.)

The two professors see a need for an empirical control processes in most business environments, too.

They call these processes artistic processes. A different name, but the same idea.

What they also say, and this is one of my claims since years.

“Not only does standardization reduce accountability, but it causes workers to switch to autopilot.”

When you have a work standardized and two high skilled worker on this process.Then it will happen that you bore your people to death. They will go on autopilot, they do not think anymore. They only do their work.

“An artistic process has to rely on external measures of success, like customer feedback.”

“Many Processes Are an Art:

  • Leadership Training
  • Auditing
  • Customer Service
  • Software Development”

The two profs give us an advice how to bring people to the level that they can live with artistic processes:

„If a process is artistic, invest in giving employees the skills, judgment, and cultural appreciation to excel in variable conditions.“

So basically what they say is, that you need to train your people again and again, that you must enable them to improve themselves.

But how do I get the right process for my situation?

The three steps to run the right process in you company:

  1. Identify what should and shouldn`t be art.
  2. Develop and infrastructure to support art.
  3. Creating appropriate metrics: Feedback
  4. Periodically reevaluate the division between art and science.

Getting art and science work together

    F.e. Support process that can be standardized.

      Building an effective training program

        Artist must learn their skills of trade. They often have to undergo a formal apprenticeship of informal mentoring and probationary period during which their freedom is curtailed.

        • Tolerating failure: The variations that are the hallmark of artistic processes make it impossible to satisfy every customer on the first try.
        • ScrumMaster vs. Domainleads (2)

          My experience, so my actual coaching praxis and that what I implement myself and with the help of my coaching teams is exactly a matrix organization, as Jürgen Apello showed.

          We change the Teamleads to Domainleads

          jolegat-gloger-managerWhy? Because we want to get rid of the notion that the Teamlead leads a team.

          The ScrumMaster “leads” the team.

          The Domainlead is responsible for his people in different teams.

          He cares about their career and he makes sure that the company goals gets communicated to all the people in his “domain.”

          He leads more by using education and training, by building guidelines and by coaching people in the domains but by imposing rules to the people.

          The second very importend aspect is steering of the company: the strategic functionality of managment.

          They have together, as a team, the responsibility to build the direction, the vision and everything else that is necessary to align the team members to the overall company or organizational goal.

          ScrumMaster and Domainleads – our solution for large organizations

          A wonderful article about organization of a department or company using a matrix organization I found here:


          Optimize Communication, Throw the Boss Out

          Yoda-metrojp-85740389 It is well-known that difficult goals are best achieved when people work in small teams of under ten people. Various agile methods were created based on this principle. Communication in teams is optimal when the lines are short. But that doesn’t tell you how to structure an organization with hundreds or thousands of people. The solution of simply dividing them into many small teams is clearly insufficient. How do all these teams fit into a bigger picture?

          I strongly recommend to read the whole article. —————–

          More about my solution to this you will find tomorrow …

          Mehr wissen! Moderationstraining

          Dieter Rösner beim Training

          Dieter Rösner beim Training

          bor!sgloger Mitarbeiter weitergebildet: Moderationstraining bei Dieter Rösner

          Das Echo auf das Training aus allem Richtungen war so positiv, wir möchten nach dem Motto „spread the word“ für Interessenten aus einem Scrum Umfeld (must have) solche Moderationstrainings mit Dieter Rösner als Weiterbildungsmöglichkeit im Zusammenhang mit „Scrum leben“  anbieten.

          Boris: Warum ein Moderationstraining? Man kann über Selbst-Organisation viel schreiben, nachdenken und philosophieren. Man kann aber auch einfach dafür sorgen, dass Selbst-organisation in Teams jeden Tag wieder funktioniert. Ich habe vor 15 Jahren Dieter Rösner und Herbert Namokel im Rahmen meines Praktikums zum Unternehmensberater kennengelernt.

          Die Tools und Techniken, die mir die beiden damals beigebracht haben, haben mich immer begleitet. Ich bin so sicher im Führen von Meetings geworden, weil ich immer auf das methodische Handwerkszeug der Moderationsmethode zurückgreifen konnte.

          Wenn ich heute die “magic estimation technique” durchführe, wenn wir heute in Coachings die Sprint Retrospektive machen, dann bauen diese Techniken immer auch auf den Ideen der Moderationsmethode auf.

          Dieter Rösner ist meiner Meinung nach der beste Trainer Deutschlands auf diesem Gebiet. Ich bin froh, dass ich ihn für Scrum begeistern konnte und er für uns ein adaptierters Scrum Moderationstraining anbietet.

          Die ersten Termine sind der 29.-30.06.06  in München und 08.-09. 10.2009 in Wien. Nähere Infos zu Locations und Preis folgen asap!
          Interessiert Sie? Einfach ein Kontakt-email an office(at)borisgloger(dot)com!