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.

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.

Summary

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.

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)

But.

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?

Pull

Workload Pull

Purpose Pull

Push

Traditional Project Management

X

Push

Pull

What?

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 http://assets.sbnation.com/assets/1074301/Valve_Handbook_LowRes.pdf)

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.

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.

Shades of Scrum: Estimation of the Product Backlog

The common saying is that in Scrum the development team estimates the Product Backlog in Story Points. This is a good start for a lot of teams since it is a suitable match between business needs and the capability of the team.

But: There are a lot of other options for estimation in Scrum.

Why estimating the Product Backlog?

The first important question is why you want to estimate the Product Backlog. Typically the Product Owner, the management or the customers want to have a release plan. To create a decent release plan the Product Owner needs a good enough estimation of the features that will make the release. (If nobody needs a release plan you may not need to estimate the Product Backlog at all).

The Product Backlog often contains items for following releases. The Product Owner should question the need for estimating these. Often he needs to create the plan for the current release but not plans for all following releases. Therefore the items with low priorities often don’t need to be estimated at all.

How to estimate the Product Backlog

For the items that need to be estimated there are alternatives to Story Points. The team could  estimate in person days, of course. Or they could use T-shirt sizes (S, M, L, XL) or even simpler they could just count the items in the Product Backlog. But counting isn’t estimating, is it?

When you just count items you have an underlying assumption: the variation in size of these items is small enough so that counting will produce a good-enough result. So you estimate that the items are more or less of the same size. You could say that you estimate all items to be one story point.

When to use which estimation technique

When are Story Points appropriate and when is counting sufficient? The so called ”sources of variabilities” (a concept from Lean Thinking) have a big impact on the decision. Sources of variability make estimations fuzzy or instable. Typical sources of variability in software development are:

  • Missing contributions of other departments or companies.
  • Missing skills within the development team.
  • Wrong or incomplete understanding of what has to be done.
  • Exchange of team members.
  • Modifications of the Product Backlog (new features are added).
  • Illniss of team members.
  • Urgent incidents.

The sources of variability interfere with the estimations. It is for example worthless to invest a lot of time in a very precise estimation if the team members are exchanged every week. These exchanges would make the performance of the team totally unpredictable. In that case the precision of the estimation doesn’t matter.

Here is a rule of thumb: The more sources of variability the less precision.

Bild

You should do imprecise estimations when you have a lot of sources of variability. Don’t invest your time to refine these estimations (red area in the figure). Invest your time in eliminating sources of variability (moving to right in the figure). It is the bigger leverage. But be aware of the fact that not all sources of variability are bad. Changes to the scope is intended in Scrum – it is the root cause for the Sprint Review. Removing all sources of variability would kill innovation. Therefore focus on the unwanted sources of variability.

After you eliminated the biggest unwanted sources of variability you could make your estimations more precise.

The following figure relates typical estimation instruments to the estimation precision.

Bild

P.S.: Scrum is aware of unwanted “sources of variability”. It just uses another name: impediments.

Shades of Scrum

Is Scrum a process? According to the Oxford dictionary a process is “a series of actions or steps taken in order to achieve a particular end”.

Is Scrum a method? According to the Oxford dictionary a method is “a particular form of procedure for accomplishing or approaching something, especially a systematic or established one”.

Is Scrum a methodology? According to the Oxford dictionary a methodology is “a system of methods used in a particular area of study or activity”.

, method or methodology. Remember that Scrum doesn’t say a word about how to estimate, how to do the software architecture, unit testing etc.

Scrum is a framework. The Oxford dictionary defines a framework as “a basic structure underlying a system, concept, or text”.

This means that every team builds it own p Scrum is none of these. Scrum is just to unspecific to be a process rocess / method / methodology using the Scrum framework as the basic underlying structure.

And that means that there is no best practice for a staffing the Product Owner, for the behavior of the ScrumMaster or the Sprint length.

