 Agile was originally developed for software projects, but now the methodology is

being applied to all types of projects from developing different types of products like
cars all the way to advertise and projects.
 So it's not something that's just exclusively used in software development, although
it's used a lot in software development.
 First of all, Agile is not really a methodology by itself.
 The word agile is a term that's used to refer to different types of iterative
development.
 Agile is about building things in small iterations or increments versus building things
as a whole.
 In Agile, it's about building things in smaller increments and then getting feedback on
each increment, encouraging more feedback, encouraging more stakeholders,
engagement or participation.
 Scrum is the most common agile method that is applied in this particular course, or
it's a term that you use a lot when talking about Agile.
 So Agile is an umbrella term that includes Scrum, but there are others Scrum.
 We'll talk about Extreme Programming or XP.

Agile Vs Traditional PM
 Traditional project management can be applied building a 20 storey skyscraper or 20
storey building.
 In the project,
 Gather all the requirements
 how many rooms they're looking for
 how big the building has to be
 how many square footage
 how many partitions are going to be in each apartment or office space
1. Gather all the requirements that is needed.
2. Get the plan
3. Plan how to build this large building.
4. Execute this project and you're going to after you finish planning.
5. Planning: Planning is for the entire building.
6. Building the entire structure from that plan.
 If the planning took six months of planning, maybe you had to get permits, approval
for another three or four months.
 It took one year to plan with permits
 Build a structure
 Go in and execute this project
 Start digging up the ground and putting down the foundations and putting all the
beams and building the whole structure.
 So in this project, you have a scenario where you have 1year of planning, then 3years
to build this entire structure.
 When it's all done, then you can close out the project and it's finished.
 So that project took about four years, maybe even five years that approvals, permits,
wait times and so on.
 So if you think about the value proposition, so the value was the building is getting
done, but the stakeholders, the customers or whoever funded that project sponsors had
 to fund that project for five years with no upfront value or no value throughout the
five years.

 Traditional project management, if you apply that to a software project in today's

world.
 In a software project, you would have a similar concept.
 You would go out, you gather the requirements, you get it approved, you would
gather the requirements for the software.
 You would go out and program this entire piece of software and maybe one year of
planning, maybe two years of programming, then you would bring in the users after
three years into this software development, for them to test it out for six months.
 Go back and fix things another six months.
 Four years now.
 At the end of the four years, the people can start using the software.
 So there is no value to be gained in from day one to the end of the fourth year.
 Value that they can use the software to make money would only be gained at the end
of that four year period.
 That brings me to Agile.
 In traditional project management, there's no value to be gained throughout the
project.
 If the project last six months to ten years, the only value you're getting is when the
project is done.
 Remember, customers don't see value when something is getting done.
 If they're painting this wall behind me, there's no value and I can't use the room.
 There's no value in them painting a wall.
 There's value when I'm actually using the room as a painted room.
 There's no value in people making software.
 There's no value in coders code in software.
 For me as a customer, maybe valuable for them, they have a job, but it's not valuable
for me.

 So Agile tries to change this.

 Agile is a little different.
 Agile is going to build the actual products in smaller increments versus building it as
a whole.
 Building it as a whole building.
 In Agile, build software and it doesn't have to be software, it could be any type of
products also.
 We're going to build the software in smaller increments and deliver those increments
to the customers.
 So they can start using it faster.
 Gain in value quicker.
 Agile does planning throughout versus traditional project where you're going to be
doing it all at once.
 So remember in the software project, you plan the entire software development, how
to build the whole software, and it took a year.
 Here's what we're going to do in Agile.
 We're going to plan for a few days and then we're going to go and execute some of
that work.
 Then we're going to get feedback on that work.
 Then we're going to plan again for the next set of work.
 Every time we do work, we do a little bit of planning, we get a little bit of feedback,
so we're not planning the entire thing in the Agile.
 In Agile, we plan a little bit and work a little bit, then a little bit of plan again, and
work alittle bit again.
 Traditional Project Management is plan for a long time, then work.
 So that is a different.
 Agile delivers the products over time versus all at once.
 So let's say you're doing a software project.
 Once again, you're doing a software project.
 And in the first three months, starting developing the software for you, you can start
to use the actual product itself.
 So in the first three months you get something to use, not the full software, but maybe
a module that you can start to use.
 So you're starting to see value from this in another three months or four months.
 It may actually let's say the in the traditional project, it took four years to finish.
 Agile projects may take three or four years, but over that period of time you're seeing
value all the time, not just all at once.
 At the end of it, customers sees value faster, of course, because throughout versus at
the end.

 Agile builds in increasement Vs as a whole.

 Agile does planning throughout Vs done all at once.
 Agile delivers products over time Vs all at once.

 Agile wants changes.

 We want customers to participate.
 We want feedback.
 Feedback means changes.
 They're going to come and tell you,
 Well, we don't like this.
 We don't like the way this menu looks.
 We don't like the way this option looks.
 We don't like the layout of this report.
 Can you apply changes to this?
 The more changes we get, we're always welcome and changes.
 And I'm going to talk a lot about this topic of welcoming changes as this course is
going to progress because it's something you're going to really have to get in your
mindset.

 Traditional project management has a problem.

 It discouraged changes.
 If you have a change management process that is very troublesome, very complex and
takes a lot of work.
  For example, can you can I make a change to your project?
 And your first response is, here's a change request form as to what happened.
 PMP, here's your change request form, full listing out.
 So it's like two pages and a whole bunch of questions and answers that I have to fill
out or select.
 And then you have to give it to a change control board and get it assessed and so on.
 That's very discouraging.
 If I know I have to do a lot of work to request a change.
 I may not request the change.
 So you're discouraging changes like that.
 You don't want that on an agile project.
 Agile projects changes and it does have a lot of terms.

Agile Benefits
1. Customer Involvement
2. Greate Customer interaction with all stakeholders
3. Constant feedback is required to stay current and successful
4. Greater Value up front
5. Change is welcomed by all stakeholders.

Customer Involvement
 The first thing up is customer involvement.
 Remember how Agile works.
 It's really about building small increments, and every time you finish building
those increments, you're always getting customers feedback.
 You don't build a product in a hole.
 You build them in smaller increments.
 Eg. if I have to build you a car, if I have to build your car, gather all your
requirements and what type of car you like and how big you want it, how many
doors you want, how wide defenders has to be, how the hood has to look.
 I build this whole car, then I give you the whole car.
 I don't like the way that car looks or it's too long, it's not wide enough.
 I'm going to talk to you every week as I build a little component of that car.
 So you're always involved in this process, and that's a good thing because now I
can always get your feedback.
Greate Customer interaction with all stakeholders
 The next thing is not only will it is it interaction with just the customers, but
you're also talking to the product, the product owner you're going to be talking
with senior management.
 So it's everybody interaction with all the stakeholders on the project.

Constant feedback is required to stay current and successful

 Constant feedback is required to stay current and successful throughout all your
project.
 In a traditional project, one of its downfalls or one of its greatest problems was not
having constant or successful feedback.
  The problem which traditional project was this lonely period when the customers
were alone and the project team was alone, nobody was talking.
 Everybody was just alone.
 Teams being alone.
 We don't want that to be successful.
 We got to bring these people together.
Greater Value up front
 Another thing is greater value up front.
 You're not going to wait to get value at the end.
 You gain more value upfront as you spend money.
 I'm building that product.
 You're not spending money and then waiting two years to get your particular product.
 And one of the best benefit is that I think is important not just for your exam, but in
real life exchanges.
Change is welcomed by all stakeholders.

 Welcome all stakeholders.

 We're going to welcome changes from them.
 Changes has to be welcome.
 If you suppress changes, people think about this.
 If you suppress changes, people will not want to participate.
 People come to give feedback because they feel like their feedback will be
welcomed.
 If people give feedback and your first thing to do is to shoot it down or make them
feel like their feedback was not welcome in their feedback will not be given.
 I wouldn't give you feedback if I know you're going to prosecute me first.
 And feedback generally results in changes.
 If a customer likes it, that's good feedback.
 A lot of times the customer is going to ask you to change things.
 You have to welcome those changes.
 If every time I ask you for a change in your first response is.
 But we can't do that or fill out this big form.
 I'm going to stop asking for changes eventually.
 But if every time I ask you for a change, that's a great change.
 I like that idea.
 I think the mindset for the Agile project manager is key to ensuring that the
successful the key to ensure a successful Agile project is that mindset.
 You have that personality in order to have that successful agile project.

Inverting the Triangle

 In Traditional, Scope is fixed. Time and Cost is variable.
 In Agile, Time and cost is fixed. Scope is variable.

 Important concept of agile mindset in a traditional project.

 Your objective was to complete that scope within time and costs.
 That's a traditional project.
 Complete the scope within the time and the cost.
 But your main objective was to finish that scope while doing your best or trying your
best to finish it within a given schedule and budget.
 So you could have varied the time, you could have scheduled it for six months and
finish it within seven months.
 You could have budgeted it for 10000 hours and finish it for $12,000.
 That's that traditional project.

 In an agile project, it's different.

 In an Agile project you're trying to keep the time and the cost the same, the
scheduling, the budget the same.
 You don't want to exceed a certain time or budget while variant scope.
 Now that is drastically a different mindset.
 In a traditional project, the mindset is Finish the work, finish the work, finish the
work, get this work done.
 Don't sway from the work.
 Stay on work.
 We go over a little bit over the project.
 how many projects have we worked on where we exceeded our budgets and way over
our schedules?
 That's normal.
 On a traditional project, but on an agile project, to complete as much keyword, as
much work as we could within a six month period and 40,000 hours.
 So when we are done spending the money and our time is finished, we are finished
working.
 Whatever work we have done, the project will produce and generally nothing more.
 So you're keeping your time and cost the same while varying the scope.
 When they're finished or when the money is done and the time is done, whatever
work we have.
 Because the work that Agile is producing.
 Is going to give you the most valuable components of those worker, that product up
front.
 On an Agile project, what you get up front is the most valuable of that product or
service or software.
  You think about this over time?
 If a project is spending money and spend in time.
 If the more money.
 If the work you're doing over time keeps on going and going and going.
 The most valuable comes first, then the second, then the third and the fourth.
 As you're spending more time on this project, you know what starts to happen.
 Towards the end, you're getting less valuable things, things that you don't have so
much value on or place value on.
 So the longer this project stays in existence, it's the less valuable parts of the product
you're getting.
 Maybe once you have come to a point where we have got the most valuable point.
 Spending any more time and money would just not give you any return on that time
and money you're spending.
 Maybe you spend in another month coding.
 This software is going to give me a product or a report on a piece of software that I
may never use or may only use once.
 And it's not worth that entire team cost or just waiting on it.
 So that's the concept of inverting the triangle.

Agile Manifesto
 Created in 2000.
 Includes 4values and 12 guiding principles.
 Any type of framework or any type of methodology, there's got to be some kind of
driving force or benefit that drives the end result or the way something is done.
 4 values are things that we're going to always keep in our heads, things to know in
order to proceed in Agile.
 The guiding principles are more specific steps that we should really be implementing
as we follow Agile.
 Exam will test four values and 12 principles in depth.

Agile Manifesto Values

 Brief look at the four values before getting in depth into all of them.
 https://agilemanifesto.org/
 software=> Agile => manifesto
  Not only for software, applicable for all the projects.
 Before I get into in-depth analysis of each of them.
Individuals and interactions
 Individuals and interactions over processes and tools.
 Project means about people.
 Projects is not about Microsoft Project.
 We want people to talk.
 We want people to interact.
 People build things, not software.
 A caterpillar is a very big machine, but it doesn't do anything.
 It takes people to build a building.
 Caterpillars by themselves can't build buildings.
 Microsoft Project doesn't do a project for you.
 You're the one that has to do that particular project.
Working Software
 The second is working software over comprehensive documentation.
 Now, what is the main objective of your project, the end product?
 The software has to be functioning well.
 I don't want you to create complex software and then give me a big binder word of
documents in order to tell me how to use it.
 If the software works, it should be easy to work, easy to operate.
 We do need comprehensive documentation, but we want work in software.
 More customer collaboration over contract negotiation.
 What happens when you have a contract?
 If you have a contract that has these particular points in it or just scope of work,
you're less likely to have leeway or be willing to accept change.

Customer Collaboration
 Customer collaboration is a willingness to change.
 It's a willingness to work with customers, not just hold them to a contract.
Responding to change
 Fourth one is responding to change or we're following a plan.
 We have to be dynamic.
 We have to be willing to modify as we go along.
 We do value the items on the right processes and tools are going to be important on
any project.
Individuals and Interactions over processes and tools
 It is very important because need to ensure that people talk, people
 interact, and there's no silo activity going on.
 In other words, no one is working by themselves and we want everybody to be
together.
 So while processes and tools, you need them.
 Projects are done by people, not tools.
 Microsoft Project doesn't do your project for you.
 You need to do your project.
 It's just a tool that we use problems.
 Every project has problems.
 Project managers are as scrum masters.
  The actual project work, we don't code software or paintballs.
 We interact with people and we talk to people and we can make sure the work gets
done.
 Problems occurs between people, not between tools.
 So problems occurs because of people in the problems will get solved by people, not
processes.
 Projects is about people.
 You think about projects, you think about people.
 People work best when they can interact.
 You need to break down the walls that lies in between people to get them to talk, let
them interact.
 The team, talking to the customers, you talking to your team, you talking to your
customers don't have cubicles with walls, have desk space where everybody can see
each other, have meetings.
 That involves all of the participants on the project and the customers.
Working Software Over Comprehensive Documentation
 Next principle is work and software over comprehensive documentation.
 On an Agile project, you're going to focus on delivering value.
 Value comes in the form of that product that you're given out at the end, not a ton of
paperwork.
 So you want to make sure that the project is focused on giving the customer what they
need, not just giving them something, what they may figure out how to use, and then
give them a whole lot of paperwork to figure it out themselves.
 Agile document is known to be barely sufficient, so barely sufficient is you don't want
to mountain a book of how to use this particular product.
 You want something just good enough and small enough that tells our customers how
to use that particular product.
 It's known to be done just in time, so it gets there the correct time.
 And just because now we have to provide documentation, you just can't give people a
software with no documentation.
 So even though our software is easy to use, it meets our customer's requirements.
 Delivering software that does what it should should come first before creating any
documents.
 The main objective in Agile is to finish that product.
 So you finish making the product.
 We can create the simple sufficient documentation for it.
 Agile simplifies the administrative paperwork related to time, cost and scope control.
 We want to reduce the amount of paperwork we have because we want the team focus
on delivering the things that matters to your customers, which is going to be that
product, that service your reengineer or that software that you're creating.
Customer Collaboration over Contract Negotiation
 One of the things you should do in Agile as you're working on an Agile project, or
talking to your customers is you want to be flexible.
 You want to be accommodating.
 You don't want to be fixed.
 Eg. You had to paint it white. But you're only going to keep saying, can you change it
to maybe off-white? So you don't want to be uncooperative.
 You want to make sure that you're welcome into change.
  You don't want to be able to stay to that contract.
 So you want to be able to manage that change.
 Don't suppress it.
 You want to have a shared definition of done.
 A shared definition of done is really important.
 The definition is done is basically me and you understand what the actual finished
product will look like.
 You want me to make something for you?
 Well, in that situation, we should have a shared understanding of what that end end
result will look like.
 That way I know what I'm building to.
 In the world of software development, we create intangible products.
 It's hard to show what it's going to look like if nobody knows what it's going to look
