Agile Principle

& Mindset
 • Agile frameworks and terminology • XP
• Agile Manifesto • Core practices
• 4 values • Core values
• 12 principles • Team roles
• Agile methods and approaches
• Agile process overview
• Kanban
• 5 principles
• Pull system
• WIP limits

Agile Fundamentals Training

• Leadership practices and principles
• Management vs. leadership
• Servant leadership (4 duties)

Agile Principles and Mindset

• Lean
• Core principles
• 7 wastes
sets the stage for understanding agile. It summarizes the agile mindset • Scrum
• Activities
and methodologies, outlines the major agile methodologies, and
• Artifacts
explores the nature of agile leadership and how it differs from traditional • Team roles

management

2
 Utilizing agile
• Why use agile?
• Different types of projects use different approaches
• Predictive project plan up front
• Knowledge work has many unknowns

Agile Principles and Mindset 3

 Knowledge Work Projects Are Different
• Industrial work requires up-front planning
• Knowledge work expects change
• Knowledge work is invisible work
• Agile is best suited for software development projects

Agile Principles and Mindset 4

 Contrasting industrial and knowledge work projects
Industrial Work Knowledge Work
• Work is visible • Work is invisible
• Work is stable • Work is changing
• Emphasis is on running things • Emphasis is on changing things
• More structure with fewer decisions • Less structure with more decisions
• Focus on the right answers • Focus on the right questions
• Define the task • Understand the task
• Command and control • Give autonomy
• Strict standards • Continuous innovation
• Focus on quality • Focus on quality
• Measure performance to strict standards • Continuously learn and teach
• Minimize cost of workers for a task • Treat workers as assets, not as costs

Agile Principles and Mindset 5

 Defined versus Empirical Processes
• Industrial work relies on defined processes
• Knowledge work relies on empirical processes
• A defined process defines all steps in advance
• Empirical processes are interactive, incremental, change often,
adapt, and pass through the reviews
• Empirical processes are change-driven

Agile Principles and Mindset 6

Exercise 1: Explain waterfall model (20 minutes)
Traditional model:

v List all of phases of Waterfall or your current working model. Each phase will be written in a sticker.
v List all of roles of Waterfall or your current working model. Each role will be written in a sticker.

v List all of the tasks of Waterfall or your current working model. Each task will be written in a sticker.
v List all of problems, issues, or weaknesses of Waterfall or your current working. model. Each problem,
issue, or weakness will be written in a sticker.

7
The Agile Mindset
Agility really involves adopting a new mindset – way of thinking – that is based on agile values and
principles.

8
 The Agile Mindset
• Can you be agile or just do a job?
• An agile mindset is based on agile values and principles
• An agile mindset is different than just recalling agile terms

The Agile Mindset 9

 Declaration of Interdenpendence

• We increase return on investment by making continuos flow of value our focus.

• We deliver reliable results by engaging customers in frequent interactions and share ownership.
• We expect uncertainty and manage for it through interations, anticipation, and adaptation.
• 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.
• We boost performance through group accountability for the results and shared responsibility for team
effectiveness.
• We improve effectiveness and reliability through situationally specific strategies, processes, and practices.

The Agile Mindset 10

 The Agile Triangle
• The key difference between the agile mindset and traditional project management is the
agile or “inverted” triangle of constraints.
• This reversal of the traditional triangle means that agile team allow scope to vary within
the fixed parameters of cost and time.

The Agile Mindset 11

Agile Manifesto
includes a statement of fours values and twelve guiding principles. It guides us to consider projects
from a value-based perspective.

12
 The Four Values

The Agile Manifesto 13

 The Four Values
Value 1: Individuals and Interactions Over Processes and Tools

We try to focus the team’s attention on the individuals and interactions involved

Focusing early on developing the individuals involved in the project and emphasizing productive and effective interactions help setup a project success

Value 2: Working software Over Comprehensive Documentation

We try to focus on the purpose or business value we’re trying to deliver, rather than paperwork

