Springe zum Inhalt

Product Owners employ User Stories as product backlog items. User Stories represent requirements and are detailed during the course of the project. Large User Stories are called Epics. Epics are coarse grained User Stories and are usually decomposed during the project and detailed further on. And then there are Themes ...

Often Themes are not used properly by some teams. I have seen that a Theme is either a more fine grained concept than an Epic or a more coarse grained concept and contains multiple Epics. It may not be wrong to use the concept of a Theme this way, because neither an Epic nor a Theme is clearly defined. But this confuses the team members and it is not helping us to adopt agile planning.

Clarifying the three different concepts before you work with them will help:

  • A User Story represents a requirement and is small enough to be implemented by a team within one Sprint.
  • An Epic is a larger User Story and represents a requirement as well, but it is too large to be implemented in one Sprint.
  • A Theme is a set of User Stories or Epics. A Theme can reference multiple User Stories from even different Epics.

But for what are we using the concepts?

A User Story is a requirement that is digested by the team within one Sprint. A lot have been written about how to use user stories. Some teams avoid the concept of Epic and simply call them large User Story - fair enough. But it makes sense to call a large User Story an Epic, because the sizing of a User Story is an imported information. Having Epics in the Product Backlog indicates that the items have to be split. If in the Backlog Grooming meeting the team labels the backlog items as Epics, which means they cannot be estimated. Separating the large and small user stories with different terms, forces the team and Product Owner to make the backlog items smaller, which is a decent goal.

But Themes? Why do I need the concept of a Theme? The answer is: For roadmap and release planning.

Usually customers and users want to have many many features. It's not agile and not helpful for the customer to convert all their wishes into fine grained User Stories, so they can be implemented by a team. It's better to narrow down the desired scope and to get closer to the best business value for available team capacity with agile planning techniques.

Agile planning has many different levels. The highest level is the product vision, that describes the actual business goal of a project or product. The next level is the release roadmap. In this roadmap the product owner and the team agree on a series of releases with a rough scope - the Themes. Releases have Themes that describe the scope of the release. Within a release we usually want to build and deliver a Minimum Viable Product (or Minimal Marketable Feature). That's a single or set of features that bring value to the customer.  In the roadmap planning we want to find out which Epics and User Stories are a minimal necessary valuable set of functionality. Since Themes are a set of User Stories they can help us to find and describe the MVP.

How can I identify Themes?

Seit einiger Zeit beschäftigte ich mich mit Design Thinking. Diese Methode hat eigentlich nichts mit Software-Entwicklung zu tun. Sie soll dazu dienen, innovative Ideen hervorzubringen. Agile Methoden verfolgen in erster Linie das Ziel, auf Veränderungen der Anforderungen zu reagieren. Aber wie kommt der Anwender oder Kunde überhaupt auf die richtigen Anforderungen?

Was ist Design Thinking?

Diese Methode basiert auf eine Reihe von Werten und Prinzipien, die jedoch nicht so gut niedergeschrieben sind, wie die Werte und Prinzipien im Agilen Manifest. Die beiden Wertesysteme sind aber sehr ähnlich und daher kompatibel. Zusammengefasst ist bei Design Thinking folgendes wichtig:

  • Gutes Design ist nicht das Ergebnis eines einzelnen, sondern eines interdisziplinären Teams.
  • Teams arbeiten iterativ in festen Zeitrahmen (Timebox).
  • Jeder wird zum Experimentieren ermutigt.
  • Fehler werden als Anlass zum Lernen angesehen.
  • Teams involvieren echte Benutzer in ihre Arbeit.
  • Jeder lässt sich inspirieren von anderen Ideen, Prototypen und Lösungen.
  • Empathie ist notwendig, um die Bedürfnisse der Benutzer zu ergründen.

Ein wichtiger Aspekt vom Design Thinking ist das interdisziplinäre Team, also ein Team, was sich in einer Firma aus verschiedenen Bereichen rekrutieren würde. Zu einem solchen Team könnten z.B. Techniker und Marketing-Leute gehören. Dieses Team durchläuft einen Prozess, der jedoch nicht starr und rigide ist. In den Prozess können je nach Bedarf Iterationen eingefügt werden. Ein wichtiger Bestandteil dieses Prozesses ist die Entwicklung von Prototypen, die dann an echten Benutzern getestet werden.

Konkret beschäftig sich Design Thinking nicht nur mit Werten und Prozessen, sondern auch mit Praktiken, in die in einzelnen Phasen des Prozesses angewendet werden können. Dazu gehören, z.B.:

  • Story Telling
  • Verschiedene Brainstorming Techniken
  • Prototyping

Wir bezeichnen Design Thinking auch als einen "Body of Knowledge", der von verschiedenen Seiten weiterentwickelt wird. Im letzten Jahr fand in Deutschland die erste Design Thinking Konferenz statt. Mittlerweile entwickeln sich lokale Gruppen, die sich mit Design Thinking beschäftigen. Aktuell wird gerade die Gruppe Design Thinking München gegründet.

Product Owner als Flaschenhals

In der agilen Methode Scrum ist der Product Owner verantwortlich für das Hervorbringen und Priorisieren der Anforderungen. Er legt die Anforderungen als User Stories ins Product Backlog und das Entwicklungsteam setzt diese Anforderungen um. Aber wie kommt der Product Owner zu den richtigen Ideen? Sind die Features, die er umgesetzt haben möchte, die richtigen? Da er eng mit dem Team zusammenarbeitet ist die Situation viel besser als im herkömmlichen Wasserfall. Der Product Owner kann direkt Ideen auf technische Machbarkeit mit dem Team klären. Ob diese Ideen dem Kunden bzw. Anwender der Software helfen und mehr als ein "Me Too"-Feature sind, wird mit dem agilen Vorgehen nicht angegangen.

