Agile Simulation - Part 3 | Purpose, Agenda, Team Norms

Okay. Welcome, everyone. We are here today

to talk about the Agility Insurance Project.

So before we get started,

we're going to go through visioning and

go through the various activities to

understand what this project is about. So

thanks to everyone who’s here. And I

would like to maybe start with something

important called team norms. Team norms

are ground rules, meeting norms that

we set for ourselves to stay on track

without distraction or dysfunction. So,

as all of you right now are sort of

doing a lot of different other things,

what do you guys think are some common

meeting distractions or dysfunctions that

we’d like to protect ourselves from that

you’ve been experiencing in other meetings?

How about electronics by

exception? Electronics by exception.

What does that mean, Kelly? Phones off or vibrate. Vibrate.

So let’s put that cell phone on

vibrate, please. Can we all just put our

cell phones on vibrate now together?

We’ll just do the ceremony.

Yay. Thank you. That’s awesome. What about laptops?

Laptops. As wonderful as

this looks that everyone has a laptop, if

you guys don’t mind, during our

collaborative sessions, we’d like you to

put your laptops down. I know. I’m so

sorry. It’s okay. It’s okay. We do say

laptops by exception. So, if you’ve got a

production support issue or something

that you really need to look at, let

us know, and we can use that. But

we’ll give you enough breaks to take

care of that. But it’s really important

for collaboration that we’re all together.

So, let’s put electronics by exception.

What else, you guys?

Are you respectful? Yeah. Like one conversation at

a time. One conversation at a time? I love

that one. How about being on time?

I like that one. I really like that one.

Be on time. And on time?

End on time. Be, and can I set that over here? You can.

End on time. What else? What are other comments?

Take notes. Take notes. Yes? Okay.

Take notes.

Focus on the topics. Yes, please.

As much as possible. And it

will be okay if you start talking about

something and it’s off-topic or

maybe you’re going into the details too

early or something like that. We’ll

bring you back again. So, stay.

Do you guys think that actually

happens quite a bit when we’re doing

requirements gathering--that we might

want a solution too early as oppose to really

just sticking with what the problem is? Do you

guys? Definitely. So, what can we put up

here to make sure that we focus on

the solution. Not the solution, but focus on

the actual problem they have, as opposed to the solution?

Do we have an agenda? We do have an agenda.

So, stay on topic. Agenda. Yep.

And then focus on the what, not the how.

Right? Focus on what they want, not the how.

Very good. Do you ever experience in

meetings where people sometimes think

that everything is not going to work?

So, all these solutions are just not going

to go well? So, like the art of positive?

The art of positive? Yes. Well, tell us about that. We can. Open-minded.

Concentrate on what’s possible. Yes.

So, concentrate on what’s possible.

It doesn’t mean that you

can’t bring up concerns or that this is not

going to work. It just means that, okay, so

how are we going to solve that problem? Okay.

Awesome. Thank you, guys. That’s awesome.

These are all of our team norms.

So, as we’re facilitating this session,

don’t be upset if we have to sort of

hold ourselves accountable for the same norms.

Okay. Here’s the purpose of our simulation:

to provide a glimpse into how an

agile team goes through the agile lifecycle.

Our very first part of our

agenda is going to be visioning--so

understand from our product owner,

from our sponsor, from our business user,

what this project is about. What is it

that we’re trying to accomplish?

What’s the purpose of the project? And then

we’re going to brainstorm

the requirements. Now that we’ve

visioned, what are the actual stories

that we have to deliver here? Then we

need to slice some of them down. A lot

of times, we’ll have stories, but they’ll

be epics--too big to get down.

So, we’ll slice them and break them

down into smaller chunks. And then we’re

going to do non-functional requirements.

This usually gets missed because people

are always thinking of the

functional stories--these are the

foundational, architectural, or anything

that we need to do to be on the right page.

And then we’ll go through

prioritizing, sizing,

estimating, and finally developing a plan.

Our next part of the

agenda is actually going into the

iteration itself and experiencing some

of the activities. So, let’s get started with visioning.