The agile approach to documentation Just enough only cover our needs; most of efforts focused on the emerging system

Just in time don’t have to spend extra time to keep it updated as reqs&designs change

Just in because easier and preferable to just proceduce it than to face the consequences of not doing

The Agile Manifesto 14

 The Four Values
Value 3:Customer Collaboration Over Contract Negotiation

To be flexible and accommodating, rather than fixed and uncooperative

Requires a more trusting relationship and more flexible contract models; it moves the emphasis from non-value –adding activities to productive work

Value 4: Responding to Change Over Following a Plan

Need to acknowledge initial plans were made when we knew least about the project and will need to be updated as the work progresses

Agile projects have highly visible queues of work and plans in the form of backlogs and task boards. The intent of this value is to broaden the number of

people who can readily engaged in the planning process by adjusting the plans and discussing the impact of changes

The Agile Manifesto 15

 The Twelve Principles

The Agile Manifesto 16

 The Twelve Principles
Principle 1: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software

Our focus should be on the customer and make them satisfy by valuable software, not perfect plans and documentation

It’s better to get something wrong up front and have time to correct it than to discover the issue much later when so much more has been built

What we’re delivering is valuable software, not completed work products, WBS items, documentation, or plans

Principle 2: Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage

Changes can be great for the project, for example, if they allow us to deliver a late-breaking, hight-priority feature

Agile methods use a lightweight, high-visibility approach –for example, continuously updating and prioritizing changes intothe backlog of work to be

done . Agile’s well understood, high-visibility methods for handling changes keep the project adaptive and flexible.

The Agile Manifesto 17

 The Twelve Principles
Principle 3:Deliver working software frequently, from the couple of weeks to a couple of months, with a preference to the shorter timescale

Principle emphasizes the importance of releasing work to a test environment and getting feedback

Agile teams need feedback on what they have created thus far to see if they can proceed, or if a change of course is needed

Delivering within a short timeframe also has the benefit of keeping the product owner engaged and keeping dialogue about the project going

Principle 4: Business people and developers must work together daily throughout the project

Written documents, emails, and even telephone calls are less efficient ways of transferring information than face-to-face interactions

Developers can learn about the business in a way that is far beyond what a collection of requirements-gathering meetings canever achieve. As a result,

development teams are able to suggest solutions and alternatives to business request. The business representatives also learn what types of solutions are

expensive or slow to develop, and what features are cheap. They can begin to fine-tune their requests in response.

The Agile Manifesto 18

 The Twelve Principles
Principle 5:Build the projects around motivated individuals. Give them the environment and support they need, and trust them to get the jobdone

Agile methods promote empowered teams. People work better when they are give the autonomy to organize and plan their our work.

Agile methods advocate freeing the team from the micromanagement of completing tasks on a Gantt chart

Knowledge work projects involve team members who have the unique areas of expertise. Such people do their best work when they are allowed to

make many of day-to-day decisions and local planning for the project.

Principle 6: The most efficient and effective method of conveying information to and within a development team is face-to-face conversation

Face-to-face conversation allow us to quickly transfer a lot of information in a richer way that includes emotions and body language

In face-to-face conversation , questions can be immediately answered, instance of “parked” with the hope that there will be afollow-up explanation

The Agile Manifesto 19

 The Twelve Principles
Principle 7:Working software is the primary measure of progress

Shift focus to working results rather than documentation and design. In agile, we assess progress based on the emerging product or service we are

creating

The definition of progress as “working system” creates a results-oriented view of the project. Interim deliverables and partially completed work will get

no external recognition. So we want to focus instead on the primary goal of the project - a product that delivers value to the business.

Principle 8: Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace of indefinitely

Agile methods strive to maximize value over the long term; Agile methods recognize the value of sustainable pace that allow team members to

maintain a work-life balance. A sustainable pace is not only better for the team; it benefits the organization as well.

Working at a pace that can be maintained indefinitely leads to a happier and more productive team.

The Agile Manifesto 20

 The Twelve Principles
Principle 9:Continuous attention to technical excellence and good design enhance agility

