The document provides an introduction to agile concepts and practices such as Scrum and Kanban. It discusses the agile manifesto, principles, features, benefits, differences from traditional approaches, and practices like Scrum, Kanban, roles, ceremonies, artifacts, and metrics. Scrum focuses on iterative delivery in sprints with product backlog, sprint backlog and daily standups. Kanban emphasizes visualizing and limiting work in progress to optimize flow.

1. Agile Concepts
Introduction To Agile Practices
Joaquim Ferreira

2. About Me
Joaquim Ferreira
.NET Engineer
@ Truphone
Email:
joaquimf@truphone.com
Profile:
http://www.linkedin.com/in
/joaquimluisdaluzferreira
Certified Scrum Master
License 000138872
June 2011 to June 2015

3. Agenda
1 2 3 4 5
6
Agile Manifesto
Features
When
Principles Benefits
Differences
7
How
8
Practices
9
Scrum
10
Kanban

4. Agile Manifest
Individuals and
interactions over
processes and tools
Working software
over comprehensive
documentation
Customer
collaboration over
contract negotiation
Responding to
change over
following a plan
http://www.agilemanifesto.org/
Kent Beck
Mike Beedle
Arie van Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowle
James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern
Brian Marick
Robert C. Martin
Steve Mellor
Ken Schwaber
Jeff Sutherland
Dave Thomas

5. 12 Principles
Our highest priority is to satisfy
the customer
through early and continuous
delivery
of valuable software
Welcome changing
requirements, even late in
development. Agile processes
harness change for
the customer's competitive
advantage
Deliver working software
frequently, from a
couple of weeks to a couple of
months, with a
preference to the shorter
timescale
Business people and
developers must work
together daily throughout the
project
Build projects around
motivated individuals.
Give them the environment
and support they need,
and trust them to get the job
done
The most efficient and effective
method of
conveying information to and
within a development
team is face-to-face
conversation

6. 12 Principles
Working software is the primary
measure of progress
Agile processes promote
sustainable development.
The sponsors, developers, and
users should be able
to maintain a constant pace
indefinitely
Continuous attention to
technical excellence
and good design enhances
agility
Simplicity--the art of
maximizing the amount
of work not done--is essential
The best architectures,
requirements, and designs
emerge from self-organizing
teams
At regular intervals, the team
reflects on how
to become more effective,
then tunes and adjusts
its behavior accordingly

7. Features
Iterative
1. Entire work is distributed in incremental units called iteration:
2. Development time of each iteration is small (couple of weeks) and fixed;
3. Every Iteration is a mini increment of the functionality and is build on top of previous
iteration;
Feature driven
1. More emphasis is on providing the required features in the application;
2. 80/20 principle is applied to decide the 20% features which would be used 80% of the
time ( Pareto Principle );
Active Customer involvement
1. There is lot of client involvement and face-to-face interaction;
2. Every iteration is tested and approved by client;
3. The feedback obtained is implemented in subsequent iterations;

8. Features
Priority based delivery
1. Features are prioritized depending on customer need, development risk etc.;
2. High priority features are developed first;
3. After every iteration, the project priorities are re-evaluated;
Adaptive
1. The applications that are developed can receive new requirements throughout its
development;
2. The goal is not to remove the uncertainty in the very beginning;
3. But is to adapt to the changing needs;
Empowered Teams
1. The project teams are generally small and have lot of interaction and communication;
2. Since entire team is actively involved, team is empowered to take decisions;
3. No separate team to manage project;

9. Features
People Centric
1. Emphasis is on using the adequately skilled people to do the development than on
following the processes;
2. The documentation and other non-development activities are minimized and more
time is devoted to development and testing;
More disciplined
1. So the process involves lot of team and self discipline thus, it requires highly skilled
and organized team members;
Rapid development
1. Being rapid, everything has to be delivered correctly first time.

10. Features
Simplicity
1. Emphasis is on keeping things as simple as possible and being open to change;
Fixed Time
1. Each iteration has a fixed time span in which it is delivered;

11. Benefits
For the customer
1. Customer is more actively involved, and gets higher priority;
2. He gets to know regular and frequent status of the application;
3. Requirements are accepted after each iteration;
4. Since the methodology emphasizes rapid delivery, time-to-
market is less. So the key functionalities can be available to use
sooner;
5. Delivery is defined by fixed timescale. So customer is assured of
receiving some functionality by a fixed time period;
6. More Testing is done, so better software quality is delivered;

