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.

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.

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:

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.

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.

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.

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.

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.

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.

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

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.

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

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.

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

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.

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

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.

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.

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:

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?

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

• Agile Manifesto: http://agilemanifesto.org/

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.

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

Fair enough!

But: Sometimes we gather new insights when we make the probem worse. What would one do if we had to replace the programming language (e.g. migrating a COBOL system to Java)? You wouldn’t just install the Java compiler and try to compile the COBOL source files, would you?

You would rewrite the whole system step by step having potentially shippable code all the time. When this approach works for replacing the programming language it should work for an easier problem like replacing infrastructure as well. And it does.

Rewrite the system on the new platform/infrastructure feature by feature. Of course you make heavy use of copy&paste to reuse the existing code.

Is it worth it?
At first sight the incremental approach needs higher efforts. There has to be something on the plus side to make the approach attractive:

• Bugs are easier to fix: When you make a mistake during the big bang migration you will not recognize it until you have finished the whole migration. But then you introduced the error weeks or months ago and it will take you a really long time to figure out how to fix the bug. Using the incremental approach shortens the time from producing the bugs to detecting and fixing the bugs. That makes it much easier to fix the bugs and therefore reduces the effort.
• Remaining time is easier to estimate: When you proceed feature by feature you can compute an average velocity and create a rough forecast when all features are done.
• Release early: With proper prioritization you can deliver the migrated system to some customers long before all features are migrated. (You could start with the features for the customer who needs the smallest feature set). These early customers would give feedback about the system in production and so lower the risk of the whole migration.

Forcing Hard Decisions

A Sprint in Scrum is timeboxed. Every Sprint has the same length and it ends when the time has come – no matter how much we completed. Jim Highsmith wrote on Twitter about timeboxes: “I’ve always said timeboxes weren’t about time, but about forcing hard decisions.” I think this is an important statement since it questions what a lot of Scrum teams do: Plan what to do during the Sprint and get the approval for that in the Sprint Review. When we look at the Sprint through Jims Eyes we get something different. First we have to think about the “hard decisions” we want to force. There are definitely several options. In my point of view there are two very important questions nowadays, that are related to each other:

1. Did we validate or invalidate our assumptions?
2. Did we produce value for customers and users?

The Sprint timebox forces us to decide how to proceed based on the feedback we got. Should we pivot or persevere? Should we stay with the current Product Backlog or adapt it?

Without timeboxes it is – of course – still possible to force these hard decisions. But most of us like to avoid hard decisions and tend to postpone and postpone and …

Creating Rythm and Flow

Tobias Mayer wrote on Twitter: “Reading anti-timebox tweets. It’s amusing how much disgust is aimed at a unit of time. Units of time create rhythm. Rhythm creates flow.” He added a blog post called “Timebox != Commitment” where he explains his perspective on timeboxes. It is NOT:

1. Set a timebox size
2. Commit to a bunch of work
3. Realize you are failing to complete it all
4. Rush to finish
5. Produce crappy work
6. Be exhausted
7. Go to #2—repeat until dead, or company goes out of business

But it is:

1. Set a timebox size
2. Engage in dialog with requester/s. Review requests, prioritize
3. Select a request, small enough to fit inside the timebox
4. Complete the work to the satisfaction of the requester
5. Breathe [reassess remaining requests if necessary]
6. Go to #3—until there is no request that can fit in the remaining time.
7. Stop work [if time remaining, take Slack time]
8. Reflect. Learn from mistakes, and adapt accordingly
9. Go to #2—repeat until all requests met, or deadline arrived at.

This perspective is supported by the latest modifications to the Scrum-Guide published by Ken Schwaber and Jeff Sutherland: The development does not commit to the Sprint Backlog but does a forecast (like a weather forecast) about what might be achieved.

Other options

Scrum-like Sprints are one possible implementation of timeboxes. I know of at least two other possible implementations. Here are the three options I am aware of:

1. In Scrum we batch together a set of features during the Sprint Planning and use this feature set for the Sprint Review.
2. In Kanban planning and release/review cadences are often decoupled. Review cadences can still be used in a timeboxed way (in the sense of Jim Highsmith to force hard decisions). In this case we batch together some features for review but not for planning.
3. Eric Ries suggests to have a kind of deadline per feature in his book “The Lean Startup“.

In the end it is just the question of when and what to batch together and that is a question of transaction/coordination costs. Batching features together for a review is an easy-to-implement solution when we want to get face-2-face feedback from customers and users. When we have a lot of active users and work a lot with Lean Startup-like cohort metrics and the like we may not need to batch together features for review. Batching features together for planning is an easy solution when the “feature requesters” are not continuously available. When the “feature requester” is available all the time (e.g. because the Product Owner role is shared across the team) it may not be the best solution.

• Before the start of the StartupMach we only had decided on the problem to solve (online discussions) and the technology we would use (Rails). So we invested the first day for some conceptual work.
• At the second day we started the development of the first ideas. We had the first product (Duscuss2Decide) live at day 3 and the second (Discumeter) at day 5. After that we had more than 15 releases per day. The rule was simply: whatever you commit into the master (aka Trunk/Head) will go live immediately.
• Typically we started the day with an informal wrap up of the product usage (a kind of review if you want). Then we discussed what to do during the day (kind of planning). And then we did it. For both “meetings” together we invested 30 to 90 minutes.
• During the day we had 2 to 4 sync meetings to check where were and how to proceed (kind of Daily Scrum).
• We did no Task Breakdown but Story Splitting on a very tiny level. We worked with MMFs (Minimal Marketable Features) that we broke down into User Stories. Most stories were done in less than 2 hours.
• We managed work in progress by gut feeling. Normally we all would work on the stories of one MMF (single piece flow). That way a MMF normally needed one day to complete.
• We did Pair Programming in most cases and often switched pairs at the sync meetings.
• We had two retrospectives. One in the middle of march, one at the end of march.
• There were no roles. No Product Owner, no ScrumMaster, no Testers etc. Just team members. During our second retrospective we had a discussion about the roles. The conclusion was that we sometimes would have profited from a ScrumMaster for facilitating discussions and forcing us to face uncomfortable facts. And we thought that the absence of a Product Owner person was helpful. The team was not only empowered to decide on how to do the work but also on what to work on.