We have to be mindful of keeping the design clean, efficient, and open to changes. Technical excellence and good design allowthe development team

to understand and update the design easily.

Agile team needs to balance its efforts to deliver high-value features with continuos attention to the design of the solutions. This balance allows the

product to deliver long-term value without becoming difficult to maintain, change, or extend.

Principle 10: Simplicity –the art of maximizing the amount of work not done –is essential

In software world, up to 60 percent of features that are built are used either infrequently or never. Because so many feature that are built are never

actually used, and because complex system have an increased potential to be unreliable, agile methods focus on simplicity.

Agile methods seek the “simplest thing that could possible work” and recommend that this solution be built first . This approach not only mitigates risk
but also helps boost sponsor confidence.

The Agile Manifesto 21

 The Twelve Principles
Principle 11:The best architectures, requirements, and designs emerge from self-organizing teams

People like self-organizing; it allows them to find an approach that works best for their methods, their relationships, and their environment. They will

thoroughly understand and support the approach, because they helped create it. As a result, they will produce better work.

Self-organizing teams that have the autonomy to make local decisions have a higher level of ownership and pride in the architectures, requirements,

and designs they create than in those that are forced on them or “suggested” by external sources.

The members of a self-organizing project team are closest to the technical details of the project. As a result, they are best able to spot implementation
issues, along with opportunities for improvements

Principle 12: At regular intervals, the team reflects on how to become more effective, than tunes and adjusts its behavior accordingly

Agile methods employ frequently lookbacks, call “restropectives”, to reflect on how things are working on the project and identify opportunities for

improvements.

The Agile Manifesto 22

Agile Methodologies
The most common approaches are Scrum, Extreme Programming (XP), Lean product development,
Kanban, Feature-Driven Development (FDD), Dynamic Systems Development Method (DSDM), and
the Crystal family of mothods.

23
 Scrum
• Scrum is the popular agile model that is lightweight and easy to understand.

• Scrum Pillars and Values

• Transparency: involves giving visibility to those responsibility for the

outcome. Example: creating definition of “Done”,…

• Inspection: involves doing timely check of how well the project is

progressing toward its goals, looking for problemetic deviations of

differences from the goals.

• Adaptation: involves adjusting the team’s process to minimize further

issues if an inspection shows a problem or undersiable trend.

Scrum 24
 Scrum

Scrum Process

Scrum 25
 Introducing Scrum Sprints
• Timeboxiterationforprojectwork. • Withinasprintthereareseveralactivities:

• Atimeboxisapredeterminedduration. • Sprintplanningmeeting.

• Scrumsprintsarebetweenoneandfourweeksinduration. • Development.

• During a sprint no changes are made that would affect the goal of the • Dailyscrums.

sprint. • Sprintreviewmeeting.

• A sprint can be cancelled if they change in the project goals make the • Sprintretrospectivemeeting.

