Stakeholder Stewardship

 This section is called Stakeholders Engagement, Domain III.

 Stakeholders Engagement is about how do we get the stakeholders involved on the
project.
 Why is it that it's so important to make 'em involved?
 Well, by having them more involved on the project, it will lead to a higher customer
satisfaction.
 We can uncover risk or hear what they think, the risk would be on the project earlier,
faster.
 We can know if what we're working on is what they're looking for earlier and faster.
 So the earlier we get 'em involved, the better it is for the project.
 Stakeholder Stewardship is about looking after everyone that's involved in the project.
 It's ensuring that everybody on the project has everything they need to complete that
project successfully.
 It includes ensuring the team members have the right tools, such as the whiteboard,
low-tech, height-touch.
 That can include teaching the stakeholders the Agile methods so they understand how
Agile works.
 That can include informing management how the Agile projects does their processes
and how it's different than traditional project management.
 It's not just giving the team members tools, but it's working with your customers.
 It's working with your senior management.
 It's working with the product owner.
 It starts by knowing who your stakeholders are.
 So we have to go out and identify those stakeholders before you even start looking
after their needs or seeing what is it they will need to complete that project
successfully.

Educating People About Agile

 If someone does not do an Agile process that they're supposed to do,such as the
product owner doesn't wanna prioritize the product backlog, the team doesn't wanna
use low tech, high touch tools.
 So your job is gonna be to teach them the benefits of Agile and educate them on why
the product owner should prioritize the product backlog, and the benefits of using low
tech high touch.
 Educating people about Agile.
 You have to become an Agile advocate.
 You have to push Agile, you have to educate people about Agile.
 You have to think Agile in order to pass the tests.
 So that's gonna be a really important technique, not just for your exam but to be
successful in Agile.
It is very easy in Agile projects to go back to traditional project management.
People have a way that if they're doing something new and it's not working out the first time
or it's a little difficult, they like reverting back to the old ways that they know.
We have to consistently push Agile.
We have to consistently educate people about Agile.
Now there's gonna be some concerns.
Senior management and sponsors of these types of projects are concerned
that the project may fail.
Worried that changing, even though they know and even though you tell them the benefit of
Agile:
1. the early delivery
2. they can see value quicker
3. incremental product funding, or project funding.
 There is some benefits to it,
 they may have some reservations.

 And what are they worried about?

 Senior Management and sponsor: worry about the risk of failing.
 Managers: fear the loss of control
 Project team: resist agile methods.
 Users: will not get all features

 This new Agile method may cause the project to fail.

 Managers, in particular project managers.
 Imagine you're coming from this traditional project management setting where you're
the head of that team.
 That team looks up to you, you make the decisions for the team.
 Imagine you're coming from that type of background.
 You're gonna do the servant leadership.
 So you're doing servant leadership and the team is making all the decisions,
 and that's leaving you out.
 Well, now all of a sudden you're losing control.
 So you may fear this loss of control.
 You may fear the team may make mistakes.
 The team themselves can resist Agile methods.
 A lot of team members, especially software development for a long time, may resist
Agile methods.
 They may not want to do a daily standup meeting, they may not see any benefit to it.
 They may see that customers keep adding changes and reprioritizing as more of a
nuisance or a distraction than actually helping the project.
 Some traditional programmers may say the customer determine what's important on
this project is a disaster.
 So the team themselves may be resistant to Agile methods.
 Now users will have to come to understand that they may not get all the features they
want.
 On the traditional project, all of the requirements are gonna probably get done
 because there's no real prioritization of it.
 We just take them all and we get it done.
 Now, we have a fixed time and cost, remember the inverted triangle, we may not do
all the scope.
 We may not have all of the features done.
 So users may fear, well all of my features will not get done.
 But that's the point of it, right?
 That's the point of Agile just get the most valuable done.
 These are some of the concerns that we have to manage as we train people and teach
people about Agile.
Engaging Stakeholders
 One of the main things that we do to keep our stakeholders engaged is the short
iterations and the releases really keeps them engaged.
 At the end of every iteration, which should be no more than four weeks, they come in
to review the product that is getting made.
 So they have a sense of how this project is progressing.
 They have a sense of how the product will look and feel every single month at a
minimum.
 So this really keeps them engaged.
 And then as the releases are coming out, every time you release new software
 Eg. they start to use it. Then they start giving feedback right away.
 Now, that's the objective.
 Keep them engaged, get their feedback.
 This can help us to identify risks very early and issues.
 For example, if the stakeholders finds that this report doesn't have all the fields they
want or the calculations are wrong on the report or it's missing specific data,
 you can find these things very early instead of until the project is done.
 Now, this can also lead to more change request
 because the more they use it, the more they're gonna ask for changes.
 Now, remember, agile principles is a good thing that they, want changes, means
they're engaged.
 And when the product is truly done, we're really gonna match their requirements.
 Now one other thing about having people constantly being engaged on a project is this
concept of issues.
 Now, some stakeholders may cause problems, some stakeholders may have a lot of
issues with the project manager or that their features are not getting done.
 Anytime you deal with people, you can expect to have issues with people.
 Now we have to manage this correctly.
 We have to come up with methods or ways in order to have, in order to manage
issues.
 And that generally involve having a process to escalating stakeholder issues.
 Now, we're gonna be using our interpersonal skills
 and we'll talk more about how to manage issues and problems later.
 But it really involves using your interpersonal skills, your communication skills,
 in order to resolve these issues.
 Why do we want to do this?
 Why do, why such a big focus on stakeholders and a whole domain on it?
 Project is done for people by people.

Methods of Stakeholder Engagement

 What are some different methods of ensuring our stakeholders are engaged?
 One of the things we must do from the very start of stakeholders engagement is we're
engaging the right stakeholders, decision makers, people that's been with the company
long, people that has a lot of experience with the product or that particular
department.
 You don't wanna go to and ask the accounting department or people in the accounting
department how to make a CRM that should be done by sales people.
  You don't want to ask a new salesperson to this organization who doesn't
understandhow this organization conduct its processes to close a sale.
 You don't want to ask a new person.
 You wanna ask a senior salesperson within that business.
 So you gotta make sure you get the right person engaged on your project.
 Now you wanna be able to cement their involvement.
 You wanna be able to show them the benefits of the Agile project.
 You want to be able to have them willingly, not forcefully, willingly, want to
participate
 and feel that this project is gonna be a benefit for them.
 Now, you wanna actively manage their interests.
 You want to look at their requirements.
 You want to give them updates on the requirements.
 You want to ensure that they understand that their requirements are getting done
 Now, one of the topics I talk about is the gulf of evaluation.
 Also look at the Definition of Done.
 So we have to constantly, frequently discuss what done looks like because you don't
want to have the gulf of evaluation, and you're thinking something completely
different.
 You told the development team how you think you saw it, and then they heard
something completely different.
 At the end of it, you give them what they want, not something that you interpreted.
 You want to be able to show progress and capabilities.
 You want to be able to show that the project is progressing.
 The best way to show that is by giving them the product to use it,
 giving them that release so they can start using it and gaining value from it.
 This project is progressing, and it's really giving them value.
 We wanna candidly discuss estimates and projection.
 You want to come to them and let them know what are the time estimates, the cost
estimates, when the project will be done. "I'm projecting this project will be done in
two months," or, "We may run outta money in three months, and that'll be the end of
the project."
 So these are things that we are engaging the stakeholders.

Agile Chartering
 In a traditional project, a project charter is used to authorize the project.
 So if you have your PMP, you remember:
1. the process of developed project charter that's where you create this charter
2. write some high-level requirements for it
3. get the sponsor
4. senior management to approve it.
 An Agile charter is basically the same as a traditional project management charter.
 It's a high-level document and it generally, has the W5H
1. Who
2. What
3. When
4. Where
5. Why
 6. How
 So it's needed to answer
1. who might be doing the project
2. who might be working on a project
3. where it'll get done
4. why are we doing this particular project?
 So you're gonna have to go through all the five WS and answer them within the Agile
project charter.
 Now, it does serve as an agreement between you and or between the entire project and
the customers or the sponsors in order for them to start paying for this project to get
done.
 So it is this agreement between the development team, the project manager, and the
organization itself.
 Now, once the charter is signed, this will give you the authority to proceed and start
with all the agile processes, start gathering those requirements, and prioritizing them
and so on.
 Focus not exactly on the requirements in depth,
 Focus on how the project will be conducted.
 Don’t focus on the requirements in depth because you don't know them yet.
 You haven't really gone out and gather all these requirements completely yet.
 So you wanna focus more on how the project will be done.
 You wanna list why you're gonna be using Agile and the methods to doing that.
 This is gonna allow for a lot of flexibility and the ability to deal with changes
 because if you list this out, you'll be able to say and tell the organization that we're
gonna be following Agile practices.
 You should have specific processes that are gonna be outlined, such as the customers
and the product owner will be able to prioritize the product backlog.
 One particular way of how you can describe your project goal of what the project is to
use something called a project tweet.
 Now Twitter by itself allows more than up to 280 characters, but it used to allow 140
