Agile presentation @ KTH

Agile
Purpose:
- Introduction to Agile –Scrum and Kanban
- After this presentation you will have the knowledge to start practicing Agile in your development projects.
Marianne Rimbark 2018-03-01 4G/5G Development

Agile at KTH | Ericsson Internal | 2018-03-01
WhoamI
— Started as developer 1995 with TDMA/2G products
— Technical Coordinator
— Project Manager for SW product development and product deployment
— Manager for developers (PLEX, Erlang, Java, C, C++)
— Strategy execution
— Operational excellence
— Auditor/Assessor
— Change leader
— Impediment and Improvement driver
— Coach & Mentor
— Today 20+ years of experience of telecommunications, Research and
Development for 2G / 3G / 4G and 5G products
— Married, two children, 3 cats, live in Huddinge, Stockholm

Ericssonataglance
42,000
23,700 55,000
1 billion
100,735
Subscribers
managed by us
Services professionals EmployeesR&D Employees
Patents 201,3 B. SEK Net Sales
Full year 2017 figures
Networks
Highly scalable, modular
platforms offering lowest
total cost of ownership,
best user experience in
4G and leadership
in 5G
Digital Services
Digitalize service
providers through cloud
and automation, providing
cost efficient cloud native
solutions in Core and
OSS/BSS
Managed Services
Long lasting cost
efficient performance
through smart
automation, analytics
and business
practice
Emerging business
Innovating new
sources of revenue
for our customers,
e.g. in IoT and new
partnership based
services

Baseband Enclosure Backhaul Small Cell
Radio Power Fronthaul Site
Software
SW
EricssonRadioSystem

New behaviors
1.6 MILLION
NEW SMARTPHONE
SUBSCRIPTIONS PER DAY
$93MILLION
CROWDFUNDING
RAISED PER DAY
$ 6.3BILLION
E-COMMERCE PER DAY
5BILLION
VIDEOS WATCHED ON
YOUTUBE PER DAY
500,000
AIRBNB STAYS PER NIGHT
3X
UBER REVENUE OVER
SIZE OF TAXI MARKET,
IN SAN FRANCISCO
20MINUTES
SPENT ON FACEBOOK
PER DAY
24h

Change in almost everything:
— Big projects to Decoupled development and flexible releases
— System-design-test silo organization to cross functional teams
— Individual offices to team spaces
— Narrow & specialized competences to broader competences and continuous
learning
— Individual accomplishment to team success
— Following a defined and detailed process to scrum framework
— Top down control to more people initiative and self organization
— Modular and more flexible product architecture
Challenges (Waterfall):
— Not meeting customer requirements, lack of flexibility
— Long lead-time, delivery pace twice a year
— Quality, not built in
— People do not feel empowered
— Insight: No longer competitive ways of working
WhydidEricssongofromWaterfall
developmenttoLeanandAgile
Pre
-pre
Pre Feasibility Execution TestWaterfall:
Agile:
Pre
-pre
Release
verification
Product Development
pre-
Study SPRINT
• Less detailed level planning leading to less initial predictability and control
• Execution starts earlier with shorter development lead-times

Agile-ScrumisaIterative,incrementalmethodology
UEH
O&M
BB
RNH
C
Iterative = don’t expect to get it all right the first time
Incremental = build in ”vertical” slices (features) rather than ”horizontal” (layers)
Monolithic development - Waterfall
1
2
3
4
1
Incremental development
2 3
Maybe we don’t
even need to
build the rest!
C
UEH
O&M
BB
RNH

Transformationoverview
2011 2012 2013 2014 2015
Scattered
experiments
Pilot Framework
Framework Deployment
Flow optimization Product Mgmt & Level 4
Flow optimization cross Level 4
2016
Continuous evolvement
Continuous Delivery
2017
Agile:
Scrum/Kanban/Scrumban
Lean:
Optimize the whole
Continuous improvements
Outcome:
— Lead-time decreased with 50%
— Customer value increased 4 times
— Improved Quality enabling Continuous Delivery every second week
— Team empowerment via fast feedback loops

