Agile Introduction For:

Scrum Teams

Elias Hajjar
[email protected]
Session 1 - Agenda

1. Agile Overview
2. Scrum Overview
3. Scrum Roles
4. Questions
5. Why do companies adopt Agile?
What is Agile? *http://www.agilealliance.org/the-alliance/what-is-agile/

Agile is an umbrella term used to cover several development methodologies.

They all emphasize:

o Close collaboration between the development

team and business experts
XP
o Face-to-face communication
SCRUM
o Frequent delivery of deployable business value FDD
o Tight, self-organizing teams Lean
Kanban
o “Ways to craft code and team such that
Crystal
inevitable requirements churn was not a crisis.” DSDM
Agile Approaches

A number of Agile approaches have been created and utilized:

o eXtreme Programming (XP)
o Dynamic Systems Development Method (DSDM)
o Crystal Clear
o Kanban
o Scrum
Why do companies adopt Agile? *Version One 9th Annual State of Agile Survey

o Foster collaboration and trust between the Business and IT

o Ensure business value focus – Build the right things
o Improve responsiveness to business
o Facilitate better Business-IT alignment on features and Applications which are built*
o Build dedicated teams to tackle complex problems
o Promote transparency across the organization
o Deliver high value and high priority items regularly
Software Product Feature Usage *The Standish Group – CHAOS Study 2002

o Historically, over 60% of methods are rarely if ever

used and 20% are always or often used.

o Agile focuses teams and organizations on delivering

what is of value, not more of what will rarely or never
be used.

o Agile also focuses on an economic view of all work.

The Agile tradeoff for the Business

What the Business is asked to give: What the Business will receive:
o Regular participation (supplemented with a proxy) o High transparency into development
o Backlog ownership o More ability to change software product or feature
o Rapid tactical decisions direction
More domain conversations with development team o User-driven features with high business value
o Timely reviews of work produced (building the right thing)
Incremental releases of minimum marketable o Most valuable features first
features (no big-bang) o Increased planning accuracy
o Accept development of team estimates Lower risk releases, higher chance for overall success
o Practice equitable exchange o Faster throughput
o Fewer surprises
The Agile tradeoff for the Business

What the Development Team is asked to give: What the Development Team will receive:
o High external transparency into o Less interference during development –
development activities more autonomy
o Team ownership of Sprint results o More domain knowledge
o Dedication to abstract estimation for releases and o Higher quality software and overall satisfaction
hourly estimation for sprint activities o Ability to self-organize
o Commitment to introspection o Better relationship with the Business side
o Daily updates and tracking in tool (Jira) of the organization
o Commitment to internal team transparency o Ability to influence software product
o Respectful question and debate with o More acceptance of Dev/QA team estimates
the entire team o Lower risk releases, higher chance for success
o No “death marches”
Traditional Software Development

Requirements Definition o Based on predictive planning and requirements

definition
o Assume customers have full knowledge of future
Design needs

o Ignore dynamics of business, markets,

Development technology as well as impact of politics and
social change.

Test o Seeks to “control” change via “fixing”

scope.

Deploy o Usually months or years from

concept to delivery.
Agile

Iteration 1 Iteration 2 Iteration 3 Iteration 4

Req’ts Req’ts Req’ts Req’ts

Design Design Design Design

Build Build Build Build

Test Test Test Test

Working, Working, Working, Working,

Tested Tested Tested Tested
Increment Increment Increment Increment

o Completes lifecycle for each increment delivered within each iteration.

o Realizes that customers do not know their future needs.
o Accommodates changes in business, markets, etc. and allows adaptation.
o Iteration duration is in weeks not months.
 Scope

o Traditional predictive planning methods conduct extensive up front analysis and then “fix” scope.
o Agile focuses on fixing time and cost and “flexes” scope.

Fixed Scope Time Cost

Agile Agile
Traditional
“Waterfall”

Variable Time Cost Scope

Stable  Requirements  Changing

Fixed Scope Variable  Cost  Fixed Fixed Time
Waterfall  Approach  Agile
Project Suitability Assessment Radar Chart

The following chart represents the adapted PMBOK’s Agile Suitability Filter Tools

12
Project Suitability Assessment

Adapted PMBOK’s Agile Suitability Filter Tools

• Objective criteria, industry standards
• The assessment dimensions were
focused on Team, Project & Culture
Participants:
The project suitability assessment was conducted
in collaboration with project core team and sponsors

Results: Suitability Assessment Radar Chart

