Posts tagged ‘Scrum’

Rare specialists in Scrum

One of the questions that occur again and again in trainings and coachings circels around rare specialists. Perhaps a company has five specialists for a special topic and all in all 80 developers. With Scrum they would end up with roughly ten teams. What should the company do regarding the specialists? Two options come to mind very quickly:

  1. Each specialist could work for two teams.
  2. The specialists could form their own team that acts as a service provider for the other teams.

While both options may work I like to highlight a third option:

Figure out which are the five important teams, put the specialists full-time in these teams and let the other five teams to their own devices. The first reaction often is: “No, no, no. That is a really dumb idea.” But what would be the consequences? The most important projects/teams would move forward very fast and the less important projects would move forward slowly.

The two options mentioned in the beginning would lead to all teams moving with average speed (if you manage to bring flow to the workload of the specialists).

What would be the more valuable approach for your company?

September 19, 2013 at 7:40 am Leave a comment

How cross-functional should my Team be?

In a Lean/Agile world teams should be cross-functional. Period.
Or maybe it’s not that easy? What does cross-functionality actually mean? And is it true that the more cross-functional, the better?


I wrote an article together with my brother Arne Roock adressing these questions. The article is published in the current edition of the “Agile Review” by it-agile. The article is available as PDF for download. (There is also a german version of the article).

August 13, 2013 at 5:26 pm Leave a comment

Wie cross-funktional soll mein Team sein?

Agile Teams sollen cross-funktional sein. Punkt. Oder ist es vielleicht doch nicht ganz so einfach? Was genau bedeuted Cross-Funktionalität eigentlich? Und gilt generell die Regel: Je cross-funktionaler, desto besser?


Zu diesen Fragen habe ich zusammen mit meinem Bruder Arne Roock einen Artikel verfasst, der in der aktuellen Ausgabe der “Agile Review” von it-agile erschienen ist. Es gibt den Artikel auch als PDF zum Herunterladen. (Es gibt auch eine englischsprachige Version des Artikels als PDF).

August 13, 2013 at 5:02 am Leave a comment

Buchempfehlung: Tribal Leadership

Nicht mehr ganz taufrisch ist das Buch “Tribal Leadership” von Dave Logan, John King und Halee Fischer-Wright. Trotzdem ist es immer noch sehr lesenswert für jeden, der sich für Team- und Unternehmensentwicklung interessiert.

