Shades of Scrum: The Scrum Master role

The Scrum Guide by Ken Schwaber and Jeff Sutherland states about the Scrum Master role:

„The Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules. The Scrum Master is a servant-leader for the Scrum Team.
The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.“

This definition states what the Scrum Master has to do but not how. And this is not a bug, it’s a feature. How to assume the Scrum Master role is highly dependent on the context. I like the situational leadership model to think about how the Scrum Master should do his job.

ScrumMasterRole

  1. Telling: When a team hasn’t done Scrum before it is unable to do Scrum and insecure if Scrum would really work for them (bottom right cell of the diagram). In this situation the Scrum Master should tell the team members what to do. Providing lots of options to the team will often result in paralysis. The team just doesn’t have the experience to choose one of the options. In addition to the Scrum framework the Scrum Master may tell the team to estimate in story points and use Planning Poker for it.
  2. Selling: After a short period of „Telling“ and delivering shippable product increments the team will move up to the top right cell. Now the team is secure that Scrum could work for them but is still unable of doing it (since it just did what the Scrum Master told them to do). Now the team is ready to take over a bit more responsibility and the Scrum Master moves to selling. He gives advice to the team and tries to convince them to do the right thing. In the „Selling“ state the Scrum Master explains in much more detail the whys of his advices. Now the Scrum Master may let the team decide if that want to estimate with story points or ideal days and wether they would use Planning Poker or something else. But the Scrum framework would not be modified by the team.
  3. Participating: Now the Scrum Master leaves most of the decisions to the team (and just jumps in when there is something really critical). The consequence is that the team becomes more capable but insecure again. „Can we be successful with Scrum when we do it ourself without the Scrum Master managing the whole thing for us?“  The team starts to self-organize in the „Participating“ state. Now the team may decide to do the Sprint Planning in another way and may remove the Daily Scrum (but not the Sprint Planning, Review or Retrospective).
  4. Delegating: Then the team experiences that it can succeed with Scrum without being dependent on the Scrum Master. Now the Scrum Master really acts as a coach leaving all decisions to the team. That means that the team may remove or adapt every single part of the Scrum framework.

In my experience switching between the left and right columns of the diagram is a challenge for most Scrum Masters. Some Scrum Master have the tendency to adhere strictly to the Scrum rules and give strict rules to the team. They are successful in the „Telling“ and sometimes in the „Selling“ state but often mess up the transition to the „Participating“ state. They just can’t let the team go.

And there are the Scrum Masters with a coaching mindset. They work successfully in the „Participating“ and „Delegating“ states but are challenged by unable teams. They often have problems providing the concrete guidelines to the team that it needs then.

One interesting question is of course: „Where is my team?“ A simple test is to not show up in a Daily Scrum. Will the team do a proper Daily Scrum? Then it is probably no longer in the „Telling“ state. What about the retrospectives? Is the team creative in finding solutions for its problems and does it implement the solutions successfully? Then the team is probably in the „Participating“ state. Or does the team just creates a list of things that other people should do? Or does the team create action items but fails in implementing them regularly? Then the team hasn’t reached the „Participating“ state yet.

Leseliste zu Lean Startup

Lean Startup wird immer bekannter. Entsprechend sprießen Bücher, Blogposts, Vorträge etc. zu dem Thema aus dem Boden. Die folgende Leseliste soll bei der Orientierung helfen. Die Empfehlungen sind nach der Lesereihenfolge geordnet, die ich empfehle. Es beginnt mit kurzen Überblicksartikeln, geht dann zu den Grundlagenbüchern und endet mit konkreten Erfahrungen, die helfen, den möglichen Einsatz von Lean Startup im eigenen Unternehmen zu diskutieren.

Lean Startup verstehen

Stefan Roock: „Lean Startup“, Artikel in Objekt-Spektrum 1/2013, deutsch