12. Benefits
For the project team
• Project teams are involved more actively in all the
stages;
• The teams collaboratively take the decisions and
are more empowered;
• Development is Incremental, teams can focus on
the specific requirements at any given point of
time;

13. Benefits
For the project team
• More emphasis is on developing the application only;
• The teams receive frequent feedback as the testing is
integrated; so the rework is reduced;
• Less time is spent in gathering requirements as all the
requirements are not gathered upfront and are
implemented as and when they arise;

14. Benefits
For the project team
• Less cost of development as rework, management,
documentation and other non-development work
related cost is reduced;
• Teams develop applications collaboratively and in
cooperative environment;
• So less time is required for planning;

15. Differences
Requirements Fixed Evolve
AgileTraditional
Time & People May Change Fixed
Costumer Involvement Before, After Throughout
Negotiable Estimates Schedule
Testing After Work Integrated
Feedback After Work During
Concentration On Processes; Reviews Finished Work
Focus On Plan On Value
Stages
Requirements, Design, Code, Test,
Feedbacks
Plan-Do-Check-Adjust

16. When
We use Agile when …
We have the customer available.
We can split the deliver.
The requirements are flexible.
The team is skilled enough.

17. When
Because we will need
Organization support
Hierarchy
ready to
empower
teams
Culture
open to
changes
Focus on add value to the
business
Infrastructure and team
support
Preferable the team and the
customer should be co-located
Hardware support for
continuous integration and
other practices
Highly skilled
& flexible
people
More &
frequent
testing

18. How
Starts with a kick-off meeting
1. Get requirements and / or feedback;
2. Plan & evaluate priorities;
3. Design;
4. Develop;
5. Test;
6. Document what is done;
7. Deliver;
1
2
3
4
5
6
7
Split the functionalities in small delivers and repeat:

19. Practices
Scrum
Kanban
eXtreme Programing
ScrumBan
Lean Software Development
DynamicSystemsDevelopmentMethods
Feature Driven Development

20. Scrum
Is an agile process
that allows us to
focus on delivering
the highest
business value in
the shortest time.
Allows us to rapidly and repeatedly inspect
actual work.
The business sets the priorities.
The Teams self-organize to determine the best
way to deliver the highest priority features.
So that in the end of an iteration anyone can
see real work and decide to release it as is or
continue to enhance it for another iteration.
What

21. Scrum
No specific engineering
practices prescribed
Self-organizing teams
Product progresses in a series of
month-long “sprints”
Requirements are captured as
items in a list of “product backlog”
Characteristics
Uses generative rules to
create an agile environment
for delivering projects

22. Scrum
Sprint
Requirements
Starts with a kick-off meeting
• Scrum projects make progress
in a series of “sprints”;
• Typical duration is 2–4 weeks
or a calendar month at most;
• Product is designed, coded,
and tested during the sprint;
• No changes during a sprint;
Design
Do
Test

23. Scrum
Rather than doing all of one thing at a time...
… Scrum teams do a little of everything all the time
Requirements
Design
Build
Test
Requirements
Design
Build
Test

24. Scrum
Framework
Roles Ceremonies
Artefacts

25. Scrum
Roles
Product Owner Scrum Master
Team

26. Scrum
Product Owner
Starts with a kick-off meeting
• Define the features of the product;
• Decide on release date and content;
• Be responsible for the profitability of the product
(R.O.I.);
• Prioritize features according to market value;
• Adjust features and priority every iteration, as
needed;
• Accept or reject work results;

27. Scrum
Scrum Master
Starts with a kick-off meeting
• Removes impediments;
• Represents management to the project;
• Responsible for enacting Scrum values and
practices;
• Ensure that the team is fully functional and
productive;
• Enable close cooperation across all roles and
functions;
• Shield the team from external interferences;

28. Scrum
Team
Members should be full-time
• Teams are self-organizing:
• Ideally, no titles but rarely a possibility;
• Cross-functional:
• Programmers, testers, user experience
designers, etc.;
• Members should be full-time;
• Membership should change only between sprints;

29. Scrum
Ceremonies
Sprint Planning
Sprint Review Sprint Retrospective
Daily Scrum

30. Scrum
Sprint Planning Meeting
Planning
Decide how to achieve sprint goal (design)
Create Sprint backlog (tasks) from Product
Backlog (Features/Stories)
Estimate Sprint Backlog in hours.

31. Scrum
Daily Scrum
Parameters
Daily
15-minutes
Stand-Up
Not for problem solving
Just to Inform
Only team members and Scrum Master talk
Whole world is invited
Others may talk if Team allow