It was a great time. We had a lot of fun, we learned a lot and it felt very productive. Although we didn’t acquire millions of venture capital for our products, Discuss2Decide seems to have value for users. There are some regular users of the tool and most online discussions at it-agile are done with the tool today.

Will it travel?
Will the “process” travel to other contexts? I don’t know. I think there were two special ingredients that are uncommon and may have been crucial:

1. With the seven team members we had roughly 45 years of experience with Agile of different flavors in the room: Scrum, XP, Kanban, FDD.
2. All team members shared a common cultural background (it-agile) that showed up as an extreme openness for other’s ideas, perspectives and needs.

Read more about the Startup March.

• Das Skript mit Fotos aus dem Theaterstück gibt es als PDF.
• Ein kurzer Ausschnitt aus dem Theaterstück als Video findet sich hier. 
• Ein kurzes Interview zu dem Thema mit Arne und mir gibt es hier.

References

• Tobias Mayer discussed the cultural aspects of projects vs. teams: Team Culture, Project Culture.
• Karl Scotland suggested to favor teams over projects in Kanban, too: Linking Flow, Value and Capability.
• Jurgen Appelo says it is short-sighted to organize cross-functional teams around projects: “Teams” (The Same Mistake All Over)
  

“Don’t!”

“What?”

“Ok, you are used to say people what to do. But Scrum is about not saying people what to do. You should not start the journey to self-organisation with command&control as the first step.”

“So I am not allowed to do anything? I just have to sit here and hope that something changes for the better? You are kidding!”

“Of course you can do something. To make change happen you have to do something. But focus on the goal not on a specific approach like Scrum, XP or Kanban. So what is your primary goal?”

“I want shorter time to market and better products.”

“Fine. You could tell the team that you want to see running software demonstrated to happy customers every 14 days. And you leave it to the team how it achieves this goal. You should offer your help when impediments occur and you could offer to hire a coach. But the most important thing is: don’t interfere with the work the team is doing. Focus on their achievements.”

Me and my collegues will write and talk about our experiences with Lean Startup, customer development, agile to the extrem, continuous deployment (we had about 15 live deployments per day) and more. I will collect all these ressources at this page.

Here is, what we have by now:

• Even before we started Henning wrote about the idea of the StartupMarch: “Lean Startup March: Ich bin dabei” (german)
• Henning blogged about his impressions about only 3 days: “Lean Startup March: discuss2decide.com – 1. Auslieferung an Tag 3” (german)
• Henning wrote about Lean Startup and the sometimes limited value of numbers: “Lean Startup March: Zahlen, bitte!” (german)
• Henning created a short video with some impressions of our team. (german)
• Markus interviewed the participants before, during and after the Startup March. (german)
• Manual wrote about some of our experiences and lessons learned: “The it-agile Startup March: Lessons learned” (english)
• Doreen blogged about incremental UI design and incremental UX: “Inkrementelle Designentwicklung” (german)
• I talked about Lean Startup and our experiences at the JAX conference 2012 in Mainz. The german slides are on slideshare.
• I wrote a blog post about the “process” we used: Lawless Agile
• Manuel blogged about all the errors we made when we tried to work with metrics: Metrics are useless on day one of a startup

In letzter Zeit gibt es vermehrt Diskussionen darum, wie eine agile Organisation aussehen müsste. Radical Management, Management 3.0, STOOS etc. sind die aktuellen Schlagworte. Eine sehr frühe und sehr weitreichende Implementation dieser Ideen findet sich beim basilianischen Unternehmen SemCo. Der Besitzer Ricardo Semler beschreibt in “Maverick”, die SemCo-Geschichte. Und auch wenn das Buch bereits 1993 geschrieben wurde, hat es an Aktualität bis heute nichts verloren. Ich empfehle das Buch allen, die sich für agile / empowerte / menschenfreundliche / moderne / scrummige / schlanke Organisationsstrukturen und Führungsstile interessieren.

In dem Artikel beschäftigen wir uns mit der Frage, was überhaupt Qualität ist und stellen die klassische Qualitätsdefinition (“Qualität ist die Übereinstimmung der Realisierung mit den Anforderungen.”) in Frage. Wir stellen die kundenorientierte Qualitätsdefinition (“Der Kunde definiert, was Qualität ist.”) dagegen und bringen diese mit agilen Verfahren wie Scrum und Kanban in Zusammenhang. Nicht zuletzt zeigen wir auf, wie die kundenorientierte Qualitätsdefinition in der Softwareentwicklung besondere Herausforderungen an die interne Qualität des Systems stellt.

Auf der JAX-Konferenz werden wir übrigens zum gleichen Thema zu sehen sein, allerdings in einem etwas ungewöhnlicherem Format (Schauspiel).

We founded it-agile seven years ago. This is a good reason to reflect on what we have achieved regarding management and organization within it-agile. Some of the things listed below were already in place seven years ago, others are just a few days old.
We believe that our employees are it-agile with the implication that the best employees would make the best it-agile. And we do not just aim for satisfied customers, we want to delight our customers. To express these believes we have a defined purpose:

“Create fulfilling jobs for our employees to delight customers.”

We achieve this purpose by:

• Transparency and openness: Nearly every information is visible for every employee including the wages, travel expenses and time sheets of every colleague (the CEOs are just colleagues also). On a company level the economic data etc. are accessible for everyone.
• Peer groups: Employees have self selected peer groups that work with the employee on personal improvements and suggest promotions.
• Pull principle: We have implemented the pull principle for coaching and development. Customer requests are visible for the whole company and employees pull these. So employees may choose to prefer jobs in their local area and decide on themselves if they are capable of doing the job.
• Meetings at it-agile are optional. Every employee decides for himself if he attends.
• As long as the results are achieved everybody can work when and where he wants. (Of course this has to be coordinated with colleagues and customers since most of the results can’t be achieved without colleagues and customers.)
• Every employee has 30 days of slack were he can do whatever he wants: go to conferences, work on a self selected project, read books, go to trainings, … Of course it is transparent within it-agile what everybody did.
• Employees don’t apply for holidays. They decide on themselves when they take their 30 days of holiday.
• Overtime: There is no pressure for working overtimes. Sometimes employees decide themselves to work overtime to achieve important results. The overtime is collected in a work hour account. Employees decide when to withdraw time from that account.
• Expenses: Employees decide how they travel and what equipment they need for their work. They don’t ask for permission. They just buy what they need.
• Profit sharing: About 2/3 of the company profits are distributed to the employees (in principle every employee gets the same percentage).
• Company ownership: About 2/3 of the company is owned by the employees. This implies ultimate empowerment: The employees can change ANYTHING. They could even fire the CEOs or change the purpose of the company completely.

Is it successful?

We have more employees, we have higher revenues and we have higher margins today than we had in the beginning. You never can be sure if the described principles created this growth or if it just was good luck. But I think we were and are successful.

Will it travel?
In general the described concepts shouldn’t be taken as a blueprint for another organization (although there are similarities with other companies like SemCo). I think we wouldn’t have been able to start with out current state even if we had known it. I think that we observed a kind of co-evolution during the last seven years. We made a small modification to the organization of the company. That enabled a small progress of company culture. This progress in company culture then enabled the next small modification of our company structure and rules. And so on…

Will it scale?
We started it-agile with 10 people. Now we are 35. In my point of view the things we did enhanced empowerment and autonomy which are important building blocks for our growth. The changes we made enabled growth. I think for further growth we have to intensify empowerment and autonomy even more.

The Future
Since there is no big boss at it-agile you never know what will happen next. There are some very interesting and challenging discussions in the moment.

BTW 1: We are hiring agile coaches and developers. (Notice; Sometimes people seem to think they wouldn’t match our expectations and therefore don’t apply for a job at it-agile. There is only one way to find out: Let’s talk!)
BTW 2: We offer consulting to managers who want to transform their company/business unit in an agile way towards more empowerment and autonomy.

References

• Christian wrote about his first impressions at it-agile (in german), especially the transparency.
• Bernd did a presentation about some of our changes at the Lean Kanban Central Europe Conference 2011.
• Henning and Jens presented some aspects of it-agile (in german) at the XP-Days Germany 2011.
• Jens wrote about self-organization at it-agile (in german) in his blog.
• Markus wrote about mentoring and peergroups at it-agile in his blog.
• Bernd wrote about the it-agile slack model in his blog.

Die Folien für beide Vorträge finden sich inkl. Foliennotizen auf Slideshare:

• Folien zum regulären Vortrag
• Folien zum Pecha Kucha
• Video des Pecha Kucha

Inhaltlich geht es darum, dass meiner Meinung nach viele Produkte / Systeme zu wenig Nutzen erbringen und wir dieses Problem nicht dadurch lösen, dass wir Anforderungen schneller umsetzen. Wir müssen es dadurch lösen, dass wir wertvolle Features entwickeln, auch wenn wir dadurch etwas langsamer werden.

One of my clients (serving several customers with custom made solutions) decided to introduce Scrum. They grouped people together that worked in the same projects or for the same customers. The result were three Scrum Teams. The next step was challenging. Who should be the ScrumMasters and who should be the Product Owners? Should there be full time ScrumMasters or would it be a better fit if the ScrumMasters were also developers? Who could be a Product Owner? In one team there were several options. Would one candidate be pissed off if the management chose the other guy? In another team there seemed to be no perfect match. Should the second Product Owner candidate of the one team be transferred to the other team although this would mean loosing his experiences with his existing customers?

I introduced the idea that self organization is a powerful tool to solve challenging problem. Here we were: We had Scrum Teams that could self organize and we had a challenging problem (filling the Scrum roles). So it was decided to let the Scrum Teams decide who would be ScrumMaster and Product Owner. This was done in a workshop with all teams. The result was to some extend surprising to the management but they stuck to their commitment to let the teams decide.
I don’t know how good the selected ScrumMasters and Product Owners will manage their jobs. Independent of their future performance I think there are several interesting aspects in this story:

• The teams selected ScrumMasters and Product Owners in an hour or so. When management tried to select the roles it took much longer and provided no result.
• The Product Owners and ScrumMasters were selected by the teams and not assigned by management. I think that will help development team, ScrumMaster and Product Owner to act as ONE team without some kind of boss.
• If problems with the ScrumMasters and Product Owners would occur it should feel naturally for the Scrum Teams to select new persons for the roles.
• The management demonstrated trust into the employees and empowered the teams.

When I mentioned the self selection on Twitter there was doubt that the approach would be suitable for the Product Owner role. I can understand the doubts but like to think along these lines (assuming that there are sufficient Product Owner skills in the Scrum Team):

• If the Scrum Teams selects the person who would be selected by the management anyway, the management demonstrated at least trust into the team.
• If the Scrum Team selects another person, things really become interesting and there is great opportunity to learn something. Why does the team have another opinion than the management? Which opinion is more relevant to the success of the team? Is there a need and the possibility to reach consensus between team and management?

P.S.: I think it is totally valid for the management to assign the Product Owner. But is that really the best option – especially for a mature agile organization?

