Agile: Implications and Complications

Joe Newton August 2011

Agile: Implications & Complications


Had the moth-to-candle moment with Agile in 2003

Worked @ ThoughtWorks in London, Sydney & Melbourne

Moved home to NZ end of 2006

D&I Manager @ Intergen in Auckland

Practice Principal @ Intergen

[email protected]

About Me


Business Team Responsibilities

Technical Team Discipline

Some common complications

Today



The Business Team


The Customer

Understands the domain well by working in that

domain and also understands how it

works

Can understand how software can provide

business value in the domain

Is determined to deliver value

regularly and is not afraid to

deliver too little rather than

nothing

Can make decisions about what’s needed now and

what’s needed later

Is willing to accept ultimate responsibility for the success or failure of

the project


The Technical Team




Story Board

Burn Down

Days to release

Team Photos

Team Leave

Project History

Retrospective Output

…

Big Visible Charts



Stand Up!


The Technical Team

YAGNI

KISS Fix broken windows

Own the estimates Uses the computer to do the repetitive work


There are a lot

It is rare for someone to know them all

Heavy reliance on experience of others

Crucial to keep learning

Design Patterns


Maintain a code repository Automate the build Make the build self-testing Everyone commits to the baseline every day Every commit (to baseline) should be built Keep the build fast Test in a clone of the production environment Make it easy to get the latest deliverables Everyone can see the results of the latest build Automate deployment

Continuous Integration


Deployments are a BIG deal (paperwork, teams involved, scheduling)

Team does not gel

Customer not available

Too much refactoring

Team not fast enough

Complications


Sort it out as the number one priority in week one – The whole point of a software project is to deploy software

Often paperwork can be mostly completed by template

Often other teams just need to know the schedule

If other parties need to sign-off spend time understanding what they are signing-off on

Deployments


Team does not gel


Understand where the speed expectation originates To understand speed implies knowledge of either:

The estimates; or

The capability of the team

The issue will ultimately be a question of trust Do you trust the team is doing its best? Do you trust the estimates?

There could be complexity There could be too much work You can try adding more people – but it probably wont work

Team not going fast enough


Refactoring != Redesign

It is an improvement to the code that preserves its behaviour

It is not changing HOW a feature works

It is not changing IF a feature exists

Too much refactoring


Stop – Seriously!

Consider changing approach

As last resort – schedule time per week for Q&A / Prioritisation

Customer not present


Business Team Responsibilities

Technical Team Discipline

Some common complications

Summary

For users and potential users of Microsoft Dynamics CRM, AX and NAV. Includes 15 sessions across three streams and presentations from

Microsoft APAC executives.

www.intergen.co.nz/dynamicsday

Questions

Thank You

Agile: Implications and Complications

Technology

implications complicationsteam

implications complicationstoo

team photos team

refactoring team

scheduling team

common complications

refactoring refactoring

software project