10 Iteration Execution HD Preview

Okay. Welcome to iteration execution. So far in the

delivery section of the Agile program pattern, we've talked
about delivery and iteration basics, stories, how to get
ready for iteration one, and release in iteration planning.

So, now we're getting ready to talk about iteration

execution, where Agile teams self-organize to meet the
commitment they've made in a given iteration. And because
Agile teams self-organize during iteration execution, we
won't spend a lot of time describing how work gets done.
Instead, we'll describe the framework within which that
work gets done.

So, let's get to it. We've looked at the life cycle of

delivery previously. In this module, we'll focus on the
bottom third of the diagram at the flow of an actual
iteration. To create a frame for this discussion, let's
look at a sample two-week iteration schedule and the
various ceremonies that take place within it.

In this sample, the team has decided to start iterations on

a Wednesday and to end them two weeks later on a Tuesday.
This can be a good strategy for not having to schedule
around holidays that typically fall on Mondays and Fridays.

So, the team begins the iteration with an iteration

planning session in the morning of day one here on July 13.

-1-
10 Iteration Execution HD Preview

As a guideline, we're suggesting that iteration planning

not take more than five percent of the total iteration
duration.

In this case, we're assuming seven-hour work days for a

total of 70 hours within a ten business day iteration. So,
five percent of 70 hours is three and a half hours or half
a day.

Iteration planning shouldn't take more than half a day in a

two-week iteration. If it does, you may want to look at
that and optimize in whatever ways you need to in order to
compress things down.

Once iteration planning is complete, the team begins work

and works for four and a half days in this case before
pausing mid-iteration for what we call a preplanning
session.

In the preplanning session, the team returns to the product

backlog and looks ahead at what's coming next. Stories are
elaborated on in the session so that they're ready for the
next iteration planning session.

Now, you'll notice we've got ten percent total iteration

duration there or seven hours of work, which seems like a
lot. But this is where things like high level design and

-2-
10 Iteration Execution HD Preview

experimentation or spikes, all this stuff can happen in

this preplanning session that teams make time for. They
schedule it up front and they know it's coming.

Once preplanning is complete, the team returns to the work

of the current iteration until the final day of the
iteration, where two things happen. One, the team holds a
showcase, where the completed work of the iteration is
demonstrated formally to the product owner and to any other
interested parties.

And then two, the team holds a retrospective where the team
reflects on the iteration just completed with the goal of
coming up with a list of actions they think will help them
improve in subsequent iterations.

Again, this is just an example of how a team might

structure its iteration schedule. Teams should experiment
with different structures continuously, always asking
themselves how can we improve.

One thing that shouldn't change, though, is the iteration

length unless it's absolutely necessary. And the reason
for that is that any metrics the team might be collecting,

they'll become somewhat meaningless if that happens.

Velocity, for example, should be based on a stable
iteration length.

-3-
10 Iteration Execution HD Preview

Over the course of the iteration, the teams should conduct

daily standups, and these should be time boxed, and we're
suggesting to 15 minutes and held at the same time and in
the same place every day. This is so the team can get into
a rhythm with them. The daily standup becomes a kind of
heartbeat for the team.

So, standups should start and end on time every day, and
team members should limit the discussion to answering just
the three questions, which are what did you do yesterday,
what are you going to do today, and what, if anything, is
belonging you. And by the end of 15 minutes, everybody
should know what everybody else is working on and what
blockers the team faces.

Also, over the course of an iteration, in addition to daily

standups, the team may schedule or hold ad hoc huddles and
hangouts. These are for one-on-one conversations or deep
dives into implementation or design details or dealing with
impediments. Certainly for collaborating with the product
owner.

We mentioned that we wouldn't be talking about how teams

get their work done in this module, and we won't, but we do

want to make people aware of the fact that we plan to
release several devops courses through the Agile academy to

-4-
10 Iteration Execution HD Preview

help technical teams with Agile engineering practices.

So, please, do stay tuned for those. At the end of every

iteration, Agile teams demonstrate the work they've
completed. They demonstrate their work to the product
owner, which the product owner has already accepted as done
it was the team only presents work that is done.

They demonstrate their work to the product owner in the

showcase, in part to ensure it's clear to stakeholders
participating in the demo that it's the product owner who
accepts and rejects work. Participating stakeholders play
a very valuable role in a showcase, however, which is in
providing feedback and input into the work being
demonstrated.

Agile teams make sure they capture the feedback of their

showcase participants for consideration in subsequent
iterations. That is, relative to the value of the
remaining items in the backlog.

Following the showcase, Agile teams hold retrospectives,

which are facilitated workshops or discussions designed to
help teams answer one primary question, and that is how do

we get better. Agile teams can always get better, so the

retrospective happens at the end of every iteration.

-5-
10 Iteration Execution HD Preview

It's a chance for teams to reflect on what worked and what

didn't work and what they think they'd like to try next
time that they think will make them more productive and
effective and happy.

Iteration managers facilitate retrospectives in service of

their teams and can add a lot of value by designing
conversations or exercises that will help their teams look
at how they're working in new ways.

It's important for iteration managers to keep

retrospectives fresh because that's where the best learning
happens. And obviously, it's important for iteration
managers to ensure that retrospectives are safe spaces for
teams to learn without blame.

In her book on Agile retrospectives, our friend, Esther

Derby defines a retrospective as a gathering of a
community, to think of it as a team, as a community, at
regular intervals, and we're saying that at the end of
every iteration, throughout a delivery to review the
events, which was the iteration, and to learn from the
experience. That we hold retrospectives so that we can
learn and improve.

And to conclude of iteration execution, let me just read

this quote from Mike Steep. When the speed of failure

-6-
10 Iteration Execution HD Preview

slows, so does of the speed of invention. Failure is

essential for learning and growth. And the willingness to
face and accept failure as a means of learning, it's a sign
of strength, not weakness. So, we want to fail early and
learn and grow from that failure. But we've got to have
courage. We can't be afraid to fail.
[END OF SEGMENT]

-7-