EXIN Agile Scrum

Foundation Workbook

3
Kanban and ScrumBan

Page 77
EXIN Agile Scrum
Foundation Workbook

Kanban

Kanban is a management technique that has been popular in manufacturing for a long time,
and has recently been used in IT projects. However, what people mean by Kanban in IT
environments is usually the ScrumBan described next, instead of a real Kanban. Kanban is
just a technic rather than a framework.

There are three rules for Kanban:

1. Work should be visualized

2. Work in progress (WIP) should be limited
3. Work should be pulled instead of pushed

Now let’s see how it works.

Visualizing is really helpful, because:

 It creates transparency and therefore, feedback and collaboration

 It creates more control

So, we prepare a Kanban board, and visualize the work steps and the work items. The
minimum steps we need are to do, doing, and done. In an IT project, you can have your
Definition of Done visualized on the board; e.g. to do, specifying, designing, programming,
integrating, testing, implementing, documenting. It is more common to have them
simplified as to do, programming, testing, done, or something similar.

The following is a sample Kanban board:

To Do Designing Programming Testing Documenting Done

- (2) (3) (4) (3) -
Done Done Done Done
. . . .
.
.
.
.. E

.
T N
. . M

Q
D

Page 78
EXIN Agile Scrum
Foundation Workbook

In this example, there are 6 main columns:

 To Do
 Designing, maximum WIP (work in progress) is 2
 Programming, maximum WIP is 3
 Testing, maximum WIP is 4
 Documenting, maximum WIP is 3
 Done

The optimum work in progress limit for each step is usually found by trial and error.

Except for the first and last columns, each column has two sub columns: one for the items
that are being processed in that column, and the second one for those that are completed in
that step. The important point here is that items in both columns are counted for the work
in progress. The other point is that this is a pull system rather than a traditional push
system. When a step is done, people cannot push the completed work to the next column
and free up capacity for new work; instead, they should wait for the next column to pick the
work. So, in the above example, all columns are full based on their defined WIP, and no new
actions can be taken.

Now let’s say the documentation team is done with item G, so this happens:

To Do Designing Programming Testing Documenting Done

- (2) (3) (4) (3) -
Done Done Done Done
. . . .
.
.
.
.. E

.
T N
. . M

T Q
D

1
U
N

These are the exact steps:

1. G is done; therefore it goes to the sub column “done” of the documentation.

Page 79
EXIN Agile Scrum
Foundation Workbook

2. Since documentation is the last step, G will automatically go to the main Done
column. Note that if we need an approval, it should be included in the existing
column or preferably have a separate column. We have not included such a step in
this example.
3. Now there are only two items in the Documenting column and therefore, one free
capacity. People in this column will pull item J from the previous column, since it was
marked as done for Testing.
4. Now that J is out, we only have three items in the Testing column and since the WIP
is 4, we can pull L from the previous column, which was marked as done for
Programming.
5. Again, there is an open space in the Programming column, so they can pull the item
N.
6. Now the designers also have a free capacity, so they can pull a new item from the To
Do column.

Note that all items in the To Do column should be sorted based on whatever criteria suits
our environment, and we should try to keep this order through the process. It is not always
possible to keep the order in every step, but we still try.

OK, this is the current state:

To Do Designing Programming Testing Documenting Done

- (2) (3) (4) (3) -
Done Done Done Done
. . . .
.
.
.
.. E

.
. . M

T Q
D
U

Page 80
EXIN Agile Scrum
Foundation Workbook

Some items get completed in each column after a while and are moved to the “Done”
section in the column:

To Do Designing Programming Testing Documenting Done

- (2) (3) (4) (3) -
Done Done Done Done
. . . .
.
.
.
.. E

.
. .
Q
T
M

N
D
U

We cannot have any changes on the board at this moment. Now let’s say that the designers
are also done with item T:

To Do Designing Programming Testing Documenting Done

- (2) (3) (4) (3) -
Done Done Done Done
. . . .
.
.
.
.. E

.
. .
Q

T
N
D
U

Page 81
EXIN Agile Scrum
Foundation Workbook

So, what should happen now? Designers do not have anything else to do, and based on the
Kanban rules they cannot push the completed work to the next column, and since they do
not have a free capacity, they cannot get a new item from the To Do column.

In this case, the designers should move to another column and help their colleagues. Which
column? The bottleneck now is Testing.

To Do Designing Programming Testing Documenting Done

- (2) (3) (4) (3) -

. .
Done Done Done Done
. . ..
.
E

. ..
. .
Q

T
N
D
U

This can be the case for everyone in the team, if, for example, the rest of the columns are all
complete and full in capacity, then their members have to move to the Testing column too.
Even the person in the To Do column, whom you can think of as a Product Owner, should
also move on to the Testing column, since it does not matter what items s/he puts in the
column, they are not going to be developed yet.

Page 82
EXIN Agile Scrum
Foundation Workbook

To Do Designing Programming Testing Documenting Done

- (2) (3) (4) (3) -

. .
Done Done Done Done
E

..
Q
. .
. M
.
T

N
. . D
U

.
.

So, everyone works in the Testing column until we have the first item complete in that
column and have the flow of the process back to normal. Then everyone goes back to their
original columns and focuses on their specialty again.

To Do Designing Programming Testing Documenting Done

- (2) (3) (4) (3) -

. . Done .. Done
.
Done
. . Done
. .
E
..
.
Q
1 2
M

T
D
N
U

