Post on 05-Dec-2014
description
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 crodriguez@softeng.es
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
Individual or personal issues
“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
Individual or personal issues
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:
Detecting Impediments
Impediments
Detecting 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
Points, estimation, value
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:
Points, estimation, value
Improve your estimation
Points, estimation, value
Improve your estimation
There are “normal” reasons why an estimation failed
Points, estimation, value
Improve your estimation
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
Points, estimation, value
Improve your estimation
“There’s no sense in being precise
when you don’t know what you’re
talking about”
-John von Neumann
Points, estimation, value
Improve your estimation
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:
Points, estimation, value
More work found
Points, estimation, value
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
Points, estimation, value
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!
Points, estimation, value
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
Points, estimation, value
More work found
proyecto:
Thank you
Christian Rodriguez Certified Scrum Master
crodriguez@softeng.es
Twitter: @guezian
Barcelona: Pau Claris, 162-164 2ª Planta
Madrid: Avda. Doctor Arce, 14