32. Scrum
Daily Scrum
What will you do today ?
1
2
3 Is anything in your way ?
What did you do yesterday ?
3Questions

33. Scrum
Sprint Review/Demo
Members should be full-time
• Team presents what it accomplished during the sprint;
• Typically takes the form of a demo of new features or
underlying architecture;
• Informal:
• 2-hour prep time rule;
• No slides;
• Whole team participates;
• Invite the world;

34. Scrum
Sprint Retrospective
Members should be full-time
• Periodically take a look at what is and is not working;
• Done after every sprint;
• Whole team participates:
• Scrum Master;
• Product owner;
• Team;
• Possibly customers and others;

35. Scrum
Sprint Retrospective
Whole team gathers and discusses what they’d like to:
Start Doing
Continue Doing
Stop Doing

36. Scrum
Artefacts
Product Backlog
…Product Increment
Sprint Backlog

37. Scrum
Product Backlog
Members should be full-time
• Prioritized list of the functionality to be developed
in a product or service;
• User stories have emerged as the best and most
popular form of product backlog items;
• Ideally expressed such that each item has value to
the users or customers of the product;
• Prioritized by the product owner;
• Reprioritized at the start of each sprint;

38. Scrum
Sprint Backlog
Members should be full-time
• The list of tasks identified by the Scrum team
during sprint planning;
• Its is estimated in Hours;
• Individuals sign up for work of their own
choosing;
• Estimated work remaining is updated daily;
• Any team member can add, delete or change
the sprint backlog;
• Individuals sign up for work of their own
choosing;

39. Scrum
Product Increment
Members should be full-time
• In every Sprint is produced one;
• Must be of high enough quality to be given
to users
• Must meet the Scrum Team's current
Definition of Done
• Each component of it be acceptable to the
Product Owner

40. Scrum
User Story
Members should be full-time
• Short, simple description of a feature told from the
perspective of the person who desires the new
capability;
• They typically follow a simple template:
• As a <type of user>, I want <some goal> so
that <some reason>;
• Should contain the conditions of satisfaction for
the story be consider done (Acceptance Criteria);

41. Scrum
Task Board
Members should be full-time
• Used to update the changes of state of the tasks during the sprint;
• Each story have a row to the board;
• Each column represents a state of the work;
• The tasks change of state until be finished;

42. Scrum
Burn Down Charts
Members should be full-time
• Show the amount of work remaining either in a
sprint or a release:
• The Release Burn Down Chart tracks the
release remaining work;
• The Sprint Burn Down Chart tracks the
sprint remaining work;
• They determining at a glance whether a sprint
or release is on schedule to have all planned
work finished by the desired date;

43. Scrum
This is Scrum

44. Kanban
The Kanban is an
agile process based
on Lean practices
and aims to
streamline the
development
process of a
product
Means Visual Signaling
Visibility into the status of the work and how it
is proceeding
Shows what is happening on the process.
Allowing to detect the problems during the
process.
Gives more precise direction on how to invest
the energy into only the most valuable work
What

45. Kanban
Change the priorities anytime
Visualization of the work flow
Deliver anytime
No need of iterations
Characteristics
Optimize Existing Processes
Introduction of visualization and the
limiting of work-in-progress (WIP) will
catalyse change with minimal
disruption

46. Kanban
Core Principles
1 - Visualize the Workflow
Represent the work items and the workflow on a card wall or electronic board;
2 - Limit Work-in-Progress (WIP)
Set agreed upon limits to how many work items are in progress at a time;
3 - Measure & Manage Flow
Track work items to see if they are proceeding at a steady, even pace;
4 - Make Process Policies Explicit
Agree upon and post policies about how work will be handled;
5 - Use Models to Evaluate Improvement Oportunities
Adapt the process using ideas from Systems Thinking;

47. Kanban
Visualize the workflow
Todo InProgres BlockedTest Done

48. Members should be full-time
Kanban
Visualize the workflow
• The card wall should reflects the current work process, with the intent to
improve it over time.
• Draw columns on the board that represent the activities performed, in
the order first performed.
• The cards themselves could be sticky notes or index cards.
• They may represent features, stories or tasks.
• Critical information for a card would be title, reference number, and date
it entered the system;

49. Kanban
Limit Work In Progress ( W.I.P)
Todo InProgres BlockedTest Done
W.I.P: 10 W.I.P: 5 W.I.P: 4 W.I.P: 3

