Disziplinarische Führung in Scrum

Immer mehr Unternehmen entscheiden sich dafür, Scrum oder andere agile Verfahren nicht nur für einzelne Projekte einzusetzen, sondern als Standard-Ansatz für die Entwicklung. Damit wird die Frage nach der Mitarbeiter-Führung in solchen Umgebungen immer drängender. Bisher ist dazu die eine heilsbringende Lösung (Silver Bullet) nicht gefunden worden. Tut mir leid. Aber es gibt auch eine gute Nachricht: Wir sind auch nicht vollkommen ahnungslos.

Führung muss sich der Arbeitsorganisation unterordnen

Werfen wir zunächst einen Blick auf das klassische Modell von Führung: Das Unternehmen ist in funktionsorientierte Abteilungen (z.B. Marketing, Vertrieb, Entwicklung, Qualitätssicherung) zergliedert. Wenn die Abteilungen ausreichend groß sind, sind sie nochmal in Gruppen oder “Teams” organisiert. Entlang dieser Zergliederung findet die disziplinarische und  fachliche Führung statt. Die Abteilungsleiter führen die Gruppenleiter, die Gruppenleiter führen ihre Mitarbeiter. Diese Form der disziplinarischen Führung passt zu dem klassischen Paradigma, Arbeit zu organisieren (Teile und Herrsche kombiniert mit funktionaler Zergliederung).

Die agile Welt folgt einem anderen Paradigma, Arbeit zu organisieren: Interdisziplinäre Teams vereinigen die Skills, die notwendig sind, um Wert aus Kundensicht zu schaffen. Es ist kaum zu erwarten, dass für diese andere Art der Arbeitsorganisation der klassische Ansatz disziplinarischer Führung funktionieren kann. Die Organisation disziplinarischer Führung muss sich der Arbeitsorganisation unterordnen. Dauerhaft kommt man bei flächendeckender agiler Entwicklung nicht um eine Reorganisation der disziplinarischen Führung herum kommen.

Funktionen von Führung können verteilt werden

Für eine Reorganisation disziplinarischer Führung müssen wir uns gedanklich von einem weiteren klassischen Dogma lösen, nämlich dass alle Funktionen disziplinarischer Führung bei einer Person liegen müssen. Dazu lohnt es sich, eine Liste mit den Funktionen zu machen, die heute im Unternehmen unter Führung verstanden werden. Dabei kommen typischerweise Dinge wie die folgenden heraus:

  • Sicherstellen, dass die Mitarbeiter das Richtige tun.
  • Sicherstellen, dass die Mitarbeiter effizient arbeiten.
  • Arbeitsmittel bereitstellen.
  • Für die Weiterentwicklung der Mitarbeiter sorgen.
  • Urlaubsanträge unterzeichnen.
  • Mitarbeiter einstellen.
  • Mitarbeiter entlassen.
  • Leistung von Mitarbeitern beurteilen.
  • Gehälter festlegen.
  • Für Mitarbeiterzufriedenheit sorgen.
  • Unter- und Überlastung von Mitarbeitern verhindern.
  • Fürsorge (z.B. Burnouts verhindern)
  • Eskalationsinstanz
  • etc.

Warum sollte so eine lange Liste von Funktionen unbedingt in einer Person gebündelt werden? Mitunter wird eingeworfen, dass es “so schön einfach” wäre. Das ist definitiv der Fall, aber es ist das falsche Kriterium. Es geht nicht darum, ob etwas einfach im Organigramm aussieht, sondern darum, ob es wirksam ist. In einer agilen Welt ist die Bündelung der o.g. Funktionen in einer Vorgesetzten-Position nicht besonders wirksam.

Führungsfunktionen in Scrum

Mit dieser Idee der Funktionsverteilung kann man jetzt flexibel entscheiden, wo welche Funktionen von Führung liegen. Ein paar Dinge klärt Scrum bereits:

  • Der Product Owner sorgt dafür, dass die Entwickler das Richtige tun (durch Priorisierung des Product Backlogs).
  • Das Entwicklungsteam entscheidet darüber, wie die Arbeit konkret organisiert wird.
  • Der Scrum Master sorgt dafür, dass das Team effizient arbeiten kann (z.B. durch Hindernisbeseitigung).
  • Das Entwicklungsteam sorgt zusammen mit dem Scrum Master dafür, dass bei der Arbeit weder Unter- noch Überlast entstehen.

Und der Rest?

