The Portal Builder Story: From Hell to Lean, from Zero to Cloud - part 2

proyecto:

From hell to lean, from zero to Scrum. Part II Pitfalls to avoid

Barcelona, 3 de Octubre de 2012

Christian Rodriguez

Certified Scrum Master [email protected]

Twitter: @guezian

proyecto:

Introduction

Objective

How scrum helped us?

How we need to improve?

Impediments Internal Quality

Personal and Individual Issues

Detecting Impediments

Story Points, estimation, value The problem

Wrong Estimation

More work found

Introduction

About me

8 years in the software industry

3 Years Scrum Master

This talk is for people who know scrum, and are applying

it or starting to apply it

I hope my experience helps you improve your process.

Context! Product Team of 6 people

Scrum Master / Architect

Introduction

Objective: Avoid pitfalls

Internal

Quality

Problems

Impediment:

Velocity

Pressure

Rushing

proyecto:

Introduction

How scrum Helped us? How we need to improve?

Introduction

How scrum helped us

Introduction

How scrum helped us

Steady-forward development rhythm

Almost no critical bugs found in production

Few interruptions

Reasonable achievable release plan

Potentially shippable product at the end of each sprint

Feedback on working software during sprint and sprint demo

Stable and robust releases

Introduction

How we (always) need to improve

We still need to improve

Release cycle: 3 Sprint + Stabilization (1-2 weeks)

Potentially shippable products (but not shippable)

Require a Release / Stabilization Phase

Need to use % of the sprint solving (non-critical) known Bugs

The overall velocity could be better

Introduction

How we (always) need to improve

proyecto:

Impediment:

Internal Quality

Impediments

Internal Quality

During late 2008 we started using Scrum

We adopted Scrum and the “Scrum miracle happen”

In a number of sprints:

order

progress

(reasonably) working software

But, as codebase grew…

Impediments

Internal Quality

Impediments

Internal Quality

Very slow progress

Constant Bugs IN production, sometimes very critical, causing Panic Mode and work in sprint abandoned

No release plan possible

Unable to measure progress, velocity

Application ultra slow performance

Application crashing

Team demotivation

User (and management) frustration

Impediments

Internal Quality

But why??? We where using scrum!!!

Impediments

Internal Quality

I entered the company as a Junior programmer in late 2007

Our codebase, was a mess, a REAL mess.

Immense up-front architecture

So strange, unintelligible

Only architecture, no features

The core was doomed, and so the rest of the system

Portal Builder DIED

Impediments

Internal Quality

Lack of internal quality is the worst impediment of them all

Lack of internal quality can cause Death, the destroyer of worlds

Impediments

Internal Quality

In January 2010 I was named Scrum Master

In August 2010 Portal Builder V2 started…

Impediments

Internal Quality

Portal Builder V2, now, has

More features

Integrated with Azure

Incomparable better performance

Incomparable better stability

Flexible design

No big up-front architecture. Microsoft NLayerApp

Everything can be improved at a reasonable cost

Impediments

Internal Quality

Warning! I’m not saying stop and throw all your code

We were in an extreme situation, “Scrum wasn’t enough”

Luckily you will be before the point of no return

The price of quality is eternal vigilance

You must be alert to symptoms of bad internal quality:

Bugs

Recurrent Bugs

Slow progress

Impediments

Internal Quality

You are not doing Scrum if you only do Scrum

Impediments

Internal Quality

Scrum is incomplete ON PURPOSE

The team is left to determine

Engineering practices

Or technical practices

Or development practices

Or VOODOO

Impediments

Internal Quality

TDD

Convince by example

Red-Green-Refactor

Design at the Refactor phase!

ATDD (BDD)

Webcasts

Group discussions

Coding Dojos

Buy books

Training

Pair Programming

Code Reviews

(both of them)

DDD

Hire!

Technical Stories

Impediments

Internal Quality

Not all of a large system will be well designed

Impediments

Internal Quality

“Not all of a large system will be well designed” – Eric Evans

Impediments

Internal Quality

High value

Feature Feature

Improvement

Feature Feature Feature

Modifications

Changes Adjustments

proyecto:

Impediment:

Individual or personal issues

Impediments


“Over-relaxing” “Releasing the gas pedal”

Acting as individuals not as team

Self-organization does not mean do whatever you want

In a “I don’t care” attitude:

“I don’t care if the sprint is good or bad I just come here do my work and don’t care about anything”

“I don’t care if someone else on the team already solved that problem I don’t want to ask I’ just rewrite this code again my way and that’s it”

“I don’t want to do test, it makes me think too much”

Impediments


Talk to the team to solve these issues

Talk to individual to solve these issues

If it cannot be solved

You must raise the issue with management

Maybe with human resources…

Hard decisions or recommendations must be made

proyecto:

Impediment:


Impediments


Impediments kill productivity

One of the most important things to do is to “detect” impediments.

Examples

Slow compile time

Slow CI Build (and automated) test time

No build visibility

The team does not see all this as an impediment

proyecto:

Points, estimation, value

The problem


The problem

At the end of a sprint “We are going slow”:

The Scrum Master must be the “referee”

Why are we “slow”?:

Impediments

Wrong estimations. Why?

Was there a mess under the hood?

Internal Quality

Need to improve your estimation

More work found

proyecto:


Improve your estimation



There are “normal” reasons why an estimation failed



You can improve your estimations

Perhaps during the planning meeting:

Not enough question asked

Backlog Items not split correctly

Backlog items not enough divided into tasks

Everyone wants to kill themselves!!!

The Team must LEARN from these mistakes

Product Owner pressure



“There’s no sense in being precise

when you don’t know what you’re

talking about”

-John von Neumann



Official Scrum guide 2011 changed the term “the team commits what will be developed” to “the team forecasts what will be developed”

That’s logic

How can you commit over an estimation !?!?!?

Force to commit will cause defects

Scrum Master must defend the team

Or negotiate with the Product Owner.

proyecto:


More work found


More work found

Consider this situation:

After finishing the most valuable stories, the team

discovers that they require more work, or discovers valuable improvements:

Perhaps the story is open

Or the product owner does not exactly know what he wants

This extra work is much more valuable than the rest of sprint items, its better aligned with the Sprint objective!

This “much more valuable” is agreed between the product owner and the development team


More work found

“Responding to change over following a plan”

“Scope may be clarified and re-negotiated between the product owner and the Development Team”

Fast feedback, collaboration, great Job!

Adapt the sprint!

But make it count on the velocity!


More work found

Re-estimation! (danger!)

Remember, story points are a tool to:

Estimate size, to compare with other stories

Estimate size and complexity, not amount of time!

Do not re-estimate only because it took longer


More work found

proyecto:

Thank you

Christian Rodriguez Certified Scrum Master

[email protected]

Twitter: @guezian

Barcelona: Pau Claris, 162-164 2ª Planta

Madrid: Avda. Doctor Arce, 14

Documents

The Portal Builder Story: From Hell to Lean, from Zero to Cloud - part 2