Author Archives: Boris Gloger

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.

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.


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” ( 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).

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.