Creating change from within

The Agile Developer storyByDror Helper

About.Me• Software Developer 9+ years

• Team’s technical lead

• TDD/Unit testing enthusiast

• Some SCRUM/Kanban background

• Blogger – http://blog.drorhelper.com

The problem with Agile

I don’t want to do this!

We don’t have time It would never work

in this project

So what can a single person do?

Let me tell you about the last year and

a half

The cast

Manager

Developer

Developer

Consultant Me

Team’s methodology• Unit tests – more or less

• Iteration tracking?

• Manual deploy builds – from developer’s PC

• Code reviews

My 1st week on the job

Let’s do TDD!

Analysis• Took two days to fix 40% of tests and make all of

the test run

• Find what are the main issues – and focus on themo Not readableo Using logic inside testo Testing too mucho Hand rolled mockso Scenarios hiding as unit testso Highly coupled code

Teach the team

And decide on next steps

CI server

Source Control

Build Server

There you go

What’s new?

Build Agents

Star

t wor

king

Build

artif

acts

Source Control

Commit

Immediate steps• Using MSTest• Write test before fixing bug• Fix existing tests when implementing new

features• Delete obsolete tests

Code reviews

Then came mocking• Hard to explain at the beginning• Instead show them!

o Free tools – low cost upfronto Commercial products

• Get rid of existing hand-rolled mocks

And excuses• “I didn’t have enough time so I didn’t write a

test”• Crisis mode• I cannot test it – so I won’t…• There’s no need to test everything • It’s much better to have one big test

• Remember not to be discouraged

Today• More than 3000 tests• Good code coverage• Most features are developed using TDD• CI server run all tests on commit

• Change code without fear

How to decide what to do?

Total cost of change

Cost of

Change

Participants

Effort (Time)

Cost (Money)

Previous investment

Emotional Value

Maintenance

The most difficult task

Replace existing tool or

methodology

Hard!

Your knowledge

Subject

domain

What you

know

Gap

Iteration tracking

In the beginning

Post-it + wall

Excel in shared folder

TFS + Work item manager

Tips and tricks

The power of code reviews

Effective Code reviews• Advise don’t force• Review the code not the person• It’s ok to discuss the good things as well

• You should get reviewed as well!• After a while team members can review each

other

Have the right attitude• Be positive• Don’t tell them what to so - suggest

improvements• Don’t force – convince• Be ready to change if proven wrong• Don’t be “that guy”

Communicate!• Email• Phone call• Face to face• Presentation• Coder reviews• Pair programming• Daily meetings

Create success record

Enlist Help Because You cannot do it all by yourself

Change is iterative• Hard to perform big changes overnight• Small incremental changes• Teach the team about the “boy scout rule”.

Be pragmatic!• Every action should have a purpose• If it doesn’t work – change it!• Names are not important – just what you do• Practices can be adapted for the team• Don’t be a strict task master

Know where to draw the line

Journey not a destination

Aftermath

Team growth opportunity/challenge

The end?• TDD & unit tests• CI server• Code reviews before commit• Automatic deployment• Task board and iterations• Better estimations• Faster time to deploy

Thank you