So, now you've done one discovery, two discovery, couple of

days. Couple of days. And you all are involved in it as

well. Now it's approve and you start delivering.

Delivery is broken down into iteration zero, where you set

it up, and then you do one, two, three. Two weeks. My

advice is fix your iteration time to two weeks. Do not do

three weeks. It's too long.

One week is too short when you're just starting Agile. Go

with two weeks. Two-week iterations. There's a rhythm.

There's a practice. At the first day of the iteration, you

do your iteration planning on maybe the Monday or the

Tuesday, whatever day you start it.

Then you do this. Standup work. Standup work. You keep

doing the work. At the end of the iteration, on the last

day of two weeks, you do the showcase, another practice

where you show what you have achieved to the stakeholders.

You actually physically show them.

And then you do the retrospective. Now, the retrospective

is not about the product. The retrospective is mainly

about the process. How did you do it? Not what you did.

Make sense? Retrospective is different.

All right. And this is the same as the Scrum sprint, so

-1-
you see. Scrum, you did the backlog. Sprint, one to four

weeks, and then you finish it, and then you start again.

So, that piece this piece is exactly the same as Scrum.

There's no need to call it Scrum because that's a branded

term. You can just call it an iteration. It's important

to understand the model. You can use whatever specific

method you want.

So, Celia Lashlie, this is very important, she did a lot of

research in New Zealand, and she studied for almost 30

years with only one question. How do you make a good man?

What a strange subject, isn't it? What a wonderful

subject to study.

So, she studied kids from the age of nine until the age of

19. And if you study boys, you have to study girls as

well. So, if you want to know how boys work.

So, she studied both for 30 years. And if you've got a son

or a brother, you have to read this book. So, she gave

them an exercise. I give you an assignment on Monday

morning. You have to deliver it on Friday. When do you

start? Friday, yeah? Girls, when do you start?

>> [INAUDIBLE].

-2-
>> Oh! Even the Sunday before.

[LAUGHTER]

So, no, the answer was that the boys were almost 80 percent

said on Thursday night. And the girls, 70 percent said

Wednesday. So, there was slightly better than the boys.

But just look at this. By nature, right from the time we

are small, this is how we work. We just leave it, leave

it, leave it, leave it, leave it, because we automatically

know there are other, more important things like partying

and partying and partying and partying. Now I need to do

my assignment.

And it doesn't take very long. She should not have given

you four days. So, because of that, and it's a law by

Parkinson called Parkinson's Law, that work will fill time.

If you give something three months, guess how long it will

take to do? Three months, the same piece of work, and a

little bit of extension as well.

So, that is why we use time boxes. These iterations are

time boxes. We time box it because it helps us focus. If

that teacher had given them an assignment in one day, just

Monday, they give it to you, Tuesday it's ready, they would

have done it on Monday evening because you've prioritized

-3-
it.

And that is what Agile is all about. It's about time

boxing. Now, even operations you need to time box. Oh,

what is that? How do I time box operations? Because I

just do my work.

They're virtual time boxes so what you do is you say this

is the work. It's going on every day. You come in and you

do your work. So, you just say Monday morning, two weeks

later we're just going to take a pause for one hour to do a

retrospective on how it went.

We're going to read the metrics. We're going to see the

mood marbles. We're going to see what worked well. We're

going to do a retrospective. We're going to do a showcase.

It's just a virtual time box, and the work goes on. But

you take time. You breathe. You take a pause. If you

don't, you're just working mad and you don't improve your

process.

You have to transform yourself. It's not some other team

that does transformation to you. That's not how it works.

That's not how it works. You have to own it and you have

to make the change.

-4-
So, very important. Now, another thing is we just break

the elephant down. The best way to eat an elephant is

piece by piece. There's no other way.

So, the big projects, I've done Agile for projects in the

region of 90 to 100 million dollars. 300 people working

for nine months or more. 12 months. Very long project.

17 streams, all small teams. Loosely coupled, tightly

aligned.

We break them down into projects. The projects break

themselves down into epics. The epics break down into

features, the features break down into stories. This is

what goes into your iteration.

This stays in your release plan and that's done. So, we

break it down. We break it down. And then you can see it

on the wall. You can see this whole breakdown.

And the beauty is whatever you do at that level is exactly

the same of what you do at that level. This is like the

universe. Look at how the atoms work. It's exactly how

the universe works. It's the same model. And there's a

lot of space, and they interact with each other.

That's the Agile principles and values at this level are

exactly the same values and principles that you use at the

-5-
strategy level, at the program level, at the product level,

at the project, et cetera.

So, there are many frameworks out there. So, this is less

from the Scrum brand. So, Scrum is a brand of doing Agile,

the actual project delivery. So, they've got how do you

scale it.

Then there's scaled Agile framework got safe. All the

same. They talk about taking big epics, breaking them down

into features, taking the features, breaking them down into

stories, and putting them into iterations.

So, whether it's, say, for less, doesn't matter. What you

all are learning is the techniques. Understanding what all

this is and how it all fits in with this.

If you forget the values and principles and just do the

