Agile Scrum Training, Day 1 (1/2)

1
Agile Scrum Training, Day 1
Jens Wilke, LangFox, www.langfox.com 8 Dec 2014
Scrum: Team(s) working as a unit
Image: Harald Selke, Creative Commons
Jens Wilke, LangFox, www.langfox.com

Agile
•Focusing on Scrum
•Info on Kanban too
Goals
•Recapping the key principles
•Discussing best practices on organizing and doing work in real world
2
About this session
Image: Thomas Teubert, Creative Commons

Agenda/Backlog for day 1
–10:00 Intro
–Agile and Lean
–Scrum
–Team and roles
–Who is not in the team
–Product and Sprint Backlog
–Sprint Cycle
–Events
–Definition of done
–Tools: Project documentation, Recalibrating speed
–Kanban
–Selecting between Scrum and Kanban
–Materials for further study
3
Day 1 – Agile and scrum in theory and practice Day 1 emphasis is on theory

See the walls, and the sticky notes on them
–They define the agenda for today’s training
–Intro, Agile, Lean, …
Anything missing regarding this training session
–Add the missing items to the backlog, as we‘re agile
–Breaks … whatever. add them to the product backlog and we’ll prioritize them together
4
Session backlog = todos

5
Agile and Lean are not exactly defined, but are rather principles and practices
Agile focuses on well organized process which allows frequent delivery which makes it easy to adjust the course of development.
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
…”
Lean focuses more on limiting waste (including work in progress which is considered as one of types of waste) and making production and delivery workflow efficient. (ref. Toyota)
1.Eliminate waste
2.Amplify learning
3.Decide as late as possible
4.Deliver as fast as possible
5.Empower the team
6.Build integrity in
7.See the whole
Scrum and Kanban are Agile/Lean methodologies

•Scrum
•Kanban
•Methodologies can be characterized according to how prescriptive they are
•The methodology matters more than the tools used to implement it
6
About Agile SW Methodologies = Tools

Scrum elements: ~9
3 roles
–Product owner
–Scrum master
–Team
2 artifacts (+2)
–Product backlog
–Sprint backlog
–Sprint burndown
–Product burndown
4 activities (+1)
–Sprint planning
–Backlog grooming
–Daily scrum
–Sprint review
–Sprint retrospective
7
Details on methodology elements
Kanban practices: ~6
1.Limit WIP
2.Visualize the workflow
3.Manage flow
4.Make Process Policies Explicit
5.Implement feedback loops
6.Improve Collaboratively

8
Example: renovation
After you make the spec, it should be pretty clear what and how it should be done, right?
Unfortunately not - real world is way more complex and there are always surprises. In order to get good results, faster and with less cost, regular feedback and guidance helps.
Task: Fix this
Result: Nailed it!

The next step is to give the free hand not to the person against you but an other one.
check that all people are connected in one circle (otherwise you and up with two circles)
below you see an example
Goal: The requested end situation is a circle of people holding hands.
The game: Start by giving the manager the instruction to solve this complex problem, the knot. He is only allowed giving instruction by voice. Start the timer. The manager will give instruction. If the manager has not solve the problem after 5 minutes you can stop. Start again in the same position but this time let the team solve the problem. You will see that the team solved this problem more than 10 times faster is my experience.
9
Example: Scrum Spaghetti Game

•Higher productivity and lower costs
•Improved employee engagement and job satisfaction
•Faster time to market
•Higher quality
•Improved stakeholder satisfaction
•What we’ve been doing no longer works
10
Why Agile
Image: Leo Reynolds, Creative Commons
•Note, that the classic waterfall works better for certain types of projects

11
Key differences to traditional ways

12
Key differences to traditional ways

13
Scrum Roles
Implementing the product

•Whether an organization is Agile or not depends on its culture.
•Does the culture support the personal values of the manifesto?
•If so, it's Agile, if not, then it's doing something else.
•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
14
Because an organization is using scrum, doesn't mean it's Agile

Product Owner (WHAT)
•Voice of the customer, customer facing
Scrum Master (HOW)
•Handles the process, more team facing
Development Team
•Scrum Teams are cross-functional, i.e. development, testing, analyst, designer, …
There is no single point of contact, but communication should flow freely through the team
•In practice product owner is mostly communicating with the scrum master, but product owner should be available to the whole team
•Split between Product Owner and Scrum Master roles often varies
15
Scrum Roles

The Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules. The Scrum Master is a servant-leader for the Scrum Team.
16
Scrum Master
•Help team in it’s use of scrum
–Facilitates scrum events, i.e. running the daily show
•Remove impediments
–So that the team can effectively execute
•Facilitates communication
•Has no authority over the team members
•Has authority over the process
•Provides guidance, not answers

Attributes of a good scrum master
•Responsible
•Humble
•Collaborative
•Committed
•Influential
•Knowledgeable
17
Scrum Master