Wedding Day by flickr:Mike_fleming

Die agile Community hat dieses Problem erkannt und schaut über den Tellerrand. Design Thinking bietet Anregungen, die Arbeit des Product Owner anders zu organisieren, sodass innovativere Produkte entstehen. Viele Konferenzen haben mittlerweile Design Thinking als Thema, so z.B. die SEACON in Hamburg oder die XP2012. Pierluigi Pugliese und ich waren bereits mit dem Vortrag "Innovation needs Waste!" auf verschiedenen Konferenzen. Ich bin gespannt, wie sich der "Body of Knowledge" Design Thinking mit dem der Agilen Softwareentwicklung verbindet. Beide Communities können von einander lernen.

I had a discussion recently with a colleague about the usefulness of the Last Responsible Moment (LRM) in the context of a complex project. The LRM is when the Cost of Delay overweights the Benefits of Delay. In other words, it's often useful to wait with a decision until a certain point - last responsible moment - before the cost of making a decision too late will be higher than the benefits. I want to come up with an example that may happen quite often in a project:

Lets assume you want to order server hardware that will host your web application. If you order it very early, you may not have enough information to buy the hardware properly sized. Later in the project you may have enough information to make the decision about the hardware sizing. But ordered too late there is a risks that the hardware will not be up and running before the release date and you will loose some expected income from your web application.

http://www.flickr.com/photos/krystalt/5286861375

We came to the conclusion that the LRM makes practically no sense. The only thing we know is that not all decisions have to be made in the beginning. The nature of complexity is that we cannot plan all details in advance. Only after a project has finished, we know exactly which decisions have been made correctly. Although there exists a LRM, we cannot find it in advance (in complex software projects). By focusing too much to find the LRM in advance, we may actually risk that some business value is not delivered.

Of cause, if we can quantify the Cost of Benefit and Delay then we can find the LRM. It may also help us to know about the LRM while we are still making decisions trusting our guts. But agile coaches should teach the whole story, so people avoid gambling for the LRM.

Ken Schwaber explained the changes to Scrum in a Keynote at the Scrum Day in Germany. One major change is the renaming of the Sprint Commitment to Sprint Forecast. Ken said that some Product Owners were yelling to the team that had just missed to Sprint Commitment. I understand that this yelling is not something you want to have when you introduce Scrum.  Scrum and agile methods in general rely on highly motivated teams. Choleric Product Owners wont help you. But is the reason for this behaviour the much more binding term "Commitment"?

From http://www.flickr.com/photos/fabiovenni/

If a team fails to meet the commitment, then this may be an indicator for two things:

  1. change in the environment of the team is needed
  2. the problems the team has to solve are to complex.

In both of these two circumstances the team or the organisation should learn and improve. The team can learn how to better cope with the complexity of the given problems and the organisation can learn how to transform to support the teams better to get things to done. IMO: Renaming the Sprint Commitment to Sprint Forecast will take away the urgency of the necessity to learn.

We find commitment in many cultures. The Germans for instance are well known for their punctuality. Everybody commits to be at a certain place on time. It reduces the time to wait and people can start working immediately. Every German who has worked in another country realizes how this behaviour helps to get things done and avoids wasting time. Commitments help us to better work together.

In the organisation we have commitments on various level. Shareholder, investors and owners give their capital and want commitment from the board that the investment will have a return. Customers pay for the products and services and want commitment from the vendor to keep the promises. Employees want a commitment that they get a monthly salary. There are commitments everywhere on the boundaries of the organisation. Inside the organisation we have managers who commit to certain goals, e.g. increase revenue, create innovative products or reduce costs.

Is a commitment by a team to deliver some value after two weeks not possible within a learning organisation?

Companies  use nowadays more and more Commercial Off The Shelf (COTS) software products. I have seen many of these projects that launch a big software product within an larger IT organization. My feeling is that it not always helps the organization and that it is usually a very costly endeavour.

I'm looking for explanations, why these projects are causing so much effort. One explanation could be found in the number of dependencies that a software product has to other IT systems. The more interfaces a COTS product has, the more complex is the integration. But why is it more complex than integrating a software written from the scratch? There are two reasons:

  1. We know less about the internals of a COTS product. Since it's not written by the developers themselves, if a problem during integration occurs, it will be more difficult to find the causes of the problem.
  2. The COTS product implements more than required. A product must be adaptable in many organization. It come with features that one organization finds useful, others don't. But it contains all the features. It will also have some kind variability build in - to adapt it to all different situations.

Because of these two reasons, the variety of a COTS integration is higher. If a company that integrates a COTS software has to deal with a larger variety, we must have in the organization with a higher variety, to be able to control it. This is due to Ashby's Law, a very important law in cybernetics. If one system wants to control another system than it must have a higher variety.

So there are two ways of dealing with it:

  1. Decrease the variety of the system that you want to control. We do that for instance in coding software by type checking or information hiding.
  2. Increase the variety of the system that wants to control the other. We do that in software development by self-organized teams. Those teams are able to have a higher variety than a team lead by a command-and-control style manager.

Okay - so what we know is that COTS will have a higher variety - maybe. If a COTS product has less interfaces to other systems/components the integration will not amplify the uncertainty into the project, and thus may still be manageable.