Aikido master Endō Seishirō shihan stated: “It is known that, when we learn or train in something, we pass through the stages of shu, ha, and ri. These stages are explained as follows. In shu, we repeat the forms and discipline ourselves so that our bodies absorb the forms that our forebearers created. We remain faithful to the forms with no deviation. Next, in the stage of ha, once we have disciplined ourselves to acquire the forms and movements, we make innovations. In this process the forms may be broken and discarded. Finally, in ri, we completely depart from the forms, open the door to creative technique, and arrive in a place where we act in accordance with what our heart/mind desires, unhindered while not overstepping laws.” (from [1])

Shu-Ha-Ri in Scrum

These learning stages can be applied to Scrum, too. A team starts with Shu. It practices Scrum by the book: the flow with the roles, the meetings/ceremonies and the artifacts. Premature adaptations to Scrum in the Shu stage often lead to the famous ScrumBut situations (see [2], [3]). A team enters the Ha stage only after it has shown its ability to use Scrum as it was intended and has achieved a deep understanding of the spririt of Scrum. Then it may (and I think it should) adapt Scrum on their understanding of the spirit of Scrum. After a team has been in Ha state for a probably long period of time it may enter Ri and dismiss all rules.

From Shu to Ha

Two interesting (and interrelated) questions arise here:

1. How do you know that you have practiced enough in Shu state and you may enter Ha state?
2. What are typical adaptations for Scrum in Ha state?

From Ha to Ri

References

1. Wikipedia article about Shu Ha Ri: http://en.wikipedia.org/wiki/Shuhari
2. My presentation about ScrumBut and Shu-Ha-Ri (in german): http://www.slideshare.net/roock/scrum-but-agil-aber-xpdays-germany-2010
3. ScrumBut from Ken Schwaber: http://www.scrum.org/scrumbut
4. Agile Manifesto: http://agilemanifesto.org

Eine Besonderheit sind dabei die extrem kurzen Zyklen, die man anstrebt. Wir haben erst vor wenigen Tagen an einem halben Tag eine Customer-Problem-Solution-Hypothese definiert und ein MVP entwickelt.

Offensichtlich ist dieser Ansatz nicht nur dann sinnvoll, wenn man ein Startup gründet. Passend dazu definiert Eric Ries Startup als Produktentwicklung unter großer Unsicherheit. Das Buch adressiert als das Startup in der Garage genauso wie eine Produktneuentwicklung in einem Konzern.

Ich finde, das Buch ist sehr gut geschrieben und es stellt einen wichtigen Meilenstein in der Entwicklung unserer Branche dar. Allerdings fokussiert das Buch darauf, den Leser vom grundsätzlichen Ansatz zu überzeugen. Es bleibt manchmal etwas schwammig, was man konkret machen soll/kann. Außerdem handeln die meisten Beispiele von Internet-Anwendungen. Für andere Produkttypen ist etwas mehr Transferleistung notwendig. Bestimmt kommt demnächst ein Nachfolgebuch “Implementing the Lean Startup” heraus, in dem konkret beschrieben wird, wie man es denn nun macht. Trotzdem ist auch dieses Buch absolut empfehlenswert.

For those who don’t know the G Forces presentation: it is all about shortening release cycles from months to weeks to days to hours to minutes.

What became clear to me: The release cadence is not the real point. It is all about feedback. You have to be able to incorporate feedback according to your release cadence. Releasing every day doesn’t help too much if you need a month to collect feedback and react on it.

Perhaps we should reflect that with our metrics. What about Feedback Cycle Time and Feedback Coefficient as new metrics for teams?

Feedback Cycle Time would be the time you need from the release of feature A until you are able to release feature B that incorporates the learnings from feature A? For example: You release feature A to production on 1st of february 2012. Then you collect data from the production usage of B for 1 week. You discuss the findings for one week and take another week to redefine some of the features in the backlog. And then you need 3 weeks for implementation, test and release of feature B that incorporates the learning. In this scenario your Feedback Cycle Time would be 6 weeks.

The Feedback Coefficient would be Number of Features for which feedback was collected / Number of Released Features. For the Feedback Coefficient it doesn’t matter if the feedback was positive or not. The only important thing is the learning. When we are honest most teams today achieve a Feedback Coefficient of zero or very near to zero. The optimum would be 1.

I think both metrics would focus on a weak spot in many teams: The teams try to maximize throughput and minimize lead time but don’t really care about feedback from the market.

Dear Thought Leader,

I really appreciate what you did for our community and the progress of our industry in general.

But sometimes I am puzzled. That happens when you bash an idea or even worse a person. The ideas you had and the concepts you developed are great enough to stand for themselves. You don’t have to bash other ideas/persons to make your concepts look brighter.

Here are some examples that might highlight what I am talking about:

“X clearly didn’t understand what Y means.” How do you know? Did you do an in-person test with X to check his understanding of Y? How does it feel for X when you say that? What will be his reaction? Will he check his understanding or is it more likely that X just defends himself?

“In his blog entry X addresses Y but sadly stops at Z and didn’t thought of A.” How do you know that X didn’t thought of A? Perhaps he did and decided to leave it out to keep the article short?

“Y is a stupid idea. It would lead to (unwanted) Z.” At least when people are involved how do you know that Y would lead to Z every time in every situation, especially when you tried Y never or only a few times? Do you think the advocate of Y is lying when he says that Y worked at his place?

I don’t suggest stopping arguing! Arguing is possible without devaluing other ideas/persons.

One could say “X wrote a nice blog post about Y. I’d like to add some thoughts on Z.” or “X presented Y in a way that puzzled me. I would rather think that …” or “Y didn’t work when I tried it. Therefore I tried something different that I’d like to present.” or even “Y simply does not resonate with me. Therefore I used Z.”