Damit bleiben eine Reihe von Führungsfunktionen zunächst ungeklärt, z.B. die langfristige Weiterentwicklung von Mitarbeitern, Einstellungen, Entlassungen und Gehaltsfestlegungen. Hier findet sich häufig die Auffassung, dass die Weiterentwicklung von Mitarbeitern und die Gehaltsfestlegung an derselben Stelle liegen sollte. Das ist aber gar nicht notwendig und häufig sogar problematisch. Es ist problematisch, weil für die persönliche Weiterentwicklung des Mitarbeiters offen über seine Schwächen und Fehler gesprochen werden muss. Wenn gleichzeitig über eine Gehaltserhöhung entschieden wird, wird der Mitarbeiter nicht besonders offen bzgl. vermeintlicher Schwächen sein. Und es ist nicht notwendig, weil eine erfolgreiche Weiterentwicklung Auswirkungen auf die Wirksamkeit des Mitarbeiters haben sollte und die Wirksamkeit sollte schließlich entscheidend sein, wenn es um Gehaltserhöhungen geht.

Dinge, die ich in der Praxis gesehen habe für die Führungsfunktionen, die per Scrum nicht fest verortet sind:

  • Über den Urlaub entscheidet das Team selbst. (Und achtet dabei darauf, bestimmte Constraints einzuhalten, z.B. Verfügbarkeit von Support für die produktive Software).
  • Über Einstellungen entscheidet das Team.
  • Bei Einstellungen redet das Team auf Augenhöhe mit.
  • Teams entscheiden darüber, ob Teammitglieder das Team verlassen müssen. Diese setzen sich dann auf die Ersatzbank und sind für andere Teams verfügbar.
  • Die langfristige Weiterentwicklung der Teammitglieder liegt beim Scrum Master.
  • Die langfristige Weiterentwicklung der Teammitglieder liegt im Team.
  • Die langfristige Weiterentwicklung der Teammitglieder liegt in selbstselektierten Peer-Groups.
  • Der Scrum Master verantwortet die Mitarbeiterzufriedenheit.
  • Ein Feelgood-Manager verantwortet die Mitarbeiterzufriedenheit.
  • Das Team verantwortet die Mitarbeiterzufriedenheit.
  • etc.

Es gibt also nicht die eine richtige Art und Weise, Führung zu organisieren. Man wird mit verschiedenen Ansätzen experimentieren müssen, um die Form zu finden, die für das eigene Unternehmen passt. Und man wird sich darauf einstellen müssen, dass auch Mitarbeiterführung einem kontinuierlichen Verbesserungsprozess unterliegt.

Mit diesem Ansatz, Führungsfunktionen zu verteilen, wird übrigens jedes klassische hierarchische Organigramm vollkommen nutzlos.

July 19, 2015 at 9:18 pm 6 comments

Salaries at it-agile

There are some discussions about open salaries coming up. Sometimes it-agile is mentioned but I think we never published what we are doing. So, here we come (we are about 30 people at it-agile).

Fixed salaries

We have fixed salary levels (roughly 9% difference from level to level).

Transparent salaries

These salary levels are transparent within it-agile and everybody at it-agile knows who is at which salary level.

No positions

We have no fixed positions at it-agile, just roles. Therefore the salary is not bound to a position. In principle everybody could “climb” to the highest salary level.

Setting the salary level

We experiment a lot with the process to find the appropriate salary level for the it-agile people. What we have done (and dismissed) in the past:

  • The CEO sets the salary of each colleague (except himself).
  • A group of senior people set the salary of each colleague.
  • The peergroup (a self selected group responsible for the personal development of a colleague) sets the salary of the colleague.
  • The salary set is set by some kind of crowd voting.

The current state is: A group called “salary checkers” (Gehaltschecker) that is elected by the it-agile colleagues sets the salaries of the colleagues and owns the process of finding the salary. Whenever a colleague want’s to get to the next salary level he is obligated to consult colleagues about his request. He has to select also critics for the consultation. When the colleague thinks the request is justified (based on the feedback he got during the consultation) he approaches the salary checkers with his request. The salary checkers check if the consultation was done properly and the feedback justifies the next salary level. If this is the case he is “promoted”.

We don’t have fixed criteria to determine the salary level. It’s more about: Where do I stand related to the colleagues below my salary level, to the colleagues at my current salary level und to the colleagues at the next higher salary level.

And the salary checkers still improve the process.

May 19, 2015 at 8:53 am Leave a comment

Three horizons innovation management and Product Ownership

3 horizons

The book “The Alchemy of Growth” (Merhdad Baghai, Stephen Coley, David White) describes the 3 Horizons model that differentiates three levels of innovation and growth.

  1. Horizon 1 is about the core business where the company make its main money. In horizon 1 you won’t do very risky things but innovation is still necessary to optimize the product/service and get ahead of the competition (or to stay ahead of the competition).
  2. Horizon 2 is about the upcoming future business. In horizon 2 companies develop the business models and products/services that should make essential money in 2 to 4 years.
  3. Horizon 3 is about the vague ideas with an unclear future. These are the startup-like ideas and statistically 9 out of 10 ideas won’t make it into relevant products/services.