characters.
 Can you describe the goal or the end result of a project in 140 characters or less?
 That's really what a project tweet was.
 That's included in the charter.
 The charter shouldn't be something that's big
 and complex and has a lot of requirements or texts in it.
 You want something that's smaller, something that's briefly describing it.
Definition of Done
 This is about creating a shared vision of what done looks like when the project is
finished.
 This is something that has to be frequently done, something that you have to
consistently do all of the time.
 Not only because when someone tells you something, you may misinterpret it, but
also because people can change their mind.
 People can describe something to you and be thinking of something completely
different than what they're describing.

 Another thing, from their perspective,

  sometimes I'm describing things to a developer
 or maybe a team member and I'm telling them what they want, and for some reason,
what I'm explaining is not what they're envisioning.
 So you don't want this.
 You wanna be able to have this definition of done correctly,
 so you can make that product as good
 or as best as you could to match their requirement.
 When the product is finished, when the software is done, there shouldn't be any
surprises.
 When they look at the software,
 and this isn't the perfect world.
 When they look at the software and they say, oh, okay, that's probably good.
 If they look and go, wow, I didn't expect this, now you have a problem.
 If it's a surprise and their face is like, oh, what is that?That is not good.
 That means the definition of done wasn't done correctly.

 Need to do the following all of the time:

User Stories
 You should have a definition of done for user stories.
 When you write the user stories, you have to ensure that this definition is done, is
correct, and they understand it.
Releases
 You should have a definition of done for releases.
 So when the release is given to them,it's not a surprise to them.
 They were expecting it, they knew what it looks like.
Final Project deliverables
 The other one is the final project deliverables.
 It is different project deliverables or the end project of itself, the deliverable of itself.
 Those, of course, you'll have to have a good definition of done.

Set a shared vision

 Important to ensure customers and agile project team has the same vision.
 We need to know the definition of done.
 We need to know what your customers are thinking.
 When we're able to deliver those products to them, we deliver the product that
they're actually looking for.
 That is set in a shared vision.

 Methods include
1. Agile Charter
2. Definition of “Done”
3. Agile Modeling: use case diagram, data models, screen design
4. Wire frames
5. Personas

 Now, it's really important that you know what they want and they know that you
know what they want.
 I'm gonna be going through a series of slides in a few minutes that's gonna cover
those things and that's gonna include using certain agile models, like a case diagram,
data models, screen designs, wire frames.
 We're gonna look at personas also, and we'll do a quick look at what an Agile project
charter is.
 It's about establishing that I know what they want and they know that I know what
they want.
 So they have confidence that when the product is done, we're gonna give them what
they want.
 You ever worked on a project before where you told the developers, or the contractor,
or whoever is it that was doing it, what you wanted?
 You were saying to yourself, "Man, this person really doesn't understand me.", or you
were saying to yourself, "I don't think he understood what I was saying,"
or "She didn't understand what I was saying."
 And you're going back to your room and you're thinking, I didn't think I explained
that enough, and I think they're gonna mess this up.
 You don't want your customers to have that feeling.
 You want your customers to have a strong feeling internallythat you really know what
is it that they're thinking and you really understand what is it that they're envisioning
for this project.

Agile Modeling
 Some different models that we can use that can really help us define that definition of
donor set, that shared vision.
 So these are different models that we're gonna be using so they understand or we
understand what they want and then we have a much better understanding of what
exactly they're looking for.
 Now, Agile models should always be lightweight, barely sufficient.
 You don't need anything complex to do this and you'll see them as I go through them.
Use case Diagram

 The first one is something called a use case diagram.

 So use case diagram is something that visually shows how a user would use an
application.
  So in this one here, how a waiter would order food, how a chef would make the food,
how a client would eat the food, how the cashier would accept payment.
 This here you would make for all different applications.
 Let's say you're doing one for an accounting system, you would write accountant or
you write accounts receivable clerk and then you'd write, okay, they'd create an
invoice, they'll be able to send the invoice, they'll be able to receive payment.
 It's basically how users will use a particular application.
 But it's a visual thing.
 Visual thing, remember a low tech, high touch,
 visual representation is always good.
Data Models

 Another one I have here is called data models.

 Now if you're a database programmer, if you are an application developer, you
probably know what these are already.
 This is how we structure data and tables.
 Relational databases are, is based on tables and these tables stores data in them.
 The tables of themselves are made up of columns called fields, and these columns,
they are gonna be things like the customer name, the last name, the address, the social
security number, the phone numbers, and so on.
 And then you're gonna have other things that these tables are related to.
 Maybe the, you have an orders table.
 So one customer can put in many orders.
 Maybe you're selling books and you're gonna have the book name, and the date, and
the price and so on.
 So data models will basically show me how the data will be structured in tables
 and the relationships amongst them.
 So maybe one table, one of these records in this customer table can have many order
records.
 This here is probably not gonna be on your exam because this is something very
particular to database designers, and database programmers and so on.
Screen Design
Simple, Screen shots.
  Screen design is one of the best things that you can do.
 Something very simple.
 It is just drawing on paper.
 This is a very simple thing that you could do that when they're explaining how they
want the application to look or how their report should look, one of the best things
you can do is just give them a screenshot that you probably drew.
 Or you can use different applications, preferably not, but you could use applications
to design the entire screen to show them what it looks like.
 Users are gonna be very visual because when they're using it they don't see the
backend code like you do.
 They may see just that screen, that screen that they're using and they find that to be
the most important part of the software because they don't know the coding that goes
behind it.
 So I think screen designs are very good as just sample screenshots that they're gonna
have.
Wireframes
 Another one is called wireframes.
 Now this is basically known as low fidelity prototype and it's a quick mockup of a
product.
 You make a screen and you put the buttons on it and then you make this next screen.
 There's no coding there's no real coding that goes behind it.
 You make the next screen of what happens if you click this button, then this screen
appears, then you click this button, then this screen appears.
 This really helps to clarify what done looks like.
 Now, it doesn't really have coding behind it.
 It's not like you're gonna go write all the codes for it.
 Some people may put some code in, but generally not.
 This here is gonna really clarify what done looks like.
 It really validates what this application and how it's used before you go out and you
start programming these applications.

Personas
 The next Agile tooling is personas.
 Personas are basically quick guides or reminders of the key stakeholders, their interest
in how they find value on the project.
 This is basically going to be a description of the users.
 It's going to be able for them to have an opportunity to give us the values or things
that they find the most valuable on their project.
 It should be grounded in reality.
 It should be goal-oriented, specific, and relevant to that particular user.
 It should be tangible and actionable.
 So you can actually take actions on what value they find in that particular software
you're making.
 This really helps to generate focus on the features that the users are looking for.
 I recommend to make a persona for every single users or types of users that you're
going to have in that particular software.
 Now, you don't only have to do software development for this, or use this in software
development.
 Even if you're building a car, you can create a persona of the community that you're
selling that car to or the type of user.
 So if you're making a family SUV or a sports car for somebody on the weekends, you
should know what type of person you're going to be selling it to and how that person
is going to see value in it.

 First of all, there's a description and then there's a value aspect of it.
 So we know who the user is and we know how they're going to see value
 in your product or your software.
 So the description says, "Andrew has been an accountant for over 10 years and has
worked with many large accountant firms."
 So that's a little bit of his background.
 "He likes to be organized and get his work done on time."
 Now, what is the value?
 What would Andrew find value in your particular software you're making?
 So the scenario here would've been that we're making an accounting software.
 We're making QuickBooks again for this business.
 So the value here is Andrew would like to ensure all company bills are paid on time
while using online auto payments.
 So the first thing is, this really helps us to understand that the value he's finding is
getting those bills paid on time, and he's going to find a lot of value by allowing us to
pay bills online.
 He would like to ensure customers are reminded automatically of outstanding
balances.
 So we need to find some way to give him auto reminders or give him reminders of
customers that owe money.
 He's looking to print the receivables and payable reports on a weekly basis to check
on bills and invoices.
 So, we have to be able to provide those reports to him.
 These are the values he's looking for.
 If you were to make this for all the different types of users and list out the values,
what is it that this particular user or this type of user or this community of users will
find value?
 Not only are the users making this for you or helping you to make this or you're
helping them, but what's good about this is that now we really understand how they
would find or how they would use it to get value out of your product.
Communicating with stakeholders
 The most important task on any project, whether you're following a traditional project
or an Agile project, communicating is key to a successful project.
 Communicating is a key to a successful relationship with your spouses and your
friends.
 It's a key to a successful business relationship in your work environment.
 Communicating is key to a successful life.
 Let's see what we're looking at in Agile.

 face-to-face communication
 Two way communicaion
 Knowledge sharing
 Information radiators
 Social media
face-to-face communication
 In Agile, one of the most important aspect of communicating lies in face-to-face
communication.
 That is one of the most important aspect within the Agile low-tech, high-touch type
communication.
Two way communicaion
 Two-way communication is when I'm talking, you're gaining information.
 I'm listening to you, you're listening to me.
Knowledge Sharing
 We'll talk a little bit here about knowledge sharing.
 Now remember this aspect of in extreme programming, one of their values was