If you defined something very clear and X presented it just plain wrong you could just call or email X and make the correction. Don’t spend your previous keynote time correcting one person. There are hundreds in the audience who want to learn something from you.

My wish for the future is that we all learn to become better at arguing without bashing and devaluing.

Yours respectfully,

Stefan Roock

P.S.: I am am sure that I bashed other peoples/ideas as well but that doesn’t make it any better.

Other teams start with Kanban, eliminate columns of their Kanban board, reduce WiP and increase teamwork.

The results are very similar: There is a short backlog of things that create customer value (sometimes called Minimal Marketable Features, MMFs). The team picks the item with the highest priority and splits it into smaller User Storys or Tasks. When an MMF is completed it will be delivered. That’s it. The would result in a 3 column board: ToDo, Doing, Done. This board design is similar to a Scrum taskboard but the “process” is different. Since there are no iterations there is no distinction between a product focused backlog and an iteration focused backlog.

The interesting thing here is that this is mainly what Arlo Belshee named “Naked Planning”. He did that already in 2007 (perhaps even earlier) but only few people recognized it! Nowadays Naked Planning is sometimes reframed to be simplified or small Kanban.

Perhaps both of the above teams should say they are doing Naked Planning (or trying to do) and try to improve even further by having a deeper look at Arlos work (like doing Single Piece Flow for MMFs and limiting the number of MMFs in ToDo zu seven).

As far es I know this video is Arlos first description of Naked Planning (2007): http://www.youtube.com/watch?v=6t4bZtnnQJA

“I love to code, but I have to coach.”

Viele Anwesende stimmten durch Gemurmel oder eindeutige Gesichtsausdrücke zu. Es findet sich hier ein durchaus gängiges Muster. Ein sehr guter Entwickler wird zum Coach, weil nur so höhere Gehälter zu erzielen sind. Und so landen Entwickler in Coaching-Jobs, die sie eigentlich nicht wollen.

Ich selbst habe mich auch immer – zumindest zum Teil – dazu gezählt. Ich hatte aber auch immer Spaß beim Coachen und Trainieren. Vor ein paar Jahren habe ich versucht, das für mich klar zu kriegen und dafür eine Vision für mich geschrieben. Hier einige Auszüge daraus:

Ich möchte mich in meinem beruflichen Leben kontinuierlich weiterentwickeln und wünsche mir Anerkennung meiner Arbeit und meiner Person. Dazu möchte ich in motivierten agilen Teams anspruchsvolle Software-Produkte entwickeln. Dabei spielt für mich ein großer Gestaltungsspielraum eine ebenso wichtige Rolle wie der enge Kontakt mit den Kunden/Anwendern. Meiner Meinung nach können nur im engen Kontakt zu Kunden/Anwendern Lösungen entstehen, die die Bedürfnisse der Kunden/Anwender befriedigen.

Das in den Projekten Erlernte möchte ich reflektieren und vergegenständlichen, als wichtige Elemente meiner Weiterentwicklung. Für das Vergegenständlichen funktioniert das Schreiben von Artikeln und Büchern sowie das Halten von Vorträge und Schulungen gut für mich.

Wie man sieht, stand das Programmieren im Zentrum. Alles, was sich um Coaching und Training drehte, war ein Anhängsel oder gar nicht erkennbar. Als ich die Vision aufgeschrieben habe, ist mir natürlich aufgefallen, dass diese Vision nicht wirklich zu meinem Job als Coach passte. Aber irgendwie fühlte ich mich mit dem Coaching-Job dann auch nicht so unglücklich. Tatsächlich war es sogar so, dass ich für Coachings und Trainings viel mehr Anerkennung erhalten habe als jemals zuvor für Programmierung.

Der oben zitierte Ausspruch auf der SoCraTes-Konferenz hat mich erneut an meine Vision erinnert und mein zwiegespaltenes Verhältnis zum Coaching. Ich habe das zum Anlass genommen, nochmal über meine persönliche Vision zu reflektieren. Dabei ist mir klar geworden, dass die Anerkennung nur eines meiner Bedürfnisse ist. Das andere Bedürfnis schien bereits in der originalen Vision durch: “Bedürfnisse von Anwendern befriedigen”. Tatsächlich geht mein Bedürfnis noch weiter: Ich möchte Fußspuren hinterlassen, etwas verändern, einen Impact haben. Das geht über die Entwicklung von Software. Aber wenn ich ehrlich bin, war das meistens nicht der Fall. Die meisten Systeme hatten keine nennenswerte Auswirkung. Das geht viel einfacher, wenn ich als Coach und Trainer arbeite! Tatsächlich glaube ich, dass ich durch meine Arbeit nicht nur Unternehmen wirtschaftliche Vorteile sondern nebenbei auch die Arbeitssituation vieler Entwickler verbessert habe.

Seit mir das klar geworden ist, fühle ich mich viel besser in meiner Rolle als Coach und Trainer. Trotzdem habe ich auch weiterhin Spaß am Programmieren. Nicht umsonst investiere ich viel Zeit in CodersDojo. Ich würde aber nicht mehr jedes Programmierprojekt machen wollen. Es sollte schon herausfordernd sein und in Clojure oder mindestens Ruby entwickelt werden. Und wahrscheinlich würde ich mich auf jeden Fall in die Product-Owner einmischen wollen. Wer so ein Projekt zu bieten hat, kann sich gerne bei mir melden. Solange mache ich meine Hobby-Projekte und bin als Coach und Trainer glücklich.

P.S.: Ich weiß von Beraterkollegen, dass sie nicht sehen, dass sie Anerkennung für ihre Coaching-Arbeit bekämen oder wirklich etwas verändern würden. So ging es mir am Anfang meiner Beratertätigkeit auch häufig. Mit der Zeit sind diese Situationen aber immer seltener geworden. Vielleicht muss man nur lange genug durchhalten, bis man die nötige Erfahrung hat