like.
 So we have to find ways of how we could come up with what done looks like, what
this product will look like.
 The other thing is to have a trusting relationship because we are so accommodating,
because we we want to incorporate changes.
 We want to be flexible.
 We have to trust each other by trusting you and you trust in me.
 Then we can better work together.
 And I could be very flexible.
 You could be very flexible to ensure that the work gets done correctly.
Responding to change over following a plan
 One of the things I keep talking about is changes, responded to change over following
our plan, our last value.
 In this particular one, you want to spend effort and energy responding to changes.
 One of the things we mentioned already is don't suppress changes in order to be
flexible and accommodating.
 You have to be able to respond to changes over following a plan.
 If you suppress changes, then you're always following a plan.

 Eg. I want to add this into your software. I want you to change this. And you're like,
that's not my plan. I can't do that.
 Well, in that way, you're not flexible, you're not accommodating, and you're not
willing to respond to these changes. You always want it just to stick to your plan.
 You have to ask why do customers asks for changes generally is because they feel
that what you're doing currently may not have much value for them.
 Think about the last time you asked a project manager for a particular change and that
project manager whether they were flexible and accommodating or whether they were
willing to just to accept it or not. Or maybe they said no because they had to follow
this plan.
 Why did you ask for that change?
 Maybe because you felt that that was important to you.
 And if that change was there, it will make it easier to to work with that software.
 Or maybe that software would produce more better work for you.
 So it'll basically give you more value.
  When people generally asks for changes is probably because they feel that those
changes will lead to more value.
 So we should spend more energy, more effort responding to those changes and be
accommodating to them.
 Now, one of the things about software projects is they do have a high rate of change
and they have a lot of requests for change.
 And that's because it's such an intangible thing.
 There's a difference between making a software and building a building.
 For example, you can't design a 20 storey building and then decide to add five stories
to it.
 That would require change and everything.
 But on a piece of software in a report added a new log in way.
 Added a new formula on a on a report or a function or something like that may not be
that much more effort or requires changing the whole software most of the time
anyhow.
 So we want to be able to respond to change or we're following just the plan.
Agile Guiding Principles
There are 3 principles.
1. Highest priority is to satisfy the customer through early and continuous delivery of
valuable software.
 We want to if there's one of the main core concepts of Agile is you want to be able to
push out your software quickly in smaller increments.
 Don't let your customer wait a very long time to get that particular software.
2. Welcome change in requirements.
 Even late in development, agile processes harnesses change for the customer's
competitive advantage.
 We keep mentioning in the actual values that changes.
 We want to be able to welcome them.
 We want to be flexible and accommodating.
 So guiding principle to, hey, we want to be able to welcome change and requirements.
3. Deliver working software frequently from a couple of weeks to a couple of months
with a preference to the shorter time scale.
 Always remember, the faster we deliver work in software, the faster they see value.
 The longer we deliver software, the longer it takes them to see value.
4. Business people and developers must work together daily throughout the project.
 One of the things we do is a daily stand up meeting, and in the daily standup meeting
you have the product owner, you have the Scrum Master, the Agile project manager,
you'll have the project team or the Agile project team working together.
5. Build projects around motivated individuals.
 Give them the environment and support their need and then trust them to get the job
done.
 If there's one thing we must do as an agile project manager is we must perform what
is known.
 And a big topic for your exam is servant leadership.
 In servant leadership, we're not there to micromanage them.
 We're not there to ensure they follow a process remembered as a plan.
 There's a value that we shouldn't be doing that.
 What we want to do is we want to motivate the team, trust the team, and give them the
support and the environment they need to get the work done.
6. To get the work done, give them the support they need the most efficient and effective
method of conveying information to and within a development team is face to face
conversation.
 This is important for the exam.
 Low tech, high touch.
 We want low tech.
 We want the lowest tech you can go is me and you talking with a face to face
conversation.
 High tech would be using some form of virtualized software.
 Maybe we can't see each other.
 Low tech, high touch.
 Agile promotes having a big white wall with markers and whatnot versus a digital
screen.
 So we don't want digital technology.
 It seems that we're going backwards in time here, but that's the best way to get it done.
 Because it promotes more collaboration.
7. working software is the primary means of measuring progress.
 Working software is how the customer measures your progress.
 You can go to your customers and say, I'm 60% done now.
 If a developer that's working on a project that I'm not involved with comes and tells
me they're 60% done, I'll say,I'm not sure if that's good or bad.
 I'm not sure how long more you got.
 I'm not sure what he's getting done.
 But if I give my users or my customers working software, they'll know that something
is getting done.
 They'll measure my progress against it.
8. Agile processes promote sustainable development.
 The sponsors, developers and users should be able to maintain a constant pace.
 One of the things we'll learn coming up later in this is that you want to have a
predictable, sustainable way of doing work.
 You want to always be able because when the team looks at the list of work, the
product backlog, and they say, okay, these are all the work we can get done in this
next coming sprint.
 The team should be able to predict that.
 The team should be able to know well in the next four weeks worth of work we can
get these things done.
 If the pace is not sustainable, then they wouldn't.
 They would never be sure how to estimate how much work they can get done in a
particular sprint.
9. Continuous attention to technical excellence and good design enhances agility no
matter what.
 We must have good technical excellence.
 We must have good design.
 We must continuously pay attention to these types of things.
10. Simplicity.
 The art of maximizing the amount of work done is essential.
 We have to ensure that we minimize complexity.
 We want to maximise simple things, but there's something about simplicity.
 Sometimes finding the simplest way is the hardest way.
 That is the reason why you want to make sure that you find simple things.
 Simple methods makes people want to follow it.
 Simple methods is easier to follow.
 Simple message encourages people to follow it.
 Complexity reduces all of that.
11. Best architects, architectures, requirements and designs emerged from self-organizing
team.
 One of the core concepts of Agile is a self-organizing, self-directed team.
 Notice self-organizing, self-directed teams.
 This is a team that basically manages themselves.
 You're a servant leader.
 Let the team come up with the design of the software.
 Let the team come up with the architectures that is needed to build this product.
 We are there to support, not to micromanage them.
12. At regular intervals, the team reflects on how to become more effective than toons
and adjust its behavior accordingly.
 So at regular intervals, we're going to want to make sure that we as project managers
look back at have the team look back at what they're doing.
 We're going to work with the team as project managers.
 We're going to work with them, and we're going to make sure that, they look back and
see how well they did in that sprint, how well they did in the previous sprint.
 You can say that you want to change the next change your methods to the next sprint.
 At the end of every sprint, you're going to do this retrospectives.
 And in the retrospectives you're going to see what you did right, what you did wrong.
 Do more of do less of so at regular intervals every month.
 You should be improving yourself, improving the process so regular intervals could
be a month.
 Maybe you do this even every two weeks.
 These are the guiding principles.
 I would recommend that you review them a couple of times before moving on with
the rest of the class, because these guiding principles will now become they will
become the way we will conduct the rest of this class.
 You'll hear me repeat them over and over as I'm talking about other topics in the class,
because this really guides the way to do Agile.

Agile Methods
 Agile is an umbrella term that basically includes all the other incremental or iterative
development.
 There are over 12 agile methodologies.
 But the most popular methods are Scrum and Extreme Programming
1. Scrum
 Scrum, which is very popular today. Popular certification called the CSM from Scrum
Alliance
 Sprint
 Scrum Master
 2. Extreme Programming
 Extreme Programming and Scrum is the two most popular now.
 Iteration
 Coach

 Scrum and extreme are the way the process is done is very similar and they carry
somewhat of different terminology for your exam.
 For your exam they sometimes interchange the terms between scrum and extreme.
 So following are the entire Agile process using the terminologies of Scrum and
Extreme so you can start to interchange the terms.
 When programmers go to do the development work of the actual project, they call it a
Sprint in Scrum, and they call it an iteration for EP
 For your exam, you should just know them as both terms.
 In Scrum, you are as a Scrum Master.
 In XP, you are as a Coach for your exam.
 It's actually called an Agile project manager.
3. Kaban Development
 All Agile projects should have is Kanban.
 Kanban development can mean sign board,
 Pull Method
4. Lean Software Development.
 Methodology of Lean comes in manufacturing, but that whole concept of to reduce
waste and its main methods within it.
 We're going to take a look at that because we want to apply some of that
manufacturing method into lean into software development and then now apply that
into Agile.

Agile Process
 In order to pass this exam, you must know the agile process
within that process has a lot of terms.
I recommend for you guys to watch this video at least twice before moving on.
Agile Terms

Product Owner The designated person that represents the customer on the
project.
Agile Project Manager/ They manage the Agile project.
 Scrum Master
Product Backlog Project requirements from the stakeholders
Sprint Planning Meeting Meeting done by the agile team to determine what features will
be done in the next sprint
Sprint Backlog Work the team selects to get done in the next sprint
Sprint a short iteration where the project teams work to complete the
work in the sprint backlog.[1-4weeks typical]
Daily Stand up meeting a quick meeting each day to discuss project status, led by the
Scrum Master, usually 15minutes
Sprint Review An inspection done at the end of the sprint by the customers
Retrospective Meeting done to determine what went wrong during the sprint
and what when right. Lesson learned for the sprint.
Partial Completed Product Customers demo the product and provides feedback. This
feedback adjust the next sprint priorities.
Release Several sprints worth of work directed to operations for
possible rollout and testing

Product owner => customer of the project

Agile Project Manager => Manage the agile project
Product Backlog => Project requirements from the stakeholders
Sprint => a short iteration where the project teams work to complete the work in the sprint
backlog.[1-4weeks typical]
Sprint Planning Meeting => meeting done by the agile team for the next sprint
Sprint Backlog => Work the team selects to get done in the next sprint
Sprint Review => an inspection done at the end of the sprint by the customers
Retrospective => Lesson learned for the sprint. Meeting done to determine what went wrong
during the sprint and what when right.

Sprint is a word that comes from Scrum.

Iteration is a word that comes from extreme.
Sprint & iteration = For Scrum & extreme programming or extreme.
sprint backlog = iteration backlog.
sprint planning meeting = iteration planning meeting.
sprint review = iteration review.

Let's take a look at how these terms fit into the process.
To make an accounting software
 manage you're going to manage an Agile project where you want to make an
accounting software for the accounting department
 use an Excel sheet and they don't have a good comprehensive software.
 Product owner represents the customers.
 All the requirements of what they want into something called a product backlog.
 This product backlog has all the features that they want.
 Eg.what do you want in accounting software?
 you need an accounts receivable system that's to do the invoicing and the billing.
 You need an accounts payable so you could pay bills and enter bills.
 You want a system to track your checking accounts and your savings accounts and
reconcile them.
 You want a system to print reports. So all the features that they can think about,
they're going to add into the product backlog.
 Let's say they came up with 20 features.
 Enter an invoice,invoices, Receive payments, Enter bills, Pay bills, Produce profit and
loss statements.
 What are 20 different features?
 That's the product backlog.
 Agile project team sits down and something they call a so the product owner, the
customer,Puts all the 20 features into that product backlog, the sprint planning
meeting.
 This is where the team sits down and determines how much of those products they
can get done in the next sprint.
 A sprint is one is really defined as 1 to 4 weeks worth of work.
 Eg. It's 1 to 4 weeks worth of work now.
 Realistically, 20 features in a software you probably can't get much done in 1 to 4
weeks.
 So the team sits down and they start to determine what they can get done now.
 This brings me to another important topic.
 The product backlog is prioritized by value.
 It's prioritized by what the customer feels would be the most valuable features that
they like.
 Maybe accounts receivable is the most valuable because that's how we make money.
 Entering an invoice and paying an invoice is the most valuable thing they would like
to have first.
 So in that product backlog, it's not just 20 features listed, it's 20 features listed by
value.
 For your exam, remember this the product owner is the person that prioritizes
the product backlog.
 So the product owner prioritizes the product backlog.
 The sprint planning meeting is where the team looks at the product backlog and says,
well, based on our previous sprint or iteration, we could do starting from the top.
 Not from the bottom, from the top.
 They're looking at all all the features.
  Eg. feature one is big, feature two is not so big.
 You know what we could do features one and two.
 We can't do any more in the next sprint.

 How do they determine this?

 Well, that's a topic for another lesson, but for now, it's called the team velocity.
 That is, they're predicting how much work they can actually get done.
 So the team sits down and they determine how much work that they're going to get
done.
 This the output to something called a sprint backlog.
 So the sprint backlog is the amount of work from the part of backlog that will get
done in the next sprint.
 What is the Sprint backlog?
 It is the amount of work that will get done in the next sprint.
 Where does it come from? Come from product backlog.
 So the sprint backlog, this is the work we can get done.
 what's the sprint?
 A sprint is a short iteration where the project team works to complete the work.
 In the sprint backlog, it's about 1 to 4 weeks.

 The next thing is a daily standup meeting.

 This is a quick meeting each day to discuss the project status led by the Scrum
Master, usually 15 minutes.
 And then after the sprint is done, you have an inspection and a sprint review.
 That's the inspection done at the end of the sprint by the customers.

So the Sprint backlog is done.

Remember, the sprint is basically 1 to 4 weeks worth of work that the team is going to do to
get the work done.
This big circle here, it's a big circle.

 They're getting the work finish.

 Now, one of the things we want to point out is this very important meeting called the
daily standup meeting, every single day that the team is coding the software every
single day that they're doing that they're going to do a meeting every morning.
 They come into work, they do a meeting.
 This meeting is a 15 minute stand up meeting.
 Now, I always tell my students and I tell them anytime I'm coaching people on Agile
or training companies
 on Agile, I always tell people, you've got to do got to do it standing up.
  What's the thing with meetings?
 Have you ever been in meetings that were useless?
 You ever been in meetings that took too long?
 Maybe because everybody's too comfortable.
 So let's make them all stand up.
 Don't make them too comfortable.
 Make them stand up.
 Go around the room.
 And you're going to ask three questions.
In the daily standup meeting, three questions are:
 What did you do yesterday?
 What do you plan to do today?
 Do you have any impediments or problems that you would need help with?

 Every team member will answer these questions, right?

 Every team member.

 Eg. Bob could come and say, Well, I worked on designing the table, or I worked on
completing the table for the for the customers.
 Today, I'm going to be working on setting up all the data fields in the table and
making sure the fields have the right amount of characters.
 Some of the problems I have is I'm not too sure how much character there should be
allowed in each field.
 So that's Bob's work.

 Mary comes around, Mary says, Well, I'm designing the form for the way to take the
customer's layout with look.
 So yesterday I laid out the form.
 Today I'm drawing all the button designs.
 The only problem heaven is where I should be put in the fields.

 They're going around the room and everyone, everyone is going to be telling basically
these or should be answering these three questions.
 This method is useful for only small team, like 10 people.
 Remember, agile teams are generally small.

 So everybody every day you're doing this meeting.

 And all of a sudden the work is done, right?
 So the sprints going sprints going.
 Then the work's done now.
 So after four weeks of coders coding applications and them talking to each other
every day during this daily up meeting, now it comes down towards the end of this
sprint.

 What they do is they call.

 They're going to call.
 The customers and they're going to say, hey, take a look at what we did.
 Look, we did the accounts receivable, a part of it anyhow.
 Look at what the customer table.
 This is what the customer forum looks like.
 This is what the invoice layout looks like.
 So they do a sprint review meeting and so the customer comes in and Sprint Review