sprintgoalsobsolete. • `

• Onlytheproductownermaycancelasprint.

• If a sprint is cancelled, uncompleted backlog items are returned to the

productbacklog.

Scrum 26
 Introducing Scrum Team Roles
 PRODUCT OWNER ‚ SCRUM MASTER ƒ DEVELOPMENT TEAM
• Ensures and maximizes the profit/ return • Ensures that the values, practices • Generates value for the customer,
on investment (ROI) for customer. and rules of Scrum are understood building high quality product
• Responsible for product vision. and followed. increment.
• Decides what will be built and in which • Helps resolve impediments. • Self organizing, self managing.
order. • Capture empirical data to adjust • Negotiate commitments with the
• Defines the features of the product or forecast. product owner.
desired outcomes of the project. • Creates an environment conducive • Intensely Collaborative.
• Chooses release date and content. to self-organization. • Cross functional.
• Prioritizes features/outcomes according
to market value.
• Accepts or rejects work results.

Scrum 27
 Scrum Activities (Events, Ceremonies)
• Scrum activities are also known as events or ceremonies.
• There are five scrum ceremonies
 Grooming the Backlog ‚ Sprint Planning Meeting ƒ Daily Scrum

• The product owner owns the • Project team needs to discuss the • The daily scrum is also known as a
backlog. goals of the upcoming sprint stand-up meeting.
• Backlog refinement is the • Team discusses how the work will • This is a 15-minute timeboxed
prioritization backlog items. be accomplished meeting.
• The entire project team may • Product owner reviews with the • The daily scrum is held every day
participate in the backlog team items in the updated at the same time and location.
grooming. backlog • The daily scrum is for the
• Development team defines how development team only.
the work will be done in the goals
of the sprint will be achieved
• The development team is self-
organized.

Scrum 28
 Scrum Activities (Events, Ceremonies)
„ Sprint Review … Sprint Retrospective

• Hosted at the end of every sprint. • The development team meeting posted after the
• Attendees will be the development team, the product sprint review, but before the next sprint planning
owner, scrum master, and sometimes other project meeting.
stakeholders. • This is a meeting to inspect an adapt.
• The development team will demo the work created in • Lessons learned and opportunities for improvement.
the increment. • Review of the product owner’s feedback about the last
• The group will decide if “Done” has been achieved. iteration.
• The development team and the product owner will • An opportunity to improve on their approach based
discuss the sprint and the remaining items in the on the retrospective and the last sprint.
product backlog.

Scrum 29
 Working With Large Scrum Teams
• Scrum of scrums.
• Scrum of scrums of scrums.

• Four questions are answered:

1/ What has your team done since we last met?

2/ What will your team do before our next meeting?

3/ Are there any roadblocks in your team’s way?

4/ Will your team put anything in another team’s way?

Scrum 30
 Scrum Artifact – Product Increment
• The product increment is the outcome of an iteration
• The product increment is a chunk of the project work

• The development team and the product owner must be an agreement of what done means for an increment

Scrum 31
 Scrum Artifact – Product Backlog

• The product backlog is the source for all product requirements.

• The product owner sorts and prioritizes the backlog items.

• The development team always works on the most important items based

on the prioritized items in the product backlog.

• The backlog is always prioritized before the current sprint.

• Backlog refinement is done by both the product owner and the

development team working in harmony.

• The team estimates their capacity to attack the items in the product backlog.

Scrum 32
 Scrum Artifacts – Sprint Backlog
• Like the product backlog the sprint backlog is a prioritization of the product.

• The sprint backlog is a subset of the product backlog.

• The sprint backlog serves as the goal for the current iteration.

• The sprint backlog is a view into the work to be accomplished in the current sprint.

• The sprint backlog is updated and refined by the development team.

Scrum 33
Exercise 2: SCRUM Roles (15 minutes)
SCRUM:

v List all of roles of SCRUM. Each role will be written in a sticker.

v Put all of the tasks of Waterfall or your current working model match to SCRUM roles.

v What is the difference between your current working model and SRCUM?

34
 eXtreme Programming (XP)
• Extreme programming is also known as XP.

• XP is all about software development best practices.

eXtreme Programming (XP) 35

 Extreme Programming Core Values
 Simplicity ‚ Communication ƒ Feedback
• Reducing complexity, extra • Ensuring that the project team • The development team needs
features, and waste. knows what is expected of them feedback early in the project.
• Find the simplest thing that could • Ensuring the project team knows • Failing fast is a way to get
possibly work. what other people are working on feedback early.
• The daily standup meeting is an • Feedback gives the team an
excellent communication tool opportunity to improve the
project.

„ Courage … Respect
• Developers’ work is entirely visible • Team members must respect one
to others on the project team. another.
• Team members share code and • Everyone is responsible for the
correct each other’s code. success and or failure of the
• XP uses pair programming. project.
• Everyone works differently but
must work together.

eXtreme Programming (XP) 36

 XP Team Roles
 Coach ‚ Customer
• Mentor/guide/facilitator/communicator similar • The individual who provides requirements
to the ScrumMaster priorities anddirection for the project similar to
the product owner

ƒ Programmer ƒ Testers
• The developers who write the code • Define and write the acceptability test

eXtreme Programming (XP) 37

 12 Core Practices of Extreme Programming
WholeTeam

• XPteammembersarecollocated

• Generalizingspecialistnotrolespecialist

• Efficientandsharingofinformation

PlanningGames

• Planninggamesarejustplanningactivities

• Releaseplanningisthereleaseofnewfunctionality

•Nomorethanoneortworeleasesperyear

•Thecustomeroutlinesthefunctionalityrequiredintherelease

•Developersestimatethedifficultytobuildthefunctionality

eXtreme Programming (XP) 38

 12 Core Practices of Extreme Programming
SmallReleases

• SmallreleasestoatestenvironmentarepartoftheXPpractices

• Increasesvisibilitytothecustomer

• Helpstodeployworkingsoftwaretotheendusers

CustomerTests

• Definitionoftherequiredfunctionality

• Descriptionofoneormoretestcriteriaforthesoftwaretobeworking

eXtreme Programming (XP) 39

 12 Core Practices of Extreme Programming
CollectiveCodeOwnership

• Anypairofdeveloperscanimproveoramendthecode.

• Multiplepeoplewillworkonallthecode.

• Improvedefectresolutionindiscovery.

• Knowledgeissharednotisolated.

CodeStandards

• Acodingstandardisdefined.

• Theteamadherestothestandard.

• Providesforconsistencyinwritingthecode.

eXtreme Programming (XP) 40

 12 Core Practices of Extreme Programming
SustainablePace

• Productivityisoptimizedthroughasustainablepace.

• Consistentovertimeandlonghoursarenotsustainable.

Metaphor

• Metaphorsandsimilesareusedtoexplaindesigns

• Metaphorshelpcommunicatethesoftwaretothecustomer

ContinuousIntegration

• Compilingthecodefrequentlythroughouttheday

• Programmerscheck-incodetothecoderepository

• Integrationtestrunautomaticallyforimmediatefeedback

eXtreme Programming (XP) 41

 12 Core Practices of Extreme Programming
Test-drivenDevelopment

• Acceptancetestarewrittenpriortodevelopingnewcode

• Initialtestswillfailbecausethecodehasnotbeenfullydevelopedyet

• Whenthecodehasbeenwrittencorrectlyitwillpassthetest

Refactoring

• Cleaningupthecode

• Removingduplicatedcode

• Loweringcoupling

• Increasingcohesion

eXtreme Programming (XP) 42

 12 Core Practices of Extreme Programming
SimpleDesign

• Whatisthesimplestthingthatcouldwork?

• Simpledoesnotmeaneasy

• Simpledesignisariskmitigationapproach

PairProgramming

• Onepersonwritesthecodewhilethesecondpersonreviewsthecode

• Thetwopeoplechangerolesfrequently

• Thepairwillcatchmistakesandspeedupproductivity

eXtreme Programming (XP) 43

 Lean Product Development
• Toyota production system

• Visual management tools

• Customer to find value

• Learning and continuous Improvement

Lean Product Development 44

 Seven Lean Core Concepts
Eliminatewaste

• Wastecanbepartiallydonework,delays,handoffs,unnecessaryfeatures

• Toincreasevaluewemustdevelopthewaystoidentify,andthenremovewaste

EmpowertheTeam

• We should respect the team member’s superior knowledge of the technical

steps required on the project and let them make local decisions to be

productiveandsuccessful.

DeliverFast

• We can maximize the project’s return of investment (ROI) by quickly

producingvaluabledeliverablesanditeratingthroughdesigns.

Lean Product Development 45

 Seven Lean Core Concepts
OptimizetheWhole

• We aim to see the systems as more than the sum of its parts. We go beyond

thepiecesoftheprojectandlookforhowitalignswiththeorganization.

Buildqualityin

• We build quality into the product and continually assure quality throught the

development process, using techniques like refactoring, continuous

integrationandunittesting.

Deferdecisions

AmplifyLearnings • We balance early planning with making decisions and commitments as late

• Involves facilitating communication early and often, getting feedback as soon aspossible.

aspossible,andbuildingonwhatwelearn.

Lean Product Development 46

 Seven Wastes Of Lean

Lean Product Development 47

 Kanban
• Japanese word that means sign board

• The signboard has categories of work for each stage of the production process

Five Principles Of Kanban

• Visualize the workflow.

• Limit work in progress.

• Manage flow.

• Make process policies explicit.

• Improve collaboratively.

Kanban 48
 Kanban Pull System

• A pull system moves work through development.

• The development team completes an item; the next item in queue is pulled into the next stage of the process

• Kanban does not use timeboxed iterations.

• Only so many items can be in each stage of the project.

• Work moves from left to right.

Kanban 49
 Little’s Law
• The duration of a queue is proportional to its size

• By limiting the work-in-progress teams complete work faster

Kanban 50
 Feature-Driven Development
• The development team creates a model for the product

• They will build a feature list and a plan for the work
• The team moves through the design and build the directions for the product features.

• The team designs by features and builds by features Feature-DrivenDevelopmentCharacteristics

• Domainobjectmodeling • Regularbuilds

• Developingbyfeature • Visibilityofprogressandresults

• Individualclasscodeownership

• Featureteams

• Inspections

• Configurationmanagement

Feature-Driven Development 51
 Dynamic Systems Development Method

• Focus on the business need

• Deliver on time

• Collaborate

• Never compromise quality

• Build incrementally from foundations

• Develop iteratively

• Communicate continuously and clearly

• Demonstrate control

Dynamic Systems Development Method 52

 Crystal

• Customized methodologies coded by color names

• Methodologies are appropriate for different criticalities and team sizes

• Criticality is about the impact of a product defect design

Crystal 53
 Management vs. Leadership
• Management is about getting things done

• Leadership is about getting people to want to do what needs to be done

• Management is more concerned with task control command

Management Leadership

• Task and things • People

• Control • Empowerment
• Efficiency • Being effective
• Speed • Direction
• Command • Principles
• Doing things right • Doing the right things

Agile Leadership 54
 Servant Leadership
• The recognition is on the team members not the project manager or coach or ScrumMaster.

• The team gets the work done

• The team adds value

• Servant leaders provide what team members need

Agile Leadership 55
 Servant Leadership

 Shield the Team From Interruptions ‚ Remove Impediments To Progress

• Isolate and protect the team. • Clear obstacles for the team.
• Keep business partners from interrupting the team design. • Remove things that may cause delays or waste.
• Ensuring people communicate to the designated channels. • Consider documentation compliance activities or anything
• Protect the team from the diversions. that does not directly add value.
• Daily scrum give insights for the servant leader

ƒ Communicate The Project Vision „ Carry Food and Water

• Ensures that stakeholders have a clear image of what the • Ensuring that the team has the resources they need to be
team is creating. productive
• Ensures that all stakeholders have a common vision of • This includes items like proper tools compensation
what done means. encouragement and other resources
• Communicate and recommunicate the project Vision to • Training and professional development may be included
reinforce the vision. as well

Agile Leadership 56
 12 Principles For Agile Leadership
• Learn the team members’ needs • Remember that ethics is not an afterthought but
• Learn the project requirements an integral part of our thinking

• Act for the simultaneous welfare of the team and the project • Take time to reflect on the project

• Create an environment of functional accountability • Developed the trick of thinking backwards

• Have a vision of the completed project

• Use the project vision to drive your own behavior

• Serve as the central figure in successful project team

development

• Recognize team conflict as a positive step

• Manage with an eye towards ethics

Agile Leadership 57
 Agile Leadership Practices Leadership Tasks
• Honesty • Give transparency through visualization
• Forward looking • Create a safe environment for experimentation

• Competent • Experiment with new techniques and processes

• Inspiring • Share knowledge through collaboration

Agile Leadership 58
Thank You
Atoha Institute of Project Management
+84 28 6684 6687

[email protected]