— Lean (theory)
— Widely applicable for any kind of production
— Scaled SW development
— Agile (theory)
— Is Lean
— Scrum (methodology)
— Is a planning method
— Exercise: Paper plane production
— Kanban (methodology)
— A planning philosophy
— XP (methodology)
— Team specific values and practices
— High performing teams
— Summary
Agenda
Lean
Agile
Scrum / Kanban
XP

— FLOW and THROUGHPUT are essential parts of
Lean philosophy, i.e optimize the whole
— Pillars of Lean thinking
LEAN
Origins:ToyotaProductionsystemandLeanProduction
Theory of constraints ref. Dr. Eliyahu M. Goldratt

— Lean (theory)
— Agile (theory)
— Is Lean
— Summary
Agenda
Lean
Agile
Scrum / Kanban
XP

AGILE–TheAgilemanifesto
Origins:17peoplemetatSnowbirdskiresort inWasatchmountain,Utah,inFebruary2001
Source: Agilemanifesto.org
Developed for small scale SW development. Embracing existing SW engineering methods & practices (Scrum, XP, etc)

PrinciplesbehindtheManifesto1(2)
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.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the
shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them
to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-
face conversation.

PrinciplesbehindtheManifesto2(2)
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.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior
accordingly.

Agile–thePrinciples
1. Satisfy the customer by delivering valuable software
2. Welcome changing requirements
3. Deliver working software frequently
4. Business people and developers work together
5. Trust motivated individuals
6. Face-to-face conversation
7. Working software is the primary measure of progress
8. Promote sustainable development
9. Technical excellence and good design
10. Simplicity is essential
11. Self-organizing teams
12. Team reflection and adjustment
http://agilemanifesto.org/

LeanandAgile,agoodfit
Lean
Agile
Respect for people
Optimize the whole
Continuous improvements
Individuals & interactions over processes & tools
Working Product over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Scrum
— First public appearance in 1995 when Jeff Sutherland and Ken Schwaber paper describing Scrum
at OOPSLA.
— Scrum is a simple "inspect and adapt" framework that has three roles, three ceremonies, and three
artifacts designed to deliver working software in Sprints, usually 30-day iterations.
— Roles : Product Owner, Scrum Master, Team;
— Ceremonies/Events : Sprint Planning, Sprint Review (Demo), Sprint Retrospective and Daily Scrum
Meeting;
— Artifacts : Product Backlog, Sprint Backlog, and Increment

The Team
3RolesandResponsibilities
Product
Owner
•Defines features and release dates
•Responsible for Return of Investment (ROI)
•Prioritizes features by business value
•Accepts or rejects work
Scrum
Master
•Ensures team is functioning and productive
•Removes barriers (impediments)
•Shields team from external interference
•Ensures the process is followed
•Facilitates planning, not a traditional Project Manager
•Cross functional, 7 +/-2 members
•Self directed
•Organizes itself and assign tasks
•Commits to Sprint and Demos to Product Owner
The Scrum Team

Scrumflow-4events
Sprint Planning Meeting
— Review Product Backlog
— Estimate Sprint Backlog
— Commit
The team
Product Owner
Scrum Master
Daily Scrum Meetings
› Done since last meeting
› Plan for today
› What is blocking us
Sprint Review (Demo) Meeting
› Demo features to all
Product Backlog
Time boxed “Sprint” Cycles
Time-boxed
Test/Develop
Sprint Backlog
› Work Items assigned
to a Sprint
› Estimated by the team
› Team Commitment
Working Code Ready
for Deployment
Sprint Burndown
Release Burndown
Sprint Retrospective
› Adjustments
Increment

Sprintplanningmeeting
Purpose:
— Review Product Backlog
— Estimate Sprint Backlog
— Commit