meetings and they say, Well, it looks good, it doesn't look good.
 I don't like how that looks.
 I don't like the layout of the buttons, or maybe they like it.
 Maybe they said, Oh, that looks great.
 That's going to be easy to work with.
 That's what you want.
 You want to get that feedback from the customers.

 Retrospect is this is a meeting done to determine what went wrong during the sprint
and what went right?
 Basically it's lesson learnt.
 After multiple sprints, you may have a partially completed work customers demoted
product provide feedback.
 This feedback adjusts as the next sprint.
 And a release is several sprints worth of work directed to operations for possible
rollout and testing.
 After the Sprint Review meeting, the customers leave a term we really should know
and this is the retrospective and the terms retrospectives are done in the sprints done
in the customer leaves when it's a lesson learned is when the team member sits down
and says, Well, we did this right, we did this wrong.

 What do we want to do more of?

 What do we want to do less of in the next sprint?
 Remember, there were 20 things in this and we only did two, remember?
 So we did two here, right?
 So the Sprint retrospective is when the team sits down and says, Well, we did the
programming right, but the way we were designing it wasn't good.
 Or maybe our programming methods were bad.
 So the retrospect is, I was really a look back, a good lesson learned on what you did,
because the next time you want to do the sprint, remember change in you've always
got to be changing.
 It's got to be evolving.

 Continuous improvement is really going to be

 about that.
 It comes after retrospectives.
 You remember you created a part of the product.
 Can you ship that product?
 The answer is maybe or maybe not.
 Is four weeks worth of work enough for a potentially ship of the product?
 And the answer is maybe or maybe not.
  There's a word I do want to mention that's not here in my process and that's releases
you see a partial completed product.
 For the customers to demo a release for your exam is a combination of sprints.
 It may take two sprints or three sprints.
 Maybe you do this cycle three times before you come up with a potentially shape of a
product.
 So you see how I have this one here at the end.
 This may not happen until you have done maybe four of these sprints or three of these
sprints.
 It depends.
 So take for example, if you're a we're doing an accounts receivable part of it for your
accounting system.
 But one sprint was just to make the customer's table and the form for them to enter the
customers.
 But that's not shoppable because they can enter customers, but they can't do anything.
 Another sprint was to design the invoice and make sure the invoicing system works
well.
 That's still not shoppable because now you have customers, you have invoices, but
you can't receive a payment.
 So the next one would be how to receive the payment.

Now you have a release of the products.

It may take three sprints.
1. make the customer's form
2. sprint make the invoice
3. sprint allow it to receive payments.

 Now we can give the customers that partial, partial part of our accounting system so
they can start receiving payments.
 So releases are basically combinations of sprint.

If you have a 50 person team, it'll take all day.

So you don't want a very large team.
That is a particular number we'll talk about in another video how big those teams should be.

Summary
The customers, they want a particular product.
The customer is the product owner sits down and they create a list of features.
And particularly there were 20 features.
This is what they want.
The sprint planning meeting happens.
The team says, Well, we can only do two of those and remember to start from the top.
So they're always doing number one.
And number two, that means that that sprint is always going to be producing the most
valuable feature
first.
Remember, the product backlog is prioritized based on value by the.
That's right.
The product owner is the one that prioritizes that.
So the team sits down, they said, well, we're going to do two things.
We're going to only do number one or number two.
Then they execute the sprint.
All right?
They execute the sprint.
They start doing the work.
They're doing the work every single day.
They do.
They come in.
They're doing that daily stand up meeting, the Daily Standard meeting.
They answer three questions.
What we did yesterday, what are we going to do tomorrow?
And is there any impediments or problems that we have that anybody can fix, that anybody
can help me
fix, I should say?
So every day they're doing that, they're doing the Daily Standard meeting.
Sprint's done.
The partial product is finished in that sprint.
They do this review meeting.
So in this review meeting, they're basically saying, okay, tell bring in the customers, OC
customers
or product owner, tell me what you like, tell what you don't like.
Give me some feedback on what we did so far, so we get that feedback from them.
Then come the retrospective.
So after the customers leave, the sprint retrospectives takes place.
So this is when the team sits down to something similar and hey, we did this right, we did this
wrong.
We could do more of this, we could do less of this.
But they're going to take those lessons, learned it.
They're going to incorporate it into the next sprint.
Now, to have that potentially skippable product or maybe they don't because after they're
done with
this, what the team does is the team goes back to this product backlog right here.
All right.
It should be an arrow.
They're actually not a very good arrow.
Okay.
So they go back to the product backlog.
Now, remember remember this for a second, there were 20 things they did, too.
So the product backlog is not 20.
You're thinking, well, it's 18.
No, it's not actually 18.
Yeah, it was 20.
They did two, but it's not 18.
You know how big it is now?
It's 22.
How well.
Because while the team is doing those sprints.
The product owner or customers, they added for things more into it.
You remember this process of Agile allows changes the product owner found for new things
they would
like.
They added it in their was 18.
Former makes 22 and they reprioritize it.
Not a team goes back and they're like, hmm, 22 things.
Okay, that's okay.
They're going to start from the top again, right?
They start doing the sprint planning meeting.
They're like, okay, well, this 22 things, but all right, let's take a look at the top.
What can we do maybe in the next sprint?
They can do four things because they did all the big ones already.
Okay.
So they keep doing this over and over and over until the product or until all the features are
almost
done.
Now I say the word almost because remember in inverted triangle, one of the things that
people have
a hard time.
I have a hard time working with an Agile.
I want to do of course things that people ask me.
Quite common is when is the Agile project done?
Because if they can just keep adding to the product backlog, add into the product backlog,
then it'll
maybe never get done.
But the answer is the Agile project is done when you've run out of time and money.
Maybe after one year of doing the Agile, maybe you have the one year of doing this and
spend an X amount
of dollars.
The things that are getting done later on in the project is not represented so much value.
So then you just cut it off.
There's no more value really to be gained out of this.
All right.
I want you to watch this again.
I want you to know all the terms here, I should say here.
I want you to review this process one more time, make sure you really understand it, because
understanding
this process will make the next series of videos are actually make this entire course easy for
you.

Scrum
 The most popular Agile method is Scrum.
 Scrum is a set of team guidance, practice roles, events, artifacts and rules that we
should be following.
 It is based on the three pillars: transparency, inspections and adaptation.
Transparency
 What are the things about Sprint that's really important?
 Is that visibility to those responsible for the outcome?
 Everything should be visible.
 Customers can see what we're doing.
  We welcome feedback from them.
 Nothing is hidden.
Inspection(Checking)
 Timely checks on how well a project is progressing towards goals.
 Looks for any type of problematic variance from the goals or differences from these
goals.
 So we do a lot of inspections in Scrum.
 You do an inspection every day.
 Every day you're talking to each other.
 One of the things we look at is like peer program and inspecting the work as your
code in it.
 You also have a customer inspection right at the end of the sprint.
 So lots of inspection where it's daily.
 When we're conducting those standard, daily, standard meetings or at the end of the
sprint, when we're doing the Sprint Review meetings, adaptation, adjusting a process
to minimize further issues.
 If inspection shows a problem or undesirable trend, we have to be willing to adapt and
change.
 If the process isn't working, it's leading to more errors or the way where we are
gathering these requirements are the way we are program and the system is not
working.
 We should be willing to change that.

Product owner
 Along with Scrum, you have some roles that we should be familiar with.
 The product owner owns the product vision.
 They define the features, then decides on market release dates and content.
 They're the ones that define the features, the defining the content of the product.
 Product owner = customer
 They're responsible for the market success because they're the one to define the
features.
 One of the main things for your exam is they prioritize those features to market value
for your exam for the for the 100th time.
 Remember:
Who prioritize the product backlog?
Product owner
They can change features and priorities in every sprint.

Scrum Master
 Scrum Master is you.
 You're responsible for facilitating the process.
o So, we are facilitators.
 We are not actual managers. We are Scrum masters.
 A Manager is more like telling people how to do something.
 We are facilitating the scrum process.

Servant leadership
 Servant leadership = we = Scrum Master
  That's who we are.
 We are servant leader.
 We focuses the team and protects them from external interruptions.
 Keep the team on as we facilitate the process.
 Keep the team on following those specific roles, those specific tasks.
 Keep them in the path of success.
 Look for ways to enhance productivity.
 Try to keep them and try to make them more productive.
 Assistant product o owners and leverage in Scrum.
Exam Question: what happens if the team doesn't know Scrum.
Then the answer is to teach them Scrum.
 You will become an agile advocate.
 You're going to love Agile so much.
 You're going to want to teach it to everybody, just like I like teaching it to you.

 Scrum is about teaching, it is about pushing it and seeing value.

 That's really what this is going to be about the development team.
 The development team is basically a small group containing all the necessary project
skills needed to make that product.
 The focus is on steadily delivering high quality features.
 That's your job to make those features.
 They come up with options of delivery, they'll tell the customers, these are different
options of how we can deliver that product.
 They manage their own work within the sprint.
 You facilitate the process.
 You fetch food and water physically and theoretically
 Physically, you're going to get them some coffee and donuts.
 Theoretically, you're going to give them the resources, the tools they need to succeed.
 But they're the one that's going to determine how the work gets done within the sprint.
 You're going to try to minimize conflict, but you're going to have to make sure that
they are doing the work the way they want to do the work.
Dirty experts
 They know how to get the work done correctly.
 And who else is best?
 Or who best can determine how to get the work done.
 Experts can only determine that.

Scrum Activities
 Scrum Activities has some very particular activities that we should know.
Sprint planning meeting
 For output of the Sprint backlog, the sprint itself that contains the daily standard
meeting.
 At the end of the sprint, you have the Sprint Review meeting and then finally the
Sprint retrospective.
 Sprint planning meeting is to determine what work will be done in that sprint
 and how the work would be achieved.
 In the sprint planning meeting, the team sits down and they're saying, well, in the
sprint.
 This is what we can get done and this is how we're going to do it.
 The team predicts what can be delivered based on estimates, project capacity and past
performance to define the Sprint goal.
 So the team is based on previous sprints, this is how will we work, this is
 how much points worth of work.
 And we'll talk about how those end points to features in another section.
 But this is how much points word of work we can get done from the current product
backlog based on the previous sprints we did.
 The development team then determines how this functionality will be built and how
the team will organize to deliver the Sprint goal.
 Sprint backlog is the record of work to get done in the next sprint.
 So after this meeting is finished, now you have the sprint backlog.
 Now the sprint starts itself now.
Time Box
 Sprint is a time box.
 A box does not have unlimited space.
 It's a box because it contains things.
 So the time box is basically a limited time.
 So Sprint is a time box iteration of 1 to 4 weeks to build a potential release of a
product, not release, but potentially release it all.
 Remember, you may not in four weeks may not be enough time to complete work that
is releasable.
 Each sprint includes a sprint review meeting, a sprint planning meeting, the daily
scrum.
 Daily scrum is the daily standard meeting.
 It means the actual work than programming a sprint review meeting that comes at the
end and the Sprint retrospective all the way at the end after review minute during the
sprint and something you should know for your exam during the sprint.
 No changes are made that would affect the sprint.
 If the team says We're going to do these two features, you should not be changing
those features during the sprint.
 No changes are made to that because it will throw off the velocity because they
already planned this work.
 Changes can be added into the product backlog that the team will look at after
 the sprint.
Team Members
 Another thing is the development team members are kept the same throughout the
sprint.
 Don't change or try not to change team members in a sprint.
 If you do that, it kills the velocity on the sprint.
 So we know now the rate velocity on points.
 We know we could do 300 points worth of work based on the six of us in this room.
 But if I replace Bob with Mary, we may do less work or we may even do more work.
 Maybe I replace Jane with Mary and now Mary comes in and she could do more
work.
 Maybe she can do as much work as Jane could.
 You predicted that you could have done 300 points now, but that was with your old
team member.
  You bring a new one in and now you're down a 200 points.
 So that's drastically affecting the sprint.
 Don't change team members during a sprint tip for your test there.
 During the sprint, you've got to do your daily scrum or a daily stand up meeting is
what your exam will call it.
 So this is a 15 minute time box.
 And again, this work time box activity for the development team to synchronize
activities, create a plan for 24 hours, should be held at the same time and same place
every day.
 Now, you don't want to change it up because you want to make sure to have a
standardized place where they do this and it should be done at the same time.
 I mentioned this when i was going over the processes.

 You want to make sure three particular questions.

 What did you do yesterday?
 What did you do today?
 What will you do today?
 And are there any impediments in your way that can get fixed now?

 Scrum in extreme programming is we always try to help each other out.

 If I see that you have a problem, I'm going to try to help you out.
 But I don't know if you have a problem, if you know, if you don't tell anybody.
 This is a meeting when users has the ability or team members have the ability to
voice their problems.

Sprint Review Meeting

 Sprint Review meeting comes after the sprints done.
 Now this take place at the end of the sprint.
 This is designed to gather feedback from the stakeholders on what the team has
completed.
 The team demonstrate the work that was completed.
 During the sprints, if we're going to show them what we did.
 This creates a conversation between the team and the stakeholders about how to make
the product better or maybe the product likes.
 Maybe the stakeholders like it already.
 This should be time boxed to no more than an hour per week of Sprint.
Retrospective(review/recheck)
 The next thing is the retrospective.
 So retrospective comes at the end of the sprint.
 It is to give them some lesson learned.
 This is the opportunity for the team to inspect and create a plan for improvement to be
done during the next sprint.
In retrospective, it includes:
 What did we do that went well?
 What did we do that went wrong?
 What should we be doing more of?
 What should we be doing less of?
Scrum Artifacts
 3basic things:
product increment
 That's part of the product completed after each of the sprint.
 That's after each iteration, each sprint, you got a small part of the product.
sprint backlog
 That's the list of committed items to be addressed within the sprint.
 sprint backlog is what they're gonna get out when the sprint is what needs to get done
in that sprint.
product backlog
 It's a prioritized list of valuable items that needs to be delivered.
 That's all the features that they want.
 This is basically a prioritized list of work that needs to get done to complete the
product.
 The product backlog has all the features or all the work that needs to get done
 to build that product.
 It's dynamic.
 It's changing all the time.
 It evolves as more work is added and reprioritized.
Remember
 items are reprioritized.
 As people add work, it's prioritized in the product backlog.
 Who prioritizes it?
Product owner prioritizes product backlog

 Prioritized based on what?

 It's based on value.[For exam]
 Product owner prioritizes product backlog based on value.
 The most valuable things will come first.

 It's constantly being refined as more work is added, work can be removed, and that's
called grooming the backlog.
 The team and the product owner sit down and they groom the product backlog or
groom the backlog.
 You remove features that may really add no value, and you move things up in that
ladder, that may be more valuable.
 So grooming the backlog is an important topic.

product increment.
 This is the part of the product that's done after each sprint, done to get feedback at the
end of every sprint.
 The most important thing is getting feedback.
 The product owner and the team needs to have some kind of agreement upon what is
the definition of done before the team starts working on a product.

Definition of done
 Definition of done is how do I know when I'm finished making this product?
 Eg. I want you to make this software for me.
  But how do I know I'm actually finished making this software?
 Does it have to pass a certain test, like a performance test?
 Does it have to look a certain way, visually compelling to you?
 Does it have to be able to output a specific function?
 It has to be a specific thing that we can come up with that will help define when a
product is done, and that should be done before the team starts working on a product.
 They have an end goal.
 They know what they're trying to accomplish.
 The sprint backlog.
Sprint Backlog
 Sprint backlog is the set of items from the product backlog that were selected for the
sprints.
 Sprint Log <=set of items from product log that were selected for the sprints
 Team sits down in the sprint planing meeting, what we can get done from product