Scrum Master …
Can be a developer
–Pretty usual approach with smaller teams
Shouldn’t be the lead developer
–Has a tendency to disrupt the self-organization
Shouldn’t be the product owner
–These roles have generally too different agendas and possibly conflicting interests
Should be internal
18
Scrum master and other roles

Provides a vision
Responsible for the product backlog
–Backlog defines what gets done
–Does not need to write all the stories
Provides boundaries
–Schedule, Performance, …
–Goals should be reachable
Each team needs exactly one
19
Product Owner
Image: Kristina Alexanderson, Creative Commons

Attributes of a good Product Owner
•Available
•Business-Savvy
•Communicative
•Decisive
•Empowered
20
Product Owner

Sometimes more persons are needed to manage product
Sometimes the sponsor or some other stakeholder wields big power
In any case, there should be only ONE product owners from the teams point of view
–There can be lot of heavy discussion in the product owner team, but this shouldn’t concern the team
21
A product owner team or a proxy product owner

A team’s time demands on their Product Owner and Scrum Master move in different directions.
22
Team need of Scrum Master and Product Owner
Graph from: Succeeding with Agile, Mike Cohn

A collection of individuals working together to deliver the requested and committed product increments.
Working together
•Succeeding together
•Failing together
Responsible together
•Follow a common goal
•Adhere to the same norms and rules
•Show respect to each other
•Be collaborative
23
Scrum team
Image: DG EMPL, Creative Commons

There’s no specific limitations on the roles. Team members can be developers, testers, business analysts, designers, architects etc.
24
Scrum team roles

•Fewer than three Development Team members decreases interaction and results in smaller productivity gains. Smaller Development Teams may encounter skill constraints during the Sprint, causing the Development Team to be unable to deliver a potentially releasable Increment.
•Big team size causes communication overhead (ref. Mythical Man Month)
25
Scrum team size optimum: 3 - 9

Those who can not commit
–Allocating a certain amount of time for doing the sprint backlog tasks
Possible examples
–Architect looking at multiple projects
–Designer serving multiple customers
26
Who is not in the scrum team

Scrum Master ≠ Project Manager
Product Owner ≠ Product Manager
Traditionally project manager was planning, what the team is doing
Product manager was talking with the customers and doing the requirements
Above tasks are now split between the roles in a different way. Few examples
•Scope management -> Product Owner
•Process -> Scrum Master
•Organizing work -> Team members select the tasks
•Backlog grooming -> Product owner, Scrum Master, Team
•Communication flows between Product owner, Scrum Master, Team
27
Side note: How do these relate to traditional project manager and manager

28
Scrum artifacts
Artifact = something created by humans usually for a practical purpose
Image: Wessex Archeology, Creative Commons

•Product backlog
•Sprint backlog
•Sprint burndown
•Product burndown
29
Scrum Artifacts

List of desired product functionality
Maintained by product owner
–Can be also somebody else, but product owner is responsible
Prioritized by product owner
Usually the items in product backlog are user stories, e.g.
–As a <type of user>, I want <some goal> so that <some reason>
In end effect roughly: A prioritzied feature list
30
Product Backlog

Next items should be clear and on top of the product backog
Next items should be small enough for sprint planning
Later items can be more hazy and big (Epics)
31
Product Backlog characteristics

Should be actively managed
–Backlog grooming
32
Managing the product backlog

The items on top will get implemented next
The long tail is for documenting the ideas
–Most of it never gets implemented
33
Product backlog can have tons of stuff

Human readable
•You can use Epics for higher abstraction
Accessible for anybody with interest
•Publish it on the wall
•Input will help to improve
The Product Owner may do the above work, or have the Team do it. However, the Product Owner remains accountable.
Roadmap can be considered a digest of a Product Backlog
34
Good product backlog

Few options
If there’s flexibility on time
•You can define release by content
If there’s no flexibility on time
•Must have content must be in the release
•You can use important ”nice to have” features as buffer
•Drop these, if things get tight
35
Release plan and product backlog
Alpha release

36
Now we have defined scrum roles and the big plan

•The scrum development runs repeating cycles called sprints
•Scrum master (with the team and product owner) define the sprint length
–Usually between 1-4 weeks
–Most commonly 2 weeks
•The sprint backlog is generally the top most items from the product backlog, that can be done during the sprint duration
•At the end of the sprint backlog should be ideally implemented, and there should be a new potentially shippable software increment
37
Sprints and Sprint Backlog

Refine
38
From product backlog into Sprint Backlog - roughly
Sprint

39
Each sprint should deliver functional software
Working software encourages feedback
Working software helps a team gauge its progress
Working software allows the product to ship early if desired

According to the Scrum Guide, one (1) day is the largest a task duration.
•Anyway, much smaller than typically in the product backlog
Smaller items
•Better predictability on outcome
•Better visibility on progress
•When breaking down, the task has been already pre- processed
40
Sprint backlog should be granular
Image: Andrew Moreton, Creative Commons

