Scrum is not enough - being a successful agile engineer

Post on 22-Apr-2015

1.635 views 0 download

description

The recipe for developers to perform in agile software development environment is to use technical practices, many of which are coming from XP.

Transcript of Scrum is not enough - being a successful agile engineer

Anton Keksanton@codeborne.com

Scrum is not enough:being an Agile engineer

Agile Days Moscow, 4.03.2011

2

Anton KeksAnton KeksCo-founder of Co-founder of

Lecturer at Lecturer at Tallinn Technical UniversityTallinn Technical University

Member of the board of Member of the board of Agile EstoniaAgile Estonia●

Author of Author of Angry IP ScannerAngry IP Scanner

Strong believer inStrong believer inAgileAgile and and Open-sourceOpen-source

Iterative &Iterative &IncrementalIncrementalNOT Big-BangNOT Big-Bang

AdaptableAdaptableNOT PredictableNOT Predictable

TeamworkTeamworkNOT Lone RangerNOT Lone Ranger

TestingTestingNOT PrayingNOT Praying

SimplicitySimplicityMaximizing the amount of work not doneMaximizing the amount of work not done

Scrum

● Nowadays, Agile is more popular than Waterfall

● 84% of Agile organizations are doing Scrum

● Only 50% of them are doing iterations● Even fewer use developers' practices● “Flaccid Scrum”

?

The good stuff

Co-locationVerbal communication

Continuous improvementWorking increment of the

software!

But can But can code cowboyscode cowboysactually do this?actually do this?

Or even worse, Or even worse, bureaucratsbureaucrats??

Top-Down Adoption

Ken Schwaber left Scrum Allianceto work on the

Professional Scrum Developer program

Thinking

Guessing

Patching

Coding

WTF

Developers need tools to perform in an agile environment

practices = = di

scip

line

Mejores prácticas

● Simplicidad (No se va a necesitar)● Programación en pareja● Propiedad del código compartida● Pruebas unitarias● Desarrollo basado en pruebas● Pruebas de aceptación automáticas● Construyes y lanzamientos repetibles● Integración continua

Mejores prácticas

● Simplicidad (No se va a necesitar)● Programación en pareja● Propiedad del código compartida● Pruebas unitarias● Desarrollo basado en pruebas● Pruebas de aceptación automáticas● Construyes y lanzamientos repetibles● Integración continua

● Simplicity (YAGNI)● Pair programming● Collective code ownership● Unit tests● Test-driven development (TDD)● Automated acceptance tests● Repeatable builds & releases● Continuous integration

Best practices

Swedbank

● The major bank in Baltics and Scandinavia● Agile since 2005● Started with XP (bottom-up)● Voted the best Internet Bank in Europe

Productivity● Decent version control● Master your IDE● One-click builds● DRY – Don't repeat yourself● Script any repetitive tasks

Avoid hopeless meetings

Unit tests● Standardize!● Continuous integration● Keep them “unit”● Keep track of coverage %

● Never let it fall!

Measuring

You get what you measure

Vertical development● Every user story must be vertical

= independently add value

= potentially shippable● Strictly story-based development

Never add a button to the UI that does nothing yet!

The Truck FactorThe Truck Factor

● Avoid overspecializationAvoid overspecialization● Collective code ownershipCollective code ownership

● Coding standardsCoding standards● TEX* meetingsTEX* meetings

* TEX = Technology EXchange* TEX = Technology EXchange

Pair programmingPair programming

TDD - Ping pong – Concentration - QualityTDD - Ping pong – Concentration - Quality

27

Software Design vs Software Design vs ArchitectureArchitecture

● Software designSoftware design is the structure of code is the structure of code and relations between its elementsand relations between its elements

● Software architectureSoftware architecture is the same as is the same as software design, but used when people software design, but used when people want to make it look importantwant to make it look important(after Martin Fowler)(after Martin Fowler)– Architecture is the part of design that is Architecture is the part of design that is

difficult to change difficult to change – Therefore it is undesired :-)Therefore it is undesired :-)

28

Design vs ConstructionDesign vs Construction● In civil and mechanical engineeringIn civil and mechanical engineering

– Cost distribution Cost distribution ~ 10% / 90%~ 10% / 90%– Design: intelligently skilled, creative Design: intelligently skilled, creative

peoplepeople– Construction: manually skilledConstruction: manually skilled

● In softwareIn software– Code is the design, not UML, etcCode is the design, not UML, etc– Construction: compilation, builds, etc – Construction: compilation, builds, etc –

almost freealmost free

~ 100% / 0% distribution!~ 100% / 0% distribution!

Sustainable pace

Software Software CraftsmanshipCraftsmanship

http://manifesto .softw

a recraft smansh ip.org

Software Software Craftsmanship...Craftsmanship...

...the ...the CodeborneCodeborne way way

UNPROFESSIONAL

Heavyweight

Lightweight

Complex

Simple

The order of adoption● Coding standard● Unit tests● Continuous integration (+ bells and whistles)● Collective code ownership● Pair programming● TDD● Automated acceptance tests

Technical debtTechnical debtAnd don't forget paying theAnd don't forget paying the

The “easy” way

Hire the right people!

“hire for attitude, train for skills”

Anton Keks, anton@codeborne.com