knowledge sharing.
 In other words, everyone will help each other: generalizing specialists.
 Information radiators, something that we have mentioned, things that can radiate
information as you walk into a room.
 what is the best form of communication?
1. face-to-face communication.
 It's face-to-face communication with a whiteboard.
 That's the best form of communication.
2. two-way communication
 The other thing here is gonna be two-way communication.
 Just don't ask for confirmation or concerns, but listen to what people have to say.
 When you're talking to someone, you should be interacting with them or they should
be interacting with you.
Knowledge sharing
 Agile teams, pair programming.
 Generalizing specialists is a theme
 We help each other.
 We share knowledge with each other.
 So Agile teams work closely with each other,such as with pair programming.
 Using Kanban boards or wireframes are good ways to share information.
 Because the Kanban boards, not only will we help to radiate information quickly out
as people walk in, but also using wireframes and the mockups of what the software
 looks like, now we know, and now we can share information on what this product will
look like.
 Low-tech tools, like a whiteboard, would allow users, would allow all to see the work
and understand it.
So this goes into more information radiators.
Remember, if something is not on a whiteboard, for example,
and it's on an application on your computer,
then no one could really see it, right?
We must encourage this.
We must encourage knowledge sharing amounts:
programmers with users and our programmers with us and the product owners and customers,
and all combinations that you can think about.
Information radiators, highly visible.
The whiteboard behind me, the big chart that I would put on the wall would be good
information radiators.
This is gonna be used to display information.
Now, I did do a training with a group that didn't like this idea of whiteboard.
So what they did was these big, flatscreen TVs and they were using Kanban software onto
them, but they would be projected.
They would be up on the wall all of the time.
I would still prefer it to be on a whiteboard though.
I don't like that idea of just having it
because if the TV goes out or the TV's not working,
then out of sight, out of mind again.
So I would prefer the information radiators to be something that is on a whiteboard driven a
flip chart.
All right, so these things has to be highly visible.
They're gonna be used to display information, usually includes charts, graphs, and different
types of boards.
Now, the other one here is social media.
So things like Twitter or Instagram,
we can use these to communicate with our users.
Users can see how we are communicating.
A lot of the world now communicates using social media.
Okay, but we know communicating with stakeholders
is important.
We know the Agile aspect.
We wanna make sure we have this low-tech,
high-touch approach to communicating.
We know for our exam, face-to-face.
Now, quick tip for the test:
Doesn't matter what the exam will tell you or the question,
what they say and how they say it,
and how much they try to trick you.
The answer in any issue or any issues of communication is always to bring them face-to-face.
I'll give you an example.
You're probably gonna get a question where it's like you have this diversified team
and they're having issues communicating because they're located in 10 countries around the
world.
And then the choices would be like implement good communication software;
reconfigured the communication software; speak to the vendor about the comm;
and then one of the choices would be like way out of place.
It'd be like, bring them all together on a co-location and have them give them a whiteboard.
And it wouldn't sound feasible, but that's the answer because that's the Agile approach to this.
So remember something:
What you would do in real life may not be what you do.
You know, in real life, it may not be feasible to bring people from 10 countries to work in
one space, but that's what they want as the answer.
Keep that in mind when you're answering the questions.

Green Zone and Red Zone

 When you are communicating with stakeholders, you may have some stakeholders
that are very defensive and upset about your project, or you may have stakeholders
that are very happy, enthusiastic about your project and looking for it to be successful.
Red Zone
 They blame others for everything.
 They respond defensively.
 They feel threatened.
 They trigger defensiveness.
 They're always on the defendant and they feel like people are out to get
them.
 They don't let go or forgive.
 So if there is an issue, they wouldn't let it go.
 And they don't wanna forgive people, even if you make a mistake.
 Shame and Blame to other people.
 They focus on short-term advantage and they don't look at the long-term aspect.
 They're looking at the short-term gain.
 They're not looking at the top of the mountain.
 They don't seek or value feedback from anyone.
 Giving feedback to them, they become more defensive.
 They see conflicts as a battle, which they only want to win.
 It's all about winning only.
 They communicate, high levels of disapproval.
 Anytime, anything that you ask them, it's all about how much they don't like it, versus
the positive aspect of it.
 Remember, the glass can be either half full or half empty.
 They see others as problems or enemies and they don't listen effectively.

 You don't want your users, your customers, your team members to be in this zone.
 Now, if you're working on a project currently, you probably can think of someone in
your life, whether it's someone at work, someone at home, someone in your family
that is probably in this Red Zone.
 That is very difficult to work with them.
Green Zone
 This is when people take responsibility for the work that they do and maybe even for
their mistakes.
 They seek to respond non-defensively.
 Now, if something goes wrong,
 they're probably saying, "Well, it's okay,
  I made a mistake."
 But they're not gonna be defended.
 They may just accept it.
 They're not easily threatened psychologically.
 They attempt to build success throughout their lives.
 Persuasion rather than force.
 "Do it this way," is force,
 versus, "I think we should do it this way.
 What do you think?"
 And here's the benefits.
 Think both short and long term.
 Think of when you're climbing that mountain to get to the top, there's gonna be a lot
of falls, but you gotta think of those falls, but you're gonna also see the end.
 Welcome feedback.
 One of the things that I do in my life, is I love feedback and I ask all my students for
feedback.
 I ask students to leave us reviews.
 I ask students to give me feedback on how I'm conducting the class and what I could
do, what I could do in my next class to make it better.
 Sees conflict as a natural part of life.
 We are humans.
 And when there's humans, there's always gonna be conflict.
 Humans have been having conflict and having world war, fortunately for the, our
entire existence, we have been fighting with each other.
 You should never see conflict as something that should never happen.
 It'll always will happen, but we have to see it as a natural part of life and try to make it
as constructive as possible.
 Remember, one of the things about conflict in this ITIL class is conflict means
 people actually care about what they're doing.
 'Cause the worst thing they can do is not care.
 Seeks excellence rather than victory.
 Listen well.

How to conduct a workshop

 Throughout the Agile project,you're gonna be using a lot of what's called workshops.
 Workshop is basically a meeting, where work actually gets done.
 That's different than a meeting where you may just have a discussion, but this is
where you actually get things done, things of improvement, things of what we did
wrong, things of completed particular user work.
 Workshops are good because it's not just a useless meeting where nothing is an
output.
 There should be some kind of output coming out of it.
Retrospect
 Retrospect is a great type of workshop that we should be doing to really look on what
we did wrong, what we did right, and what we're gonna do more of.
 Now, one of the things I wanna talk about is how to make our workshops more
efficient.
 Now, the way to do that would be to have a diversified group as large as possible.
 The more diversified a group is with different opinions.
  This here will lead to a larger perspective and get more work done or, and allow for
more diversified level or type of work to get done.
 If all the people in the workshop knows one topic, then the entire workshop may just
be about that particular one topic and never diversify to others.
Round-robin
 Another thing you want to do when you're managing your workshop is you want to
use something called round-robin.
 In every group of teams, there's one or two people that are very dominant.
 There's a lot of us have very dominant personality and what happens is these
particular people or person may start to dominate the workshop and drive the
workshop and not give everyone an ability to speak.
 But, sometimes the best ideas or the best abilities that are coming from people is from
the most quiet one.
 Round-robin is when you just go around a room, you speak, then you can speak, then
you can speak.
 Just go around a circle is a type of a round-robin.
 Another thing you want to do is that first few minutes in every workshop or even
meeting is vitally important that you get everyone to speak.
 One of the things that people do is they go around a room and have everyone
introduce themselves, help to quote unquote, break the ice.
 You want to have everyone start speaking at the beginning, and I'm gonna talk more
about this in the end of this class.
 When we get to Domain 7 with retrospectives.
 What starts to happen is from the very start, they feel welcome and they feel like they
can give out their ideas.
 There's a lot of people that may have issues or may be very scared to speak in front of
others.
 They prefer to keep to themselves, but once you break that ice with them,
 you may come to understand these people actually like to talk to you.
 Have you guys ever met someone that are very shy amongst others,
 but when you actually know them and they know you and they're comfortable talking
to you, they talk all the time, or they participate or they're very outgoing,
 but they only do it to certain people.
 You wanna do that from the very start of this meeting.
 Open everyone up, so everyone can talk.
 Now, one other workshop that I wanna mention here is known as user stories.
 Now, a user story workshops are where we write the actual user stories and keep the
stakeholders engaged.

Brainstorming
 Brainstorming is one of the most commonly used methods in meetings, and in
workshop, or generating ideas amongst users.
 Brainstorming has issues though, and we should know how to resolve these issues.
 Eg. if you got a issue to solve and you put a bunch of people in a room to talk.
 While they're talking, they start to generate ideas out.
Free-for-all
 Now, most brainstorming is probably gonna fall into the last option here that's called
free-for-all.
  So free-for-all is when people shout out their thoughts.
 This here has a lot of issues if it's not done in some type of a supportive environment.
 So free-for-all, let's say we're doing a brainstorming on how we should design the user