How it works
Single piece flow means that the whole team works at one User Story at any given point in time. Only when the whole User Story is done the team moves to the next User Story.

Why it
Single Piece Flow works due to several positive effects:

1. Single Piece Flow forces the whole team to cooperate continuously.
2. This ensures that every team member is informed about state and progress of each User Story. Furthermore the team members learn from each other through intense cooperation.
3. On this basis it is easy for team members to help each other.
4. Point 3 together with the fact that a team generally is faster in implementing a User Story leads to a shorter lead time of the User Story.
5. Shorter lead time and reduced Work-in-Progress means for the team that it has to remember only few things for a short period of time. And this fact reduces the number of bugs and decreases the time needed for bug fixing.

Really?
You may doubt what I wrote. Perhaps Single Piece Flow reduces the lead time per User Story. But does it enhance overall throughput or does it lead to under utilization of the team members and higher costs?
Maybe… Luckily it is easy to check. Just try it for one Sprint and then inspect&adapt. You are welcome to share your findings in the comments of this blog article.

I prepared some Flipcharts with the SOLID principles (Slideshare), code examples for Java, Ruby, Scala and Clojure (GitHub) and a paper with a description of the SOLID design principles and some thesis about their application to dynamic OO and functional languages (PDF).

I am not sure if the session can be counted as a success. We had three groups. One was working on the application of SOLID to dynamic OO languages with the Ruby code examples. The second group was working on the application of SOLID to statically typed functional languages with the Scala code examples. The third group worked on the application of the SOLID principles to dynamic functional languages with the Clojure examples.

The results were ambiguous and we didn’t find final answers. What became clear is that the SOLID design principles can be applied to all these types of languages. What stayed fuzzy was the question if that application would be useful for the everyday work with these languages. While I tend to think that in fact not every principle is useful in every languages there were others having the opposite opinion.

One of the problems within the workshop was that today OO thinking is baked into out heads. And so the Scala and the Clojure group created designs in OO style. And if you do that with a functional language of course SOLID is applicable and at least to a certain degree useful

In the end of the session we had a discussion in a smaller group of people if it may be to misleading to apply SOLID to functional programming. Perhaps it drives our thinking in the wrong direction. Perhaps it would be better to go back to the underlying principles of cohesion and coupling and creating new design principles for functional languages on top of these. And perhaps such design principles already exist and I am just to blind to see them.

So: There is still a lot to learn and a lot of experiments to do. If you like to contribute I would really much appreciate it.

But I prefer a simpler mechanism and just adding impediments to the existing Task Board which I have described here in a PDF.

Every team member answers two questions:

1. What did I achieve since the last Daily Scrum? (and update the taskboard)
2. What are my impediments? (and make impediments visible at the taskboard)

Then the team updates the Sprint Burndown Chart (yes, let the team draw it on a big sheet of paper).
Now the team sees the current state of the Sprint at the taskboard and the prognosis at the Sprint Burndown Chart.
Then ask the third question in a slightly modified form: How can we as a team organize until the next Daily Scrum to create the most progress towards the Sprint Goal?

That will avoid stickyness to tasks (“I worked on the database schema and will work on it again”). Instead the team plans together who should work on what. Perhaps Henning should help Stefan with the database schema? Perhaps it would be better to stop working on the database schema for now and focus on another more important task?

Die Übersetzung habe ich (Stefan Roock, stefan.roock@it-agile.de) vorgenommen. Ich habe mich entschieden. an einigen Stellen leicht vom Original abzuweichen mit der Absicht, einen Sachverhalt einfacher zu erklären.

Ich denke an Scrum als etwas fast unfassbar Einfaches, das häufig unnötig verkompliziert wird. Es ist diese Verkomplizierung, die so viele Missverständnisse verursacht und zu schlechten Anwendungen von Scrum führt. Die folgende Beschreibung von Scrum hat das Ziel, Scrums Geist der Einfachheit einzufangen.

Scrum ist ein Framework, um die Art und Weise zu verbessern, in der Menschen arbeiten, oder wie auf der Scrum Alliance-Website definiert „ein team-basiertes Framework zur Entwicklung komplexer Systeme und Produkte“. Scrum benutzt einen iterativen Prozess in dem die Iterationen (aka Sprints) so kurz wie sinnvoll möglich gehalten werden. Die Sprints erzeugen einen gleichmäßigen Rhythmus der durch Planung, Durchführung und Reflektion pulsiert. Diese strikten, rhythmischen Time-Boxen von Scrum fördern auf frappierende Weise organisatorische Dysfunktionen zu Tage.

Scrum definiert drei Rollen (Scrum Master, Product Owner und Team), erfordert eine priorisierte Menge von Zielen, ein Commitment für jeden Sprint und eine einfache Art, Fortschritt zu messen. Scrum benutzt Zeremonien mit Timeboxen, um zu planen und auf täglicher sowie Sprint-Basis zu inspizieren und zu adaptieren.

Das „Was“ (das Ziel) und das „Wie“ (der Weg) werden klar unterschieden. Scrum erfordert klaren Fokus, Commitment und vollständige Transparenz auf allen Ebenen; es hebt auf bestimmte menschenzentrierte Werte ab, einschließlich (aber nicht eingeschränkt auf) Vertrauen, Integrität, Mut und Respekt.

Rollen
Der ScrumMaster ist eine dienende Führungskraft (Servant Leader) für das Team und ein Change Agent in der Organisation. Der Product Owner ist die Hauptstimme des Kunden, etabliert eine fesselnde Vision und benutzt einen Prozess kontinuierlicher Priorisierung, um die Vision umzusetzen. Das Team ist eine selbstorganisierte, cross-funktionale, bevollmächtigte Gruppe, die die Vision in das Produkt oder den Service umsetzt.