backlog, and create the sprint backlog.
 The sprint backlog is accompanied by a plan of how to achieve the sprint.
 So it serves as a development team's forecast with a functionality that'll be part of the
sprint.
 It is a highly visible view of work being undertaken.
 May only be updated by the development team.
It has to be highly visible: low tech, high touch.
It has to be highly visible a nice big whiteboard with a ton of, all the work listed on it.
So every day, we can go and we can see it.
There's a term you should be familiar, you're gonna be familiar with called information
radiators.
When you walk in, this big board with all this work, so people know what they're looking at.
It should only be updated by the development team or the project team,
because they're the one that know how much work can get done.

Extreme Programming
 It is a software development centric agile method.
 It focuses more on good software development practices.
 On the other hand, Scrum, looked at it more project management than it was more
project management level focus on prioritizing work and getting feedback.
 So extreme is really about software development but some of the terms and practices
that is in extreme, we will use in Agile.
 Extreme programming = XP.
 So it has some core values and particularly these five core values:
1. simplicity
2. communications
3. feedback
4. courage
5. respect.
Simplicity
 Simplicity is about being able to reduce complexity extra features and waste.
 So you don't want complex things.
 You don't wanna have extra features
 You don't want waste.
 You don't want to have things that people don't use.
 You wanna find the simplest thing that could possibly work.
 When you find something simple, people like it.
 People want to do it.
 People want to follow it.
Communication
 Team members know what is expected of them and what other people are working on.
 The daily standup meeting is one of the key communication components in XP.
Feedback
 Get impressions of correctness early.
 You do them at the end of the iteration,
 You do them throughout the iteration as you're doing peer programming or you're
doing your daily standup meetings.
 Getting feedback from other team members, getting feedback from your customers is
gonna be highly important.
 Another Thing is failing fast allows for faster improvement.
 I haven't gotten into this yet, but we want to fail quick.
 If a process has to fail, let it fail so you can learn from it.
 This allows us to do improvements.
Courage
 we want to allow our work to be entirely visible to others.
 You wanna be able to have your work be editable.
 Your codes in developing software to be completely visible.
 You have to have courage for that.
 You have to be willing for other people to look at your work, criticize it and make it
better.
Respect
 People work together as a team, and everyone is accountable for the success or failure
of the project.
 Recognize people work differently and respect those differences.
 Sometimes, it contradicts a lot of what you have heard.
 It says, everyone is accountable/ responsible.
 XP wants the team to function as a unit and because of that, we want everyone to be
held accountable if they're considered a single unit.
 This, of course, will take courage also for everyone to be held accountable and for
everyone’s work to be visible.

XP Roles
 What are the roles in XP?
 XP and Scrum are going to be very similar, so we do have some very similar roles.
Coach
 First one is the coach.
 In Scrum you're the Scrum Master
 In XP, you're the coach.
 Will you act as a mentor guide in the process, helping the team stay on track?
 You're a facilitator, helping the team become more effective.
 You're not going to be a manager and you're not going to tell the team what to do.
 Remember the team itself organizing customers.
  This is the business representative who provides the requirements, priorities and
drives the business direction to the project priorities and requirements.
 That's their main job.
 In Scrum => product owner.
 programmer => Agile Project Team.
 These are the folks who build the product, they write the codes.
 In XP => testers.
 These are the people that helps the customers define and write the acceptance test for
the user stories.
 XP have testers and they work with the customers and because one of the things that
XP pushes is the customer writes the test and then the team helps to come up with
ways of meeting the tests.
 if we can pass the customer's test, we did something right.

XP Practices
 Some calls planning games or planning activities.
Release Planning
 The first one is release planning.
 A release is basically a combination of sprints or iteration that's pushed to production
users.
 Release = sprint1 + sprint2+ sprint3+… => production users
 So we can give out to those production users.
 The customers should know what those functionalities are, not the team.
 The team may create a way, like the building and accounts receivable module, and
they have a way to input the customers and they can put all the customer's
information.
 The team has finished.
 It took two sprints to make and give it to the users.
 And the users are like, we don't want that because it's not very useful.
 We can just enter customers, but we can't do anything with them, so it's not very
useful for them.
 So the customers want to be able to make an invoice and to receive the payments.
 Not a customer is just telling us what they want in two releases.
 That means they're seeing value there.
 They don't see much value.
 Just enter in a customer.
 Customer => want only one release, which is the most value.
 Then, developers will estimate how difficult it is to build.
Iteration Plan
 Iteration is comparable to sprints.
 Iteration Vs Sprint
 These are short development cycles within a release.
 This is conducted at the start of every iteration of about or every two weeks.
 Now, in extreme, you're looking at their door cycles of about 1 to 2 weeks.
 Customers explain the functionality they want in that iteration.
 Developers then break down into task and estimate the amount of work.
 Now, how much work can they get done that iteration?
  That is going to be based on the estimates and the amount of work to accomplish in
previous iterations.
Small Release
 A small release is a frequent small release that is given it's frequently
 It's what I mean small it's not going to contain many sprints.
 It may only have one sprint or one iteration, but it's something that's given to test
environments.
 You want to make sure that you do rigorous testing and continuous integration is code
is coming in as being checked in.
 You want to make sure you keep doing that because that's how quality is maintained.
 This helps to demonstrate progress and visibility to your customers.
Customer Tests
 The customers describe one or more tests to show to work and the software is
working.
 The team then builds the automated test to show the software is working well.
 That's different than how the older software development would work in older
software development.
 The Team members, the programmers would come up with a way to test the test the
codes or test the program.
 But if the customer can determine what type of test they want and how they would
test it, and then we would build to ensure we meet those tests would be better because
then they feel like this thing works the way they want it to work.
Collective Code Ownership
 Any pair of programmers can improve or amend any code.
 Multiple people work on all code.
 This results in increased visibility and knowledge of that code.
 First of all, it sounds risky that anyone can change anything, any code.
 But even though that sounds risky, what this does is it opens visibility because now
everyone can see the code.
 More eyes.
 Hopefully we can catch more errors or more bugs.
 This does lead to higher quality.
 With more people looking to code, there's a greater chance of less defects, less risk.
 If a programmer leaves.
 If someone leaves, you don't have to worry that you don't have a replacement.
 People get sick.
 They may be out for a couple of weeks because the knowledge is shared and all the
people know what the code looks like.
 Speaking about code, one of the things you have to do is follow good code in
standard, consistent code and standard when the software is done.
 It should be it should be looked like if it has been written by a single knowledgeable
programmer.
Sustainable Piece
 While periods of overtime is generally necessary in any project, repeated long hours
of overtime are unsustainable.
 Counterproductive work in 14 hours every single day, six days a week, seven days a
week is counterproductive.
 People get tired, especially programming.
  Programmers have to be very analytical.
 It's a very mental, challenging job.
 If there's no downtime or time to refresh the mind, they start to lose the ability to be as
knowledgeable or analytical as they would be.
 The practice of maintaining a sustainable pace of development optimizes the delivery
of long term value.
 Sustainable pace leads to long term value because they're always going to deliver
most of the time deliver, hopefully bug free software.
Metaphor
 XP uses metaphors and symbols to explain designs and create a shared technical
vision.
 One of the things we have to understand is when we are talking to users.
 Programmers think in programming methods.
 Users thinks in simple methods.
 Is there a gap, a bridge that can be between those programmers and those customers?
 Well, this is need to create that bridge.
 It's going to help create that shared understanding.
 That shared vision of where we're trying to get there.
 These are basically descriptions.
 They help establish the comparisons that all the stakeholders can understand and help
explain how the system should work, basically.
 Eg. the invoice and module is like an accounts receivable personnel who make sure
money is collected from our customers.
 So actual programmers know what they're looking for.
 They're looking to have a system that they can collect money from the customers.
 Easy to understand on every end.
Continuous Integration
 This involves bringing code together and making sure it compiles and works together.
 The moment you write codes, you check in the codes into a code and library.
 It integrates that code to ensure it doesn't break any other functionality.
 This practice is critical because it brings problems to the surface before more.
 More code is built on top of faulty or incompatible designs.
 In the world of programming, it's pretty standard now to do continuous integration.
 As you're writing codes, you integrate it into the codes that's already there.
 You don't want to write codes that's bad integrated there, then write more bad code,
put it there.
 And even if you write good code later and you put it in now it's on top of that code.
 You don't want that.
 You want to keep integrating your codes over and over.
Test Driven Development
 This is going to sound a little bit backwards and what people that have followed
traditional work that I've learned
 the team writes the test prior to developing the new code.
 If the tests are working correctly, the initial code that entered will fail.
 Why?
 Because they didn't write any.
 The code will then pass the test once it's written correctly.
 Let's talk about that for a second.
 Test driven development.
 You write the tests.
 You didn't write the code.
 You've written nothing and run the test.
 Well, there's nothing in there or whatever is there.
 It's not complete.
 It's going to fail.
 Know the tests, then study.
 So you're building your knowledge based on the questions you've got to answer.
 To prepare PMP, Read the chapter, and then test.
 Test driven development works in this manner.
 Write the tests, then write the code.
 So, the code is written to the test.
 This in shorter codes would pass the tests, try out method of studying.
 It'll probably make you pass more exams.
 Remember, I have like 60 certification.
 That's a method I use all the time.
Pair programming
 Pair programming in XB Production Code is written by two developers working as a
peer to write and provide real time reviews of the software as it emerges.
 Working in pairs also helps to spread knowledge about the system to a team.
 There's a guy sitting next.
 He's watching the code as I'm writing it.
 Or maybe he's writing and I'm watching him.
 Well, this sounds this may sound inefficient because now you're spending you have
two people you're paying to write one line of code.
 It sounds inefficient, but it leads to less defect over time.
 Pair programming is a core concept in Agile because the more eyes on it, the less
bugs on it.
 When you write 2 million lines of code, it's impossible to go back and look at all of
them.
 But if there's a second pair of eyes on it, the less likely you're going to have any bugs
on those particular codes.
Simple Design The next thing we have is simple design.
 When it's done, simple design.
 The code is always the code should always be testable, browser understandable and
explainable.
 Do the simplest thing that could work next.
 Complex design is replaced with simpler design.
 There was simplicity as one of its core values the best architects, requirements and
designs emerge from self-organizing teams.
 That's a big concept.
 We're going to have to inspect that and learn more about self-organizing, self-directed
teams.
 But remember, everything should be simple.
 Refactoring
 Refactoring = removing redundancy
  Exam: Notice word by its definition, refactoring its definition is about removing
redundancy(unnecessary), eliminate an unused functionality and rejuvenate(revitalize)
an obsolete design.
 You want to refactor throughout the entire project cycle.
 This help saves time and increased quality.
 Basically, refactoring is about keeping your code clean and concise, making it easy to
understand, modify and extend.
 So remember, refactoring is basically cleaning up your codes when you're finished
writing them.

Basic Terminology review

 This table shows the difference between Scrum and extreme programming and how
the terminology line up.
 Because going forward in the class,
 what's gonna happen is, we're gonna sometimes interchange using the term sprint and
iteration.
Sprint
 Sprint is the same thing as an iteration.
 Fixed time box, length of time.
 Remember, about one to four weeks worth of work.
 A release in Scrum is known as a small release in extreme programming.
 This is generally what's released to production.
 You have sprint or release planning.
 This is determining what iterations, or how many sprints will be within a certain
release.
 This is basically an agile planning meeting.
Product owner = customer
 The product owner, customer, in extreme programming, that's the person, that's the
business representative that represents the business to the project.
 The retrospective is the reflection, which is the lesson learned that extreme
programming does at the end of their iteration, we do a retrospective in Scrum.
 This is that lesson learned-style meeting.
 ScrumMaster = Coach = Agile Project Manager
 You have a ScrumMaster, coach for your exam.
 Though, they'll call it an agile project manager.
Development Team and Extremists = Agile Project Team = Empowered cross-
functional team
 The development team and extremists call a team, that's the empowered cross-
functional team that does the development work.
 In exam, it's called the Agile Project Team.
Daily Scrum = Daily Standup Meeting
The Daily Scrum is also known as the daily standup meeting.
For your exam, they'll call it the daily standup meeting, that's that 15-minute meeting
when they answer the three questions.

Lean Development
 First of all, Lean is not really originally started as a software development.
 Lean was started by Toyota, the car manufacturer, as a manufacturing method,
 and then was then applied to software development.
 Some of the things that Toyota used in order to minimize waste when producing their
cars is those concepts will then be applied to software development and is now being
applied to Agile.
Principles of Lean
1. using visual management tool, using a lot of those, any tool that's visual.
 Remember this concept of low tech, high touch, some information radiators,
 in which case you can see things right away.
 So Agile promotes this.
 Let's use a big whiteboard.
 Let's use big charts.
 Everybody can see things.
2. Identify customer-defined value.
 So the other thing is we have to know what the customer defined as value.
 Who defines the value?
 Who defines what value is?
 The customer does because we want to give them valuable products.
3. Building in learning and continuous improvement.
 Toyota promotes, and so should you, continuous improvement on our products?
 You can't improve your products in your business if you don't improve the people in
the business.
 Products don't improve themselves.
 People improve products, and people to learn in order to become more knowledgeable
or they have to keep learning in order to continuously improve themselves.
 So you want to make sure that you're building learning into things, always ensuring
that your employees and even your managers are learning continuously.
Now, Lean has some important principles, such as:
 eliminate waste
 empower the team
 deliver quick
 optimize the whole
 build quality in
 defer decision
 amplify learning
These are some of the Lean principles that we should be looking at.
Eliminate waste
 This is one of its core concepts
 Lean identifies what's known as seven different types of waste, and we'll take a look
at that in a few minutes.
 To maximize value, we must minimize waste.
 Remember, this is really coming from a car manufacturer.
 So imagine Toyota manufacturing a car, and when they buy different types of metals
and materials to make that car or truck or SUV or whatever is it they're making, they
wanna minimize waste, because when you're producing millions of cars, a little bit of
waste really adds up.
 So in software, what do we consider waste?
 You should know about waste in software development or in Agile for your exam.
 Waste would be something that's partially done work, delays, handoffs on
unnecessary features.
Empower the team
 Don't micromanage the team.
 Don't take that approach.
 We should respect the team members' superior knowledge of the technical steps
required on the projects, and let them use it.
 Why would you want to micromanage your team?
 If they have more knowledge than you in programming software why would you want
to micromanage them?
 It doesn't make sense for micromanagers, especially when you don't have as much
knowledge as they do.
Deliver Fast
  You wanna deliver fast, quickly delivering valuable software and iterating through
designs, right?
 So you wanna deliver software as quickly as possible because that's how they see
value.
Optimize the whole
 We aim to see the system as more than sum of its parts.
 When you optimize the whole, you're optimizing everything in the system.
 You can't optimize one little part of a system or two little parts or even one big part,
 because you are as strong as your weakest section.
 Eg, if you're building a car, you could build a car that goes 300miles/hr
 Let's say you wanna build a cargo 300 miles/hr, but one of the engine mounts or bolts
can only sustain vibrations with a car of up to 200 miles per hour.
 So just that little bolt, forget about the engine and the transmission and the body of the
car.
 If that car exceeds 200 miles per hour, that bolt can break, the engine can fall, and the
car can crash.
 So it doesn't matter all the other 2,000 parts that goes into making a car.
 That one bolt, you're as strong as just that one bolt.
 So when you optimize the system, you gotta see it as every single part.
 You think of a race car that does go 300 miles per hour.
 Every single part in that car has to be rated for 300 miles per hour.