Das Buch vertritt die These, dass für die Leistungsfähigkeit von Teams und Unternehmen die vorherrschende Kultur wichtig ist. Sie stellen ein 5-stufiges Modell der Kulturentwicklung in Teams/Unternehmen vor:

  1. “Life sucks” – Das Leben an sich ist schlecht und es wird auch nicht besser werden. In dieser Stufe kommt es häufig zu Gewalt gegen andere oder sich selbst – wenn das Leben sowieso an sich schlecht ist, ergibt es auch wenig Sinn, sich an moralische Maßstäbe zu halten.
  2. “My life sucks” – Das Leben anderer Leute mag gut sein, aber mein Leben ist schlecht. Auch wenn der Übergang von “Life sucks” zu “My life sucks” sich häufig wie eine Verschlechterung anfühlt, ist es ein Fortschritt. Die Erkenntnis, dass das Leben nicht für alle schlecht ist, enthält die Chance, dass es für mich auch besser werden kann.
  3. “I am great (you are not)”: Ich bin großartig, viele andere leider nicht. Daher muss ich immer alles selbst erledigen. Dieser Zustand ist der vorherrschende Zustand in den Unternehmen in den USA (und sicher auch in den meisten anderen westlichen Ländern).
  4. “We are great (they are not”: Jetzt steht das Team-/Unternehmensergebis im Vordergrund nicht mehr das, was ein einzelnes Individuum leistet. Das Team/Unternehmen grenzt sich dabei gegen andere Teams/Unternehmen ab und definiert sich auch dadurch, dass es besser ist.
  5. “Life is great”: Jetzt verschwindet die Abgrenzung gegen andere und ein höheres Ziel (Noble Goal) definiert das Team oder das Unternehmen.

Laut den Autoren kann man bei der Kulturentwicklung Stufen nicht überspringen. Wenn man sich auf Stufe 2 befindet, kann man sich nicht einfach zu Stufe 5 weiterentwickeln, man muss den Weg über die Stufen 3 und 4 nehmen.

Das Buch zeigt Techniken, mit denen man (anhand der verwendeten Sprache) den Zustand von Teams/Unternehmen bewerten kann sowie Techniken, wie man die Kultur weiterentwickeln kann.

Das ganze ist übrigens nicht einfach ausgedacht, sondern mit Studien belegt und so finden sich in dem Buch immer wieder Fallbeispiele zu den einzelnen Stufen.

Von mir eine eindeutige Leseempfehlung für alle, die sich für Unternehmensentwicklung interessieren.

August 12, 2013 at 9:16 am Leave a comment

Shades of Scrum: Scrum outside IT

Scrum originated outside the IT (development of cars, copiers, printers, photo cameras, computers, see Nonaka’s & Takeuchi’s famous article “The New New Product Development Game”) but most Scrum implementations are in software development. But non-IT strikes back and Scrum starts to spreads into non-IT areas. Some real world examples:

  • Develop service products.
  • Develop and manufacture cars (e.g. Wikispeed, Johnson Controls)
  • Manage enterprise transitions.
  • Execute training classes.
  • Manage consulting.
  • Organize sales.
  • Manage accounting.
  • Organize scientific research.
  • Schools (see Facebook)

Every area has its own specific challenges. But let’s start with some general observations.

When applying Scrum to non-IT it is in my experience helpful to start with the product concept. What is the created product (or service) we are talking about? When we try to develop and manufacture a car with Scrum this pretty obvious: it is the car. When it comes to more intangible areas we may have to spend some time thinking. Some examples:

  • Sales: Is the product a set of orders? Or is the product a set of long-lasting customer relationships? The decision what the product is has a huge impact on the way we think about the work of sales.
  • Training classes: One might guess the product is knowledge but that doesn’t cover the whole story. The knowledge was there before the training classes and wouldn’t need the class for creating it. For a CSM class one might think the product is a set of Certified Scrum Masters. That is a valid product and it would focus the training class on test preparation. Since I don’t want to do test preparation and prefer to prepare participants for work I prefer to think of the product as “more skilled participants” (or more specifically “more skilled Scrum Masters”).
  • Enterprise transition: The product is an agile enterprise. This seems to be pretty easy but it has a significant impact on the work of the transition team: A set of Powerpoint presentations doesn’t make a valid product increment.
  • Scientific research: Often the success of scientific research is measured in publications. Therefore one could think of these publications being the product. But I think this isn’t appropriate. The number of publications is a KPI (Key Performance Indicator) like the revenue for a software product. In the same way you wouldn’t see the revenue as the product you wouldn’t see the publications as the product. I think a more appropriate product is insights.

When the product concept is clear the next step is pretty easy: What are valid product increments and what does “potentially shippable” mean for these product increments. For scientific research an insights might be shippable if it is new to the world of science. In the case of enterprise transition the product increment usually is a more agile enterprise and it is already shipped (= implemented) when the Sprint Review happens. In the case of car development and manufacturing a drivable car may be a valid product increment. But parts of the car that can be inspected, assessed and as a part delivered may also be valid product increments. When you want to create a very fuel efficient car by developing an innovative fuel efficient motor the motor might be a valid product increment. How to produce a product increment like a more agile enterprise every Sprint (at least once a month) may be again very challenges. I will address that later.

Now that we have a concept for product and product increment I like to address the question of the Product Owner. How do we measure success and who is the right person to be the Product Owner for that product. To find an appropriate Product Owner two questions should be answered: Who is empowered to prioritize features (or who could be empowered to do so)? Who is accountable for the product (who is an appropriate “single wringable neck” for the product)?

  • For a training class the trainer is the Product Owner. In my training classes we regularly have a discussion if the participants are the Product Owner. I then ask: “Imagine you are pissed off by the training class and leave it disappointed. Who is responsible? You as the participant or me the trainer?” The trainer is the “single wringable neck” and therefore is the Product Owner of the training class.
  • For an enterprise transition the Product Owner is a top level manager, e.g. the CEO.

The Product Backlog is quite easy to build. What is necessary to create the product? It may be appropriate to fill the Product Backlog with goals (not features). In sales for example you typically would have goals like “win a deal of at least 100.000 USD at customer XYZ”. When applying Scrum for training classes the learning modules or learning objectives may provide the Product Backlog Items.

The next step is to form the Development Team. The team needs all the skills necessary to produce product increments. When we have a clear understanding of the product we want to deliver it is quite easy to decide who should be in the team. For an enterprise transition the team needs to have managers and leaders of the company (otherwise the team is not able to achieve changes).

As the Scrum Master you need an experienced Scrum Master (of course) but as a rule of thumb you a more experienced Scrum Master than for an average software development project. The body of knowledge about how to apply Scrum for non-IT is much smaller than for software development. That means that the Scrum Master needs a more solid understanding of the Scrum principles and he needs to facilitate insights about how to apply Scrum in new ways.

When you have chosen an appropriate product the Sprint Review is easy. When you have problems demonstrating and inspecting product increments and gathering feedback about the product chances are high that your product concept is inappropriate.

During the Sprint Retrospective the Scrum Team (Product Owner, Development Team and Scrum Master) inspects its way of working and comes up with action items to improve their way of working.  I haven’t encountered any specific challenges here when applied to non-IT.

The mechanics of Sprint Planning and Sprint Backlog are easy to apply but during Sprint Planning a problem may become visible: The team has no idea how to create product increments at least every month:

  • How could we possibly change the organization in just one month?
  • How could we create a car in a month?
  • How could we win a new customer in just a month?

The team has to find out how to create product increments every Sprint and we need to bear the tension that is created: We need to create product increments every Sprint and we don’t know how. Constraints like these create innovations. Just extending the Sprint length or faking the product concept (“Powerpoint presentations are the new product”) would kill this possibility to improve. We need to forge and apply new ways of working and there is no promise that we will succeed. In all the areas I listed at the beginning of this article teams have managed to find these new ways of working. I am confident that others can do it also.

In some cases we have to tweak the Sprints. A training class might last for two days. Since we want to gather feedback from the participants during the training we might end up with a Sprint length of 2 hours or a half-day. That might question the justification of the Daily Scrum. While there are ideas how to apply Daily Scrums in such a situation I generously skip them in training classes with a Sprint length of a half-day. (But I have applied four Daily Scrums per day for software development successfully).

Some domains require the team members to work highly distributed. Consultants may form a team but work at different clients. Sales people also normally work alone or in pairs when they work with clients. Still coordinating with the rest of the team to achieve a higher mission (create the product) is worthwhile. But is more challenging to apply appropriate mechanisms and the Scrum Master may have more work to do to make people cooperate that were used to work on their own for years or decades. Sometime it might be appropriate to transform the Daily Scrum into a Weekly Scrum.

When Scrum is not appropriate

The list of areas where Scrum is applied may suggest that Scrum could be applied everywhere. That may be true but it wouldn’t be efficient. Scrum needs teamwork. When teamwork isn’t necessary or teamwork isn’t achievable Scrum doesn’t make sense. When you just have routine work with low variability to do and there is nothing to lean, Scrum is inefficient (why would you talk so much during Planning, Review, Retrospective and Daily Scrum?).

But sometimes there are surprises. I would have thought that accounting is just routine work that doesn’t need a team. But I know of several accounting teams that say that teamwork is appropriate for them.


Scrum can be applied to a lot of knowledge work domains where teamwork is appropriate. For most areas outside IT there is only a small body of knowledge about how to apply Scrum. When trying to apply Scrum in a new area prepare to be challenged. I love to hear your experiences and of course I offer my help as a coach when you want to apply Scrum to areas outside IT.

April 26, 2013 at 2:26 pm 1 comment

Shades of Scrum: The Sprint Planning and the pull principle

The Scrum Sprint Planning incorporates the so-called pull principle. The pull principle origins from the Toyota Production System (at least it is he first occurrence I know of) and aims at creating flow while avoiding overload. A processing unit B pulls new work from an upstream processing unit A when B hast he capacity to process it. This is in contrast with the push principle where a planner defines how many items should be processed by time unit and results of upstream processing unit A are pushed into the downstream processing unit B.

In the Sprint Planning the team pulls work from the Product Backlog (the Scrum Guide says that the development team „selects“ Product Backlog Items for the Sprint).

One re-occurring question is whether the team is allowed to deviate from the prioritization – for example when a Product Backlog Item is too fuzzy or when the development team thinks an Product Backlog Item is just bullshit.

The answer is: it depends.

The very first reason fort he pull principle is to avoid overload with its negative consequences (lower quality, burnouts, developers quitting jobs etc.). Therefore it is totally valid to expect the team to pull work strictly according to the prioritization. While older literature is sometimes a bit ambiguous about the „selection“ of Product Backlog Items the current version of the Scrum Guide is pretty clear about that: „The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team.“ (emphasis added by me)


Kent Beck once told me that he likes to ask developers if they would invest their own money into the product they are working on. I use this question from time to time when working with teams and I will never forget a larger retrospective at a client where I asked the team exactly Kent’s question: „Would you invest your own money into the product you are developing?“ The team laughed and answered: „We think it would be more valuable to buy Greek government loans.“

That is great feedback for the Product Owner. The team isn’t convinced about the product but it should be (remember the Scrum value „commitment“). The Product Owner should start asking questions: Is the product idea bullshit? Does the prioritization of features lead to weak product while the product idea may be great? Does the team lack the information about the market and users needs to understand the product and the prioritization of features? Working with these questions provides the opportunity to enhance the product a lot. But it requires hard work on the side of the product owner.

A Product Owner who is open for these kinds of discussions may apply the pull principle not only for limiting the amount of work to the team’s capacity but also to the meaning of work. The team would only pull Product Backlog Items into the Sprint when it is convinced that these items are valuable fort he product.

I have seen a lot of confusion about these two types of the pull principle. To make clear what we are talking about we could call the original pull principle „workload pull“ since its motivation is to find the optimal workload. The extended pull principle could be called „purpose pull“.

The workload pull delegates the decision about how much work can be done to the team. The purpose pull delegates the decision about what should be done to the team.

How much?


Workload Pull

Purpose Pull


Traditional Project Management





Valve (a company famous for its computer games) applies purpose pull on a product level. Developers choose the products they are working on. If a Product Owner has an idea for a new game but is not able to motivate developers to join his project the game wouldn’t be implemented. (see

Typical open source projects apply purpose pull on the product level as well as on the feature level. Everybody decides for himself on what product to work (and is free to quit whenever he is fed up) and within the product development the developers are free to choose the features to implement.

The following table summarizes the two pull principles:

Workload Pull Purpose Pull
Create flow of work Create better products
Avoid overload Provide meaning for the development team
Enhance work satisfaction of the development team
Avoid quality problems due to overload Avoid quality problems due to decoupling of the team from the product

Scrum as a framework supports workload pull as well as purpose pull. (Applying purpose pull to the fullest possible extend would eliminate prioritization by the Product Owner completely and then you leave the Scrum framework). Every project has to determine the appropriate pull level.

April 15, 2013 at 8:02 pm 4 comments

The Sprint and the ROI

There is a simple, yet powerful idea in Scrum: When every single Sprint has a positive ROI (return on investment) risk management becomes very easy and the need for accurate long term planning diminishes.

When every single Sprint has a positive ROI you can just plan from Sprint to Sprint. When a Sprint planning provides the information that this Sprint would not generate more value for the company than it costs, you just stop the development. You have created something with a positive ROI with the previous Sprint(s) and everything is fine.

Think about it. How cool is that!

Impossible? No. I have seen it working.

Hard to achieve? Of course. You need to resign from traditional project planning and really think about how to create small valuable software increments. And adapting a new perspective is always challenging.

P.S.: One may ask what I mean with ROI. For me a Sprint has a positive ROI when you could just stop after the Sprint and have created a value that is higher than the Sprint costs.

April 5, 2013 at 5:59 pm 2 comments

Older Posts Newer Posts