practices, oh, I Agile, I'm doing a standup. And you're

not Agile, because you don't live this.

So, small teams, 7 to 12 people, somewhere there. It could

be an iteration manager here. Some call it the Scrum

master. Then there's an extended team. So, this would be

the stakeholders, the team leaders, the managers, external

experts, enterprise architects. They come sometimes.

They're not needed all the time.

-6-
But this core team is dedicated. Now, they could be

operations. This is just an example. They could be

marketing people, they could be finance people, but it's

the core team. This is the extended team and that's the

steering committee. So, it's the same model for operations

and the same model for projects.

Then people ask me, yeah, but can you write down my

responsibility? So, what's your responsibility in the

boat? You cannot say my side of the boat doesn't have a

hole. That does not work. If there is a hole, we're all

going down.

So, you have to work as a team. Now, yes, you do have

skills. You have special skills that are needed. That's

why you're on the team. But at the point something's

happening, you have to roll up your sleeves.

You worked with one team once, they had seven developers,

one tester, four BAs. Guess where the bottleneck was.

Testing was the bottleneck. So, what's the first thing

they said to me and to the manager? Yeah, we need more

testers. Yeah, sorry, there's no budget for more testers.

So, what do they do? So, they keep on building stuff and

letting it pile up there. Oh, we don't have tester. So,

-7-
they're building. No. What does the team do? The team

looks at the flow and says where's the bottleneck.

Remember the bottleneck. Where's the bottleneck? Testing.

So, what can we do? Automate, very good. What else?

Sorry? Thank you very much. You can do that. At the end

of the day, what has to be done is testing. You don't need

a tester. You need to do testing. Roll up your sleeves.

Four of the developers did some of the testing while the

others were building and suddenly the bottleneck was

finished and they were flog again. So, they divided the

work.

The team knows what best to do. No manager has to decide

this. You don't have to go to your manager. You have to

take ownership and find out where the bottleneck is and fix

it.

So, it's a combined role that everybody plays, including

the customer. The customer is there as well in the boat

because at the end, the customer...you are taking the

customer from A to B. The customer's in your boat. If the

boat goes down, the customer goes down.

In Agile teams, there's something that will happen that

you'll know later on as you get mature. It's very strange

-8-
to watch. It's fantastic.

It's called the Stockholm Syndrome. Has anybody heard of

the Stockholm Syndrome? So, this is in the seventies,

there used to be a lot of hijacking. And they found that

when the hijackers hijacked the plane, after two days,

everyone that were hijack were supporting the hijacker.

Oh, he's a good man. I know he hijacked us, but he's a

very good man. What is that? And it's called the

Stockholm Syndrome, because very often customers when they

work very closely with Agile teams, after some time, they

become part of the team and they'll be telling others, oh,

no, no, the team cannot do this.

So, actually, you have to manage that because the pendulum

can swing to the other side. So, that's projects. So, now

let's look at operations. How many of you here from

operation background. Let's say you do operations. Okay.

So, almost half the room.

So, we're going to talk about operations. I'm going to

speed up a little bit. So, very important, look at the

process. Mobilize, understand, explore, build, test.

Exactly the same.

But in the explore and understand stage, you are using a

-9-
technique. You use the business canvas to find out what

you do. So, that will be there. But then you do value

stream mapping.

And this is not the 12 weeks value stream mapping that LEAN

does. It's the same process, but it's an Agilized, faster

version. And within three or four hours, the team will get

together and build this. So, you will know exactly.

Now, you have to be careful of some things. Because you

work in silos, sometimes you can do a value stream map for

your silo, and you change something there but it's made it

worse on this side of the silo. So, you have to find your

parent process. You have to find what is the process

you're optimizing at the top.

This is where the leaders come in. They work with the

teams. They go we're going to pick this process. All sit

together, workshop maybe two hours, maybe four hours, maybe

one day.

And you've got a picture on the wall of exactly your entire

process with the cycle time and the throughput. Two

measures you must have. Cycle time and throughput. Cycle

time is how long does it take to go from here to here. And

throughput is how many balls can you push through the pipe

for one month. How many pieces of work can you do.

-10-
Now, once you do that, it's amazing. And you look at it on

the wall. You will see the bottlenecks and you will see

the waste. It will shout at you. Why are we doing that?

We're waiting there for four days for somebody to approve

something.

Can we not stop it? Yeah. We could. Let's have a

conversation. Let's stop it, empower yourselves, discuss

it with the leaders. Get rid of that process. So, this is

the [tube] you want.

So, what you do is you change the process, but you can't

change it without testing it. Why do you think so? Sorry?

Correct. Because of the impact. The change may be not

always improvement. Change could be a step backwards.

So, you test it on a small area, say okay, that works. Now

you roll it out. And once that is done, you start all over
again. That's it. And here, this is the beauty of it.

The actual testing and the implementation, how do you do

that? You do it like an Agile project. You have a wall,

you have standups, you have story cards and you execute it.

So, same. Understand, explore, test, implement. And you

do it for operations.

[END OF SEGMENT]

-11-