Build Quality In
 Build quality into the product and continuously assure quality throughout the
development process.
 Quality should be built in.
 You should be checking for quality, doing continuous integration testing, rigorous
testing also of the products you're building.
Defer Decisions
 Balance early planning with making decisions and committing to things as late as
possible.
 You want to defer decisions.
 You don't wanna make decisions right away.
 Generally, you make decisions when you're ready to go with just that decision,
 you're less likely to or be willing to accept change.
 You're less likely to accept change if you make decisions right then and there.
 If you defer your decisions to a later part or a later time, you're more than likely
gonna welcome that change.
Amplify Learning
 This concept involves facilitating communications early and often and getting
feedback as soon as possible and building on what we learn.
 As we go through the software development process, we want to communicate what
works, what doesn't work.
 You want to get feedback on what the customer thinks or even how the team is
performing.
 You want to do this quickly, you want to do this early so you can fix and change
things as this project is progressing.
7 Wastes of Lean
1. Partially done work
  It is work that cannot be delivered to the customer or wouldn't be delivered to the
customer, the customer is not using.
 In other words, they paid you to do work that they gain no value of.
 Imagine I paid you to paint this wall for me, but you only paint half of the wall and I
can't use the room.
 So in that situation, that's partially done work that I spent money on that I'm not
getting any value on.
2. Extra processes
3. Extra features
 Anything extra that I didn't ask for or find useful is considered waste.
4. Task switching
 People working on multiple things, people working on multiple projects.
 If they're not focused on one particular task, they will not be able to complete that
task.
Waiting
 Anytime you wait for something, waiting for an approval, waiting for a sign off,
waiting is of course a waste of time.
 If I told you, "Okay, well, you want to get this project approval. Give me two weeks."
 Okay, what do you do for two weeks?
 You wait, but now it's two weeks.
 If you doing nothing, you're wasting time.
Motion
 Any motion that doesn't add value is probably gonna be a waste.
 Eg. having a distributed team around the world and people having to do motion, extra
motion just to start a meeting online or to start up a GoToMeeting or a WebEx
meeting or whatnot, that's motion that doesn't really add much value. If that team was
co-located in the same room, you could have eliminated that waste.
Defects
Things that needs to be fixed,
Things that has errors in them, those would also be considered waste.

Kanban Development
 Next Agile method is Kanban development.
 Kanban is the Japanese word meaning sign board.
 This comes from the lean production system that comes from Toyota.
 So Kanban is a sign board.
 It's basically a board with little sticky notes on it.
 And they have the number of cards that they have in there.
 In Agile projects, you should use a Kanban board, or a sign board, because it helps to
visualize the work.
 And it limits work in progress.
 So in Agile we promote this theory of visualization.
 We promote this theory of information radiators with diagram, chart,radiates
information.
 So one of the best ways to do that is with a Kanban board.
 Kanban don’t need to use software.
 It is drawing on a whiteboard that you can just write out.
 Just make a couple of columns and I just have a few simple columns there.
 Let's take a look at this diagram.

 There are the things with the column, the middle is six and four
 It is limiting the work in progress.
 If it is six cards, it means we should never be working on more than six items.
 So you notice I have one, two, three, four items.
 So that's good.
 Another one is we should never be testing more than four things in testing.
 So in diagram, we have three, so we're doing good.
 So we're limiting the work that's getting done.
 The work that my team is working on.
 So that's one of its main things is that it's going to give us the big visualization of
work.
 That way the moment people walk into the room, they can see what we're working on.
 They know why we're limiting things.
 And the main thing is of course it limits to work in progress.
 What is the five principles of Kanban?
1. Visualizing the work
 As you saw from that diagram, you look at it, you know what I'm doing,you're able to
to see how much I'm limiting them.
 Eg. Softwar projects, by definition, manipulate knowledge which is intangible and
invisible.
2. Limit Work In Progress(WIP)
 Keeping the amount of work in progress low increases the visibility of issues and
bottlenecks.
 You don't want to put too much work in a process queue because too much work
means that if we're working on a lot of things, we may not be working on anything.
 We want to focus our attention on just a certain amount of work.
 And the team should determine what's that limit in work in progress in visualization.
 Software for example by definition is not visualized.
 You have to come up with a method to have visualized the work.
3. Manage Flow
 By tracking the flow of work through a system, issues can be identified and changes
can be measured for effectiveness.
 So as the cards are moving from work that needs to get done to going into in
progress.
 In testing, it doesn't have to be something as simple as design coding, stress testing,
code testing, static testing, dynamic test.
 You could have different columns.
 It just doesn't have to be four columns like I had.
 So you can create a pull system.
 It creates this pull system as data is being pulled across.
 It makes the process policies explicit.
  This is important because you wanna, clearly explain how things work, how the team
is getting work done.
 This leads to good open discussions on how we can improve our processes.
 It does help with collaboration, improves collaboration a lot because now we can look
at different types of measurements and experimentation and we can find issues or we
can find ways to improve it.
Pull System
 Kanban is known as a pull system.
 Data is being pulled from one to the next.
 So, for example, in progress, maximum is six.
 We can pull one more item from here.
Testing
 Testing is limited to four.
 But we have three.
 We can pull one more to here.
 When this is done, then we can put it here.
Push System
 So if you don't have a pull system, you have a push system.
 Push systems are not good.
 Push system is, okay, let's say I do the in progress.
 I do the coding, you do the testing.
 I'm done coding, I'm pushing that work to you.
 I'm done coding, I push that work to you.
 Now all of a sudden a bottleneck starts to happen because now you start to pile up the
work.
 I'm finishing work, I'm just giving it to you.
 Now let's say there's somebody after you.
 If you're doing a static testing and somebody has to do dynamic testing.
 Static testing is code testing.
 So you're doing all the code testing.
 So I finish writing the code, I give it to you.
 You gotta examine the code, but it's taking you longer.
 All of a sudden you start to create this bottleneck.
 You start to create this bottleneck.
 What we should do, and that's a push 'cause I keep giving it to you, but you're not
keeping up with me.
 And then the other person after you is just waiting.
 Remember waiting is considered waste.
 We got that from lean.
 So you don't want that.
Pull System
 A pull system is when you are ready, you're gonna take the work from me.
 When that other person's ready, they'll take the work from you.
 So a pull system, that way things are being pulled through the system, not just push,
push, push throughout.
 So that's another concept you want to ensure you understand with Agile.
Work In Progress
 Kanban limits the work in progress.
 It's one of its main things.
 And I wanna show you this diagram of a concept you should expect a question on
your exam.
 This is called Little's Law.
 Now this is a law that says the cycle times are proportional to queue lengths.
 We can predict completion time based on the queue.
 So I wanna show you guys how to read this.

 Here you have a chart and in this chart, you notice you have this reddish, pinkish area,
yellow area and then you have this green area.
 Now in the Kanban board, you have the total work.
 This is the work in progress.
 And then you have the green.
 So what's happening over time is this red area is pushing down into that green area by
going through the work in progress.
 Let's say the project started and you had 400 features that you had to get done.
 So the project started in April, you had 400 features to get done.
 By March this work was pushing down.
 And by Mar, you were able to complete this much work. 'cause the queue is coming
down.
 By June you were able to complete this much work.
 By July you're finishing this much work.
 So eventually the way this thing looks at the endis that all of that red will become
green, and the yellow will go away because all of the red is pushing down into the
green.
 What is Little's Law?
 Little Law does is that it analyzes the queue of the work in progress, and that can tell
us how much work is getting done.
 So if we look, if we just take a circle and we just analyze this section.
  So we're looking at the Y axis.
 This is how long it will take to get this much work done.
 Y axis is the length, the units.
 So this is the amount of work we're getting done.
 And this is how long, in theory, it should take to get that work done.
 So it depends on how this line is.
 If this line is gonna cross like this, that may be a month and a half worth of work to
get this much work done.
 Really that's what it's showing you.
 So if I look at the queue and how long would it take to get all of this work done?
 Well, it should take this long.
 My line is not perfectly straight there, but good enough.
 It should take about that much time.
 That's all this law is saying.
 You don't necessarily need to memorize this.
 You should understand that what is Little's Law?
 You should expect a question on it for your exam.
 It's just basically showing the work in progress.
 And by analyzing the the work in progress queue you can see how long certain work
will take.

Other Agile Methods

 These are other agile methods, but you really don't need to know this for your exam.
Feature Driven Development
 This is when the team of first develop an overall model for the product and then
 build a list of features and then plan the work around the features.
Dynamic Systems Development
 This is one of the first models and it has eight particular principles:
1. Focusing on the business need.
2. Having good collaboration
3. Demonstrating control over the project …
Crystal
 Crystal is a customizable methodology that are basically coded by color names.
 How big the team has to be and how critical the project was.
 So if it was crystal clear, Eg, the project would be low critical, but a small team, if it
was a very big color, it will be high critical.
 It's high critical, but a big team would be crystal magenta.
 So those are some of the other agile methods.

Agile Declaration of Interdependence

 Need to be familiar with the principles, not to memorize, but be familiar with the
principles for exam.
 Agile Declaration of Interdependence = DOI
 also known as DOI.
 In 2004, there was the Agile Development Conference, and a bunch of experts came
together, and you can see their names in the copyright at the bottom.
 And they created, they came up with all these principles and they created with this
concept of the Declaration of Interdependence.
 So I want to quickly review because it helps to get you in the Agile mindset.
 The first thing up, agile and adaptive approaches for linking people, projects, and
value.
 We are a community of project leaders that are highly successful at delivering results
to achieve these results.
 So, we're going to be a community of project leaders.
 We're going to help to deliver results.
 Firstly, we want to increase return on investment by making continuous flow of
value our focus.
 So we want to consistently give value.
 We want to keep, not only do we want to focus on it, but we want to continuously
keep it flowing.
 Every time we do a release to a customer, they're getting value.
 We deliver reliable results by engaging customers in frequent interactions and
shared ownership.
 In Agile is at the end of every sprint or iteration, you're going to do that review
meeting in which case you're going to be reviewing what is it that you did.
 So you're always engage in them.
 When they're adding things to the product backlog, that they're also engaged.
 We expect uncertainty and manage for it through iterations, anticipations, and
adaptation.
 Project management in its definition is uncertainty.
 PMBOK defined the project as a temporary endeavor to create a unique, and if it's
something that you're creating that's unique, means you probably haven't done it
before.
 So there's this level of uncertainty, but we have to know how to manage that
uncertainty.
 We have to know how to look at those iterations, anticipate the uncertainty,
 We unleash creativity and innovation by recognizing that individuals are the
ultimate source of value and creating an environment where they can make a
difference.
 Value comes from people doing work.
 Value comes from a painter painting a wall, a software developer programming an
application.
 That's where value comes from.
 We want to make sure that we give them that environment so they could produce
valuable work.
 We boost performance through group accountability for results and share
responsibility for team effectiveness.
 We must have accountability for that team.
 How are we going to get performance out of them?
 We want to make sure they function well.
 We improve effectiveness and reliability through having specific situations,
 strategies, processes, and practice.
 So we want to improve our processes.
 We want to have effective process,
 We want to become more reliable.
 No need to memorize, just read several times.
  But it starts to get you into that mindset.

Agile mindset
 What is that mindset.
 You want to have this mindset.
 You want to become an agile advocate.
 You want to promote agile.
 You want to think agile.
 What this thinking agile mean?
Welcoming Changes.
 In every agile project, you're gonna anticipate changes.
 You're gonna welcome it and promote it.
 That sounds vastly different than a traditional project in which case you may suppress
change with change request forms and processes.
 Traditional method => suppress change(change request)
 Agile method => bring all your changes.
 I want changes.
 You're gonna work.
Working in small value increments
 You're gonna be working in small value increments.
 In other words, it is called delivering increments of work.
 You're going to always giving them value.
 You finish a little part of the work, give it to them.
 Let them use it for value.
 You're using building feedback loops.
Using Build and Feedback Loop
 You're gonna be building and you're gonna have in feedback loops.
 In other words, I build something, I give it to you.
 You give me feedback.
 I take that feedback,
 I input it into the next sprint or iteration, and I start again.
 Based on the feedback I'm getting, I'm improving.
Learning through Discovery
 You're gonna learn through discovery.
 The more you know, the more you're gonna learn.
 Value driven development.
 Everything we develop is based on value, because we're gonna talk to the customer.
 We're gonna have 'em define what value is.
Failing fast with learning
 When you fail, you learn the best lessons.
 The best lessons in life will come at failure but you don't want to fail.
 If it takes too long to fail the lessons will be hard to come by.
 You're not gonna learn quickly.
 If a process has to fail, let it fail quickly.
So, we can learn from it and improve on it.
Continuous delivery.
 We are alwaysremember it's not a big bang delivery that comes at the end in
traditional software development.
  This is gonna be continuous delivery.
 As the product is being developed, you're giving it to them.
Continuous Improvement
 At the end of every iteration, you're doing a retrospective.
 That's a meeting where you look at the end of that iteration or that sprint and you're
gonna improve on it.
 So you always, you're doing lesson learn, all the time.
 You're improving on how we're gonna conduct these processes.
 These are some of the mindset that we should be thinking as we move forward.

Leading Effectively
 To motivate people
 To tap into people's intrinsic motivations, internally speaking, what motivates them.
 Why would the team members want to do something and what would motivate them
to do it?
 And how do we align that to the project goals?
 Money is a motivating factor, but it is not the only factor.
 Maybe people has a sense of work.
 In other words, they feel happy when the work is complete.
 So they like working on things that can get finished.
 Maybe people take pride in that work.
 Maybe people like other types of rewards, such as a letter of recognition.
 Find what motivates your team member and align that to the project.
Management Vs Leadership
 Management is more mechanical focus,
 Leadership is more human focus.
 Managers or management focus on task.
 Focus on controlling people to get a certain work done.
 The command that the work gets done.
 Leaders are different.
 Leaders are more focused on people and the purpose why we're getting something
done.
 They're more focused on empowerment of the person to get those job done.
 Instead of commanding, they're more of communicating with people.
 Eg. If I need someone to run my accountant department, I want management focus.
 In the accounting department, task has to get done in a certain way.
 Financial statements has to be made in a certain way.
 So I need somebody to control, command the users in that department to ensure it's
get done correct.
 Leadership, the CEO of a business has to be a leader.
 This is a person that has to have a vision.
 This is a person that empowers the people around them and communicate what they
want.
 So they are basically more people-focused 'cause they have a vision and they're trying
to drive the direction of that business.
 Do you wanna be management or leadership?
 Well, on an agile project, you want to lead your team.
 You don't wanna manage your team.
 You don't want to command them and say,"This is the way to do it."
 You want to empower them.
 You want to communicate to them and let them find a way.
Servant Leadership
 One of the main ways of managing an agile team is a term that you should be very
familiar with, and that is a term called servant leadership.
 Now, servant leadership is an important concept on this test.
 It's something that you should be practicing.
 So servant leadership is different than a traditional project management leader.
 A traditional project manager is a real management focus.
 Follow this process, do it the way I want.
 Servant leadership is different.
 Servant leadership is empowering the team.
 It's really about shielding them from interruptions, any type of interruptions,
bureaucracy of a business, users trying to come after them or changing their tools or
changing their teams.
 It's about removing impediments to progress, removing the obstacles that can
slow the team down.
 It's about communicating and recommunicating the project vision, keeping them