In the “Shades of Scrum” blogpost series I explain possible implementations of parts of the Scrum framework with the underlying forces that may make one choice more suitable in a specific situation than another choice:

  • The ScrumMaster role: The article explains how the ScrumMaster role may change over time according to the ever growing capabilities of the team.
  • 3 Product Owners and a Product Owner Shaped Object: The article describes 4 implementations of the Product Owner role and argues that one of the more common implementations isn’t a valid Scrum Product Owner.
  • Sprint length: The article compares shorter and longer Sprint lengths and shows that longer Sprint lengths have their value – not only for beginners.
  • Waterfall, Pipelining and Sprints: Most companies aren’t capable of doing perfect Scrum from day 1. They need to transition from Waterfall to Scrum, maybe with Pipelining as an intermediate step. The article shows pros and cons of the Waterfall, Pipelining and Scrum Sprints and helps to define an appropriate process for the specific whole value stream.
  • The Sprint Planning and the pull principle: The team pulls work into the Sprint during the Sprint Planning. The article discusses different types of pull.
  • Estimation of the Product Backlog: The article presents different approaches to estimation and discusses when to use which approach.
  • Empirical Management Meetings: The article highlights that fact that most Scrum meetings are empirical management meetings and therefore there should be transparency, inspection and adaptation in the meetings. The article gives guidelines on how to optimize these meetings for your context.
  • Scrum outside IT: Scrum is used mainly for software development today but starts to spread out to other areas. The blogpost shows concrete example of Scrum outside IT and presents an approach to handle projects outside IT with Scrum.

Shades of Scrum: Waterfall, Pipelining and Sprints

Waterfall and Scrum

We all know the traditional approach to software development – the sequential waterfall model.

Waterfall

Activities like analysis, design, implementation and test are done sequentially – an activity is completed before the next activity is started. The work is done by specialists like business analysts, software architects etc.

And there is Scrum: All activities are done in parallel in Sprints by a cross-functional team.

Scrum

Combining Waterfall and Scrum

Moving from Waterfall to Scrum is a big step for most companies. Most companies are not capable of doing this change in a short period of time. Therefore a combination of Waterfall style phases and Scrum sprints is very common. Typically the Waterfall style phases embed the Scrum sprints.

WaterfallScrum

For example market research and product definition would be done in Waterfall style. UI design, programming and component tests would be done in Scrum sprints. And then integration tests, roll-out and sales would again be done in Waterfall style.

The problem with this kind of combination of Waterfall and Scrum is not it used but that companies stay with it. A lot of companies that practice this combination of approaches find out that the advantages are limited:

  1. End-to-end responsibility is hard to establish due to the silos and hand-overs.
  2. Long time to market: Since the phases before and after the sprints stay the same the overall lead time often is reduced only by a few percentages.
  3. Long feedback cycle: The end-to-end feedback cycle is nearly as long as with the waterfall.
  4. Feedback may invalidate a large amount of work: If the last activity (e.g. sales) generates relevant feedback for the first activity (e.g. market research) a lot of work done during the activities in between may be invalidated.

Notice that Waterfall is not a bad idea in general. Especially when there are low risks and few things to lean, Waterfall may be a suitable approach.

Pipelining

Pipelining is a more beneficial approach. Pipelining simply means that several teams work in parallel sprints where one team generates the input for another team.

Pipelining

Pipelining is much better than the waterfall approach but in the end it just reduces batch sizes without changing the general way of working. Compared to Scrums all-in-one-team approach the drawbacks are the same as with the waterfall approach.

The first important aspect is that the feedback cycle is not one sprint but – in the case of three teams – three sprints.

PipeliningFeedbackCycleLength

The second aspect is that pipelining is a very poor approach to address learning.Pipelining assumes that the upstream team (team 1 in our example) hands over its output to the downstream team (team 2 in our example) and proceeds with the next sprint. But when the downstream team discovers something about the work done by the upstream team  it is challenging to integrate that discovery into the work flow of the upstream team.

PipeliningFeedback

If for example a downstream team does testing, how would the upstream team handle the discovered bugs?

Fold the pipeline into Sprints