Artefakte
Ein Backlog (Auftragsbestand) aus Anforderungen oder Zielen ist immer vorhanden. Es enthält zu jeder Zeit all die Dinge, von denen wir möchten, das das Produkt oder der Service sie enthalten. Es ist eine lebendige Liste, kontinuierlich im Fluss und trotzdem jederzeit nach Priorität geordnet, die sich über die Zeit ändern wird. Die Einträge des Backlogs fokussieren auf das „Was“. Das Sprint-Commitment ist eine Untermenge des Backlogs, manchmal herunter gebrochen auf Arbeitsaufgaben (Tasks), die das „Wie“ beschreiben. Scrum fordert einfache Metriken, z.B. die verbleibende Restarbeit oder gelieferter Geschäftswert. Diese Metriken sollten verwendet werden, um die Wirklichkeit zu erfassen – nicht, um Erfolg oder Misserfolg zu festzustellen. Nur Metriken der Wirklichkeit können wir vertrauen, dass sie dem Team keinen Anreiz für Quick-Fix-Verhalten geben.

Zeremonien
Das Team und der Product Owner treffen sich vor dem Start jeden Sprints, um die Arbeit zu planen. Das Team committet sich auf priorisierte Arbeitspakete, die „wohldefinierte Ergebnisse“ (das Ziel) haben und es wird von ihm erwartet, dass es das fertige Produkt gemäß diesen Kriterien am Sprintende liefert. Wie das Team seine Arbeit erledigt (der Weg) ist allein ihm überlassen. Jeden Arbeitstag treffen sich die Teammitglieder an einem visuellen Board (z.B. Taskboard), um sich abzustimmen und Hilfe einzufordern und anzubieten. Am Ende jedes Sprints begutachten Stakeholder und Konsumenten die abgeschlossene Arbeit und machen Vorschläge für Anpassungen. Nach dem Review reflektieren die Teammitglieder über ihren Prozess, suchen nach Verbesserungsmöglichkeiten und committen sich auf Veränderungen ihrer Arbeitsweise. Jeder Sprint produziert ein verbessertes Produkt oder einen verbesserten Service und – sogar noch besser – ein glücklicheres Team.

Das ist mehr oder weniger die Beschreibung von Scrum, die seit der Veröffentlichung des ersten Scrum-Buchs 2003 existiert. Ich habe sie aus dem Software-Kontext herausgelöst, einige Begriffe fallen gelassen, um auf die grundlegenden Prinzipien zu fokussieren und versucht, sie auf ihre Essenz zu kondensieren. Ich habe nichts hinzugefügt oder weggelassen.

While I think that Envisioning is often necessary I am often shocked when I see what companies do during “Envisioning”:

• The Envisioning lasts weeks or months when hours or days would have been sufficient.
• Comprehensive fine grained product backlogs are created.
• Detailed designs are created.
• etc.

That is not Envisioning. That are the early phases of a waterfall project. Therefore some people consider the Envisioning an anti pattern in Scrum.

Before I join these people I want to try to explain better what Envisioning should be and what not.

During Envisioning I value

• learning important things over designing things
• having business and technical people in the Envisioning team over having only the Product Owner doing the Envisioning
• Product Owner and Team listening to and working together with real customers and users over giving research orders to marketing
• checking assumptions about the market, customers, users over dealing with corporate stage gate processes
• checking technical assumptions with prototypes over having long design discussions within the team
• sketching things on flip charts over creating power point slides
  

At it-agile we created a Scrum team to restructure some aspects of our software development unit. For the first Sprint the Sprint Goal made it necessary to interview customers. So far so good.

But when I was at the site of a coaching client with potential interview partners it wasn’t that easy. I had a full email inbox and it was hard to get in touch with the potential interview partners. It would have been much more comfortable to postpone the interviews. And if I hadn’t committed to the Sprint Goal I would have postponed the interviews. But the commitment made me focus on what really mattered and it pulled me out of my comfort zone and do the interviews. And in the end it was the right thing to do. Learning something about customers was much more valuable than reading emails.

In this story my commitment to the Sprint Goal made me leave my comfort zone.

This is just one of the possible positive aspects of the commitment concept done right. Others include building trust, having an additional feedback mechanism, create focus etc.

Ein Buch, in dem ein windsurfender Scrum-Coach aus Norddeutschland mit Namen Stefan vorkommt, muss einfach ein großartiges Buch sein Die “Kraft von Scrum” ist demnach großartig. Das Buch ist eine Scrum-Einführung nicht nur für Manager, verpackt in romanartige Geschichte, in der besagter Scrum-Coach Stefan einem angeschlagenen Software-Unternehmen durch die Einführung von Scrum den Weg aus der Krise weist.

In der Geschichte werden alle Elemente von Scrum am praktischen Beispiel eingeführt, so dass der Leser einen guten Eindruck davon gewinnt, was Scrum ist. Die Geschichte drumherum hat trotz windsurfendem Scrum-Coach keinen großen Inhalt. Sie ist halt Mittel zu dem Zweck, Scrum zu erklären und dafür ist sie vollkommen in Ordnung.

Das kleinformatige 150-seitige Buch lässt sich schnell durchlesen. An der im Vorwort genannten Lesezeit von 2-3 Stunden bin ich aber kläglich gescheitert. Naja, vielleicht habe ich einfach noch nicht die Qualitäten, um Manager zu werden…

Obwohl Scrum für mich nichts Neues mehr ist, hatte ich dennoch Spaß an der Lektüre und empfehle das Buch gerne weiter. Vielleicht ist es ja das passende Geschenk für den eigenen Chef? Für meinen Chef allerdings nicht; er hat das Buch schließlich ins Deutsche übersetzt und die Lokalisierung vorgenommen. In diesem Zuge wurde aus dem Scrum-Coach auch der windsurfende Stefan, warum auch immer