Whatisauserstory?
— A user story describes functionality that will be valuable to an user
— depending of context, the user might be an human user, another subsystem, a customer, a stakeholder, …
— It consists of one or more sentences in the everyday or business language of the user that captures
what the user wants to achieve
— Represents customer requirements rather than document them
— As opposed to requirements (which are something the system must do) user stories are brief
statements of intent that describes something the system needs to do for the user.

Myrequest
1. The product shall have a gasoline-powered engine.
2. The product shall have four wheels.
a) The product shall have a rubber tire mounted to each wheel.
3. The product shall have a steering wheel.
4. The product shall have a steel body.
Give me your offer!

Myrequest
1. The product makes it easy and fast for me to mow my lawn.
2. I am comfortable while using the product.
Do you want to change your offer?

WhatIwanted?

Auserstoryhas3aspects
Each user story is composed of three aspects:
1. Written description of the story, used for planning and as a reminder.
2. Conversations about the story that serve to flesh out the details of the
story
3. Tests that convey and document details that can be used to determine
when a story is complete
The three Cs
Reference: Mike Cohn, User Stories Applied

UserstoryCARD
Backlog Item #1
Importance
SMS Message size
20Description
Estimate
As a SMS user I want to send bigger messages,
so that receiver won’t get two messages
3
Acceptance Criteria
Value
1)" Write a big message
2)" Send it to another phone
3)" Read the message on the other phone
4)" Check it’s only one message
As a <role>
I want to <what>
so that <why>
8

INVESTinGoodStories
Independent
— If possible. Dependencies leads to prioritization and planning problems
Negotiable
— It is not a written contract or requirement, but negotiated in conversation
Valuable
— Valuable to user/customer. Avoid stories only valued by developers.
Estimatable
— Enough information for developers to be able to estimate. is required.
Small
— Makes estimation and planning easier. Large stories can be split, and too small
stories can be combined
Testable
— If not, how do we know when done?
Reference: Mike Cohn, User Stories Applied

Thesprintcommitment
— Team’s commitment to the product owner:
... we will do everything in our power, to reach the sprint goal and complete the stories,
... we will work on stories in priority order,
... we will display our progress and status on a daily basis and keep you informed,
... every story that we do deliver is complete.

Mutalcommitments
“No changes” during a sprint!
•What the team commits to – and
what the product owner agrees to –
during sprint planning, should be
what is delivered.
The team commits to delivering
some amount of functionality –
forecasting what
The product owner commits to
leave priorities alone during the
sprint
However keep in mind that:
•We start with vague requirements
•Our understanding of those
requirements is refined during the
sprint