interface, and I'm gonna say, "Well, I want you to put that buttonon the bottom," and
then somebody else says, "Ah, no, put it on the right side," and then me and this
person go back and forth, and then everybody else starts to join in, "Maybe we should
put the button to the top," and so on, and so on.
 Maybe the size, the color, the width of the button, and so on.
 So free-for-alls could have issues if it's not done in an environment
 where everyone supports this idea and know that it could be a little bit chaotic.
Writing
 Now, there's some other ways of doing brainstorming.
 I like this idea of quiet writing.
 I've used this myself, and I find that this works well.
 Instead of people just shouting out their ideas and then before you know it, it's very
chaotic to manage, how about if we give people about five minutes to write down
their ideas?
 Give everyone five minutes, give everybody some cards and say, "Okay, we're gonna
do a quiet writing brainstorming session.
 We'll talk about them after you have five minutes to write down your ideas on what
we should be doing."
 I think this works well, because now I can get everyone's ideas in there, versus having
some folks that are very dominant.
Round-robin
 Round-robin also, pass a token around.
 So I've done this round-robin, I think this works well also.
 I've done round-robin by passing around bottle caps.
 That could be your token, or coasters, where we put our coffee mugs.
 So we pass this token around for, "Okay when you have the token, you can speak,"
because this helps to stop that, "Okay, well, I'm talking, and I'm so loud that no one
else can talk."
 One of the things I always try to do when I'm doing a brainstorming session
is to have everyone to communicate.
 Give everyone the ability to communicate.
 That is gonna be vitally important.
 There's no point in inviting people to come to a brainstorming session
 if one person dominates the entire session.
 That is not effective, then there's no point.
 Just have that person do a speech and we all listen to their speeches
 if that's what it's gonna be.
 Brainstorming should really be about everyone should have the ability to voice their
ideas and to voice their concern about other people’s ideas.

Collaboration Games
 Some different games we can do to have everyone collaborating on the project.
 Imagine working with your customers by bringing them in and they can collaborate
with you and show what requirements they want.
 I think these are some interesting games here that you guys can play.
  So we'll talk about,three of them.
 Remember the Future
 Prune the product tree
 Speedboat or something referred to a sailboat

Remember the Future

 "Can you remember six months from now when we released that new software
 that whole accounts receivable module?
 What made it so successful?
 What did you like about it?"
 And Bob is gonna say, "Well, it was successful because it was very easy to use at
first.
 I didn't have to read a giant manual to figure it out.
 The interface was very easily or nicely laid out.
 The color options were good.
 I didn't need any more design options.
 The software responded quickly."
 Notice that Bob is giving us everything that Bob really wants.
 He's telling us what we need to give him for him to see this software as being
successful.
 This is gonna give us a better understanding of how a stakeholder would define
success.
 It outlines how we can accomplish that success for them by them telling us basically
what they would look at in a particular software at the end or a particular product for
it to be successful.
Prune the product tree
 Now, the other one is prune the product tree.
 Now, this is something that I've done with users.
 I was working on a school system software and this is something that I worked with
the administration on.
 And I did this and I think it works very well.
 So let's go through the steps and then we'll talk about it.
 First thing to do is to draw a tree and ask the stakeholders to add features to it.
 So you could just draw a tree.
 You just draw two straight lines that comes up with some branches and put the roots
at the bottom.
 Now, the core of the tree here would be the core of the software.
 Like, coming down to the roots and stuff, you can have your databases where the core
would lie.
 Now, then you give everyone sticky notes.
 So you use stick notes to have them place new features on the tree.
 So have them write out all the features and then they start to place them on the tree,
as, like, different form of leaves.
 And then they gotta start grouping those leaves,
 those stick notes to different branches on the actual tree.
 So different features on different trunks of the tree.
 Now, features that are dependent on other features would be higher up the tree.
  So a database would be more towards the bottom because it doesn't depend on a lot of
things.
 It's standalone.
 Everything else depends on that.
 So the higher up, the more you go up is the more those features are gonna be
dependent on other features.
 This lets everyone understand the priorities of development.
 It's a great tool for this and this is one of the main reasons I use it because people may
not understand why I can't do this feature here, because I can't do this feature here if I
don't do this feature here.
 I can't start to do anything with my software if my table structure isn't laid out, if my
data models are not done correctly.
Speedboat or something referred to a sailboat
 Another thing you could do that I find very good to help identify stakeholder, for the
stakeholders to identify threats and opportunities is to use this concept of a sailboat or
speedboat.
 You take a whiteboard and you draw some squiggly line to represent water.
 You just go up and down the line.
 It's gonna represent the water.
 And then what you do is you just draw a boat in this water.
 It doesn't matter how you draw the boat, just put a boat in your water line.
 So you have the water line and you have the boat.
 Now, you put a little sail.
 You draw one line at the top and you make a little sail at the top.
 What moves a sailboat is wind.
 What stops it are things at the bottom, like an anchor.
 Now, the boat of itself is moving, the wind is moving it towards the goal.
 The goal is to complete the project.
 Now, use more sticky notes to show how to move the boat.
 So, now people put things that can drive the boat like less competition, easy-to-do
development, use of the software before, would be ways to move this boat.
 But then you have rocks at the bottom of the water that can anchor the boat and cause
the boat to sink.
 Maybe more regulations or competition are things that you can write.
 So you can start to identify the threats to this project.
 You can start to look at the opportunities to what can help drive your boat or create
wind and push your boat far.
 These are some amazing games that you guys can do with your customers, with your
product owner to really help get them involved.
 And you notice something about these three games: they are all low tech, high touch.

Using Critical Softskills

 Your own critical soft skills is one of the way to engage stakeholders.
1. emotional intelligence
2. Negotiations
3. active listening
4. facilitation
5. conflict resolution
 6. participatory decision models.

 No matter what job you do, whether you're as a project manager, you're a general
manager, you're a programmer, you're a maintenance person that that cleans up the
environment, it doesn't matter basically what job we do today, we need to have good
critical soft skills.
 You need to have good critical soft skills in your personal relationship.
 You need to have good critical soft skills when dealing with vendors, when dealing
with a spouse, when dealing with a regulator, when dealing with a a customer or a
programmer.
 Soft skills are critical to all aspects of life.
 I have over 60 certifications and I think the single, I guess I have a lot of skills I
should say, over 60 certifications I have, I have certifications in accounting, I have
certifications in different types of software.
 I'm actually certified in QuickBooks if you ever wondered why he referenced
QuickBooks a lot but I have a lot of security certifications.
 But I think go and looking through my entire career, I think the number one skill
 that would allow me to get a job that pays well or make me successful is having good,
soft skills.
 I believe I have good soft skills.
 Being an instructor and teaching tens of thousands of students over my career, I think
without the soft skills I would've never been very successful.
 I hope you guys are enjoying my course here and I would love some feedback when
this course is over from you guys.
 Whether you're sending me an email or you're leaving it on some kind of review site
or whatever, I would love to hear your response to that because I look at reviews very
importantly, not just to improve the course but to improve my own soft skills.
 Knowing how to talk to people, understanding people's need, resolving conflicts.
 So as you go through this course and you go through life, I think the most important
thing we can do is work on our soft skills and never think you're ever gonna get the
best at it.
 Anyone that ever comes to you and says, "Ah, I have the best soft skills
that I don't need to learn anymore."

Emotional Intelligence
 One of the main skills we have to have as we are dealing, or talking, or
communicating with so many people is we have to have the skill or the ability to
identify, assess, influence the emotions of ourselves and others around us.
 When you are communicating with people, do you understand when they're happy?
 When they're not happy?
 When they are upset about something?
 If they're concerned about something?
 This is why face-to-face communication is so important, because face-to-face
communication really allows you to see my emotions.
 If you're laughing, everybody laughs with you.
 If you're crying, everyone is sad with you.
 It's just the human nature.
 We have to be able to recognize our own feelings.
  It's only then we can learn how to respond to others and how they feel.
 If we know we are upset about something, they might be upset about it.
 We also have to learn how we can care for ourselves, and how we of ourselves will
impact others around us.
 If I'm very upset and I'm very chaotic then the environment around me may not be
very happy, and it might be just very chaotic.
 Eg, when they're stuck, when they're angry, and they're frustrated.
 It's about reading other people's emotions.
 It's about understanding your own emotions.
 And it's about using your own self, your own emotions to affect and influence others.
 Emotions mean a lot.
 It's not what you say, it's how you say it.
 It's the passion within you.
 I think if I have a passion for this, and I feel very good about this.
 Hopefully this passion is being transferred to you
 Hopefully I'm influencing you to go back to work

You wanna change yourself.

You wanna adapt agile,
you wanna change the way you work, or you wanna get better at it, and that is what this is
about.

Negotiation
 One of the main skills we use in Agile is negotiations.
 You need to negotiate with users for requirements and how to get it done.
 You need to negotiate with team members.
 You're gonna be negotiating with vendors, senior management, and so on, and so on.
 This is something we do almost every single day.
 You negotiate with your children, and your spouse.
 I sometimes negotiate with my dog, right?
 Sometimes my little dog, she wants to go outside and I have to negotiate with her.
 "Well, take this bone, I don't wanna go outside."
 Negotiation is something that we're gonna do all the time.
 This will happen throughout the entire life cycle of the project.
 And good negotiations, how do we know we are gonna be able to do good