As you can see, people are focused on getting the product done, instead of their specialist
activities, which is mainly applied by the pull system. This system can be more effective in
terms of productivity, even though it might seem strange to stop working on a column when
you can actually work. In addition, the fact that we expect people to move to other

Page 83
EXIN Agile Scrum
Foundation Workbook

specialist areas in certain situations and help their peers seems unacceptable and
unproductive to some people. This is because they believe that one should have the
expertise to do the job, which is correct in general, but we insist on the fact that even
people who are not specialists in testing can help testers by bringing their different
viewpoints. Let’s take the person in the To Do column for example, who is usually a non-
technical business-oriented person. When s/he goes to the Testing column, s/he might
realize that they can increase the efficiency by buying more powerful equipment, so s/he
calculates the payback time, for example, and sees that it is only 8 months, which is really
good. So, the person goes to whomever they should, to convince them, get the budget, buy
the equipment, and make the testing activities faster. As you can see, this way of working is
all about throughput and team working.

You should realize that this viewpoint is really close to what we have in Agile environments
such as Scrum. In Scrum, for example, everyone is accountable for everything, ownership is
shared amongst everyone, we do not have any titles or extra roles, and therefore we are
required to help each other as much as possible. A tester in an Agile environment is not only
responsible for testing, but responsible for the whole product.

ScrumBan

There are lots of misunderstandings about Agility. For example, most people think they can
just divide their predictive scope into smaller pieces, develop them in non-timeboxed
periods they call Sprints and call it Scrum, which is totally wrong. Being Agile is about being
adaptive, rather than adopting a certain set of terms.

But, how can we be adaptive? There are lots of consequences and requirements involved,
and that is why it is always better to use a predefined framework instead of reinventing the
wheel. Each framework has a certain set of rules, and capacities for tailoring. This tailoring
capacity is extremely low for Scrum, since it is really lightweight. Almost everything is
mandatory in Scrum and you cannot omit any aspects. But some people do! For example:

 We use Scrum, but we do not keep the Sprints timeboxed.

 We use Scrum, but we set the duration of the Sprint in the Sprint Planning.
 We use Scrum, but we do not let the Product Backlog evolve.
 We use Scrum, but we do not find it necessary to have Sprint Retrospectives.

All of these cases are called ScrumBut instead of Scrum. The rule is that a ScrumBut is not
Scrum. A ScrumBut is not Scrum, because when you only follow 95% of the Scrum rules, you
cannot expect 95% of its benefits; just expect about 20%.

Page 84
EXIN Agile Scrum
Foundation Workbook

It is not wrong to use a non-Agile method; Agile frameworks are good solutions for IT
development and some other kinds of initiatives, but not the only way. You are not required
to limit yourself to Scrum, as other Agile frameworks might work better for you.

In some situations, Scrum does not seem to be the best possible solution. When
maintenance is the only goal or the most important part of the job, you need to respond to
bug fixes or add urgent features as soon as possible, you might want to use ScrumBan
instead of Scrum.

ScrumBan is a combination of a ScrumBut and Kanban. Even though most people say that it
is a combination of Scrum and Kanban, which is not quite right. Lots of people just call it
Kanban, which is not right either, because Kanban is a technique rather than a framework.

ScrumBan is a very simple framework: a ScrumBut, which does not have Sprints, plus a
Kanban system. So, we have a Kanban board similar to the one discussed in the previous
section, and a Product Owner with the standard roles and responsibilities managing the To
Do column (Product Backlog). The Development Team picks the items from the top of the To
Do column whenever they have free capacity, and they let it flow to the next columns based
on the Kanban Rules.

So, the main difference between the type of ScrumBut we use here, and a real Scrum is that
we do not have Sprints. However, when do we have the rest of the events? This is how we
manage it:

 Planning meeting (Sprint Planning): we do not need it anymore.

 Review meeting (Sprint Review): it is still required and essential, because the
framework is adaptive nevertheless, and we need the customer feedback. The
review meetings are held as follows:
o Either after a certain volume of work (e.g. after developing each 100 story
points), or
o In certain intervals (every three weeks)
 Retrospective meeting (Sprint Retrospective): it is still required, and it would be held
after each review meeting.
 Daily standup (Daily Scrum): it is still required, and is done daily.

And this is the state of the artifacts:

 Product Backlog: exactly the same as the Scrum Product Backlog. It is visualized as
the To Do column in the Kanban board.
 Sprint Backlog: we do not have it anymore.
 Increment: we still have the same definition for increments and they are the output
we have right before each review meeting.
 Definition of Done: exactly the same as the Scrum DoD.

Page 85
EXIN Agile Scrum
Foundation Workbook

 Monitoring progress toward a goal: this project measurement is done exactly like we
do it in Scrum.
 Monitoring Sprint progress: we do not have it anymore.

Some customers and Product Owners might prefer ScrumBan, because it seems easier to
use. However, we usually have a lower productivity rate in this framework because we do
not have the safe and calm environment created by Sprints. Therefore, you should keep
using Scrum, unless you really have to switch to ScrumBan.

Page 86
EXIN Agile Scrum
Foundation Workbook

The Journey Starts

We hope you have found the book helpful. We also hope that you will be the next successful
adopter of Agile frameworks. Do not forget that becoming Agile requires a change in your
mindset.

We would be glad to receive your feedback. Our email addresses are

[email protected] and [email protected].

Good Luck

Nader K. Rad, Frank Turley

Page 87