on track, letting them see that what is it you're trying to accomplish.
 Carry food and water, both physically and theoretically.
 In other words, you'll bring 'em some coffee and donuts
 once in a while, but you're also gonna give them the tools and the environment for
them to succeed in.
 Now, in a book by Jeffrey Pinto titled, "Project Leadership from Theory to Practice,"
 12 principles for agile project that we should follow when you being a leader of how
to manage your team.
1. Learn the team member needs.
2. Learn the project requirements.
3. Act for the welfare of the teams.
 The simultaneous welfare of the team and the project.
 You're looking at the team, you're looking at the project.
 We gotta make sure they both work well.
4. Create an environment of functional accountability where the team will be held
accountable.
5. Have a vision of the completed project.
6. Use the project vision to drive your own behavior.
7. Serve as the central figure in a successful project team development.
 You want to be that central figure, so the team, not only are they empowered, but
you're there to help them and facilitate them.
8. Recognize team conflicts as a positive step.
 You know, we'll get to conflict management in another part of this class, but a lot of
project managers may not like conflict, but conflict is good.
 When people have conflict with each other, when people are willing to fight each
other, have major disagreements, it means they care about that topic.
 One of the worst things you can ever have is when team members don't care about the
work, but if they're having conflicts, means they really care.
 They're passionate about what they want versus what somebody else's want.
 So conflict is good, it means they care, but you have to manage that.
9. Manage with an eye toward ethics.
 There isn't enough that I can say why ethics is good.
 Good ethics means good trustworthiness.
 If your team doesn't trust you, I think you're gonna have a hard time managing that
team.
10. Remember that ethics is not an afterthought, but it is integrated into part of our
thinking.
11. Take time to reflect on the project and what has happened.
12. Develop the trick of thinking backwards and seeing what we did and learning from
that.

What are some of the tools we can use?

 Tools like Microsoft Project is great, but you still need good soft skills.
 Having good soft skills, the ability to learn how to talk and communicate to people is
gonna be important.
 You sitting here, taking this class, listening to me, do you feel that you have good soft
skills?
 I think as a project manager,and this is something I tell my P&P students,
 and I'm telling now my agile students,
 the most important skill a project manager can have is not necessarily Microsoft
project skills.
 It's good people skills.
 We interact with people.
 We need good soft skills.
 The type of behavior we need, we need to have good honesty.
 You want to be honest.
 You want to come across as an honest individual.
 That way, people trust you.
 You want to think forward, always see forward.
 Yes, things behind you may not be the best, but keep moving forward.
 You wanna be competent.
 You want to be able, for people to say, "Okay, this person knows what they're
talking."
 Learn what you're doing so you can come across competent person.
 One of the most important things you can be as a leader is inspiring.
 There's a difference between commanding someone to do something
 and inspiring them to do it.
 If you have that agile mindset, you can pass this exam.
 If I inspire you,
 I'm pretty sure you're gonna take it and pass.
 If I just command you,
 you're gonna find it very difficult to do it.
 You're gonna find it more of a chore than something you want to accomplish.
 Always communicate the project vision.
 Let the team know.
 Enable others to act.
 Switch from exclusive tools to inclusive tools.
 Microsoft Project is an exclusive tool, because if I'm using it, my head is stuck in this
screen.
 Using a whiteboard and drawing.
 When on a whiteboard with other people behind me drawing next to me are watching
me draw it is inclusive.
 You want people to participate.
 The people that change the world are the people that's willing to change the status
quo.

 If everyone wants to follow the status quo, humanity will never advance in time.
 It's visionaries that decides that we need to colonize Mars and move to Mars,
 even though that sounds crazy.
 Those are the people that changes the world.
 You have to be that person.
 You have to be willing to change that status quo.
 And if that is so, then you have to be willing to fail, and we'll talk about that in a
minute.
 Practice transparency through visualization.
 Everything should be transparent.
 Everything should have big charts, everything should have Kanban boards.
 Now, I mentioned changing the status quo.
 If you change the status quo, you're probably gonna fail most of the time.
 But remember, if you're not willing to do that, if you're not willing to change that
status quo, you may never find that better method or that better way of doing
something.
 So what we want is we want to create an environment so that our team members has a
safe place or safe environment for experimentation.
 Let them experiment with new techniques and processes.
 Let them share knowledge through collaboration.
 And you should encourage emergent leaderships through the safe environment.
 As people try new things, encourage them, let them try new things because that may
be better.
 A safe environment for experimentation.
 What happens when you have an environment when someone tries something new
and they're prosecuted?
 Prosecution/take legal action happens when somebody tries something new
 and it fails.
 Generally, when something is tried new and hasn't been done before, it may fail.
 You prosecute them, you ridicule/mock them, you punish them.
 No one will ever try anything new after that, ever.
 So, when you create a safe environment for experimentation, people want to try.
 If they fail, you don't ridicule them, you don't punish them.
 You tell them, "Well, it was a good job.
 We don't win all the time, but we gotta keep trying."
 Let's say you tried a new process to code the software, and it didn't work, but we lost
two weeks worth of programming time.
 I have two things I could do.
 I could come to you and say, "Well, Mary, you did a bad job.
  You made us waste two weeks and now we're spending more money, all because of
you."
 Now you feel prosecuted.
 Now you feel that you're being punished for trying something.
 Or I could have come to you and says, "Mary, great job.
 I think you did, I think it was a good try.
 I think you really put a lot of time and effort.
 But I want you to try another method.
 Keep trying until you find the right way that works.
 Because if we find that new breakthrough in that process,
 we can drastically increase how we program this software."
 When other people see this, they will say to themselves,
 "Oh, okay, so we're not prosecuted for trying."
 And they themselves try.
 They themselves try new things because now they know they can experiment
 and not be prosecuted.
 It's in this type of environment that your team will grow.
 It's in this environment that will make a team become the highest performing team
that they could be, exceeding industry norms and changing the status quo.

Value-Driven Delivery
 The first thing to understand is why these projects get undertaken.
 Why do we do projects?
 Companies do projects, because they see some kind of value in it.
 Now, when we think of value, most people probably think of money.
o We're gonna do this project, and we're hoping that this project returns more
money in the future.
 So if I spend $10 doing this project, we're hoping that the project eventually returns
$30 or $40 worth of value back to us, or extra income that we need.
 So, what all project management is about, is about delivering value.
 As we're delivering increments of the project or the entire project,
 we're basically delivering value.
 Now, value just doesn't have to come in the form of money or capital.
 It can come in other ways.
 So other ways could be producing a product of what benefit does this product have,
 including improving the current products and services that we have.
 There may be a market demand for a particular product that we don't offer that we
see.
 Eg. you're in the market of manufacturing computer hardware, and you realize there's
a big demand right now for wireless keyboards.
 So you decided, "Okay, there's a big market demand, let's get into that space."
 Another one is safety compliance.
 Being in compliance is a value by itself, because if you're out of compliance, you
could be fined.
 So, one of the things that people confuse, especially with compliance projects,
 and regulations or regulatory compliance is,
 you spend money to be in compliance, but it may not return any money to your
business.
  It allows you to keep the money you have, that's the value.
 Because if you're not in compliance to that new regulations, or safety compliance,
 you might be losing money if you're fined, or you might even be put out of business.
 So, the value is not getting fined.
 The value is being able to conduct business in that particular market.

Early Value Delivery

 All Agile Projects looks to promote value early and often.
 So as you're doing Agile Projects, you're doing releases.
 One of the main benefits of an Agile project is having those releases into production
of periodic points versus that traditional project of where you're doing this big bang
release one year or two years after the project has started.
 So with Agile Projects, you're creating small sets of that product and you're giving it
to the users.
 So Agile promotes this concept of having value being delivered early.
 Eg. in a traditional project there's no value for years as the project is getting done if it
took two years to do.
 On an Agile Project, if you're gonna deliver a functional product within a matter of
three months of it being started after three sprints, that means you're getting value
from that project within three months of that project getting started.
 That's promoting early value delivery, maybe after the third month, you're not gonna
get a release for another three months or another four months, but that is still better
than waiting two years.
 So you're doing it often and you're doing it early.
 Now the good thing about Agile is that what you get first at the beginning of the
project is known to be the most valuable components of that project.
 So let's say you're building an accounting system and the most valuable module to the
business is the accounts receivable section where they can send out invoices and build
their customers.
 Well, the good thing about Agile Project is you're gonna get that first.
 So you're gonna get the most valuable aspect or the most high value components
quickest or as soon as possible.
 This helps to reduce risk and the risk of it not meeting or the risk of it not meeting
your requirements or the risk of customers not being satisfied because when you
deliver it, they can go back and change it, they give you their feedback.
 So it helps to reduce this risk of not meeting requirements because if you let the
project finish and then you give it to them and they don't like it, you have to redo the
whole system.
 Another good thing about Agile Project as we're delivering products early, as we're
given value early, is that this is really gonna help lead to a stakeholder satisfaction
which is the ultimate test of a successful project.
 Because we're gonna help to engage them.
 Remember, at the end of every sprint, they have the ability to review the products
 that we have worked on.
 We are gonna help to understand what their needs are as they come in after the sprint.
 They look at the product and they say, "Well, we like this part of it or we don't like
this part of it."
 So we're gonna help to understand what their needs are on the project itself.
  So we're helping to understand their needs.
 We're gonna keep them engaged because every couple of weeks they're there,
 they're even invited to some of our standup meetings.
 So they're always engaged.
 This is gonna build confidence.
 The more they see work is getting done, the more they're getting products to use,
 the more they're actually engaged in the process.
 It puts confidence within them that the team is doing what they like or the team is
delivering value to them often and early.

Reduce Waste
 One of the core concepts of ensuring that you maximize value on any project is to
minimize waste.
 Waste can lead to value being decreased.
 Waste is really anything that is non-value added.
 It's things you may be doing on your project that has no value or is adding any value
to that particular project.
 So you wanna be able to reduce or minimize these particular non-value added
activities or non-value added parts or components.
1. Waste could be things such as partially done work.
 So partially done work is work that has not completed.
 And if you spend time doing work that was never completed and given to those
particular stakeholders, that is considered waste.
 In other words, you wasted time, you wasted money, you wasted specific resources,
but there's nothing to gain from that work because it's not completed.
2. Extra processes
 Doing extra processes that may not require or add any value or add any functionality
to a product is of course considered waste.
3. Extra features that users may not use.
 So let's say I'm programming an application for you and I add two or three new
features to an application that you will never use or none of your users in your
department finds useful.
 That is wasting time and money once again.
Waiting, any unnecessary waiting on a project is gonna be considered some form of waste.
Imagine I'm waiting for a sign off, I'm wasting time waiting for that sign off.
Defects.
 If I produce products and the product is defective and then I have to go back and fix
the product, then that of itself is considered a waste because the defect of itself needs
to be fixed.
 Now I'm wasting time and wasting resources fixing it.
 And on any project, whether it's an Agile project or traditional project, you emphasize
these wasteful activities, these non-value added activities or components,
 and remove them or minimize them.
 So we could maximize the value added work.

Assessing value-Financial metrics

 When you wanna assess value, you must understand that one of the most popular
ways to assess value will be in the terms of money.
  Your CEO your board of directors, your shareholders will assess value based on cash.
 For exam, These particular formulas, such as the ROI(Return on Investment) or
IRR(Internal Rate of Return) or NPV(Net Present Value) or the earned value
ROI(Return on Investment)
 It is a ratio that looks at the benefits received from the investment to the money
invested.
 It's usually percentage.
 So let's say I have an ROI of 20%.
 So that means that, well, all the money I invested and I'm gonna get back that plus
20%.
 Eg. I invested $10,000 and I'm gonna get back 20% more= $2,000.

IRR(Internal Rate of Return)

 This is an interest rate you will need to get in today's money to receive a certain
amount of money in the future.
 Now, that means if you spend this amount of money, what would, how much interest
do you need to return?
 What percentage do you need to earn every year in order to make a certain amount of
money later?
 Now, in terms of percentages, the higher the IRR in percentage, the better that project
is or the more value in terms of money it would return.
NPV(Net Present Value or Present Value)
 This is looking at the future, the value of future money in today's terms.
 So one of the ways I tell students is would you like to get $10 now or $15 in 10 years?
 If you're looking at money and how much money is being generated?
 If you assume a certain amount of interest rate, inflation rate that happens over time,
 then you know what it's better I take the $10.
 Now I could buy more products with it than if I was to take $15 in 10 years.
Earned Value Management
 So the Earned Value Management is a series of formulas that looks at how the project
is being tracked.
 It is a formula that monitor the value of the project as its progressing.
 Things such as plan value(PV), earned value(EV), SPI, CPI, these are gonna be
formulas that you would find more on a PMP exam, no need for ACP exam.
 And is the project on budget?
 Is the project ahead of budget?
 Is it under budget?
 Is it ahead of schedule?
 Is it behind schedule?
 It really helps to assess how that project is progressing in terms of value.

Accounting on agile projects

 While managing an agile project, you're gonna have to do some kind of accounting in
order to spend the money that has been allocated to the project.
 So agile accounting is about accounting for the money, how you're spending that
money.
 Now, you could do different type of economic models that would tell us how to
spend the money on an agile project.
  So for this concept, you don't need to know any particular economic model.
 What you do need to know is just how it works, so how does an agile project
accounting differ than traditional projects?
 Agile accounting is different than traditional accounting.

Traditional Project
 You're basically spending a lot of money upfront with no money coming back in from
that project.
 So let's say the project is $100,000.
 You're basically gonna spend $100,000, but there's no return at all until that project is
done, the project, it comes into production, whatever that product or service was,
 and customers start to use it.
 Agile works differently than that, because agile will look to deliver value as quickly
as possible.
 It uses something called MVP(minimum viable product), or a very small amount of
the product that is just good enough to be used, so returning value quicker.
 This leads to the project or an opportunity to be funded incrementally.
In Traditional project
 You got that $100,000.
 So let's say the project took one year to complete.
 So let's say the project return was another 100.
 So you spend 100, you make 100, and a traditional project, you're gonna spend this
100.
 After you're done, you're gonna get $100,000 worth of value coming back.
 So you gotta wait 12 months, you spend 100,000 as the 12 months is progressing on
the traditional project.
 12 months is up, and let's say it takes a year to return that money.
 So in two years, you could make your $100,000 after spending your 100.
Agile Project
 In the agile project, let's say in the first couple of months, you spend $20,000.
 You start using the product, and now you start saving money or generating more
revenue because of the product.
 So in three months, you start using it in two months, and then you make back the
money you've already spent in that three months.
 Now, after that three months is done, you do another three months worth of work, you
spend another $20,000 or $30,000, then you return what you finished there and you
start to generate revenue off of that part.
 So you're not actually spending all the money on a project and returning nothing till
the end.
 You're actually funding it incrementally.
 The good thing here is that you're doing, and you're getting the most valuable aspects
of the project right upfront,
 So you're funding the most valuable aspect of your project upfront.
 And there may come a time when, especially on software projects, when we only did
70% of the project, but 70% gives us all the value we'll ever need, no need for that
30%.
 So they stop funding it, and they gain maximized value from the money that they have
spent.
  So, Agile looks to deliver value as quickly as possible.
 Us MVP(Minimal Viable Product)
 This lead to more opportunity for incremental funding.
 So this is how an agile project is funded differently than a traditional project.

Key Performance Indicators(KPI)

 As an Agile project is progressing, you have to find ways or key performance
indicators of how we could measure the performance of that project.
 And there are a few different KPIs, or key performance indicators, once again, that