Dailyscrummeeting
Purpose:
— Progress visibility (team + individual, i.e nobody can hide
— Raise issues early
Daily Meeting Agenda
— Max 15 min. Other interesting discussions have to be
stopped. Plan another meeting with the parties concerned.
(Make a note on the task board)
— Gather the team in front of the task-board. Attendees have
to stand up.
— One after the other answers the following three questions:
— What did you complete yesterday?
— What will you complete today?
— What obstacles are in your way?
— Move yellow post-it tasks and update remaining time.
— The team updates the burndown chart

Thesprintreview-demo
Purpose:
— Team presents what it accomplished during the sprint
— Focus on ready stories (“Done Done”)
— Whole team participates
— Invite the world!
— Get feedback

SprintRetrospective
Purpose:
— Continuous improvement and learning (fast feedback loops)
— Performed after every sprint
— Time boxed (30 minutes to 1 hour)
— Whole team participates: Scrum Master, Team, Product Owner
(optional), Possible customer and others (by invitation of team)
Retrospect (example)
— What did we do well?
— What did we learn?
— What should we do different the next time?
What could be changed that makes the next iteration more
enjoyable and productive. Write down suitable actions and vote
— What still puzzles us?

Theimportanceofdone
— Done must be clearly defined
— Strive for “No Work Left”
— It might take some time, maybe years
— Understand what your present Done really means
— What work is left before shipment?
— When will that work be done?
— Done Done
— 1st Done = up to a clearly defined step
— 2nd Done = All work ready!
— You are not done if your are not Done!

Stabilizationiswhenyoudoallthe
undonework
P D SPlanning Development Stabilization
P P D D D DP P P S
Undon
e
Undon
e
Undone Undon
e
Scrum project with incomplete or variable “Done”

DoD–Overview(example)
Progress
updated
Approved
Design
Ready
Unit Test
Cases written
Design
Reviewed
Code
Complete
Unit tests
passed
Refactoring
done
Code
Reviewed
Work is
versioned
Work is
deliverable
Feature tests
passed
Regression
tests passed
Test
automated
Documentation
ready
Knowledge
shared
Delivery
checks
passed

Paper plane production
an exercise
Now, this model
would take some
time to construct!
Purpose to exercise Sprint:
• Planning
• Execution
• Demo
• Retrospective
And we will run 2 sprints

2. Sprint Planning Meeting - 3 minutes
The team
Product Owner
= Customer
Scrum Master
4. Sprint Review (Demo) Meeting – 3 minutes
• Demo all your produced flying planes
Both lead-time and throughput will be measured:
• Time until first paper plane is accepted by
customer (scrum master keeping time)
• Number of planes accepted by customer (each
group keeps their own count).
5. Sprint Retrospective – 5 minutes
› Adjustments
1. Product Backlog
• Construct as many paper planes as
possible during a time period of 3 minutes
• Each plane has to pass the acceptance
test, i.e. fly across the taped distance.
3. Sprint - 3 minutes
• Only one plane at a time can be
brought to acceptance test by
each group
• Each plane can be tried up to 3
times in acceptance test – if yet
not flying, it shall be discarded

Outcome
Time until first
paper plane is
accepted by
customer
Throughput Chosen
improvement
Time until first
paper plane is
accepted by
customer
Throughput Reflection of
exercise, next
improvement
Group 1
Group 2
Group 3
Sprint 2Sprint 1

The3rulesofkanban
— Visualize the workflow
— Split the work into pieces, write each item on a card and put on the wall.
— Use named columns to illustrate where each item is in the workflow.
— Limit Work in Progress (WIP)
— assign explicit limits to how many items may be in progress at each workflow state
— Pull value through the system
— Only start work when the need is created by the system
— Measure the lead time and optimize to reduce leadtime
The word Kan means "visual" in Japanese and the word "ban" means "card". So Kanban refers to "visual
cards".

KANBANBOARD

Differences
SCRUM
— WIP limited indirectly (per sprint) by
time boxed iterations.
— A sprint backlog and a Scrum board is
owned by one specific team.
It is reset between each sprint.
— Prescribes:
— 3 roles
— 3 artifacts
— 4 ceremonies
— Uses Velocity as default metric
— Typically used for development in
cross functional teams
KANBAN
— WIP limited directly (per workflow
state). No time boxing.
— A kanban board may be shared by:
multiple teams or individuals
…and is persistent
— Does not prescribe any roles, artifacts
or ceremonies
— Uses Lead-time as default metric
— Typically used for maintenance and
support
— For overview on “program” levels
Experiences of usage scenarios

XP-12practicesinfourareas
1. Fine scale feedback
› Pair programming
› Planning game
› Test driven development
› Whole team
2. Continuous process
› Continuous integration
› Design improvement/Refactoring
› Small releases
3. Shared understanding
› Coding standard
› Collective code ownership
› Simple design
› System metaphor
4. Programmer welfare
› Sustainable pace
More emphasis on coding / programming techniques

— Lean (theory)
— Agile (theory)
— Is Lean
— Summary
Agenda

Background: In 1965, Bruce Tuckman developed a simple four-stage model of team development
that has become an accepted part of thinking about how teams develop. In his article,
"Developmental Sequence in Small Groups," Tuckman outlines four stages of team development:
Forming, Storming, Norming, and Performing. A successful team knows which stage they are in, and
manages transitions between the different stages adeptly.
The Forming stage involves the introduction of team members, either at the initiation of the team, or
as members are introduced subsequently. Members are likely to be influenced by the expectations
and desires they bring with them, and will be keen to understand how the group will operate. In
particular, they will be keen to understand how the leadership is likely to operate, in terms of style and
character. This is a stage of transition from a group of individuals to a team.
As team members grow more confident, the team are likely to enter the Storming phase. Team
members will have different opinions as to how the team should operate. There may be anxious
about conflict arising, the storming phase is a difficult one for the team. The best teams will
understand the conflict, actively listen to each other, and navigate an agreed way forwards. Other
teams may disintegrate as they bolster their own opinions to weather the storms of the group.
As the teams emerge with an agreed method of operating, the team enters the Norming phase.
Team members have signed up to a common working method, and everyone is usually willing to
share in this. During this phase, team members are able to reconcile their own opinions with the
greater needs of the team. Co-operation and collaboration replace the conflict and mistrust of the
previous phase.
Finally the team reaches the final phase, Performing. The emphasis is now on reaching the team
goals, rather than working on team process. Relationships are settled, and team members are likely
to build loyalty towards each other. The team is able to manage more complex tasks, and cope with
greater change. The performing stage can either lead onto :
a return to the forming stage as group membership changes,
a new "dorming" stage as the group gets complacent or
"adjourning" as the group successfully reaches its goal and completes its work.
Teamprocess
Source:BruceTuckman

Howdoyoubecomeahighperformingteam?
Discussinpairsfor acoupleofminutes

Kickstart with a kick-off:
Purpose to create a common understanding around:
— WHY
— WHAT
— HOW
— WHEN – deadline?
— Knowledge about yourself
— Knowledge about your team members
— Culture/Values
— “We are punctual to our meetings”
— “When we work we focus on tasks to be achieved”
— “We respect each other by listening and ask clarifying
questions.”
— Learning environment
— HAVE FUN! And CELEBRATE!
Howdoyoubecomeahighperformingteam?

— The coloring of types in the book is the same as
DISC: Dominance-Influence-Steadiness-
Conscientiousness ( https://discprofile.com/what-is-disc/overview/ )
I am “red”:
— how can I improve my communication to fullfill
the needs of other colours? Purpose: Improve
speed and quality of the tasks at hand.
— How can I invite “blue” to speak his/her mind?
— How can I get “yellow” to liste more?
— How can I learn to listen even if I do not win?
— What traits do I have that will help us succeed?
— It is only TOGETHER WE ARE PERFECT!
SurroundedbyIdiots
“Omgivenavidioter“,ThomasErikson2014

Personalitytypes
https://www.16personalities.com/ freepersonalitytest

Summary
Lean (theory) • Widely applicable for any kind of production
• Scaled SW development
• Respect for people
• FLOW and THROUGHPUT are essential parts of Lean
philosophy, i.e optimize the whole
• Continuous improvements
Agile (theory) • Is Lean Agile manifesto:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Scrum (methodology) • Is a planning method
• Typically used for development in cross
functional teams
• 3 Roles,
• 4 ceremonies/events
• 3 artifacts
Kanban (methodology) • A planning method
• Typically used for maintenance and support
• For overview on “program” levels
XP (methodology) • Team specific values and practices
• More emphasis on coding / programming
techniques
• Pair programming
• Test driven development
High performing teams Common understanding around:
• WHY
• WHAT
• HOW
• WHEN
• Knowledge about yourself / your team members
• Culture/Values
• Learning environment
• HAVE FUN! CELEBRATE!

Furtherstudies,lotsofbooksinthisarea…

Feedback, have we fulfilled the purpose:
1 = No, need much more information/training
2 = Partially, need specific information/training
3 = Yes, I am willing to give this a try
4 = Yes, I feel confident and can support my colleagues
FistofFOUR:
- Introduction to Agile –Scrum and Kanban
- I have the knowledge to start practicing Agile in mine/our development projects.

Agile presentation @ KTH

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Agile presentation @ KTH

Ähnlich wie Agile presentation @ KTH (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Agile presentation @ KTH