1.
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

2.
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
Jens Wilke, LangFox, www.langfox.com

3.
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
Jens Wilke, LangFox, www.langfox.com

4.
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
Jens Wilke, LangFox, www.langfox.com

5.
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
Jens Wilke, LangFox, www.langfox.com

6.
•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
Jens Wilke, LangFox, www.langfox.com

7.
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
Jens Wilke, LangFox, www.langfox.com
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.
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!
Jens Wilke, LangFox, www.langfox.com

9.
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
Jens Wilke, LangFox, www.langfox.com

10.
•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
Jens Wilke, LangFox, www.langfox.com
Image: Leo Reynolds, Creative Commons
•Note, that the classic waterfall works better for certain types of projects

11.
11
Key differences to traditional ways
Jens Wilke, LangFox, www.langfox.com

12.
12
Key differences to traditional ways
Jens Wilke, LangFox, www.langfox.com

13.
13
Scrum Roles
Implementing the product
Jens Wilke, LangFox, www.langfox.com

14.
•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
Jens Wilke, LangFox, www.langfox.com
14
Because an organization is using scrum, doesn't mean it's Agile

15.
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
Jens Wilke, LangFox, www.langfox.com
15
Scrum Roles

16.
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
Jens Wilke, LangFox, www.langfox.com
•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

17.
Attributes of a good scrum master
•Responsible
•Humble
•Collaborative
•Committed
•Influential
•Knowledgeable
17
Scrum Master
Jens Wilke, LangFox, www.langfox.com

18.
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
Jens Wilke, LangFox, www.langfox.com
18
Scrum master and other roles

19.
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
Jens Wilke, LangFox, www.langfox.com
19
Product Owner
Image: Kristina Alexanderson, Creative Commons

20.
Attributes of a good Product Owner
•Available
•Business-Savvy
•Communicative
•Decisive
•Empowered
20
Product Owner
Jens Wilke, LangFox, www.langfox.com

21.
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
Jens Wilke, LangFox, www.langfox.com

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

23.
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
Jens Wilke, LangFox, www.langfox.com
Image: DG EMPL, Creative Commons

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

25.
•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
Jens Wilke, LangFox, www.langfox.com
Graph from: Succeeding with Agile, Mike Cohn

26.
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
Jens Wilke, LangFox, www.langfox.com

27.
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
Jens Wilke, LangFox, www.langfox.com

28.
28
Scrum artifacts
Artifact = something created by humans usually for a practical purpose
Jens Wilke, LangFox, www.langfox.com
Image: Wessex Archeology, Creative Commons

29.
•Product backlog
•Sprint backlog
•Sprint burndown
•Product burndown
29
Scrum Artifacts
Jens Wilke, LangFox, www.langfox.com

30.
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
Jens Wilke, LangFox, www.langfox.com

31.
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
Jens Wilke, LangFox, www.langfox.com
Graph from: Succeeding with Agile, Mike Cohn

32.
Should be actively managed
–Backlog grooming
32
Managing the product backlog
Jens Wilke, LangFox, www.langfox.com

33.
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
Jens Wilke, LangFox, www.langfox.com

34.
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
Jens Wilke, LangFox, www.langfox.com
34
Good product backlog

35.
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
Jens Wilke, LangFox, www.langfox.com

36.
36
Now we have defined scrum roles and the big plan
Jens Wilke, LangFox, www.langfox.com

37.
•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
Jens Wilke, LangFox, www.langfox.com

38.
Refine
38
From product backlog into Sprint Backlog - roughly
Sprint
Jens Wilke, LangFox, www.langfox.com

39.
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
Jens Wilke, LangFox, www.langfox.com

40.
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
Jens Wilke, LangFox, www.langfox.com
40
Sprint backlog should be granular
Image: Andrew Moreton, Creative Commons

41.
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
Jens Wilke, LangFox, www.langfox.com
41
Estimating the backlog sizes

42.
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
Jens Wilke, LangFox, www.langfox.com
42
Scrum board

43.
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
Jens Wilke, LangFox, www.langfox.com

44.
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
Jens Wilke, LangFox, www.langfox.com

45.
•Sprint planning
•Daily scrum
•(Backlog grooming)
•Sprint review
•Sprint retrospective
45
Scrum events
Jens Wilke, LangFox, www.langfox.com

46.
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
Jens Wilke, LangFox, www.langfox.com
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

47.
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
Jens Wilke, LangFox, www.langfox.com
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.

48.
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
Jens Wilke, LangFox, www.langfox.com
• 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

49.
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
Jens Wilke, LangFox, www.langfox.com

50.
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.
Jens Wilke, LangFox, www.langfox.com
50
Sprint Review

51.
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.
Jens Wilke, LangFox, www.langfox.com
51
Sprint review

52.
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
Jens Wilke, LangFox, www.langfox.com

53.
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
Jens Wilke, LangFox, www.langfox.com

54.
Q&A
Jens Wilke, LangFox, www.langfox.com
54