you can use to measure the progress of your Agile project.
1. Rate of Progress
 One of them is called the rate of progress.
 So this is how much points has been completed.
 We haven't gotten into to assigning points to work or coming up with user stories and
assigning points to those user stories, but just know that the work is generally rated in
points.
 So this feature may be worth three points.
 This feature may be worth five points.
 This feature may be worth 13 points.
 So there's a system we use to assign points to these features.
 So one way to keep track of it is looking at how much points or work is getting done,
where you're progressing.
2. Remaining Work
 The other one is just looking at the remaining work.
 So how much work is yet to be done from the backlog.
 So let's say you have 30 features in the product backlog, and you've finished about 10
of them, so you got 20 more left to do.
3. Likely Completion Date
 Another one is the likely completion date.
 Speaking with the project team, they'll tell you based on how much work is in there
and how they estimated the work, they'll tell you, "Well, we estimate that the work
would be done in six months from now or maybe one year from now."
4. Likely Cost Remaining
 Remember the Agile inverting the triangle, where we try to keep fixed time and cost.
 So maybe if we had set a fixed cost or a fixed budget on the project, now we'll be able
to see how much cost is left on this project, like, how much more of the budget do we
have to spend.
 So let's say the project was $100,000, and we have spent $60,000.
 So we got $40,000 more to go on this particular project.

 Now there are other KPIs that you can use out there that you can come up with
yourself.
 This is just some examples of ways to help keep track or manage the progress of an
Agile project.

Regulatory Compliance
 Regulations are generally mandate given to you by some government agency or local
authority and it must be implemented into the project work.
  Because if you don't, if you do the project and you don't incorporate your regulatory
compliance, sometimes the project can be discarded or the product cannot be used
because it is in need of certain regulations.
 So, lets say you're working on or building a car in the car industry and it doesn't meet
certain emissions, requirements or safety standards, then the car could probably never
be drivenso you wasted all of this time and money.
 So, one of the things that we have to do is we must be able to incorporate these
regulatory compliance's or regulations into the project work as regular work that's
getting done, its regular, develop and work of that particular product.
 So, that's one way of doing it, is just as you are building the product, as you are
building that software, as you are building like recreating that service, you wanna
incorporate these regulations or these regulatory compliance into it as just normal part
of the work.
 So, if you are building a car you want to incorporate the legal standards or the safety
standards or the mission standards as just part of the way the car is developed.
 So, as you're looking at the engine and the transmission and you're designing it, you're
thinking about these emission standards and how to meet them as you are designing
the engine.
 The other way to do it would be just completing the product itself and then fitting it
with whatever regulatory compliance is needed.
 So in that situation instead of building it into the car as you were, instead of building
the emission standards into the car as you were building it, maybe you built the best
performance car you can think about and then added in ways to reduce its emission
after you have finished building the actual car itself.
 Now, on any project that you work on and for most of us that work on projects with
regulatory compliance's on top of us,

Risk Managemet
 In Agile project, one of the things that you have to keep in mind is risk.
 Risk management is a very complex process in the PMBOK.
 Risk management, in general, needs to be done throughout the entire project.
 Because risk is closely related to value.
 Risk is considered anti-value, which means that risk can pose a threat
 that can remove value from the project.
 Eg. one of the best values of following an Agile project.
 Well, that would be getting the products delivered to you as early as possible.
 That is one of the best values of it.
 But risk can delay that.
 There is a risk that you could have a hurricane or a snow or a snowstorm.
 There's a risk that could be a pandemic.
 And your whole project is delayed and you're not gonna get that value.
 So it's anti-value.
 There's a risk that the feature fails.
 There is risk that the feature that implementing this feature can affect other features.
 There's risk that a team member can be out for an extended period of time causing the
sprint velocity or the team velocity to get out of place.
 So it is really anti-value.
 It has the potential to remove, erode, or reduce value with different types of threats.
  Risk management is something that should be done throughout the entire project, as
the team should be identifying risk and assessing risk.
 Now, one of the ways to do that is by following risk management processes.
 Risk management process is very straightforward.

Plan
 The first thing is you gotta make a plan.
 You gotta make a plan of how to identify and assess and assess your risk
 and coming up with the right risk responses and so on.
 That you're gonna do with the first process of plan risk management.
 So you're making a risk management plan that tells you how to do the next set of
processes.
To Idendify a Risk
 The next one is to identify a risk.
 Here's where the project team identifies some of those risk such as there's a
snowstorm, there's a pandemic, there is a failure of a piece of hardware.
 There's a feature that causes corruption.
 So you gotta identify all the risks that can affect your project.
Qualitative Assessments
 The next thing is a quantitative and qualitative assessments.
 So a qualitative assessment is more of a verbal ranking the risk like which risk ranks
the highest, which risk ranks medium and which risk ranks low.
 So a qualitative risk assessment is basically looking at the probability of the risk, the
impact of the risk, and then assigning some verbal values, like it is high, medium, or
low.
Quantitative Assessments
 Quantitative analysis is assigning a numerical value.
 So this risk takes place, this is how much it will cost this project, it will...
 If this risk happens, it'll delay the project by 10 days.
 It'll cost the project $20,000 worth of additional materials.
 Now, after you have identified the risk, you have assessed the risk.
Plan Risk Response
 Now, you gotta come up with how to respond to the risk.
 Responding to the risk could be ways of mitigating the risk or lowering the risk.
 Maybe if there's a snowstorm, we can all work from home.
 It'll have a little bit of impact on the way we communicate and may delay the project
but it doesn't stop the project.
 So it doesn't completely shut the project down.
 So that's a mitigation.
 You can accept risk by not doing anything about the risk and just accepting it like an
earthquake here in New York City may be a risk that you just accept.
 Now, your project gets executed and you start doing the work.
 As the sprint is going on and people are doing the work, if there is a particular risk
that takes place, you have to implement the response.
 So let's say there is a snowstorm and everybody has to work from home.
 Well, now you gotta implement your risk response.
 Maybe you're using the latest in the remote technologies, like Webex or GoTo
Meeting or Zoom and whatnot, to ensure that we can work from home.
 So if there is a risk that takes place on the business, then you have to implement those
responses and ensure that you reduce those risks.

 Now, comes as the project is consistently keep going and they're doing the work and
the sprint, you gotta monitor and control the risk.
 You have to see the work that's getting done, see if the risk materializes itself, see if
those responses are working and getting done correctly.
 And these are just some of the traditional risk processes that you would have.

 What are some tools in Agile?

 The first thing is called risk adjusted backlog.
 That is not a different backlog.
 It's adjusting the product backlog for risk.
 It's looking at the product backlog and reprioritizing it or removing features from the
product backlog because that feature has a high risk of failing or that feature will add
more risk to other features.
 So the risk adjusted backlog is basically looking at the backlog itself, the product
backlog, and adjusting it for risk.

 Another thing is called a risk burndown charts.

 Risk burndown charts are basically showing you how risk is evolving throughout the
entire project.
 Whether the risk is getting more, errors becoming less on the project.

 There are some of the risk management process.

 risk is considered anti-value.
 We have to be able to identify them, assess them, and if they do take place, we wanna
be able to respond.

 One of the worst things is you're working on a project and there is a risk that
materializes itself that you should have identified.
 And before you know it, it takes out your entire project or it causes massive delays or
removes value.
 You wanna be able to catch these things early.
 You want to be able to think about them early.
 You wanna come up with your right responses and you wanna be able to reduce risk.
 That way, there is no loss of value throughout the project.
How Customers Conduct Value Prioritization
 One of the core concepts in Agile practicing or Agile project management is this
value-based prioritization.
 The features, in the product backlog, is prioritized based on value.
 Well, what does that mean?
 How do we assess value?
 How do we know features are more valuable than others?
 It can be based on how much return investment, return on money that particular
feature will return.
 Eg. if you're building a CRM system, one of the most valuable features would be an
automatic response to leads that are coming in.
 That way the lead knows or the that potential customer knows that we're gonna get
back to them as soon as possible.
 So maybe we prioritize that to be the highest features in our CRM but it can also be
risk and other dependencies that can affect how we value certain features.

 This is not something that we as the Agile project manager or our team does.
 This is something that the customers will conduct.
 The customers, the product owner needs to prioritize the features for us.
 They need to tell us, "This is the most important feature.
 This is the second, this the third, this is the fourth."
 How do we get them engaged in order to do this?

 Now, let me give a tip for your exam.

 On your exam, a question about the customers don't think they should do this or the
Agile project manager doesn't want them to do it or something like that.
 No matter what the question says, the answer is:
 Teach the customers why it's important to do this and have them do it.
 For your exam, you must let the customers or the product owner do this.

 One of the main things about Agile is interaction.

 It's about having everybody come together in collaboration and communication.
 We have some prioritization techniques:
1. Simple Scheme
2. MoSCoW Prioritization
3. Monopoly Money,
4. 100-point method
5. Dot Voting or Multi-voting
6. Kano Analysis
7. Requirements Prioritization Model

Different Prioritization Techniques

Simple Scheme
 The first one is simple scheme.
 This technique is to get the customers involved and to help prioritize those features in
the product backlog.
 So the customers can and tell us,what do they think is priority1,priority2?
 And they label it.
  They look at this feature and they say, " that's priority1, this is priority2, and this is
priority3."
 This can be very problematic, if all the features are prority1.
 If you have 20 features, we can't do all 20 at the same time.
 You need to discuss with the customers, and let them know, not everything can be
priority one or priority two, or priority three.
 We should select most important one, and least important one, when you use this
scheme.
MoSCoW
 MoSCoW basically is a prioritization scheme where you put things into basically four
categories:
1. must have
2. should have
3. could have
4. would like to have, but not this time.
must have
 Must have are features that must be in the software.
 Eg. you're making a CRM system.
 Capturing leads and storing the leads is a must have.
 It must be able to capture the leads off the website as people typing them in, because
that is its main cores, what it does.
 It should have the ability, and this is gonna be important features, should have their
important features.
 It should have the ability for us to keep it, as salespeople for us to keep a track of
when we call them or when we email them.
 It would be nice if we could have things such as automatic responses if they send in
any type of query requests or any type of emails.
 We would like to have the ability to keep track or have reports that tells us the
percentage of conversions.
should have
 This here is something that, how I would see, how I would rank the features in a
CRM.
 Having a percentage of conversion is a should have."
 That's good.
 When you're interacting with me, you're saying, " I would like to rank that higher."
 Remember, there's no right and wrong answer to this thing.
 It's basically the customers have to do it.
Dot Voting or multi-voting
 Each person gets a certain number of dots to distribute.
 Eg. you give everybody dots on sticky notes, or I even saw this with done with bottle
caps.
 You give everyone a certain number of dots, and they can put so many dots.
 Eg. I'm a security person. If I'm doing a software, and one of the features is dual
factor authentication logging into a system,
 I'm gonna put four dots on that.
 You're not a security person.
 You put one dot on that feature.
 Another person puts two dots on that feature.
  The CRM system, the percentage of conversion, you put two dots on that, I put one
dot on that.
 So all the customers are putting different dots on different features, and then add 'em
up at the end, and then you'll see which one carries the most dots.
 So those are probably the most valuable features that people find the most valuable.
Monopoly Money
 Give everyone equal monopoly money.
 They distribute the funds to what they value the most
 Give everyone a thousand dollars of Monopoly money, and then they'll distribute it.
 Encryption of the database is important.
 Dual factor authentication is important, so I'm gonna put $500 on that.
 You don't find it that important.
 You're gonna put $100 on that, so you distribute how much funds you want on that.
100-point method
 Each person is given 100-points.
 They use to distribute to individual requirements.
 Now, another one is also similar, what's called Dot Voting, , and 100-point method.
 100-point method, same concept.
 So everybody gets 100 points and then they're distributed.
 I feel that the dual factor authentication is important, so I'm gonna put on that, I don't
know, 50 points.
 You put 20 points, somebody else put five points.
 So go through all the features,and then they put points or money or dots onto them.
 these names of these things because they're famous to show up on practice questions.
 or maybe even on your real exam,
 but you can't forget what the purpose is of these things.
 The purpose is, two main purpose of these techniques.
 Number one, definitely to prioritize the features.
 Number two, get 'em involved, get interacting, engaging in the project.

Kano Analysis
 Important for the exam.
 It helps to understand the customers satisfaction.
 4Types:
1. Delighters or Exciters
2. Satisfiers
3. Dissatisfiers
4. Indifferent
Delighters
 These are high value features.
 These are features that really makes the software usable.
 Going back to an accounting system,
 the ability to receive payments online quickly using credit cards is something that the
customers may feel is a high value feature.
Satisfiers
 Now, these are good.
 The more the better.
 The ability to edit the invoice, the ability to produce accounts payables and receivable
reports are gonna be very good to have.
Dissatisfiers
 If the feature is not in the software or in the product,
 it makes the customers unhappy, but it doesn't really add any more satisfaction,
 but if it's not there, it's gonna make them really unhappy.
 Eg. the ability to reset a password on a piece of software.
 It doesn't add any more features.
 It doesn't make me happy to use the software, but if that's not there, I'm gonna be very
upset with it.
Indifferent
 This has really no impact on the customers one way or the other.
 The feature is there, but it doesn't impact them whether it's there or it's not there.
 So you notice functionality based on the charter, satisfaction and functionality,
performance, attractiveness, and must be.
 That's really what this is looking at.
 In order for things to be satisfactory to our customers, the functionality has to be
there.
 The performance has to be there.

Delivering Value Incrementally

 When you're working on an Agile project, you're going to be delivering value
incrementally.
Incremental Value
 Incremental Value is about deploying working parts of the product over the life of the
product, of the project.
 As the project is progressing you're delivering value is a part of the software that you
can start using and start getting value from it.
 In software development, deliver it to a testing environment, than to production.
 You never wanna release components, or modules, or features in a software that hasn't
been tested because that's just gonna make them more upset or make the customers
more angry if it doesn't function the way they want.
 So you need to test it.
 By doing this, what's gonna happen is that you'll be able to reduce the amount of
rework
 because you're gonna find issues quicker and earlier.
 This allows you to fix them quicker and earlier.
 The faster you can find problems in a particular system, the faster you can fix it
without piling on more stuff.
 Eg. after three months worth of work, I give you the accounts receivable system
 on your account and software.
 But then after using it for a few weeks
 you tell me, " there's some bugs with it, or this doesn't work, or this feature doesn't
work."
 I can get and fix it right away instead of me, instead of you telling this to me years
later
 after the account system is already made.
 Because now for me to edit that part I have to edit all the parts.
 This brings me to a very nice looking graph and this is what this is.
 So in this one, you'll notice the cost of change as things is going into production,
 as things is being, go as,
 in a traditional project, as things is pushed all the way to the end user in production,
 the cost of change rises significantly.
 So if you want to change something, or rediscover an issue, we want to fix something,
 during the requirements it's very cheap.
 It doesn't cost much.
 In coding, not that much.
 But by the time you start to get into that testing and especially into production, the
cost of the systems or the cost of these, of fixing errors or defects will drastically
increase.
 So this is one of the core concept of Agile.
 One of the core reasons why we want to use Agile is because we can find issues and
defects
 and fix them and a lot earlier.

Minimal Viable Product

 One agile concept that you should be familiar with for your exam is minimal viable
product.
 So something that is small, not something very large, it's not a whole project.
 So MVP, this refers to a set of functionality that is complete to be useful, but small
enough not to be a whole project.
 Now, in software development, this is a module.
 Eg. In the accounting system, think of QuickBooks.
  QuickBooks accounting software does accounts receivable, it does payable, it does