Every horizon has to be managed differently and needs different optimization criteria (like KPIs), types of people, processes and structures.

Horizon 1

The purpose of the products/services on horizon 1 is not only to pay the salaries and make money for the shareholders but also to finance horizon 2 and 3. The products/services of horizon 1 need a compromise of stability and innovation for optimization. The goal of the optimization is to ensure (or even improve) the market position. The successful products/services need to be improved (and often cost reduction is an important part of this improvement).

The products/services and the market in horizon 1 are well understood and relatively stable. Therefore it is possible to calculate business cases for innovations. Every innovation should have a short payback period and the payback forecast will often match the reality.

Horizon 2

The purpose of horizon 2 is to develop the products/services that will move to horizon 1 in a few years. The innovations of horizon 2 often need new organizational structures and processes. The business model is not yet validated and relevant users needs are still unknown. Therefore detailed long term planning doesn’t make much sense. A rough sketch of the key features and best guess for budget and time (e.g. one team with 8 developers for 6 months) are as accurate as it can get. The details are figured out during the development with short feedback cycles and intense market/customer contact.

For the products/services in horizon 2 there is a high confidence that they will be successful in the market. Therefore minimizing time-to-market is essential. The team should work full time on the product/service and must not be restrained be bureaucratic stage gate processes.

When horizon 1 and 2 are mixed, conflicts will arise and most times horizon 1 wins (since it makes the money). But also in an environment where horizon 2 is isolated from horizon 1 conflicts will occur, when horizon 2 products/services are developed and move to horizon 1. Therefore horizon 1 innovations need a powerful driver (e.g. CEO).

Example: Steve Jobs drove the first iPhone and then the iPad development.

Horizon 3

The purpose of horizon 3 is to obtain and secure options and validate business ideas. In horizon 3 most of the bad ideas should be eliminated and most of the options won’t be exercised.

MVPs, (Minimum Viable Products), prototypes and mockups are king. Often there is no real product development necessary in horizon 3. Within horizon 3 we need to accept that most of our attempts will fail. We need to embrace failure and need to minimize learning cycles.

Product Ownership

Every horizon needs another type of product ownership. According to the three types of product owners Eric may serve horizon 3 best, Jeff may be necessary to drive a horizon 2 innovation and Marty may be best suited for horizon 1 innovations.

December 20, 2014 at 4:53 pm 1 comment

Agile Scaling Cycle: from SCaLeD principles to practices

