Agile Team Bootcamp

 Welcome
o About: Agile and Scrum Basics
 I’m E-LMO
o Enough, lets move on
 Questions
o And feedback
 Bootcamp Frame
o Open minded
o Equal voice
o Communication
o Trust
o Listening
o Fun
o Respect
o Acceptance
o Mobile phone silent
o Laptop closed
 Why Agile?
o Doing agile =/= being agile
o Practices =/= mindset
o * Both of those means 3x the benefit vs 20% the benefit (using scrum, canvas,
etc vs having engagement, joy at work, innovation, customer delight, etc…)
 Look below the surface…
o Process and tools
o Organizational design
o Values
o Principles
o Values
o * greater benefits comes from the last ones
 Agile manifesto values
o Working software over comprehensive documentation
o Customer collaboration over contract negotiation
o Responding to change over following a plan
o Individuals and interactions over processes and tools
 Agile principles (Manifesto)
o Satisfy customer
o Welcome changing requirements
o Deliver software frequently
o Business people and developers work together
o Build projects around motivated individuals
o Trust them to get the job done (don’t overcontrol)
o Face to face conversation
o Working software is the primary measure of progress
 o Sustainable development
o Constant pace
o Attention to technical excellence and good design
o Simplicity
o Self-organizing teams
o The team reflects (on how to become more effective)
 Development
o Waterfall (cascada, secuencial)
 Documentation, documents, unverified system, product only at the
end of the process
o Incremental delivery (iterative e incremental)
 Product since the beginning, increasing on each increment
 LAB: Coin flip the agile way

 SCRUM
o Took the name from American football, de la “piña”
o SCRUM is the agile way of working
 Scrum Framework
o 6 events (planning, review, retrospective, sprint, daily stand up, backlog
refinement)
o 3 roles (PO, squad, AC) (product owner, equipo y agile coac/scrum master)
o 3 artifacts (product backlog, sprint backlog, product increment)
o 3 social objects (burn down chart, impediments, scrum board)
o 2 increments (definition of ready, definition of done)
 Team members - DEV Team
o Every team member is responsible for the whole work to be done
o Self organizing
o Multi disciplinar
o Have the mandatory to organize the work themselves
o Ideal team 7 + o – memers
o Teams deserve to see the bigpicture and be involved in program planning
o * Focus on finishing, “The whole is greater than the sum of its parts”
o * Somehow there are no deadlines, but in fact there are but only on a high
level and not on the micro pieces
 Build cross-functional Agile Teams
o Teams able to define, build and test features or components
o Optimized for communication and delivery of value
o Deliver value every iteration
 Commitment to the Iteration Goals
o A team meets its commitments:
 By doing everything the said they would do
 OR
 In the event that this is not feasible, they must immediately raise a red
flag
o Adaptability
  Balanced with
 Commitment

[BREAK]

 Product Owner
o Has a vision
o Responsible for maximum value
o Represent the stakeholders
o Has mandate
o Is in Scrum Team
o Is responsible for management the backlog
o * Focus on the backlog
o * There can only be one
 Agile Coach / Scrum Master
o Makes sure the Way of working is understood (training/coaching)
o A servant-leader for the squad
o Protects the team
o Helps the team to become high-performance Team (self-organized)
o Creates transparency
o * Focus on the whole process, (sprint and daily stand up)
 Management 3.0
o True leaders are Servant Leader
 Motivating
 Enabling
 Supporting
 *Typical leadership structure: piramide -> control people
 vs
 *Servant leadership structure: piramide invertida -> empower people
o Role of a Leader / Manager so far:
 Pushing
 Requesting
 Controlling
o * We rise by lifting others
 Team events
 Product backlog
o A collection of requirements prioritized upside down in a list format
o Portfolio (Investment Themes -> Epics) -> Program/Project (Epics -> Team Epic
-> Bug/Task/Story) -> Team (Bug/Task/Story ->Sub-Task)
 User stories and Tasks
o A user story describes functionality that is valuable to a user or a customer
o It tells a story about how someone uses the product!!
o User stories are to facilitate a dialogue
o A story is not a specification but captures the essence of a conversation about
the features of a product
 o * every user storie should have an acceptance criteria
 Definition of Ready (DoR)
o DoR contains the criteria needed to make the Sprint successful
o The DoR is made byt the Team and the Product Owner (PO)
o The Team determines wheter the Product Backlog Items (Stories/Tasks) meet
the DoR
o The DoR is respected by the PO. This means a Product Backlog item can only
be pulled into the sprint when it meets the DoR
o * Story/Task DoR example: small enough, described, accepted, has value
 Once accepted, it gets a label for Ready to work/develop
o * DoR are some basic rules you don’t want to repeat on each sprint
o * ACC is usually in DoR, Acceptance Criteria
 [LAB] Crear un DoR list: lo que los developers le piden al PO para aceptar una
tarea/historia
 Backlog refinement sesión
o Regular (at least once per sprint) priorization and refinement of new work,
using the DoR
o The PO explains new items
o Items too complex are divided by the team
o Product Backlog items are shuffled to clarify them
o No refinement without a DoR
o It is also about knowledge sharing
o Stories will be estimated in size using Story Points
o Participants: PO & Team
 Story Estimation