Direkt bei Amazon kaufen: “Die Kraft von Scrum: Inspiration zur revolutionärsten Projektmanagement-Methode”

But why work physical tools better than software tools?

Software tools are used with another focus than physical tools. Software tools are used for managing (e.g. for managing the Sprint Backlog). Physical tools facilitate communication and cooperation. When somebody moves an index card at a card wall, the other team members can see that directly and step into a discussion. When somebody changes the status of a ticket in an issue tracker nobody notices immediately and starting a discussion is unlikely.

And facilitating communication is more important than easy management?

This question is easy to answer with a look at the agile manifesto: The first value statement of the agile manifesto reads “Individuals and interactions over processes and tools”. And principle number six says: “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”

Yes, communication and cooperation is king.

So whatever tool is used communication and cooperation should be the goal, not management. And I think that this goal is easier to achieve with physical tools than with software tools. But in the end the decision is up to the team.

Things to try

• The team should at least try physical tools for one Sprint to make an informed decision.
• As ScrumMaster shield the team from existing tools and do the mapping from the physical tool to the software tool during the trial period.

Im Mai wird das Buch “Agile Entwicklungspraktiken mit Scrum” im dpunkt-Verlag erscheinen. Roman Pichler und ich sind die Herausgeber. Wir wollten ein deutschsprachiges Buch herausgeben, in dem die in Scrum gängigen Entwicklungspraktiken nach dem aktuellen Stand der Technik beschrieben sind. Dazu haben wir namhafte Coaches angesprochen und sie gebeten, jeweils ein Kapitel beizusteuern. Wir selbst haben ebenfalls das eine oder andere Kapitel beigesteuert und versucht, für einen einheitlichen Stil des Buches zu sorgen, so dass sich eine möglichst durchgängige Leseerfahrung ergibt. Ich hoffe, das ist uns gelungen

Die Autorenliste umfasst Alex Bepple, Jens Coldewey, Jutta Eckstein, Peter Friese, Andreas Havenstein, Johannes Link, Martin Lippert, Bernd Schiffer und Henning Wolf. Die Themen des Buches umfassen die Architekturvision und den inkrementellen Entwurf, Continuous Integration, Testgetriebene Entwicklung, Refactoring mit und ohne Refactoring-Browser, automatisierte Akzeptanztests, Pair Programming, Collective Ownership, Coding-Dojos und Code-Katas, Modellgetriebene Entwicklung und Entwicklungspraktiken bei verteilter Entwicklung.

Es ist seit langem bekannt, dass in größeren Scrum-Projekten kein Weg daran vorbei geht, dass das Team passende Entwicklungspraktiken auswählt. Die Entscheidung, welche Techniken eingesetzt werden, obliegt in Scrum dem Team. Aus unserer Sicht sollte das Team aber die in Frage kommenden Techniken kennen und beherrschen, um eine qualifizierte Entscheidung treffen zu können. Wir hoffen, das unser Buch einen Beitrag dazu leistet.

Wer sich bereits intensiv mit eXtreme Programming auseinandergesetzt hat, dem wird vieles bekannt vorkommen. Wir hoffen, aber auch diesen Lesern einen Mehrwert bieten zu können, indem das Buch den aktuellen Stand der Technik beschreibt.

“Agile Entwicklungspraktiken mit Scrum” bei Amazon bestellen!

Bedürfnisse und Features auseinander zu halten fällt vielen Product Ownern sehr schwer. Heraus kommen dann Formulierungen, in denen Bedürfnisse und Key-Features identisch sind – nur leicht anders formuliert. Beispiel: “Menschen, die andere Menschen anrufen wollen, können mit dem Festnetz-Telefon Call-2000 über das Festnetz telefonieren.”

Wenn man vor der Frage steht, ob etwas wirklich ein Bedürfnis ist, hilft die Maslowsche Bedürfnispyramide. Sie hat diese Stufen (von unten nach oben):

1. Physiologische Bedürfnisse: Atmung, Schlaf, Nahrung, Wärme, Gesundheit, Wohnraum, Kleidung, Sexualität, Bewegung
2. Sicherheit: Recht und Ordnung, Schutz vor Gefahren, festes Einkommen, Absicherung, Unterkunft
3. Soziale Bedürfnisse: Familie, Freundeskreis, Partnerschaft, Liebe, Intimität, Kommunikation
4. Anerkennungsbedürfnisse: Höhere Wertschätzung durch Status, Respekt, Anerkennung (Auszeichnungen, Lob), Wohlstand, Geld, Einfluss, private und berufliche Erfolge, mentale und körperliche Stärke
5. Selbstverwirklichung: Individualität, Talententfaltung, Perfektion, Erleuchtung, Selbstverbesserung

Jetzt müssen wir uns lediglich die Frage stellen, auf welche Stufe unser “Bedürfnis” fällt. Wo würde man das vermeintliche Bedürfnis “telefonieren” verorten? Genau! Es passt da nicht rein. Man kann telefonieren, um in Kontakt mit seiner Familie oder seinen Freunden zu bleiben. Dann wäre genau das das Bedürfnis und wir könnten z.B. schreiben: “Menschen, die im sozialen Kontakt mit ihrer Familie bleiben wollen, können mit dem Festnetz-Telefon Call-2000 über das Festnetz telefonieren.”

• Upfront Architekturvision vs. inkrementeller Entwurf während der Sprints
• die Rolle des Architekten in Scrum
• Einsatz von Tools zur Architekturüberwachung in Scrum

Das Interview gibt es in einer Kurzfassung (siehe http://vimeo.com/19394558, 42 Minuten) und vollständig (siehe http://vimeo.com/19389234, 53 Minuten).

Red Pencil Code Kata