negotiations?
 Good negotiations will allow everyone to investigate the options and the trade-offs.
 Good negotiations is not "Well, this is how I want it, that is it."
 Good negotiations is not, "Well, can you do it this way?"
 Good negotiations is not I don't wanna do business with you."
 Good negotiations is, "This is what I would like, this is how I would like to get it
done."
 Good negotiations is "Well, I understand that but this may not be..."
 Good negotiations is to make trade offs, "Okay, I understand, I can't get it this way."
 Good negotiations is “It should be, or it should have room for interactions between
me and you.”
 It shouldn't be one-sided.
 It shouldn't allow for just for me to talk and you basically have to do what I tell you.
  That's not negotiating, that's giving orders.

Dictatorship
 In a dictatorship environment, there is no negotiating.
 "I want this wall painted white, so you paint it white."
 That is not negotiating.
Negotiation
 Negotiating is, "Well, what color you think we should paint the wall?"
 And somebody's asking me that, and I say, "I want it white," and they're like, "Well,
you know, white,the light reflects off the white, so you don't want it a complete white,
because when the light hits it, it might reflect off.
 So you want maybe an off white."
 And then I said, "Hmm, you know what?
 I'll take that into consideration.
 Okay, you're right.
 Because of these bright lights that they set up in these studios, I understand, okay,
 that okay, you know what?
 The off white's probably gonna be better, or the whiteboard, or whatever."
 So this is most effective when interactions between people are positive.
 We wanna stay positive.
 We don't want to be negative, or pushy, or being a dictator.
 And there's always good negotiation should always have room for give and take.
 If it's my way or the highway, that is not negotiating, that is dictatorship.
 Negotiation should happen when I have a little bit of leeway
 and you have a little bit of leeway, because you know why?
 This is something we're gonna do every day in our lives and also in our projects.

Active Listening
 When you were listening to this story, what was going through your mind?

I just made that up because I wanna hear you,

I wanna understand how you were listening.
Now, let's talk about this story that I just told you.
When you were listening to this story,
what was going through your mind?
1. How is this gonna affect me, what does it have to do with the exam?
 That's one way of doing it.
2. Did you put yourself into the mind of me and say, "Wow, that sucks, that's terrible.
 He probably gonna cost a lot of money to fix that car mirror"?
 Not really, it's a cheap car, but...
 Or did you get emotional?
 Did you have body language, like whoa?
 Were you like, wow, that's crazy?
 Okay, your head all started moving, your hands started moving.
 This is the concept of active listening.

 Active listening is important.

 When you're talking to people, are they actively listening to you?
  Are they a level one, two, or three?
 When people are talking to you, as an agile project manager, are you number one,
two, or three?
 You should be a number two or number three.

Level 1:how is this gonna affect me?
 It means you don't care about that person.
 It is not good.
 You're thinking of yourself only, it's like a selfish way of listening.
 You were thinking, when I was telling you the story, what does it have to do with our
exam?
 Why are we listening to this?
 Why is he makin' up this story?
 When a user or a team member starts talking and you're like, what does it have to do
with the project, why are you telling me.
 That person is telling you that because it means something to them.
 You as a project manager, you as someone that they feel important enough to tell that
story to, need to communicate that back with them.
Level 2: You need to put yourselves in the mind of the Speaker.
 You need to feel their pain.
 You needed to feel the pain of me in that story of getting the car hit.
 You needed to, to feel that.
 Listen, I felt very bad, right?
 If the story was true, I would've felt very bad because I had to spend all this money on
it.
 So let's say it was a cheap car and I didn't have to spend, but I still felt bad that I hit
the car.
Level 3: In a global listenining, now you start to have emotional aspect.
 Now people can look at you and see you're emotionally reacting to their story.
 This is when they feel good.
 Imagine you're talkin' to me and I'm lookin' at you like, what does it have to do with
me, what does it have to do with this project?
 Or you can look at me and you can feel in the tone of my voice that I feel your pain,
or if you're excited, I'm excited.
 Then you're gonna wanna keep talking,
 you're gonna wanna keep collaborating with me.
 Or imagine you come and tell me, Andrew I passed my exam.
You call 'em enthusiastic.
You call 'em great listeners.
You call them good emotional people
and you like being with them.
But why?
Because they care about you
or you feel that they care about you.
Because not only do they show it with their voice,
or I should say listen to with your voice.
Not only do they show it with your voice,
but they show it with their body language.
And now you have a closer connection to that person.

Facilitation
 One of the things for Agile project managers is that you have to become a good
facilitator.
 Facilitator means to running your workshops and your meetings very effectively.
 Most of the time on Agile projects, you're talking to the group or to two or three
people so you have to facilitate that type of communications.
Facilitation includes the following
 Goals
 Rules
 Timing
 Assisting
Goals
 Now, when you're facilitating a meeting or you're facilitating a workshop, you should
know what is the goal?
 What are you trying to accomplish in this meeting or this workshop?
Rules/Ground Rules
 The next thing is to have ground rules, such as, you can't use your cell phone while
doing this meeting so people are not distracted.
 Ground rules can also include etiquette, like no foul language, no overtalking each
other.
 People should know these rules before they actually get to the meeting.
Timing
 The other one is timing.
 So meetings can be an incredible waste of time.
 We have to make sure that we have timing on our agendas.
 So if we are gonna be doing this topic, we'll spend 10 minutes here.
 We're doing another topic, we'll spend 15 minutes there.
 So we wanna have timing.
Assisting
 Assistant, having assistants or assistant people with the topics are gonna be important.
 So we have to find ways to run effective meetings.
 Every day has daily standup meeting, you're doing constant workshops with users,
such as when you do retrospectives or even when you do the sprint review,
 Those are also gonna be places where you are gonna need to facilitate those.

Conflict Resolution
 Conflict Resolution is important for exam because every project can have conflict.
 Sometimes, not small conflicts, but a lot of conflicts.
 People have conflicts, people have disagreements.
 It's just human nature.
 It's just the way projects work.
 It's just the way teams work.
 It's the way human get along.


  So all projects will have conflict.
 Some level of conflict is good, but we have to ensure that they don't become
World War.
 We don't want 'em to try to destroy each other.
 We have to be at the point where conflict is good because we know it shows
that they care about the topic that they're talking about or they have a very
passionate feeling about their methods of doing something.
 But you also have to understand that conflicts themselves could lead to
physical alterations or physically hurting each other.
 So we can't let the conflict escalate too far.

There's different levels of these particular conflicts that we should be familiar with.
Level1: Problem to solve=> sharing information
Level2: Disagreement=> Personal Protection
Level3:Contest => must win
Level4:Crusade=> Protecting one’s group
Level5:World War=> Must destroy the other

Level1
 Problem to solve=> sharing information
 This is a conflict where it's just started off and people are not there to kill each
other or hurt each other.
 I don't like the way you're doing it but here's how I would do it.
 So, it is share some information.
Level2
 Level two is disagreement.
 Level two is personal protection.
 I don't like the way you're doing it, but I think my way is better.
Level3
 Level three is more of a contest.
 This is where my objective is to win for you to lose.
 Because this is a conflict that's gonna be very difficult to manage because it's
not no more about what's best for the project, it's I must win and you must
lose.
Level4
 Level four is about a crusade.
 Crusade is about protecting my group.
 It's about forgetting about you and your group.
 So level four is a conflict that may not even be solvable at this point.
Level5
 Level five does nothing to solve.
 A level five is I must destroy you or you must destroy me.
 Physical alterations probably gonna happen at a level five.
  There's nothing good that can happen.
Solution for level5
 The best thing you can do at a level five is to separate them so they don't
physically harm each other.
 And after they calm down, after a while maybe then you can go back and try
to see how to resolve this particular conflict.
 So one of the things we must know for our exam is don't let conflicts escalate.
 Use your interpersonal skills, your critical soft skills that you have,
 in order to understand why this person's perspectives or ideas are different
than this person.
 And can we meet each other in the middle?
 Can we find ways to negotiate a better solution so conflicts don't escalate?
 Because if it comes to a level five there may not be an option to fix or solve
this.

Participatory Decision Models[For Decision Making Process]

 These are the ways to come up with decisions on a project while having one,
while having everyone participate, while engaging all your stakeholders in the
decision making process.
 When you're making decisions on a project, whether it's to resolve a conflict,
whether it's to decide on what features to include or not include, there has to
be a way to keep your stakeholders engaged, or participate in any which way
on the project.
 3 quick ways are the following:
 Simple vote
 Thumps up/down/sideways
 First of five

Simple vote
 One way is, we want to make a decision on should we use this method or that
method?
 You can just go around the room, and ask for a simple vote.
 Do you want it or do you not want it?
 I vote for it or I'm against it, easy.