General advice is to estimate the sizes of the sprint backlog items, so that you can estimate what gets done during the sprint
•Some prefer not to, but use something else, e.g. number of tasks.
General advice is to use fake time units for estimation, so that you can calibrate your velocity/estimates in the future sprints
•Some prefere plain hours
For estimation, you can use different measures
•Natural numbers
•Fibonacci numbers
•T-Shirts sizes
You might want to use different sizing schemes for product backlog and sprint backlog
41
Estimating the backlog sizes

Make your work visible for yourselves and everybody with interest
Each scrum backlog item has a status, and you see items moving to completion
All modern tools like VersionOne, Rally and Jira (with Greenhopper) have these
42
Scrum board

See how your sprint is progressing
Tools like VersionOne and Rally provide these automatically
Use this to re-calibrate your efforts in the future sprints
43
Sprint backlog burndown chart

See how your Product is progressing
Tools like Scrumworks and JIRA/Greenhopper provide these automatically
With product backlog there is many more unknows than with the short well planned sprints
–Thus preparing for emergent stories is advised
44
Product backlog burndown chart

•Sprint planning
•Daily scrum
•(Backlog grooming)
•Sprint review
•Sprint retrospective
45
Scrum events

The Sprint Planning Meeting is time-boxed. According to guide, 8 hours for a one- month Sprint. 2 week Sprints have four- hour Sprint Planning Meetings.
46
Sprint Planning Meeting
Part One: What will be done this Sprint?
–Product owner, Scrum Master, Team
–Create sprint backlog
–Define sprint goal
Part Two: How will the chosen work get done?
–Team understand how they get the things done
–Product Owner may be present, but is not needed
–Recalibration of part 1 may follow with product owner

The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created. Sprints have consistent durations throughout a development effort. A new Sprint starts immediately after the conclusion of the previous Sprint.
47
The Sprint after the planning by the book
Often modified
During the Sprint:
• No changes are made that would affect the Sprint Goal;
• Development Team composition and quality goals remain constant
• Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.

The Daily Scrum meeting is a 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours.
48
Daily Scrum
• What has been accomplished since the last meeting?
• What will be done before the next meeting?
• What obstacles are in the way?
Not a status meeting
Idea of standing is not to get too comfortable
The Scrum Master ensures that the Development Team has the meeting, but the Development Team is responsible for conducting the Daily Scrum.
Image: Improve It, Creative Commons

Product backlog grooming is the act of adding detail, estimates, and order to items in the
Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate
–Product backlog should be well groomed prior to the Sprint Planning
During Product Backlog grooming, items are reviewed and revised.
–However, they can be updated at any time by the Product Owner or at the Product Owner’s discretion.
Grooming is a part-time activity during a Sprint between the Product Owner and the Development Team. Often the Development Team has the domain knowledge to perform grooming itself.
Grooming usually consumes no more than 10% of the capacity of the Development Team.
The Development Team is responsible for all estimates. The Product Owner may influence the Team by helping understand and select trade-offs, but the people who will perform the work make the final estimate.
49
Backlog grooming

Demo
–The Development Team demonstrates the work that it has “Done” and answers questions about the Increment
The Product Owner identifies what has been “Done” and what has not been “Done”
–Often facilitated by the scrum master
The Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved
As book example, two week Sprints have two-hour Sprint Reviews.
50
Sprint Review

Items should have a clearly defined definition of done at the beginning of sprint
–Task will become more clear
–It’s easier to say, if task got done
Undone items are moved to the product backlog or directly to the next sprint backlog
Recalibrating the velocity, i.e. how the story points correlate to the actual hours
–Idea is to get better with estimation
The Product Owner discusses the Product Backlog as it stands. He or she projects likely completion dates based on progress to date
The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning Meetings.
51
Sprint review

The Scrum Master encourages the Scrum Team to improve, within the Scrum process framework,
• Inspect how the last Sprint went with regards to people, relationships, process, and tools
• Identify and order the major items that went well and potential improvements
• Create a plan for implementing improvements to the way the Scrum Team does its work
52
Sprint Retrospective

To be shared
–Scrum guide
–Scrum vs. Kanban
Selected books (good for CSP = Certified Scrum Professional)
1.Succeeding with Agile: Software Development Using Scrum - Must read for CSP
2.Agile Estimating and Planning - Must read for CSP
3.Agile Software Development with Scrum - Must read for CSP
4.Agile Product Management with Scrum
5.Agile Retrospectives
6.Refactoring: Improving the Design of Existing Code
7.Test Driven Development By Example
8.Agile Retrospectives
53
Materials

Q&A
54

Agile Scrum Training, Day 1 (1/2)

More Related Content

What's hot

Viewers also liked

Similar to Agile Scrum Training, Day 1 (1/2)

Recently uploaded

Agile Scrum Training, Day 1 (1/2)

Editor's Notes