50. Members should be full-time
Kanban
Limit Work In Progress ( W.I.P)
• A limit on work-in-progress constrains how many work items can be in
each workflow step at a time;
• When a work item progresses, a slot opens and a new work item can flow
into the workflow step;
• A key result of a W.I.P. limit is that blocked work “holds up the line”;
• No new work can progress on the workflow step until the block is
resolved;
• The W.I.P. limit provokes the conversations that lead to improvements;

51. Kanban
Limit Work In Progress ( W.I.P)
How big a limit ?
• W.I.P. limits for workflow steps should be set as an average number of items
per person;
• Limits should be in the range of one to three items per person, pair or team;
Agreed upon limits ?
• W.I.P. limits should be agreed upon through consensus with up- and
downstream stakeholders and senior function management as well as the
development team;
• Not every step must have a limit;

52. Kanban
Limit Work In Progress ( W.I.P)
No W.I.P. limit?
Care should be taken when establishing any unlimited on workflow steps !!!
• Does not introduce bottlenecks;
• Cause excessive transaction;
• Cause excessive coordination costs when are made;

53. Kanban
Measure And Manage Flow
Todo InProgres BlockedTest Done
W.I.P: 10 W.I.P: 5 W.I.P: 4 W.I.P: 3
Lead Time

54. Kanban
Measure And Manage Flow
Lead Time
Starts when the request is made and ends at delivery;
Is what the customer sees;
Cycle Time
Starts when work begins on the request and ends when the item is ready for delivery;
What the team can influence by itself by changing its work process
Reaction Time
The time until the work begins on the request.
Lead Time
Reaction
To reduce Lead Times one should reduce Cycle Time.
But often the time before the work starts is really long.
So this wait time should be reduced also.
Cycle Time

55. Kanban
Explicit Process policies
It is often best to post explicit process policies in a public team area such as next
to the card wall
Workflow
Should agree upon policies regarding:
W.I.P Limits
Approvals Prioritization
Other Process Topics

56. Kanban
Use models to evaluate improvement
• Womack & Jones on Waste Reduction
• Eliyahu M. Goldratt on Theory of Constraints
• John Seddon and Peter Senge on Systems Thinking
• W. Edwards Deming’s System of Profound Knowledge and specifically his work on variability
• Taiichi Ohno (Toyota Production System) on muda, muri and mura.
Flow Time
Gather data on system performance as:
W.I.P
Useful models to learn and use may include work from:

57. Kanban Vs Scrum
Scrum Kanban
Fixed-length iterations Required Optional
Commitment to a specific amount of
work
Required - at the personal daily level and
at the team level (per sprint)
Optional
Metrics for planning process
improvement
Velocity Lead Time
Cross-functional teams Required Optional
Item size So it can be completed within one sprint No particular
Prescribed diagram type Burn down chart No particular
Work-in-progress limits Per sprint Per workflow state

58. Kanban Vs Scrum
Scrum Kanban
Estimations Required Optional
Adding new items to ongoing iteration Not allowed Allowed
Sharing sprint backlog/ kanban board Within one team With multiple teams or individuals
Prescribed team roles
Project Owner, Scrum Master, Team
Member
No
Board life-time Reset after each iteration Persistent
Prioritization Requires a prioritized product backlog No

59. How do you work?
Kanban Scrum
• Your work is often interrupted with new,
immediate tasks.
• You need to be flexible and highly responsive to
changes.
• You are unable to lock your backlog for a couple
of weeks.
• Your work more often involves repeatable tasks
than new ones.
• You do feature development which relies heavily on
stakeholders' feedback.
• You can run only one project at a time.
Kanban Vrs Scrum

60. What is your team type?
Kanban Scrum
• You have a small, medium or large team of
specialists in the same or related fields.
• Your team is small and cross-functional.
Kanban Vrs Scrum

61. What is the specificity of your organization?
Kanban Scrum
• Your organization has low maturity.
• You have a limited capability of risk taking, change
management and decisions making.
• You have time to let the culture and performance
evolve and improve.
• Your organization is highly mature.
• You are capable of assessing risk, managing changes,
evaluating alternatives and making good quality
decisions.
• You can only make changes in your company using
shock therapy - revolution in your organizational
culture and approach to team and project
management
Kanban Vrs Scrum

62. Sources
Manifesto for Agile Software
Development
http://www.agilemanifesto.org/
http://www.mountaingoatsoftware.com/
Portions of this presentation are based on the next sources:
http://www.indicthreads.com/1439/quick-
introduction-to-agile-software-development/
http://refcardz.dzone.com/refcardz/ge
tting-started-kanban

63. Questions