Thumps up/down/sideways
 The other one is thumbs up, down, or sideways.
 I support it or I don’t support it or sideways is if they can't make up their mind,
I'm not too sure whether I support it or I don't support it.
First of Five
 Another one is called the first of five.
 People how up finger based on they support the idea.
 1finger:total support-5finger:Stop against it.
 So the fist of five is do you guys like this idea?
 I'm gonna put up a one, I really like that idea.
  Do you guys like this idea?
 Number two, I have a little bit of reservation.
 Three, I have a lot of reservation.
 Four, I may not like this way at all.
 And five is just stop, right?
 So when you have your full hand up, it's like, stop.
 We don't like that idea at all, or I'm not down with that idea at all.

 So these are just three simple things you can do because you wanna keep
your stakeholders engaged, right?
 You wanna keep them engaged in that decision making process.
 Make them feel like their opinions count, and using these three ways is really
easy ways of just basically using your hand, I'm like using your hands and
saying, I like this idea, or I don't really like this idea, or just stop, no, that idea's
no good.
 It's just easy ways of getting them to participate and getting them engaging
on your decision making process.

People Over Processes

 Project management should not be called project management.
 Project management should be called people management.
 Project managers don't use software to code applications, programmers does.
 They facilitate the processes that is needed in order to manage the people on
the project, customers, senior management, developers, or painters, if you're
painting a house, contractors, consultants and so on.
 In the Agile Manifesto, individuals and interactions over processes and tools.
 Because projects are done by people, for people, not tools.
 Microsoft Project does nothing on your project unless somebody comes and
uses it.
 But you need to manage that someone so they can use it correctly and
beneficial to the project.
 Projects are more about people management than tools, especially from our
perspective, of being the Agile project manager.
Constructive Cost Model
 People consume a lot of our resources on a project.
 To illustrate this, there's a model for this.
 That model is called a Constructive Cost Model.
 Now, the Constructive Cost Model helps you to look at cost factor within
different variables on a project.
 So to determine correlation between project input variables and the final cost
to use, to estimate future projects.
 So if you're estimating future project, there's some variables we can use
Constructive Cost Model
  Let’s look at the model.
 This model look at a different cost.
 These are the different inputs and variables in a project.
 Cost for Schedule Constraint, Project Precedence, Design, Reuses that you can
be reusing, Computers, Tools and Processes, Products and People.
 Tools and Processes has a score of 3, while People has a score of 33.
 11 times more than the cost of the tools and the processes.
 Basically, this is not for your exam but just to illustrate the different types of
cost modeling for projects.
 So if you use tools and processes and it cost you $1, then the people cost of
this project is gonna be $33.
 So, People factor has a score of 33.
 That's gonna be 11 times more significant than tools and processes.
 The main point is manage your people.
 Ensure that your team is taken care of because it is the biggest cost to your
project.

Development Team Roles

 3particular roles that occurs on an Agile project.
1. Delivery Team/Development Team
2. Product Owner/Customer.
3. Scrum Master/Coach/Agile Project Manager

 product owner = a scrum term

 customer = an extreme term

Delivery Team
 The first one here I have is the development team or the delivery team.
 These are the group that build and test the increments of the product.
 They build the product in increments.
 Remember, this is your developers/programmers.
  They update those information radiators such as if you have whiteboards, if
you have Kanban boards or task boards, they should be self organizing
directing.
 The project team is a self-directing team.
 They organize themselves,
 they determine how they do the work.

 We are servant leaders.

 They're gonna share their progress by doing daily standup meetings.
 They're gonna write the acceptance tests.
 They don't define the criteria.
 That's done by the customers,

 Customers define the criteria.

 They do demo the completed product increment when it's done during that
sprint review.
 They hold a retrospective meeting at the end of all the sprints.
 Does release and sprint planning and estimation.
 They do plan how to get the work done for that release or that particular
sprint, and they determine the estimates of the work.
 Only they should know how long work should take to get done.

Product Owner or Customer

 They are the person that prioritizes the product features and the product
backlog.
 Product backlog is a list of work, that all the work we can get done in this next
coming sprint.
 They manage the product backlog, ensuring that it's accurate and up to date.
 They have groomed this product backlog.
 They ensure the team has a shared understanding of the backlog items.
 Remember =>shared vision.
 They have to ensure the team actually knows what is it that they want.
 Even though the team writes the acceptance test, they will determine the
acceptance criteria.
They provide the due dates for the releases.
They attend the planning meetings, the reviews, there is the sprint reviews and the
retrospectives that comes at the end.

Agile Project Manager

You're a servant leader.
Help the team to become self-dependent, self organizing, and self-directing.
We talked a lot about, in the previous domain, we talked about you being a
facilitator.
One of the main things, facilitating meetings and workshops.
It's very important that you act as a mentor and a coach to the team.
Ensure the team plan is visible and the progress is known to the stakeholders.
You should know what the team plan is.
You should ensure that people know what the team is doing.
You are that liaison between the customers and the actual developers.
You work with the product owner to manage the product backlog.
You no need to do it, you're gonna work with them.
If you facilitate the meeting, you need to ensure issues are gonna get solved.
Why?
In the previous domain, we talked about issues getting escalated too high up the
ladder.
You want to be able to resolve those issues, so you ensure that they're solved.
All right, these are three main roles that happens on an Agile project and some of
the things that should be done in these roles.

Building Agile Teams

When building an agile team, one of the most important things to remember is you're a
servant leader.

Traditional Teams
 Project managers at the top, team follows.
 That is a traditional project.
Agile Team
 you're a servant leader.
 You fetch food and water,
 so you're there really to support them versus direct them
 because they are self organizing and they're self directing.
 It means they determine how to do the work.
 They determine their path of getting the work done.

 Now, that is a core concept of agile project and it will be a core concept of your exam.
 For your exam, you want the team to be small.
 You don't want it to be any bigger than 12 people.
 Now, in real life, you may have more people
 but for your exam, we're gonna keep it at 12 people.
  So you want the team to be small.
 Why? Because when the team gets too large or too big, it becomes difficult to manage
them.
 It becomes difficult to have collaboration.
 It becomes difficult to share knowledge on larger teams.
 You wanna break your teams up into small, if you have big teams, you wanna break
them up into smaller teams, make them much more efficient.

Generalizing Specialists
 It is a very important topic for your exam.
 This is a topic that you really have to understand for your exam because, one of the
things we learned about an extreme is sharing information.
 If you get questions where the answer would be have another team member help
them.
 Specialist is someone that knows one thing and knows it very well.
 This person doesn't know any other tasks but that one task.
 If you only do databases or UI design, then I can't ask you for help if I ever have a
problem with the UI, if you have a problem, then I can't help you.
 That becomes an issue because it can lead to bottlenecks.
Database
 For Database, we have the programmers, UI designer.
 Database designers finished designing the database, giving it to you now to code it
and you've ran into some issues code in it.
 Now they're finishing the work, they're giving it to you, but you're not finishing your
work, and I come after you. Well, you know what starts to happen is you become my
bottleneck because you're not finishing your work.
 I'm sitting here reading the news all day.
 I'm sitting here playing solitaire all day because I'm just waiting on you and your
work is piling up.
 I can't help you because I don't know your work.
 When you're building an agile team, you don't wanna build a team of just very
specific specialized skills.
 You wanna have members that can do different tasks.
 You want to have members that are skilled in more than one area.
 By doing this, so I know how to help the databases and help with database design.
 If I could do that, then I can go in there and help you with the database so I can reduce
the workload on you, reducing that bottleneck or eliminating that bottleneck.
 Because you can look at me and says, I'm getting stuck on this database. I can't figure
this out."
 And if I know it, I can look back on it and says, "Oh, that's easy. I could fix that.
 Let me show you how to fix that really quickly."
 So I go in there and I help you out and the work keeps flowing.
 This is a core concept of agile practice.

 Small team, self organizing, self-directing, generalizing specialists.

 Now, another thing to consider here
 when you're building a high performance team is you gotta have this shared vision.
 People should know what they're working on, have realistic goals.
  Realistic goals means goals that could be met, not goals that can't be met.
 I want to be a trillionaire.
 That's not a very realistic goal.
 But me being very successful in my work and being able to own a house and drive a
car, maybe those are realistic goals that I can set because they're achievable.
 You being a billionaire is probably not an achievable goal for everybody.
 Fewer than 12 members.
 You wanna build a team that have a sense of identity.
 Let them feel that they're part of that team.
 And then one of the most important part of any agile team is the having a strong
leadership, right?
 Provide strong leadership to them.
 Be a servant leader to them.
 Let them know you support them, facilitate their processes, and this is how you're
gonna build a really high performance agile team.

Safe place
 To build an Agile project team, you have to have the ability to allow safe
places or safe spaces where your team can experiment with new methods or
approaches on a project.
 This is highly important because you are gonna have team members that
wanna try
 new ways or new processes or new software or new tools and they're scared
to do it because if they do it and it fails, it may delay the project.
 And if that happens, they may be prosecuted for it.
 For example, other team members may get very upset with them and not