bank reconciliation, it does report, and you would think I'm sending QuickBooks here
to you guys.
 So this particular software, if they were to build this software following Agile
methods, then what they would do is, they would build each section that would say,
 here's the accounts payable section
 here's your accounts receivable section,
 here's the ability to write checks,
 here's the ability to make invoices."
 So they're giving you these systems and little modules that you could start using right
away.
 This is, as they're giving you these little systems or modules, this is considered an
MVP.
 Now, Agile pushes this because you don't have to wait for me to build a whole
software for you to use it and see value.
 For me to deliver value early, I'm gonna use a whole lot of MVPs throughout this
entire software project.
 So remember, agile pushes MVPs throughout the entire project so we could see value
throughout the project.

Tools for Agile Projects

 Speaking engagement to a large team of developers that were starting to use Agile.
 And one of the questions that was presented to me was what type of tools should they
be using?
 What type of software in particular were they using?
 And my response to them was, the cheaper the better.
 In fact, the cheapest tool you can get that doesn't have to deal with a licensing cost
like a piece of software is best.
 And that's how I'm gonna introduce the theme and that's how I introduce the team to
them.
 And what you should know for your exam of low-tech, high-touch. Low-tech, high-
touch.
 This whiteboard behind me, I just need a marker now in order to use it is probably the
best tool we have.
 Sticky notes and paper are the best tools that you wanna have.
 That's why I said the cheaper the better?
 Because if you go out and you buy a complex software tool to manage your project,
it's probably gonna cost you thousands of dollars.
 And then you gotta pay a per user license.
 This whiteboard behind me probably costs a few hundred bucks and I'm gonna use it
for a long tim and the markers are a few dollars each.
 There is problems with computer models or using computer tools.
1. First of all, there is this perception of when you're using a computer model.
 So let's say you're using Microsoft Project to create a schedule for your project.
 There is this perception that the computer is modelled and the way the software is
being entered, that the data is accurate and the precision of the data is accurate.
 But let's be realistic, on any computer model that's creating a schedule or a budget for
you, if you put garbage data in your schedule's gonna come out being garbage, your
budget's gonna come out being garbage.
 So the moment people say, oh we have a model for this or we use a financial model to
calculate our budget or scheduling model, now all of a sudden people start to believe
that this is the right one.
 But in theory, it's not necessarily the right one because that could lead to people
having a high perception of it when there isn't any because the model is producing
wrong data.
 So there is some issues with them.
 The other major issue that I have with computer models is there's no interaction.
 Look, if I'm using Microsoft Project and I'm using a desktop.
 So let's say I have a desktop, a laptop on my desk, I'm looking down I'm typing in my
Microsoft Project, I'm typing.
 I'm not talking to you anymore.
 I'm just inputting data.
 And if my head is here, it's not with you, it's here.
 That means there is no interaction.
 And that really goes against the principles of an agile project.
 So if you're using a model, only few people update them, only few people are gonna
be using them.
 Now there are other things here we should keep in mind.
 Low-tech, high-touch.
 Use card, charts, whiteboards, and walls.
 Visual things, visual charts and graph always looks good versus something on a
computer screen that only one person can see.
 Low-tech, high-touch promotes good communication and collaboration.
 Don't use a Gantt chart.
 Use a Kanban board
 You want to use something where, look, if this is a Kanban board behind me
 and I'm using the Kanban board and I'm taking my little sticky paper and I'm just
putting them over and I'm saying let's pull it from here to here.
 Now me and you are interacting with each other.
 And that's what you want when you're using low-tech and high-touch.
 I want you guys to touch.
 So Kanban and task boards are great things, right?
 Kanban and task boards are great information radiators.
 Imagine if this whole wall behind me here was some form of a Kanban board.
 And I had like you see here
 I had lines put up and I had little cards in them.
 People can walk into my space and be like, oh, there you go.
 All the cards that they have and that's what they're getting done.
 That's what those people over there are testing.
 So it radiates information.
 So information radiators ensures efficient diffusion of information means
information is being given out.
 Now, I prefer don't ever ask me for what Kanban software to use.
 I am against Kanban software, highly against it.
  Unless it's a virtual team, then you have no choice.
 But if the team is co-located which is what your exam wants,
 Can be drawn on whiteboard or even a section of wall.
 I prefer to be on a whiteboard or if you guys know some of the agile tooling,
some companies have walls that are basically whiteboards.
 Not just a whiteboard, but a wall could be a glass wall, it could be they have
wallpaper now that are basically whiteboards from ceiling to the floor.
 This makes everything very visible.
 It makes the iteration backlog visible.
 The sprint backlog.
 Imagine this room is this is where my team sits.
 This is where we're all looking at it.
 We can all just look at the wall and see what's there instead of having to put on a
software.
 If you're using software, it's not visible, right?
 You minimize the software because you're working on the screen.
 Out of mind, out of sight, out of mind is the same.
 So if I don't see it, I'm not thinking about it.
 But if it's on a white board the moment I look up I can see the task at hand.
 So you go into a meeting, you have your big task board or Kanban board, people can
talk about it because imagine we're doing a meeting and everybody's just seeing it.
 So it becomes a good focal point of the meeting because everybody can see the
Kanban board or the task that is in front of them that they have to get done.
 Okay, so on any agile project, high-tech, low-touch or sometimes I would tell people
the cheapest thing.
 No software.
 Again, unless it's a virtual team, you got no choice.
 But let's keep it as low-tech, high-touch.
 Let's make sure everyone interacts, let's have it on the wall at all times so we know we
have to get it done.
 That way there's no out of sight, out of mind thing happening.
 And let's get everyone to be participating and good collaboration on the projects.

Limit WIP
 Why do we wanna limit the work in progress?
 Work in progress is work that it's considered waste if remembering the lean concepts,
that it's considered some form of waste.
 Now, this is work that has been started but has not been completed yet.
 So you don't wanna have too much work in progress.
 Kanban board is one of the methods to limit work in progress.
 Work in progress is money spent with no return because work in progress is I'm
spending money on programmers to get the job done, as they're programming the
software, but there's no return yet because they're still programming it.
 One of the things that it could do is that it hides bottlenecks.
 It hides things that can slow down the process because you don't know what they are
 until the work is actually done.
 It's when the work is getting done is when the risk can happen.
 The risk of the software crashing, the risk of the server's hard drive dying.
 The hard drive on the server can't die if the server was never turned on.
 The software can't crash or the programming software using to program or code with
 can't crash if you never actually started it.
 So it's potential risk.
 The moment you start doing the work, that's when the risk could take place.
 If you're not doing the task, there is no risk there.
 Eg. if you're not driving the car, there is no way to get into a car accident
 if you're not in the car.
 But the moment you get into the car and you start driving the car, the work in
progress, if you get into work, for example, now you can get into an accident.
 There's potential risk there.
 Agile projects, of course limits or tries to limit the work in progress, optimizing it,
making quick, making it as efficient as possible, so there is very little work in
progress.
 The best way to do this is just to use a Kanban board and limit how much work you
can do in each cycle or each phase of that particular project.

Cumulative Flow Diagrams

 To show the progression of work as it's getting done,how much points we have
completed, or how much work we've gotten done and how much work is in each
particular phase of the project is called a CFD or cumulative flow diagrams.
 Now, cumulative flow diagrams are basically stacked graphs that show how work is
progressing throughout the project.
 So in the beginning of it, we have about 600 points, but as the project is progressing,
we're cutting into that work and we're getting it done.
 Hopefully the project finishes within a year or in about 11 months here, and it's
almost all done.
 Then it goes into development as all of this work that's ready to get done goes into
development, testing, and deploying.
 Now, there's a very important concept that we need to know for our exam with CFDs
is this theory of constraints.
 And here's the graph again.
 I just changed up to color to make it a lot easier to see.
 And this theory of bottlenecks and constraint is something that you should be able
 to identify on your exam.
 Now, one of the theories was something called Little's Law.
 Go back to domain one when I covered Little's Law where I showed you on a CFD
how to determine how long it will take work to be done by just looking at the queue.

 Now, one theory that I do want to cover in this section is this bottleneck and theory of
constraint.
 Now, by looking at this diagram,
 I want you to watch this diagram carefully.
 And let's take my trusty pin here that I have and you'll notice, so this blue one here,
this is all the work that needs to get done.
 In comes this red section.
 This is all the development work.
 But you notice there's something odd about this development work.
 It's getting wider.
 Look at how wide this thing is, right?
 You notice it's getting very, very wide as the project is progressing.
 And what's causing this? Why?
 What's the bottleneck?
 What's constraining this one, pushing the work down?
 In theory, all of this blue should go into this purple one.
 In theory, all of the work that's ready to go through development and testing
should be deployed to the users.
 But you notice there's some kind of constraint here because it seems like the testing is
stuck here.
 The development is not the testing has work to be done.
 Nothing is really coming out to deployment.
 Whatever's happened here in April it seems, that was it.
 That's all we deployed.
 We haven't deployed much.
 So what's causing this problem?
 Well, what's causing that is gonna be known as how we determine that is the theory of
constraint.
 How do we find the bottleneck?
 And the bottleneck activity is not the development.
 The bottleneck activity is the one that comes right after the widening activity.
 So that's what the theory specifies.
 The one that's coming after the activity that's widening is the bottleneck.
 Why?
 Because it seems like the work that has to get done, the work that's ready to get done
is pushing down into development.
 Now development is doing the work, but development can't push it down.
 So whoever, maybe the testers are stuck.
 Like they're stuck in one section and they can't finish the testing activities
 to take the work from development.
 So development is doing work, doing work and they have work ready to push into the
testing section, but it's not pulling.
 Remember it's in Agile.
 It's a pull system.
 So it's not pulling in the development work.
 So the development work is widening and widening and wide, while that bottleneck
activity is just staying there.
 So when we talk about the theory of constraint or bottlenecks, know this concept for
your exam.
 You should expect the questioner to give you a graph and you gotta find the
bottleneck activity.
 The bottleneck activity is the one after the activity that is widening the most.

Agile Contrating
 This is a difficult topic to cover on an Agile project or to do on Agile project.
 Imagine hiring an external company to do the software development for you or to
develop a piece of that software outside the project.
 So you gotta get a contract, or even internally, you have contracts with your internal
developers.
 This becomes difficult for a couple of reasons.
1. Agile's huge flexibility with scope.
 Agile’s flexibility creates difficulty in outlining contract acceptance criteria.
 Anytime you've ever written a contract with someone, generally a contract doesn't
have much flexibility in terms of the scope.
 I go out and I get a contract with Bob's Painting Company to paint my wall white.
 That's different than an Agile project.
 In Agile project, the scope shouldn't vary.
 If the scope varies a lot, it's the time cost that doesn't vary.
 So that's where this becomes difficult.
 So the flexibility of the Agile project of scope makes it difficult and outline and
the contract's acceptance criteria because how does the contractor know the
work is done if the scope can vary and change.
 Agile attempts to have fixed time and costs while varying the scope or the
functionality on it.
 Remember that inverted triangle concept?
 One of the Agile values is, we're going to look at customer.
 We're gonna take customer collaboration
 over contract negotiations.
 We want less contract negotiation.
 We want more participation, more cooperation or closer cooperation, we want more
feedback on our projects.
 So that's what you want from an Agile contract.
 Now, you do have a contract that some people refer to as money for nothing and
change for free.
 So this, imagine you have a contract.
 Let's take a look at money for nothing.
 Let's say you do an Agile contract and you have 20 features.
 And after 15 features, you realize, now we paid for 20 features.
 You do a contract with a software developers, you say, here we got 20 features.
 How much are you gonna charge?
 So they give us a price on those 20 features.
 But after the 15 feature, remember they have to do the most valuable one first.
 After the 15 feature, we don't see much value left on this project so we say, cut the
project off, I'm done with this project, you can keep the money.
 So it's money for nothing.
 The other one is change for free.
 Change for free is this.
 So let's say, again you got these 20 features you have to get done, but as the project is
progressing, we want to change one of those features, but you have to allow me to
change it for free.
 You have to say, I'm not removing the number of features.
 I'm just gonna remove feature 10 and I'm gonna replace feature 10 with another
feature.
 That's called change for free.
 Now, the other thing that I have here,
 the other two I have here, is something called a graduated fixed price contract.
 This is where me and the buyer, the buyer and the seller.
 Me = buyer, the contractor = the sellers
 We're gonna share the rewards.
 And to do this, we're gonna do an hourly rate based on if they finish early, they get
$20 an hour.
 If they finish on time, we'll give them $18 an hour.
 If they finish late, we give them $15 an hour.
 So those are really low wave rates for programmers, right?
 So basically, you're basically paying out a different fee based on how the work is
getting done.
 So we are encouraging them, hey can you finish a little bit early on this project?
 Because the earlier you finish, the earlier we're gonna see value.
 Now the other one here is a fixed price on a work package.
 Now this here is basically looking at each one of the work packages or each one of the
features that we have and then telling me a price, okay, this feature is $2,000, this
feature is $3,000, and so on and so on.
 So you're basically assigning the cost per each individual feature.
 This is probably the most used of these here.
 You can combine this with change for free or money for nothing in order to help
promote your Agile contracting.

Verifying and Validating

 Throughout the Agile project, you have to do a constant verification and validation of
value.
 The reason for that is because of something known as the Gulf of Evaluation.
 It means what one person describes is often different from how another interprets.
 Eg. if I was to describe this room to you or this studio, to you guys and interpret to
you guys that there are lights over here and there's a big screen in front of me and
there's mics and all types of weird sound dampening materials and whatnot.
 I could describe this room to you guys so in depth, and what you are seeing is not
what's actually here or how somebody else next to you is seeing it.
 It's just the way humans' perception work.
 We don't want this on our project.
 We don't want someone to describe something.
 We go out and we build it.
 There's an old technique where you start a line with 10 people, but there's a line where
you start a line with 10 people and you guys have probably heard about this before.
 And you tell something to the guy at the beginning of the line to tell it to the guy
behind him and they tell it to the person behind them and they tell it to the person
behind them.
 By the time you get to the 10th person, it's a completely different story than what was
told originally.
 How people interpret this and how then people reinterpret it again and give it to
somebody else.
 So you don't want this on a software project because I could explain as a user
  what I want to the programmer.
 The programmers can then, to the designers, the designer interprets this in their way
and it's not really what I want.
 And then they give it to the programmers and the programmers programs it in their
own method.
 Then the testers test it in their own method.
 By the time I get it back, it's nothing what I wanted.
 So you don't want this.
 How do we solve this problem?
 This is done by doing frequent validation and verifying the work.
 Now, the way to get this done would then be to use a variety of different things.
 And you can use things like the sprint review is a major one when they can come in
 and see what you're doing so you don't progress too far at the end of every sprint.
 You have those daily standup meetings that where they can be a part of,
the information radiators in the room the customers can see.
 So you don't wanna let this thing grow over time and let the Gulf of Evaluation
completely get outta hand.
 Now in XP you have validations and feedback consistently.
 Things such as peer programming.
 So the moment it's being written, it's being checked.
 Unit testing on every unit, peer negotiation.
 Peer negotiating can be done every hour as they're doing it.
 Every day we're doing those standup meetings.
 User comes in to do acceptance testing, we do iteration planning,
 and then we can do those sprint reviews.
 So there are different ways and methods to ensure that we do frequent validation and
verification because the Gulf of Evaluation is a real thing and it can really affect your
project.

Agile Quitz