The results were tabulated anonymously and Median
of each of the answers were calculated (slight deviation
from PMBOK) .
The results were charted on the Suitability
Assessment Radar Chart to develop visual model
The radar chart contain 3 centric circles.
The inner circle represent Agile suitable project;
While the middle & outer circles represent Hybrid and Predictive suitable approaches respectively
13
 Agile Principles

1 Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

2 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
3
the shorter timescale.

4 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
5
them to get the job done.

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

© Scrum Adventures LLC – Proprietary and Confidential

 Agile Principles

7 Working software is the primary measure of progress.

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

9 Continuous attention to technical excellence and good design enhances agility.

10 Simplicity-- the art of maximizing the amount of work not done -- is essential.

11 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
12 behavior accordingly.

© Scrum Adventures LLC – Proprietary and Confidential

 Scrum Framework

Ceremonies Artifacts Roles

Sprint Planning
Daily Scrum Product Backlog Team Member

Sprint Review
Sprint Backlog Scrum Master
Sprint Retrospective

* The Sprint Software Increment Product Owner

Elias’ Extra Ceremony: Story Grooming

Agile Manifesto *http://agilemanifesto.org/

We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over Processes and tools

Working software over Comprehensive documentation

Customer collaboration over Contract negotiation

Responding to change over Following a plan

That is, while there is value in the item s on the right, w e value the item s on the left m ore.
Agile Frameworks

Scrum Team

KANBAN Team
 Agile Approach - Overview
Inputs from Executives, Team, Daily Scrum Meeting
Stakeholders, Customers, Users
Burndown/up Charts
• Chart showing how much work remaining in sprint
• Calculated in hours remaining • Held every day during a Sprint
• Maintained by the Scrum Master Daily • Lasts 15 minutes
Scrum Master • Team members report to each other not Scrum Master
• Holds daily 15 minute team meeting (Daily Scrum) • Ask 3 questions during meeting
• Removes obstacles • “What have you done since last daily scrum?”
• Shields the team from external interferences • “What will you do before the next daily scrum?”
• Maintains the Sprint Burndown Chart • “What obstacles are impeding your work?”
• Conducts Sprint Retrospective at the end of a Sprint • Opportunity for team members to synchronize their work
• Is a facilitator not a manager
Product Owner The Team
• Team is cross-functional and consists of 5-9 people
• Accountable for product success • There are no set project roles within the team
• Defines all product features • Team defines tasks and assignments
• Responsible for prioritizing product features • Team is self-organizing and self-managing
• Maintains the Product Backlog • Maintains the Sprint Backlog
• Insures team working on highest value features • Conducts the Sprint Review

1 Sprint Review
Task
2 Team selects • Team presents “done” code to PO and stakeholders
Ranked list Breakout
3 starting at top • Functionality not “done” is not shown
of what is • Feedback generated – PB maybe reprioritized
4 as much as it
required: • Scrum Master sets next Sprint Review
5
features, can commit to
6 stories,… deliver by end Sprint Backlog
7 of Sprint
Sprint end date and team
• To-do list (also known as Backlog item) for the
8 Sprint deliverable do not change
• Created by the Scrum Team

Product Backlog Sprint Planning Meeting • Product Owner has defined as highest priority

• List of all desired product features

Day 1 / First Half Finished Work
• List can contain bugs, and non-functional items
•
•
Product backlog prepared prior to meeting
First Half – Team selects items committing to complete
FAQ
• Product owner responsible for prioritizing
• Additional discussion of PB occurs during actual sprint
• Items can be added by anyone at anytime • Who decides when a Release happens? At the end of any given Sprint the PO can initiate a Release.
Day 1 / Second Half
• Each item should have a business value assigned • Who is responsible for managing the teams? The teams are responsible for managing themselves
• Occurs after first half done – PO available for questions
• Maintained by the Product Owner • What is the length of a task? Tasks should take no longer than 16 hours. If longer then the task should be
• Team solely responsible for deciding how to build broken down further. Sprint Retrospective
• Tasks created / assigned – Sprint Backlog produced • Who manages obstacles? Primary responsibility is on the Scrum Master. However, teams must learn to resolve
their own issues. If not able then escalated to SM. • Attendees – SM and Team. PO is optional
• What are the two biggest challenges in Scrum? Teams not self-managing, Scrum Master managing not leading. • Questions – What went well and what can be improved?
• SM helps team in discovery – not provide answers
Scrum – What is it? https://www.scrumalliance.org/?gclid=CKHTreCuuscCFUQvgQodAY8HZw