wanna talk to them.
 They may be fired from their job.
 In other words, when you try new things at a particular job,
 you may be prosecuted for it and because of that prosecution, you're scared
to do it.
 We don't want that.

 Establish a safe environment for disagreements.

 Allow team members to build strong commitment to the decisions because
when the decisions are made, everyone knew of the problems and they're
gonna commit to it because they have disagreed and now they agree on it.
 Encourage people to experiment with new methods because when people
experiment is how they find better ways.

 They find a better software tool,

 they find a better process to create a new product.
 There they create new products, completely different because they don't like
the current product they have.
  People that change this world are the people that works against the status
quo.

 It's people that experiments with new ways.

 And we want those people on our team.
 We want those people working for us.
 We don't wanna prosecute them.
 We wanna encourage them.
 This is of course, gonna lead to much more engagement on the team.
 If people know they're not gonna be prosecuted for trying new things,
 They're gonna be more engaged on that project.
 They're gonna be happier to work and they're gonna be much happier to
change that status quo.
Constructive Disagreement
 Now another thing is constructive disagreement.
 When you have issues on a project and there's disagreement and those things
are solved, that leads to better buy-in and decisions because now, everybody
supports those decisions.
 Disagreement, but it has to be good disagreement.
 We have to go back and forth, negotiate the best way.
 Something avoidant conflicts only leads to conflicts getting worse or
escalating.
 Never avoid a conflict.
 A conflict, approach that conflict.
 Safe place for disagreements will lead to successful problem-solving.
 When people know there is a safe place we have for disagreements and
problems, they're more than likely gonna try a new method or a new
experiment because they know they're not gonna be prosecuted.
 Listen, anytime you try something new, there's gonna be someone that's
gonna disagree with you.
 Anytime you try to change the status quo, a million people out there is not
gonna like it.
 There is a safe place for this, you're gonna try it.
 And if you know that there will be disagreement but it's constructive
disagreement, it's good disagreement and people are gonna support you in it,
you're gonna try it.
 This concept of a safe place, constructive disagreement is one of the most
important aspect of building any agile team because this is how we change
the world and change your products.

Models of team development

 Every time you learn a new skill, it takes a while before you become an expert at that
particular skill.
  Learning a new skill is gonna be no easy task as skill learning requires a lot of
practice.
 Two models that illustrates this
o Shu-Ha-Ri.
o Dreyfus Model Skill Acquisition
Shu-Ha-Ri
 Shu = obey, Ha = Moving away, Ri= finding individual paths
 This is a model of skill mastery.
 So you learn a new skill of programming a software, at the beginning of it, you're
gonna obey all the rules and all the syntax, and you're gonna follow exactly what
people tell you.
 Maybe you write a book, you watch training videos on it.
 So whatever they're doing, you're just gonna follow it.
 As you start to get better, and better, and better at this particular skill you're gonna
start to move away from it.
 You're gonna start to try new things, maybe combine different functions.
 The last one is you're gonna find your own path.
 You're gonna find your own method of developing or using this particular
programming language to make your own programs.
Dreyfus Model Skill Acquisition
 Novice, Advanced beginner, Competent, Proficient, Expert
 The next one is the Dreyfus Model Skill Acquisition.
 Over time, we will acquire new skills.
 At the beginning of learning a skill, let's go back to being that programming, you're a
novice, you follow all the rules, once again, you're not too sure how to do things, you
might mess it up a few times.
 Then, you become more of an advanced beginner in which case there's less errors in
what you're doing.
 By the time you become competent and proficient
 There's really no errors in the work that you're doing.
 You're good at it and people sees you as good at it and, eventually, then you can start
teaching others because then you become an expert at it.
 These were just two quick team development models that we all go through in
different phases.

Tuckman Five Stages of team development

 Tuckman's five stages of team development was created in order to show you
the different stages that teams go through.
 Now, whether they're coming together in their forming to adjourning the
work is done or they're performing and getting the work done.
 Now, Tuckman's ladder is something that was covered in your PMP.

 Forming
 Storming
 Norming
 Performing
 Adjourning
 All deals with bringing people together.
 In PMP exam, there is no direct questions on Tuckman.
 In ACP exam, question may come what happens before this or after this? What
happens after storming or what happens before norming?

Forming
 the team is formed.
 The team comes together.
 When the team comes together, they start to get to know each other.
 There's not much conflict or communication.
 If I put a lot of people in a room together, in order to work, there're probably
not going to be too much communications in that team because they don't
know each other.
Storming
 Once they get to know each other, now there's a storm.
 Team members start to have conflicts with each other.
 They start to learn of each other's ideas and may not agree with them.
 Most of the conflicts will take place in the storming stage.
 Well, because its name is storming.
 So storming really is about, I don't like your way of installing it.I don't like of
each other's ideas,
 We start to have this disagreements because I don't like your idea. You don't
like mines.
 Eventually, the team will have to come together and they're gonna have to
come up with ideas to get it done or come to their agreement.
Norming
 Norming, the team members begin to agree with each other on the best
methods to build those deliverables.
 Generally, everyone is coming to a consensus at this point.
Performing
 Once they come to an agreement, they have to come and do the work.
 The team is performing well and is working without conflict.
 Now they're actually programming the software with the methods
Adjourning
 That is, the project is done.
 The assignment is completed and the team may be reassigned to other,
maybe to another sprint, or if the project is still ongoing or day or the project
will be completely finished.

 Forming -> Directing

 Storming->Coaching
 Norming->Supporting
 Performing->Delegating
 Adjourning

 Now, what is your role in these stages?

 So your role in these stages, this concept of adaptive leadership
 and how we're gonna change and adapt our method of leadership based on
what's happening with the team.
 So how can we lead the team?
 How are we gonna change our methods of leadership based on how mature
that team is getting or how that team dynamic starts to change?
 Informant, you're more of a directing leadership.
 A directing leadership is someone that tells people, "Hey, this is what we need
to get done on a project.
 Here is the scope of the project."
 So you're directing them at this point.
 Notice that's the only point you're gonna direct them.

 Once the team starts to talk, that storm is there and they're starting to have
disagreement.
 Your objective is to support it and coach it.
 So you're more of a coaching person.
 You don't wanna suppress the storm.
 You wanna let them disagree.
 So you wanna coach them through this process of constructive disagreements
with each other.

 Then comes norming.

 You're gonna be supporting them as they're doing the work.
 Be that servant leader and support them actually coming to a consensus.
 You're gonna say, "Hey, I like that idea.
 That's a good idea.
 I support that idea."

 As they all come to a consensus, then delegate them.

 The work is starting.
 You gotta delegate the work.
 They have to get this job done.
 So you delegate the work in adjourn.
 It's just finished.
 All right, these are just some things to keep in mind how your leadership style,
 you're going from this directing leader to this delegating leader and how your
leadership style is changing as the team dynamics will start to change.
 Training, Coaching and mentoring
 You may be just training, coaching, or mentoring one person or the entire team.
 Remember, we work with people.
 People management, not really project management.
 We should rename project management as people management.
 So we're gonna help them resolve issues and overcome issues.
 I tell project managers is we have to work with our team members to resolve business
issues,
 also personal issues, because what's in their personal lives has a drastic impact in their
performance at work.
 Now, that's if the person is willing to have them help you.
 And if they are, then you should help them.
 You want them to stay on track.
 You wanna have the team stay on track and overcome the issues.
 One of the most important thing for team members or for anyone in an organization is
to improve their skills.
 If they feel that you're improving their skills, and they're getting better at their job,
 and they're getting that recognition,
Training
 Teaching of skills or knowledge
 Training is about teaching of a skill or knowledge, maybe training someone on
how to learn a new programming language, or training them how to follow a new
process would be training.
 You should be expecting to train, coach, and mentor some of the team members
on there.
 Whether you're doing it individually, as you're coaching a particular team
member, or you're mentoring one of them or the entire team as you're training
them on something.
Coaching
 Coaching is a process that helps a person develop and improve their skills.
Mentoring
 Mentoring is more of a professional relationship between you and a person that
you're really helping.
 So this is more of a professional relationship that can fix issues on an as needed
basis.

Team Spaces
 Co-located Teams
 Team Spaces
 Osmotic Communication
 Global and Cultural Diversity
 Distributed teams

 One of the most important aspect of having your team members feel comfortable
working in their environment is to ensure that the team space that is set up for them is
conductive of learning.
  It is gonna be a space where everyone can learn, everyone can speak to each other,
collaboration works well with each other.
 We have to design our team spaces in a sense of good collaboration.
 Look at what co-located teams are, how to design our team space.
Osmotic Communication.
 We are gonna look at global and cultural diversified teams and some different ways
to handle these distributed teams.

Co-Location, Co-located Team

 All team members work together in the same location.
 Allows for face-to-face time and interaction.
 Should be within 33feet of each other.
 No physical barriers.
 Sometimes a vitual co-location.
 In your exam, hot topic for your exam=>co-location, co-located teams.
 This is when all team members work in the same physical location.
 Now, there is such a thing as virtual co-location.
 Any question you, guys, get with conflicts because of the team space or they weren't