When you work with pipelining the whole thing can be folded into Sprints. When we have for example 3 teams doing pipelining with a Sprint length of 1 week it is easy to put all the participants in one team with a Sprint length of 3 weeks. The team then may decide to do some kind of pipelining but is empowered to modify the way of working within the sprints to suit current needs. And even if the team opts for pipelining it is more likely that the team members cooperate.

Conclusion

Scrum isn’t generally better than Waterfall. Both approaches have their specific pros and cons.

Waterfall Scrum
Learning during the project very expensive since a lot of work have to be redone cheap
Innovation unlikely by working within silos likely due to cross-fertilization
Efficiency efficient by using specialists for specialists tasks less efficient since specialists work outside their specialization

In general Scrum is better suited when a lot of things are unknown and therefore learning has to be incorporated in the project. In the end it boils down to the question what and how fast we need to learn – or where the risks are. When the roll-out of the software is of low risk it may be suitable to do it with pipelining or even Waterfall.

Therefore the question is not if Waterfall or Scrum is better suited. The question is, where we should use Waterfall and where we should use Scrum. And when we choose to use Waterfall pipelining is in most cases the better implementation – the smaller batch sizes (aka work in progress) generate shorter lead times.

Related reading

  1. Shades of Scrum: Sprint length – the article describes some advantages of longer Sprint lengths (which may be the result of folding a pipeline into Sprints)
  2. Twelve emerging best practices for adding UX work to Agile development – In this article Jeff Patton suggests to use pipelining for User Experience (UX) work.

Shades of Scrum: Sprint length

The Sprint length in Scrum is 30 days or less. Most teams work with 2 or 3 week Sprints and the most common recommendation for the Sprint length seems to be 2 weeks. 30 day Sprints seem to be very rare.

The general thinking here is that shorter Sprints lead to more frequent inspect&adapt regarding the product (Sprint Review) and the process (Sprint Retrospective). When a team is capable of doing 3 week Sprints it should therefore try to work with 2 week Sprints and then 1 week Sprints.

But I think there is missing an important aspect: When the team is capable of delivering within a certain Sprint length there are actually two possibilities for further improvement:

  1. Shorten the Sprint length to reduce feedback cycles and allow more frequent inspect&adapt.
  2. Deepen the teams capability by reducing the Definition of Ready (start the Sprint with a less formal specification) or increasing the Definition of Done (e.g. by including live deployment).

Which direction to take is – of course – dependent on the specific context.

Shorten the Sprint length is valuable if

  1. the Product Owner is actually able to react that fast to feedback about the product
  2. the team is able to create and implement process improvements that fast

Deepen the teams capabilities by reducing the Definition of Ready is valuable if

  1. cross-functional work seems valuable not only for the implementation but also for the definition of the “what” (remember the benefits of cross-functional work: more creativity, higher quality)
  2. the Product Owner is overloaded (e.g. he is a Jeff type of Product Owner but is forced to work like a Walter or Marty)

Deepen the teams capabilities by increasing the Definition of Done is valuable if

  1. the product increment isn’t really shippable until now (e.g. integration tests are missing; the demo is done in a branch)
  2. there are often problems in the downstream processes (e.g. operations has problems with deploying the product increment into production)

Consequences

  • When your team becomes more capable you should discuss if you want to shorten the Sprint length or deepen the capabilities of the team.
  • When your team is capable of doing the current Sprint length but not a shorter one, you should discuss if it would be valuable to extend the Sprint length and deepen the capabilities of the team.

Related Posts

Shades of Scrum: 3 Product Owners and a Product Owner Shaped Object

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

The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.
The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes:

  • Clearly expressing Product Backlog items;
  • Ordering the items in the Product Backlog to best achieve goals and missions;
  • Ensuring the value of the work the Development Team performs;
  • Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
  • Ensuring the Development Team understands items in the Product Backlog to the level needed.

Product Owner Personas

I have seen four different types of Product Owners. I have created little personas to describe them: Walter, Marty, Eric and Jeff.

