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

http://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

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

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


http://pascaldufour.wordpress.com/2012/07/15/agile-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


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


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


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


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.


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


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


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


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


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.


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.


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


Agile Scrum Training, Day 1 (1/2)

Software

Transcript of Agile Scrum Training, Day 1 (1/2)