Dieser Artikel gibt einen kurzen Überblick über Lean Startup und sollte hilfreich bei der generellen Einordnung des Ansatzes sein. (Der Artikel ist tatsächlich noch nicht erschienen. Aber solange dauert es nun auch nicht mehr 🙂

Eric Ries: „The Lean Startup“, Buch, englisch & deutsch

Eric Ries ist derjenige, der Lean Startup unter diesem Namen bekannt gemacht hat. Daher ist das Buch in gewisser Weise ein Must-Read. Man sollte allerdings nicht zuviel erwarten. Das Buch argumentiert gut, warum und wann der Ansatz nützlich ist. Er gibt aber wenig Hilfestellung dabei, wie man Lean Startup konkret anwendet.

Das Buch gibt es auch in einer deutschen Übersetzung. Die habe ich aber nicht gelesen und kann daher nichts zu deren Qualität sagen.

Ash Maurya: „Running Lean“, Buch, englisch

Dieses Buch ist deutlich handlungsleitender als „The Lean Startup“ und daher meine Empfehlung für alle, die sich ernsthafter mit Lean Startup auseinander setzen wollen.

Lean Startup für den eigenen Kontext bewerten

Doreen Timm, Sandra Reupke-Sieroux: „Lean Startup – Lessons Learned“, Artikel in Agile Review 2/2012, deutsch

Dieser Erfahrungsbericht beschreibt, wie 7 Kollegen von it-agile einen Monat lang ein Startup nach dem Lean-Startup-Ansatz betrieben haben. Dabei werden insbesondere auch die kritischen Punkte deutlich herausgestellt, die nicht funktioniert haben. Es ist daher ein sehr nützlicher Artikel, der hilft, nicht nochmal in die selben Fallen zu tappen. Wer die „Agile Review“ noch nicht besitzt, kann sie bestellen bei info@it-agile.de.

Stefan Roock: „Pivots in grown companies„, Blogpost, englisch

Der Artikel beschreibt ein wichtiges strukturelles Problem bei der Anwendung von Lean Startup in „erwachsenen“ Unternehmen, die eine funktionale Abteilungsstruktur haben. Wenn man Lean Startup in „erwachsenen“ Unternehmen anwenden möchte, ist es aus meiner Sicht wichtig, diese Fußangel zu kennen. Dann kann man sie früh adressieren und angemessen damit umgehen. Es zeigt außerdem, dass Lean Startup in „erwachsenen“ Unternehmen durchaus auch Unternehmensentwicklung bedeuten kann.

Lean Startup anwenden

Stefan Roock: „Lean Startup: a classification of MVPs„, Blogpost, englisch

Der Artikel präsentiert eine Klassifikation von MVPs (Minimum Viable Product), die dabei hilft, den passenden MVP-Typ für die vorliegende Fragestellung zu identifizieren.

Steve Blank: „The Startup Owners Manual“, Buch, englisch

Das Buch von Steve Blank ist umfassend und entsprechend dick. Es ist eher als Nachschlagewerk konzipiert als ein Buch, das man von vorne bis hinten durchliest. Entsprechend ist das Buch nützlich, wenn man konkret beginnt, mit Lean Startup zu experimentieren.

Unterstützung durch it-agile

„Lean Startup mit Scrum“, Schulung, deutsch

Diese Schulung vermittelt praxisnahes Wissen zu Lean Startup. Mehr Informationen findet sich unter http://www.it-agile.de/leanstartup-mit-scrum.html

Lean Startup Coaching

Natürlich ist Coaching viel teurer als ein Buch oder eine Schulung. Dafür ist die Vermittlung von Wissen und Fähigkeiten durch Coaching viel schneller und direkter anwendbar. Wer externe Lean-Startup-Expertise für sein Team sucht, wird fündig unter: http://www.it-agile.de/innovative-produktentwicklung.html

Lean Startup Team

Wer eine neue Produktidee hat und ein komplettes, erfahrenes Lean-Startup-Team sucht, wird hier fündig: http://www.it-agile.de/innovative-produktentwicklung.html

 

 

 

XP-Days Germany vom 29.11. bis 01.12.2012 in Hamburg

Die XP-Days Germany gehen dieses Jahr „back to the roots“ und fokussieren wieder auf Entwicklerthemen. Das bedeutet, dass viele Sessions rund ums Programmieren ins Programm aufgenommen wurden. Allerdings begreifen wir in der agilen Entwickler den Entwicklerbegriff viel weiter. Jeder, der aktiv an der Entwicklung von Produktinkrementen mitwirkt, ist ein Entwickler. Entsprechend finden sich auch Sessions zum Testen, UI-Design und User-Experience im Programm. Dabei gibt es einen sehr großen Hands-On-Anteil bei den Sessions, ganz gemäß den aktuellen Erkenntnissen aus der Lerntheorie, die das bestätigen, was Konfuzius bereits vor 2.500 Jahren wusste als er schrieb: „Erzähle es mir und ich werde es vergessen. Zeige es mir und ich erinnere mich vielleicht. Involviere mich und ich werde verstehen.“

Aber seht Euch das Programm selbst an: http://xpdays.de/twiki/bin/view/XPDays2012/Programm

Ich werde übrigens auch eine kurze Session auf den XP-Days anbieten zur Zusammenstellung von Teams.

 

it-agile 28 weeks later

In january I blogged about the internal state of it-agile. Let’s have a look what changed during the 28 weeks since then.

  • We have introduced autonomous business teams to enable scaling and support local experimentation. The business teams synchronize monthly at a whole-day face-2-face meeting and with an offset of two weeks at a shorter monthly telco.
  • After we introduced the teams we discovered some limits to the teams‘ capabilities. Not every team was able to generate sufficient customer demand to „make a living“. Therefore we created a virtual sales team (consisting of members of business teams) that focused on demand creation.
  • There was a institutionalized group called „senior consultant group“ consisting of the two CEOs and the two most senior consultants. This group decided to dissolve since most of its responsibilities were transfered to the employees and business teams over team.
  • One left over was the process for deciding on salaries. Employees had and have peer groups with whom they discuss their personal development and peer groups may suggest increases in salaries. The final decision was made by the „senior consultant group“. As this group dissolved completely we introduced a „SalaryChecker“ group consisting of four people elected by all employees. (The two CEOs were proposed as candidates for the group but didn’t accept the nomination. The current „SalaryChecker“ group consists of the two „seniors“ of the original board and two other employees.
  • Intrinsifier published an article about it-agile.

Pivots in grown companies

Thesis: Pivots in grown companies are challenging

When you pivot in a real startup the situation is quite simple. The product team recognizes the need to pivot and then does the pivot.

In a discussion with Markus Andrezak I realized that the situation is quite different when you want to pivot in a grown company. Then the pivot often affects not only the product team but completely different departments. And therefore you may need to get the commitment of the CEO to pivot. In a larger company this may increase the time you need for the pivot to weeks or months.

An Example

Let’s look at an example of a marketplace platform with a transaction oriented pricing model like eBay or Amazon: The company earns money everytime a transaction is completed. According to this model the KPIs of the marketing department are based on transactions. The KPIs of the sales force may be based on new registered sellers.

Now let’s assume that in our imaginary example company revenues have stopped to grow. After some investigation the product team thinks it should pivot the transaction based model and just connect buyer and seller. While the product may need only minor modifications it changes nearly everything for marketing and sales. The marketing KPIs based on transactions become senseless and need to be replaced. For the sales force the change may be even more dramatic. Perhaps registered sellers are not that important any more. Perhaps there is even no need for a sales force any more?

The product team would not be able to make these changes happen within the company on its own. The changes would need the intervention of the CEO.

Rationale

The situation described in the example is not a special exception. It is the result of the nature of a pivot. A pivot is not just a modification to a product feature. Pivots address the product strategy – revenue streams, cost structure, key partners, target group, customer needs as well as key features.

The most aspects of the product strategy are built into a grown company. The revenue streams and key partners affect sales. Target group and customer needs affect marketing. The cost structure affects operations. And so on.

Therefore: In a grown company a pivot is a major change to the whole company.

The consequences are:

  • You need to analyze what parts of the company may be affected by the pivot.
  • You often need commitment or at least explicit support for the specific pivot by the CEO.
  • You may have to market your pivot to the whole company.
  • The pivot may take weeks or months.

Artikel zu flexiblen Architekturen online

Früher oder später werden Softwaresysteme unwartbar. Änderungen werden so teuer, dass sie faktisch unbezahlbar werden. Irgendwann werden die Schmerzen so groß, dass ein neues System entwickelt wird. Und das Spiel beginnt von vorne. Dabei handelt es sich aber nicht um ein Naturgesetz. Wir können Software entwickeln, die sich langfristig zu moderaten Kosten weiterentwickeln lässt – und das, obwohl wir auch bei der initialen Entwicklung nur moderate Kosten verursachen

Der vollständige Artikel findet sich hier.

Lean Startup: A classification of MVPs

There are different kinds of MVPs (Minimum Viable Products) with specific consequences. For me it is useful to think along two dimensions:

  1. Coverage: The number of reached customers. (An interview is done with few people, an Ad-Words campaign may reach thousands).
  2. Product Fidelity: How similar is the MVP to the end product? (A software prototype has a higher fidelity than a paper mockup).

Here are the MVPs I am aware of:

Bild

The size of the dots is the length of the feedback cycle. An interview is done in a few minutes. A software prototype needs hours or days to program and then days or weeks to gather the feedback.

How to use it

The classification is useful to find the appropriate MVP. When teams start learning Lean Startup they tend to use high fidelity, high coverage MVPs and pay the price: The need weeks to get feedback. But in the very beginning many of our assumptions are just plain wrong and we want to learn that as fast a possible. Therefore first MVPs should be as fast as possible. Using low fidelity, low coverage MVPs from the bottom left help to achieve that. When we validated some assumptions with low fidelity, low coverage MVPs we move up and to right: higher fidelity, higher coverage.

More MVPs

I am keen to discover other MVPs (the empty space in the middle of the diagram looks like there is something missing). What are the MVPs you know of?

Definition of Ready: A double edged sword

A german version of this article is available at: https://www.it-agile.de/wissen/agile-teams/definition-of-ready/

The Definition of Done is a well known concept in Scrum: The Scrum team defines when a feature is Done and may be demonstrated during the Sprint Review. The Definition of Ready is a newer concept that is less common. The Definition of Ready states the conditions under which a User Story (or more general a Product Backlog Item) is ready to be included into the Sprint. The goal is to avoid working on User Stories in the Sprint that are too fuzzy to be successfully finished within the Sprint. This is definitely a good intention since often development start to work on a User Story although their understanding of the User Story is too weak. In that case working on the story may be blocked due to necessary clarification or work may loose focus due to different interpretations of the User Story.

On the other hand the Definition of Ready may be used to create an over regulated process that impedes collaboration between Product Owner and development team: Whenever there are communication problems between Product Owner and development team the Definition of Ready is extended by a new policy. After several „improvements“ the Definition of Ready requires the Product Owner to specify each requirement correct, complete and consistent pre-checked by another Product Owner and a Software Architect to avoid any ambiguity or missing details.

This is NOT Scrum and it is NOT Agile.

The Agile Manifesto has something to say about the intended relation between the Product Owner and the development team:

  • „Individuals and interactions over processes and tools“
  • „Business people and developers must work together daily throughout the project.“
  • „The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.“
  • „The best architectures, requirements, and designs emerge from self-organizing teams.“

Don’t forget about the underlying values and principles of agile development! For the Definition of Ready I recommend: The smaller the better. The team becomes more and more capable of handling incomplete information. Therefore the Definition of Ready should be shrinking over time and not growing (while normally the Definition of Done is growing with the capabilities of the team).

 

Moreover the Definition of Ready should focus on the process not the artifacts (like User Stories). I prefer „Product Owner and Development Team defined the acceptance criteria of each User Story collaborating in a workshop.“ over „Each User Story has acceptance criteria.“ as part of the Definition of Ready.

References

 

Selbstorganisation im Unternehmen

Selbstorganisation in Teams ist durch Scrum und andere agile Verfahren heute quasi Stand der Kunst (ja, ich weiß, ess es vielfach in der konkreten Umsetzung noch hakt). Aber ist damit das Ende der Fahnenstange schon erreichen? Ich glaube nicht. Nun, um ehrlich zu sein, ich weiß sogar, dass das nicht der Fall ist (durch den Grad der Selbstorganisation, den wir bei it-agile aber auch einige andere Unternehmen erreicht haben).

Selbstorganisation über Teams hinaus und sogar im ganzen Unternehmen ist möglich. Ich habe Folien auf Slideshare hochgeladen, die zeigen, wie Selbstorganisation auf Unternehmensebene funktioniert: Folien

Die Folien stammen von einem halbtägigen Workshop, den ich bei einem Kunden zu dem Thema „Selbstorganisation im Unternehmen“ durchgeführt habe. Wer so einen Workshop auch gerne bei sich im Unternehmen durchgeführt haben möchte, kann sich dazu gerne bei mir melden.

Risk Management in Complex Domains

We had a discussion with some it-agile colleagues about risk management in complex domains and if there is a relevant difference to complicated domains. Here is my current understanding.

Classical risk management in software development comes from waterfall like approaches tailored for simple and complicated domains. In a nutshell you create a list of all risks at the beginning of the project. Every risk has a probability and a potential damage. Multiplying probability with damage yields a kind of „risk cost“ which is then used to prioritize the risks. After that we define countermeasures or mitigations for the risks. Here is a short introduction to classical risk management.

In my experience the focus of classical risk management  is on creating a plan that can be executed without big surprises. And second is focus is on avoiding the risk to ensure project success.

For this traditional approach it is crucial to anticipate cause-effect relations. That is possible in simple and complicated domains but not in complex domains. Therefore traditional risk management is of limited value in complex domains (yes, I tried it for some years).

Feedback driven approaches like Scrum have built in risk management for a lot of typical risks:

  • Does the software match customer needs?
  • Will we deliver in time?
  • Does the software scale?
  • etc.

But we believe there is more to it. Let’s have a look at a story told by Don Reinertsen at the LSSC 2012 conference about fire fighting. Fire in forests behaves in a complex way. It is impossible to forecast what the fire will do in the near future. There is the influence of wind and rain and even the fire itself may create relevant wind.

The fire fighters do risk management in a when-then pattern. „When the fire crosses this boundary, then we will evacuate this town.“ It is not possible to guarantee that the fire will cross this boundary. Therefore we make a plan to minimize damage not to avoid the damage completely.

We think that this pattern of risk management is applicable also for software/product development. We identify the risks that may cause critical damage and were we need to react really fast. For these risks we create a plan what to when the risks becomes reality.

This is exactly what one of my clients did when the global financial crisis started. „When sales drops below this point we will reduce costs here and use money from another business area to avoid layoffs.“

With such a plan the appropriate preparations can be done in advance (e.g. not signing long term contracts that bind a lot of money and put new investments on hold). And it creates a safe atmosphere for employees. They see that there is a plan and that this plan does not include layoffs.

Conclusion
In complex domains risk management ist more „when X will occur we will do Y“ than „to avoid X we will do Y“. (That doesn’t imply that traditional approach had no place n complex domains. It is just less important.) But one thing stays the same: More important than risk lists are the collaborative discussions about risks with and within the team.

P.S.: I used the term „risk management“ throughout this blogpost although I think it is misleading. Risks in complex domains can’t be managed. We only can prepare to be able to react accordingly. But by now I don’t have a better term. I love to see proposals in the blogpost comments.

P.P.S.: I like to thank my colleagues for the discussions about the topic, namely Arne Roock, Norbert Hölsken, Christian Dähn, Jens Coldewey, Sebastian Sanitz (and I hope that I didn’t forget anyone).