Walter

Walter is very accurate when preparing the next Sprint. He knows the domain very well and doesn’t need the support of the team for Sprint preparation. He only calls the developers for Sprint preparation when he needs an estimate for a newly created Product Backlog Item. In the Sprint Planning Walter hands over very clear and detailed specifications of what has to be done in the Sprint.

Walters Product Backlog Items are described very carefully and have a detailed list of acceptance criteria. Therefore there is no need for intense contact with the development team during the Sprint.

Marty

Marty asks the development team regularly for help during Sprint preparation. He writes some of the Product Backlog Items together with the development team and often details Product Backlog Items and their acceptance criteria together with the team.

Marty is available during the Sprint to clarify details that are not described by the Product Backlog Items.

Eric

Eric does not only work as a Product Owner; he is also a member of the development team. He creates and manages the whole Product Backlog together with the development team. When the Sprints begins, the Product Backlog Items are often very rough and a lot of stuff is detailed and clarified during the Sprint.

Jeff

Jeff has some distance to the development team. Normally he interacts with the development team only during Sprint Planning and Review. His Product Backlog Items are coarse grained leaving out most of the details. The development team has to figure out the details itself. Jeff may provide a Product Backlog Item “Birthday list” and the team has to figure out the filter criteria, printed data and layout.

Conclusion

In my point of view three of the described Product Owner personas are valid Scrum Product Owners and one is only a Product Owner Shaped Object (POSO). From an outside view the POSO complies with the Scrum rules but he doesn’t incorporate the Scrum mindset.

Walter

Walter is the POSO and his complete name is Walter Falls. His way of working is still sequential waterfall. He specifies the requirements and the team does the execution. What is missing here is the overlap of development activities (namely analysis and development) and the collaboration between the Product Owner and the development team.

Walter is a guy you would meet in a lot of Scrum implementations, because his way of working is very similar to the way the people have worked in waterfall projects for years. When doing a transition to Scrum Walter may be a suitable temporary type of Product Owner. But you should keep in mind that it is only an intermediate step and that Walter should transform into one of the other Product Owner personas.

Marty

Marty is the Product Owner that is described by the most of the Scrum literature and he is the most common valid Scrum Product Owner. I have chosen the name ‘Marty’ since I think this type of Product Owner is what Marty Cagans book “Inspired” implies.

Marty is relatively easy to implement and is therefore quite often. For a team beginning with Scrum Marty is normally a good choice. And then it may evolve into Eric or Jeff.

Eric

A lot of people think that Eric and Jeff aren’t valid Scrum Product Owners since they don’t provide all the details to the development team. Often the following statement referring to the dotted lists with the Product Owners responsibilities from the Scrum Guide is ignored:

The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.

As long as Eric (or Jeff) remain accountable their approach to the Product Owner role is completely valid.

Eric is the most collaborative Product Owner regarding the interaction with the development team. Eric is a good choice when the what (the Product Backlog Items) is very unclear and need to be refined and redefined within the Sprint based on feedback gained during the Sprint. Teams doing Lean Startup with Scrum normally end up with Eric as the Product Owner. (And that is the explanation for the name. The cross-functional Lean Startup team described by Eric Ries is very similar to a Scrum team with Eric as the Product Owner).

Jeff

Jeff is the less supportive Product Owner but gives the development team the greatest freedom. The development team is not only responsible for the how but also defines large parts of the what. Jeff needs a mature development team with deep domain knowledge. Typically a Jeff Product Owner comes with long Sprints (e.g. a month) because the development team needs more time within the Sprint to figure out the details of the Product Backlog Items.

Jeff is suitable when the Product Owner can’t dedicate a lot of time to the Product Owner role. An example could be a CEO or other manager who assumes the Product Owner role. But this is only successful, when the development team has enough domain knowledge and is trusted adding all the details of the Product Backlog Items in a meaningful way.

And for the name: As far as I understand the first Scrum software project done by Jeff Sutherland at Easel incorporated a Jeff as Product Owner.

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.