Bernhard Findeiss
Saturday January 30th, 2010

(Deutsch) Warum Scrum? Gründe für das Management (1/2)

Sorry, this entry is only available in German.

Bernhard Findeiss
Wednesday January 13th, 2010

(Deutsch) Sind nur selbstorganisierende Teams echte Teams?

Sorry, this entry is only available in German.

Bernhard Findeiss
Tuesday November 3rd, 2009

(Deutsch) “Done”, oder: Wann ist etwas fertig?

Sorry, this entry is only available in German.

Bernhard Findeiss
Wednesday September 30th, 2009

(Deutsch) Unser Scrum Plakat jetzt in Version 2 verfügbar!

Sorry, this entry is only available in German.

Bernhard Findeiss
Wednesday July 8th, 2009

Scrum vs. Kanban (2/2)

In my last article, I began a little comparison between Scrum and Kanban: What are the key similarities and differences between the two methods?

This time, I’d like to talk a little bit more about the distribution of boards to teams, and how to work on different products at the same time.

This blog post is based on the previous one. If you haven’t read it until now, I suggest doing so before going on with the rest of this article.

As mentioned in part 1, a Scrum Board always shows the state of the current sprint for a certain team. At the end of each sprint, a new “potentially shippable product increment” is created, the items on the board are “reset”, and the next sprint begins. As a consequence, requirements to be implemented by a Scrum team mustn’t be more than one sprint in length. Bigger chunks must be split into smaller ones until they fit.

In Kanban, this is handled differently. As sprints do not exist, items can be of arbitrary length. Also a result of lacking sprints, a Kanban board doesn’t undergo the same cycle as a Scrum board, and is not reset after each sprint. But there are some similarities, however: The rows contain the various requirements, and the columns represent the states of the workflow. Requirements are “done” as soon as all tasks associated with it have moved to the right-most workflow state.

<———————————>

This is not the only difference between the two panels: In Scrum, the table exactly the work of a team again. While it may all see the blackboard, but the team may also change. The team is cross-functional occupied. I.e. all the capabilities needed to the current sprint to a successful conclusion, are included in the team.

In KANBAN are here from the outset, no such limits. Cross-functional teams are optional. Even the restriction to a single team is not required. Instead, it refers to a Kanban board to a specific workflow. A workflow can, in principle, but also include several teams. A Kanban table may be purchased by several teams changed.

To say it is better to be able to imagine, the whole thing again here graphically:

A Scrum-table is always in possession of a single team
Figure 1: A Scrum-table is always in possession of a single team

Figure 1 shows a typical Scrum board. She is always in possession of a single team. All columns of the table will only be changed by this team.

Figure 2: A Kanban board of several teams can be managed simultaneously
Figure 2: A Kanban board of several teams can be managed simultaneously

Figure 2 shows a Kanban board. It is not only not in possession of a single team. Instead, it reflects a workflow again (in this case simply “Todo -> Processing -> Done). The individual steps of the workflow may be arbitrarily divided in teams.

In this example, here is example the column “Todo” by only one person managed (which could, for example a kind of project manager or his Product Owner). For the remaining columns, however, is another team responsible. In reality, the board would be from Figure 2, probably a bit expanded to really useful to be able to work. Links of column 2 “Todo” could be a column about “backlog” to introduce a kind of disordered wishlist without prioritization, as the pool for all future requirements serves. Should any of the requirements to be realized, it will be easy for “Todo” postponed.

Of course you can have the workflow to many other types of distributed teams. With a high number of items it might be useful to some, that two or more teams share a column. But the Scrum used in case (a team manages the entire table) is possible.

A Scrum-table is really nothing other than the special case of a Kanban board.

Behaves similarly to the case also with the estimate of items, or their lead on the table:

In Scrum, use the length of an iteration as a frame of reference. This means that the team appreciates all the new incoming requests and selects them exactly as many as it is in this iteration (sprint) can be implemented. If one adds the estimated values of all the requirements of a sprint, so you get the “total value” of a sprint (in Function Points). We call this number also “Velocity”. This value can then several sprints continued to write and compare. He serves the team as a clue in the sprint planning when it comes to requirements for the next sprint to select.

Figure 3: Calculation of the Velocity
Figure 3: Calculation of the Velocity

In KANBAN, however, this is a bit different. Since it is of no house of iterations, and also the new requirements Beschätzung is not absolutely necessary, there is no fixed reference frame, one to calculate the velocity would use. Instead, we need to manage differently here. Some teams such requirements are grouped into so-called “MMF” (Minimum Marketable Features). Then they measure the time it takes all the requirements to implement this group. On this basis, can then also service level agreements (SLAs) are working. “We provide a MMF always at max. 10 days would be an example of this.

Other teams break requirements (without explicitly beschätzen) in approximately equal-sized pieces and then measure the throughput. Based on a fixed (arbitrarily chosen) time can be once again a “Velocity” calculate ( “10 requests per month).

The possibilities are almost limitless. One can of course always a fixed frame of reference to introduce, with estimates and / or re-iterations of a Scrum-like method come. The best way is to try different looks, and then take the one that is for the current case, the most appropriate.

Together, the two methods, however, the same team several products simultaneously work for you. In Scrum, you often feel that this does not work (as a Product Backlog is always based on just one product). However, one could indeed be a team on several product backlog at the same time to work. The order of execution (in a row, alternating each sprint, at the same time, etc.) will be given jointly by the team reached with the Product Owner (s) specified.

