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.

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.

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

Scrum is none of these. Scrum is just to unspecific to be a process, 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 process / 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.

 

Shades of Scrum: Waterfall, Pipelining and Sprints

Waterfall and Scrum

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

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.

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.

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 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.

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.

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: Product Owners and a Product Owner Shaped Object
• Definition of Ready: a double edged sword