able to communicate right,and one of the choices is to co-locate them,
 Face-to-face time and good interaction, is gonna be key to doing this.
 Communications should be within 33 feet of each other.
 Communications should be, you don't want spaces that are too far out and physical
barriers that are set up.
 So we can't see each other, we can't talk to each other, we can't hear each other.
 Even 33 feet, it's quite a big distance, but at least we'd be able to somewhat hear each
other.
 So you don't want too much space in between them.
 You don't want walls in between them.
 In today's world, co-locations and bringing everybody in the same room may not be
something that's an option for you.
 I know some businesses that have quite a few teams and employees.
 I know one particular business that I did some training for that had over 300
employees and they had no physical space.
 The entire company was based in an online platform and there was no space, no team,
and there is no physical location.
 No one comes to meet each other in physical location.
 Interviews were done online.
 People were hired to work in virtual space with each other.
 That's fine.
 The co-location could be virtual.
 If you're doing a virtual co-location and you wanna be able to really simulate a
physical co-location versus a virtual one would be keep the GoToMeeting software,
the WebEx,
 or the Zoom or whatever it that you're using, keep it on all the time.
 we can share each other if any of us have problems or issues we can discuss each
other about.
 Make sure they can see each other.
 Phone communications doesn't lead to very good communication because you can't
see expressions.
 Video communication is better and face-to-face is the best.
 Now the other thing here
 is when you're designing these team spaces, and probably I've said this at least a
hundred times now, is low-tech, high-touch tools like whiteboard, task board, sticky
notes, flip charts.
 One of the things when you're designing a co-location or an agile space is you want
people to see each other.
 Long table=> cannot see at each other, looking at the wall
 Round table=> can look around and see what people's expressions are.
 Face-to-face communication is the key.
 No barriers to it.
Team Spaces
 Now the thing with co-locations is the common areas where everybody work, but
you gotta have a cave.
 Caves is a space where team members can retreat to make individual phone calls to
their family members or personal calls to medical doctors and whatever people have
to do personally that we don't need broadcast in a team space.
 You gotta have a little room, a little cave where people can go to.
 Caves => space team members can retret to individually.
 Common=> space team members can work as group.
Osmotic Communication.
 One of the best things about co-location is osmotic communication.
 People learn just by listening to each other.
 Let me give an example of that.
 This is when information flows occurs within the team by themselves, questions and
answers between each other.
 That's when communications has occurred and over there, over here, and it has flowed
on my way and now I know about it.
 This is a great thing with having a common team space.
Tacit knowledge
 This is information that is not written down, supported through collective group
knowledge.
 This is information that people just know and learn.
 For example, like fixing a printer, like fixing a jam printer would be a good example
of that.
 These are things that nobody's gonna write down how to take out a paper out of a
printer, but it's knowledge that we eventually will learn.
Global Teams and Diversify Teams
 Now, one other thing is about global teams, diversify teams,
 cultural diversify teams.
 This is very difficult, especially when you have a distributed team.
 Time zones
 Cultures
 Native Languages
 Styles of communication
Time zones
  First of all, time zones, very difficult to work with different time zones
 because they sleep when I work, I sleep when they work.
 24 hours, this project can keep running.
 The problem is this varied time zones really affect the flow of communication.
 So you're gonna have to find ways to mitigate this.
 I don't wanna wake up at two o'clock in the morning and neither do you,
 considering you're somewhere in Asia or Europe.
 But I don't wanna wake up two o'clock in the morning, but neither do you,
 but those are things that may have to get done in order for us to communicate.
Cultural Issues
 It's a holiday here in the United States, but it's not a holiday where you are.
 So some countries don't work on Fridays.
 Some countries don't work on Sundays.
 Some countries don't work on Saturdays and so on and so on.
 So different cultural issues.
Language Issues
 Languages can become an issue, accents, mispronunciations of words, like I just did
there.
 Obviously, you can tell here that my accent, and I'm of Caribbean descent, so my
Caribbean accent kicks in every now and then.
 So my native language sometime, my native language is English, by the way, here in
the Caribbean, in the United States.
 I've grown up here in the United States, in New York in particular.
 And I think that native language of the Caribbean English,
 Caribbeans do speak English, by the way, most of it anyhow, our English is slightly
different
 as we have an accent to it.
 Think of Jamaica, Trinidad and Tobago, Guyana, Barbados, and so on.
 All right, so sometimes it's difficult to communicate, especially with people with
certain accents or their native language is not the same.
 And then you may have developers or programmers or managers or particular team
members
 that just doesn't even know your language.
Style of Communication
 Style of communication may be different depending on that culture.
 These can be very difficult things to manage, so we do have some tools here that we
need to talk about.
 So if you have this distributed team, it may be cultural diverse, but you have this big
distributed team.
 So sometimes you only have like one person that may be working offsite, but you
may have an entire team.
Agile Tools
 You need to find a way to replicate the co-location benefit.
 Low tech, high touch.
Digital Tools for Distribute Teams
 video conferencing
 Interactive whiteboards
o Tons of software
 o Platforms like WebEx or GoToMeeting have these interactive whiteboards
o where you could just write on the screen.
o Microsoft Teams has it now too.
o Instant messaging is also great.
 VoIP calls
 Virtual card walls
o Sticky Notes
o virtual Kanban boards
Web Cams
o When I do meetings with my group, especially virtual meetings, using camera.
o Highly efficient.
 Digital Cams
o human-to-human interaction
o Seeing people interact is also important because it keeps your focus.
o It makes the communication just a lot more effective, especially when you're gonna
work in the digital world.

Burn and Velocity charts(***)

 Tracking team performance=>Looking at high visualization charts to show how
you're doing.
 Super important for your exam.
 Burn Chart
 Velocity Chart
Burn Chart
 Burn charts are one of the hottest topic on an agile test.
 Burn up chart
 Burn down chart
So you must know burn charts, okay?
Burn Up Chart

 It is called because of lines going up.

 It shows with iteration and points.
 The project starts out at iteration zero, with 100 points worth of work.
 In iteration five and six, there were added more.
 It means people added in some changes and it goes up to 120 points worth of work
 Red line is what the team is actually completing throughout the project.
 So by iteration one, they did six points, teams by iteration 218 and so on and so on.
 Now, the thing to remember about a burn up chart is that it shows work that has been
completed.
 It's easy to tell by iteration five, we completed 57 points worth of work.
 By iteration three, you probably did about 30points worth of work.

Burn Down Chart

 It is called because it burns it down.

 The burn down chart really tells you work that remains to be done.
 It is not how much was completed, but how much is left to be done.
 It is telling that at the beginning of the project, there are 90 points.
 So if you follow this here on day one, we have 90 points worth of work to do.
 Blue line is the plan,
 Red one is the one we're doing.
 By day 5, we have, we have 60 points worth of work to be done.
 By day 8, we have 30 points worth of work.
 By day 9, we have about 12 points worth of work to get done.
 If you drag up the lines and you read it, you'll probably be able to understand it.
 But a lot of times on the exam,
 they're not just gonna give you the chart
 and you have to look at it and read it.
 No, they're gonna give it to you in a verbal question.
 It's gonna be a choice that you have to select.
 So before I move on to the velocity charts,
Quick Review:
 Burn up chart shows work that has been done. It's work that you completed already.
  So if you ever wanted to know, or if you, any question ever wants to know what can
you give the customers, or what can you use to show all the work that you've already
done, use a burn up chart.

 If the customer comes to you and says, "Well, how much more work does this project
has?"
 And your can response, "Let me take a look at my burn down chart.
 We got this many more points remains to be done."
Velocity Chart

 Velocity chart is what the team will use to help estimate how much work they can do
in all iterations.
 If you have iteration one, the team started out and they did about 3 or 4 points, word
of work.
 By iteration 2, they went to 15points.
 By iteration 3, they went to about 16, 17 points.
 In those iterations, that is their velocity,16 or 17 points worth of work.
 That's important because if their estimate in work and they look at the product
backlog and the product backlog has a feature.
 Feature one is 17 points.
 I can do that feature in this iteration.
 But if they notice that the top feature is six points and the other one is six points, they
know they can do dose two in the next iteration.
 So this is how the team will use to estimate what work, or how much work they're
gonna get done in that iteration.
For exam
 If a team has completed three iterations with the average velocity of 18 points per
iteration, how many iterations would it take to complete 250 points worth of work?
 Sol: They've completed three, and I'm giving you the average 18 points per iteration.
 So, iteration1 was 20 points, Iteration2 was 19 points, iteration3 was 15, and then you
would've had to found the average was probably about 18 or 17.
 How many iterations would it take to complete it?
 250 iteration /18points =13.88=14iterations
 So, 14 more iterations to complete.
 So we'll finish all of the work in the product backlog in 14 iterations.
  How much time is that?
 Remember, each iteration is about one to four weeks word of work, so we can then
estimate the total length of the project.
 Now that's assuming if they don't add any more changes or remove any particular of
those points, i.e if it stays at 250 points.
 It’s important for the exam.

Agile Planning, Problem Resolution and Continuous Improvement