o It’s impossible to predict in hours. But its ok a rough estimate.
o We are good estimating using sizes. We can use a Fibonacci series sequence
o 0, 1, 2, 3, 5, 8, 13, 20, 40, 100
o Skate board, Tricycle, Cycle, Scooter, Car, Bus, Truck, Train, Aeroplane, Space
Shuttle (100)
o Other methods: Planning Poker, Magic Estimation, Team Estimation Game…
tambien se puede añadir ½ o un comodin o un café… baraja de cartas Agile
o The team choose the limit to fit on a Sprint (5? 8?) take testing,
documentation and all other things into account
o Team include then developers, testers, documentators…
o Freedom to choose estimation

[BREAK]

 [VIDEO Backwards brain bicycle]

o Knowledge=/=understanding
o Once you have something on your mind takes a lot of time to change it. Keep
going and you’ll improve it, even if you do mistakes.
 JIRA
o Boards: vistas
  Scrum: backlog, sprints, issues, etc
 Kanban
o
 JIRA - IPE-2217 Kinder Sorpresa Epic
o Issues in EPIC: IPE-2230 Sorprise Eggs
 ACC: acceptance criteria
 Chocolate eaten
 Process understood
 Puzzle in the Eggs are build
 [LAB] Estimation session
o Lessons learnt:
 Work as a team and decide between all opinions
 Don’t compare two teams estimations
 The estimation is useful for future sprints

 Planning session
o The Team decides how many Product Backlog Items can be included in the
Sprint. The Product Owner determines the priority.
o The Sprint Backlog items are reshuffled and details are set out in tasks
o The Planning session ends with a prioritized and commited Sprint Backlog
 Part 1: Planning with the PO, choosing the stories for the Sprint
 Part 2: Defining the relevant Sub-tasks for each story to complete
 [LAB] Planning session + JIRA
o Start Sprint
o Viewable under active Sprint
 Issues To Do
 Issues In Progress
 Issues Done
o Charts
 Burdown chart: progression de las tareas del Sprint
 Daily Stand-UP
o Daily work coordination meeting attended by the entire team
o Active use of Scrum Board
o Identify new impediments
o Discuss status of impediments
o By the end of the Stand-Up the Squad will have a picture of the day
o * 3 key questions:
 What did you achieve yesterday?
 What will you achieve today?
 Is there and impediment/do you need help?
o Timebox: 15 minutes
o Participants: team (PO can go but not talk)
 Sprint Review / Demo
o The Team and the Product Owner hold a Demo of deliverables for the
stakeholders.
 o Stakeholder input (=feedback) is taken on board in subsequents Sprints
o This is a formal point of acceptance by the PO
o Participants: team, stakeholders, other interested parties
 * Many teams, 1 product: Scaled Agile, special frameworks for collaboration - > SAFe,
LeSS
 * One team, many products: depending on the stakeholders how to approach
 Definition of Done (DoD)
o DoD contains thecriteria needed to mark a User Story as Done
o The DoD is made by the PO (contraire to the DoR done by team)
o DoD describes the Acceptance Criteria
o A User Story can only be accepted by the PO during the review/demo
o For example:
 On a User Story Level
 The code is reviewed
 The component is tested on an automated unit
 Demo completed
 Acceptance Criteria met
 On a Sprint or Release Level
 Required user documentation
 No open defects
 Test cases documented
 Usability guidelines
 Demo completed
 Acceptance Criteria met
 [LAB] Definition of done
o Documentation, testing, support inclusion, guides, demo, uat, QA…

[BREAK]

 JIRA – Sprint Board

o Burndown Diagram / Chart for 37 story points on a 2 weeks sprint
o Perfect line vs story points closed
o Used to improve on a next Sprint
 What are our KPI’s?
o KPI Sprint X
o Happiness Index 12345
o Forecast 28,5 SP
o Velocity 23,5 SP
o Forecast Reliability 82,46% (% forecast to velocity)
o Product Improvement Ratio 78,73% (how many stories improved the
product, vs maintenance, preparing demo, meetings, tasks…)
 SP= Story Points
 And shall we start now???
o Define teams
o Create Jira Space
 o Start doing it!!!
o Improve
o Improve
o Improve
o * important that management changes their mind, no need to keep control
over everything, be part of the change
o * Start with yourself, be the change that the world need
o * Create a Culture Bubble
 Be a bubble inside the overall organization culture
 Have the mindset, the fun, the communication, the collaboration even
if is only inside you little bubble on the org.
 A leader is critical, compatible org. teams
 [VIDEO First Follower Leadership Lesson]
 The movement has to be public
 The first follower means is not an individual, but a team
 As more people joins is no longer risky
 Sprint Retrospestive
o 1.Set the stage
o 2.Gather Data
o 3.Generate Insights
o 4.Decide what to do
o 5.Close retrospective
o
o Address every area that surfaces as a constraint to the teams performance
o The Team look back on the previous Sprint
 The Team uses data and sentiment
o The retrospective is facilitated by the Agile Coach / Scrum Master (el master
lidera y comienza a explicar los problemas, no empieza pidiendo voluntaries
que nunca nadie dice nada)
o The retrospective results in specific improvement measures the next Sprint

o Preconditions
 Open atmosphere
 The willingness to improve
 Safe environment
o Participants
 Team
 SM/coach
 PO
o * Failing and Learning: Continuous Improvement

[LAB] Retrospective

 More
 Less
  Start
 Stop
 Continue

 The recurring topics of the session should be took apart, discussed and put onto
practice

*funretrospectives.com for some nice examples