Scrum

My Scrum Experience

what works for me might not work for you...

Questions

1. What is important to you?
2. Where do you feel the pain?
3. What is your goal?
4. What benefits do you hope Scrum will give you?

My Goal

Silver Bullet?

No! But a good methodology if you can plan at least 2 weeks ahead.

Your Context!

You know your context best. Try out and see what works best. Don't do something because it is written in a book. Do it because it works.

Do you want to see the pain?

Scrum is not for you if you are not interested in seeing and reducing the pain.

Will problems just disappear?

No! What can you do to solve the problems?

So many problems, so little time?

It might seem like you have only problems. But don't worry, after a couple of months and years, you will have resolved most of them. Focus and resolve one by one.

Predefined Scope and Launch Date

Thanks to your estimations and capacity, you know whether the goal is realistic.

In the rare case when it is not realistic, you can communicate and prioritize from the beginning.

But hey, we really need to deliver the whole scope at an impossible date!

Feel free to shoot yourself into the foot. Welcome technical debt, a lot of bugs, and an unmaintainable piece of software.

Properties: INVEST

• Independent
• Negotiable
• Valuable
• Estimable
• Sized appropriately
• Testable

Additionally:

• Motivational sentence
• Acceptance criterias
• Test cases

Reasonable Size?

Between 0.5 and 8 story points.

Acceptance Criterias

Easily understandable and verifiable definition of what needs to be done.

Record Time Spent

Data for better estimations. Do we have systematic errors?

Does it make sense to setup a project with Scrum?

Yes. Stories for the setup.

How to Integrate Marketing?

Marketing is defining requirements for our software. They write stories. They can be part of the reviews. They can be there to answer questions.

How to Integrate Concepters?

Same as marketing.

Who prepares and presents a Story?

• Business Engineer
• Concepter
• PO
• Developer

What to discuss?

Only what is relevant for the estimation itself. Leave out everything else.

How do we estimate?

Simple criterias.

• Simple/complicated service?
• How many input fields on the UI?
• How many open points?
• With which systems do we have to interact?

There are open questions - what now?

Define and document assumptions. Estimate based on those assumptions. Modify estimations if the assumption do not hold.

Estimation in Story Points or Hours?

Both. Stories in story points and tasks in hours during planning.

Creating Tasks

• Kickoff
• PO review
• Test review
• Complex tasks: pair programming
• Who has special knowledge?

Tasks: Electronically or Physically?

We started out electronically and switched to physical cards.

What is important?

• Only 3 questions answered!
• No discussions!
• At max 15 minutes!
• Timeout!

Be Strict

You are not here to make friends. Remind people about the rules.

Responsibility

Make sure that your team is self organizing and self responsible. Be very strict about this!

Who is on the team?

Difference between an average and an excellent software engineer is measured in factors.

Make sure to have the right people on the team!

Pair Programming Interviews!

Every candidate has to get through a 3 hour pair programming interview.

What Happens during a Pair Programming Interview?

1. Big picture view of one area of our code.
2. Task that requires both big picture view and algorithmic skills.
3. Candidate navigates and writes code.
4. Questions about implementation.

Goal: As much production ready code as possible.

Why do we do what we do?

• How easily does he understand the big picture?
• How fast does he solve a simple algorithmic problem in Java?
• TDD or tests?
• How does he approach the problem?
• How does he react when he gets stuck?
• Any philosophical discussions?
• How fast is he getting things done?
• ...?

Code Reviews

Before we check in code, we ask a friend to look at it with us.

Test Reviews

Before we demonstrate the functionality to the PO, we go through it with a friend.

Team Feedbacks

Periodically, we have team feedback sessions. Three minutes to give feedback to every single person in the team. Be honest! Provide constructive feedback.

Team Rules

Rules that are defined by the team.

Definition of Done

Define it! And live up to it.

Awkward! Uncomfortable!

Don't try to be friends with everybody! A team needs people that try to resolve the uncomfortable stuff! We call it "Wadenbeisser".

Meetings are Expensive!

Keep them short with the minimal number of people. Have a clear agenda and a protocol sent to all the participants. Be punctual!

Together

Have at least two people per story. Knowledge is automatically shared.

Scout Law

Continuously improve your environment.

Everybody!

Everybody has valuable input. Use techniques that ensure this!

Focus!

Focus on a very limited number of points.

Outcomes

Make sure you have concrete and verifiable outcomes. Make sure somebody is responsible.