”Scrum is a simple yet incredibly powerful set of principles and practices that help teams
deliver products in short cycles, enabling fast feedback, continual improvement,
and rapid adaptation to change.”
Sprints

o Sprints are short time-boxed iterations of fixed capacity.

o Complete lifecycle activities are completed for each story worked.
o Sprints have a daily cycle which is centered on the daily scrum or stand-up meeting.
Sprint Guidelines

There are a few rules that we will apply to Sprints:

o Sprint length does not vary, it is a time-box of fixed duration on which we measure capacity.
o Sprint scope can be negotiated with the PO but may not endanger the Sprint goal.
o Product Owner is the only person empowered to cancel an in-flight Sprint.
Scrum Roles

Role Definition

Team Member • Plans the work of each sprint based on prioritized backlog of items for the release.
• Completes all work necessary to deliver working tested increments of software.
• Champions lean, sustainable software development practices.

Scrum Master (SM) • Works diligently as coach and servant to the team to remove any barriers to success
and continuously improving the scrum process.

• Works with the Product Owner / Product Owner Team to constantly refine the
product backlog.
Product Owner (PO) • Owns and communicates the product vision.
• Defines the value added capabilities that need to be implemented.
• Elaborates feature concepts and user story details to Scrum Team.
• Represents external stakeholders.
The stages of Teams formations
Bruce Tuckman
The team reaches the performing stage, when hard work
leads, without friction, to the achievement of the team's
goal. The structures and processes that you have set up
Most team members are positive and polite. Some are
support this well.
anxious, as they haven't fully understood what work the team
As leader, you can delegate much of your work, and you can
will do. Others are simply excited about the task ahead
concentrate on developing team members.
It feels easy to be part of the team at this stage, and people
who join or leave won't disrupt performance.
Performing Forming

Adjourning

Norming Storming
This is when people start to resolve their differences, where people start to push against the boundaries
appreciate colleagues' strengths, and respect your authority established in the forming stage. This is the stage where
as a leader. many teams fail.
Now that your team members know one another better, they Storming often starts where there is a conflict between team
may socialize together, and they are able to ask one another members' natural working styles. People may work in
for help and provide constructive feedback. People develop a different ways for all sorts of reasons but, if differing working
stronger commitment to the team goal, and you start to see styles cause unforeseen problems, they may become
good progress towards it. frustrated.
Questions?
Playbook

1. Decided on Kanban Vs Scrum

2. Form team and product owner, Team size
3. Decide on Sprint length and start day
4. Release planning
5. Decide on Ceremonies time.
• Working with offshore/offsite
• How to run the ceremonies
6. Backlog
7. Workflow
8. Writing Stories.
• Difference between epics and stories, Tasks & sub-tasks and Bugs
9. Storypoint estimate (1, 2, 3, 5, 8, 13, 21, 34 and 100 reach for the sky)
10. Definition of done
11. Controls & Charts
Backlog Exercise

You are ask by the new company president to create a website for a new 3d Printer to be released on
an upcoming tradeshow.
Q: What approach would you use and Why?

Partner in another person on your team. One person write an Epic for a backlog and 1 person write an
acceptance criteria.
Story Grooming Exercise

The tradeshow is coming soon and you are ready to start planning your first sprint.
Q: What questions would you ask to clarify the stories and to whom?

Work with your partner again and groom each epics to its corresponding stories.
Q: When do you know if the story is completed and ready for development?
Hint: INVEST
INVEST Definition of Story

I INDEPENDENT The item can be developed without any dependency on any other item or component to be
completed beforehand.

NEGOTIABLE If the item is complex or large in size and cannot be completed in one sprint, the team
N can replace it with an alternative item, it can be split into smaller items, or it can be removed from the
product backlog. This is a decision the product owner makes after negotiation with the team.

V VALUABLE An item must deliver value to the end user. There may be a loss of value if the item is not
developed an important factor for consideration.

E ESTIMABLE If the item cannot be estimated, then the team cannot commit to deliver this item in the sprint.
The team must always be able to estimate the size of an item.

S SMALL Items should not be so big as to become impossible to plan/task/prioritize with a certain level of
certainty.

T TESTABLE The product owner must have acceptance criteria as part of the Definition of Done. If the item is
not testable, that means you cannot verify the rule of "Done."
Sprint planning exercise

Lets take the top 5 stories the product owner decide to include in sprint 1 and estimate them as a
group
Q: How can we be sure this stories can be done in this sprint?
Hint: commitment and working smarter not harder will help
Q: How can we decide if the story is ready for the sprint