With KANBAN, the whole thing much easier: A blackboard always belongs to a workflow, rather than a product. It is therefore readily possible to use several products at the same time using the same workflow to drive. For better distinction, one could still take different cards, or you carry more than one line (one line per product). But otherwise, no further changes to the process necessary.

Where at first the comparison between Kanban and Scrum. Here are the results again in a table briefly summarized:
Scrum Kanban
Iterations with a fixed duration. Iterations are purely optional. Fixed length is not mandatory, also control event possible.
3 rolls firmly planned (Product Owner, Scrum Master and Team). Initial no prescribed roles.
Team selects a set of requirements for a sprint, and undertakes to implement this. None of iterations, therefore, no solid commitments necessary. But there is the possibility to introduce SLAs.
Velocity (work done per sprint) as the primary parameters for planning and improvement. Throughput as the primary parameter.
Product Backlog is (descending) sorted by business value. Prioritization optional.
Entries must be in the Product Backlog in a max. a sprint feasible. Scrum tasks on the board are <= 1 day. Requirements may be arbitrarily large.
No changes to the requirements during a sprint possible. New requirements will be the earliest with the next sprint planning. New requirements can in principle be brought at any time (if a slot is free).
A Scrum-table after each sprint will be reset. A Kanban board is continuously updated.
A Sprint Backlog (and thus also a Scrum-table) is always exactly one team. A Kanban table can have any teams to be divided.
Cross-functional teams required (and also necessary, as a Sprint Backlog only by one team is being processed). Cross-functional teams optional. Even more (special) teams per workflow possible.

If you look at this table so committed, then you can see quite well how Scrum and Kanban actually related: Kanban and Scrum are not mutually exclusive. Quite the contrary: Since every rule in Scrum is a special case of a rule is Kanban, Scrum is really nothing more than a special case of Kanban.

Scrum is one of (probably infinitely) many ways to make Kanban …

BFI mehr »

Bernhard Findeiss
Tuesday June 30th, 2009

Scrum vs. Kanban (1/2)

The topic Kanban frequently came up during recent discussions. Often associated with the question “Do you still use Scrum, or have you already changed to Kanban?”.

That gave me the impression that many people think of Kanban as being the “successor” to Scrum. However, this statement is wrong! The contratry is true: Scrum and Kanban are both based on the same ideas. Even more: Scrum is one possible way of doing Kanban…

A detailed paper on this has recently been published by Henrik Kniberg ( see here). But don’t worry, you don’t have to read everything in detail. I’ll give you a brief summary:

If you try to categorize today’s project management methods, you can base your categorization e.g. on the number of rules and regulations these models contain, and the number of areas these models cover.

mehr »

Bernhard Findeiss
Monday May 11th, 2009

ScrumDay Munich: Ken Schwaber’s keynote

On May 6th, 2009 Munich saw its first “ScrumDay”, a new conference on Scrum. It paralleled “TeamConf”, a conference on “Microsoft Visual Studio Team System.

The day began with a keynote by Ken Schwaber, one of the inventors of Scrum, on “Scrum, but … “.

At first, he gave a brief introduction to the topic of Scrum and the underlying values (self, transparency, integrity).

Afterwards, he made clear software development in general (and Scrum in particular) is an empirical process, as it is necessary to periodically look at the project situation and make corrective adjustments. He compared it to an air conditioning system’s temperature sensor, which periodically checks the temperature in a room and then sets the system accordingly.

This approach is necessary because the complexity of today’s software development projects is generally too high to understand everything in detail. It’s sufficient to detail the next 4 weeks. In addition, approx. 35% of a project changes anyway, so too much planning in advance is a waste of time.

mehr »

Bernhard Findeiss
Thursday May 7th, 2009

Presentation on Retrospectives at ScrumDay Munich

Yesterday, Alexander Maisch and I were at Munich’s first “ScrumDay” to give a presentation on retrospectives.

We explained why agile methods rely heavily on retrospectives, and showed some best-practices for holfing them (most of it can be found in my two articles on retrospectives here and here).
In addition, we made a short detour to the topic “culture of criticism”.

We thougt the ScrumDay was a very successful event with many interesting presentations and even more interesting people.

Here are the slides of our presentation (currently only available in German):

Retrospektiven als Grundlage agilen Projektmanagements (2038)Of course, this download can also be found in the “technical corner” of our document section.

Bernhard Findeiss
Wednesday April 29th, 2009

Scrum and hyperproductivity Part 2 – or: Advanced Scrum

Sorry, this entry is only available in German.

Bernhard Findeiss
Monday April 6th, 2009

Agile Retrospectives (Part 2)

In part 1 of this article I introduced the basic structure of a retrospective and suggested using the 5 step agenda created by Diana Larsen and Esther Derdy in their book “Agile Retrospectives: Making Good Teams Great!”:

1. Set the stage
2. Gather data
3. Generate insights
4. Decide what to do
5. Close the Retrospective

As mentioned earlier, the quality of suggested improvements relies greatly on the outcomes of step 2 and 3, i.e. building a high quality database and drawing conclusions from it.

Having an agenda helps a lot, but does not necessarily guarantee high-quality results. Fortunately, there are a number of techniques you can use to support these steps. We tried out quite a few of them in various projects. I therefore want to give summaries on the ones we found to be most helpful.

If you want descriptions in more detail, you can find them in the book by Derby and Larsen, but also in Project Retrospectives: A Handbook for Team Reviews” by Norman Kerth.

I suggest reading both of these books to anyone who really wants to get serious about retrospectives.

mehr »