The SCaLeD principles (http://scaledprinciples.org) were well received and gained many supporters. Of course a set of principles is not sufficient to be successful in projects – specific practices (depending on context) need to be used.

When we defined the SCaLeD principles we knew that practices would be needed and that we didn’t want to define another blueprint. So we accepted the gap for the moment.

Later I did a CSM class together with Peter Beck where the participants collected scaling practices. While the participants brainstormed we thought about how to structure the results and came up with the Agile Scaling Cycle (the name came into being during a presentation about scaling I did some weeks later).

The Agile Scaling Cycle is a simple three step cycle. It starts with “reduce dependencies”. Autonomous teams are a cornerstone of agile. Therefore we reduce dependencies between teams as much as possible.

Then we start to work and in the second step of the Agile Scaling Cycle the teams have to coordinate the remaining dependencies.

During the work problems (often pointing at organizational dysfunctions) will occur. These feed the third step of the Agile Scaling Cycle: develop the organization. After that we should have more options to reduce dependencies so we start over again with the first step “reduce dependencies”.

Agile Scaling Cycle.001

We have gathered lots of practices for reducing dependencies during the last decade:

Agile Scaling Cycle.002

And we gathered lots of coordination practices as well:

Agile Scaling Cycle.003

For developing the organization we often work with a transition team:

Agile Scaling Cycle.004

July 13, 2014 at 1:23 pm 2 comments

Coordinating teams with Scrum of Scrums

When multiple teams are interdependent (typically because they develop the same product), Scrum of Scrums is a common coordination practice within Sprints. Here are some tips to make it an effective meeting:

  1. During Sprint Planning identify the features that need contributions from several teams during the upcoming Sprint (e.g. with a dependency matrix).
  2. Focus the Scrum of Scrums meeting around these dependencies. (And dismiss the Scrum of Scrums if there are no relevant dependencies – which is actually a good thing.)
  3. Let the teams with dependencies send one or two delegates to the Scrum of Scrums. The delegates are developers – not the Product Owners and not the Scrum Masters. Delegates may be the same during the Sprint or teams may choose to rotate the delegates.
  4. Find an appropriate periodicity for the Scrum of Scrums. Sometimes a daily Scrum of Scrums is what the teams need, sometimes one or two Scrum of Scrums per week are sufficient. The teams should decide during the Sprint Planning.
  5. Timebox the Scrum of Scrums to 15 minutes if it is done on a daily base (weekly Scrum of Scrums may have longer timeboxes).
  6. Visualize the state of the features with dependencies during the Scrum of Scrums (e.g. with a dependency matrix).
  7. Let one of the team Scrum Masters moderate the Scrum of Scrums.
  8. Discuss three questions (similar to the one used in the Daily Scrum):
    1. What did my team achieve since the last Scrum of Scrums regarding the features with dependencies?
    2. What impediments occurred in my team regarding the features with dependencies?
    3. What do the teams plan to do until the next Scrum of Scrums regarding the features with dependencies?

Also consider alternatives to the central Scrum of Scrums meeting, e.g.:

  • Teams may visit the regular Daily Scrums of other teams if they have a dependency.
  • Teams may visit each other on demand. This is especially suitable in open office settings that encourage communication and cooperation between teams.
  • Teams may form task forces for the features with dependencies. Scrum of Scrums may be established per task force. Over the time of several Sprints patterns regarding the task force members may become visible. These are often good starting points for reorganizing team structures to improve team autonomy.
  • The ideal of the Scrum team is the autonomous team without dependencies. Although a dependency free situation won’t be achievable we strive for reducing dependencies. If we are successful the teams don’t need any coordination meetings during the Sprint.

 

May 27, 2014 at 10:56 am 1 comment

ASMM: Agile Scaling Maturity Model

During a presentation of our approach to scaling agile I constructed „Stefans Agile Scaling Maturity Model“ (SASMM, not trademarked) in an ad-hoc fashion: The number of scaling practices you don’t need. It was a joke but I think there might be something behind the curtain.

Let’s start with the Agile Scaling Cycle: We start with reducing dependencies between teams and with the outside context. Then we do some work and need to coordinate the remaining dependencies. During this work we generate insights and detect organizational impediments. These direct us during the further development of the company. The evolved structures and processes of the company give us additional options for reducing dependencies and we start a new loop through the Agile Scaling Cycle. The whole cycle is driven by the agile scaling principles (which are just the agile/lean principles reformulated for scaling; see http://scaledprinciples.org).

Bild

The trick here is to reduce dependencies to the point where coordination becomes dead simple. When we went through the Agile Scaling Cycle several times the company should be more mature, teams should be less dependent and in consequence we need very few coordination practices. Therefore the first formula to compute the scaling maturity on a scale from 0 to 10 (the higher the score more mature) could be:

ScalingMaturityLevel = 10/NumberOfCoordinationPractices

Of course some coordination practices are more agile than others. A dependency matrix is less agile than a shared Sprint Review. So we could weight the practices by the additional weight they put on the process. But that would be another blogpost and in the end I’m not convinced that maturity models are valuable.

April 9, 2014 at 10:28 am Leave a comment

Use what works, ditch the rest?

„Use what works, ditch the rest!“ is something that I have heard over and over again regarding Agile. On one hand it sounds logical, one the other hand it feels somehow wrong. And for a long time I didn’t really understand why I felt that way.

In a recent Twitter conversation around that theme Dave Snowden wrote, „if you don’t know why it worked you end up being fooled.“ That statement helped me to understand my gut feeling better.

I think the really important part of „Use what works, ditch the rest!“ is your definition of „works“. Let’s be more precise: Scrum wasn’t made to „work“ in your environment. It is designed to make the organizational dysfunctions visible, so that you can remove them. In that way you shouldn’t expect Scrum to “work”. And if you ditch Scrum since it doesn’t “work”, you ditch an opportunity to evolve the company.

Sidenote: It doesn’t matter if you use Kanban instead of Scrum. Slack time generated by WiP limits doesn’t “work” in most companies either.

Don’t get me wrong: I do not propose cargo-cult dogmatism. In alignment with Dave Snowden you should have experienced agile practitioners on board who know why Scrum and Kanban are designed the way they are and help you understand why something does or doesn’t work in your context. Then you really learn and get the opportunity to improve.

In conclusion the „Use what works, ditch the rest!“ is OK for me, when the definition of „works“ is that our problems become visible so that we can attack them.

March 26, 2014 at 8:05 pm 1 comment

Older Posts



Follow

Get every new post delivered to your Inbox.

Join 191 other followers